Security & AI Bảo Mật & AI · · 10 min read

Inside Cloudflare's Security Audit Skill: Turning Coding Agents into Adversarial Vulnerability Hunters Khám Phá Security Audit Skill Của Cloudflare: Biến Tác Tử AI Thành Thợ Săn Lỗ Hổng Bảo Mật Khách Quan

A technical architectural teardown of Cloudflare's open-source security-audit-skill—examining isolated multi-phase hunting, coverage ledgers, adversarial disproving, and deterministic verification. Phân tích kiến trúc kỹ thuật của security-audit-skill từ Cloudflare—mổ xẻ quy trình kiểm thử 6 pha độc lập, sổ cái bao phủ, phản biện loại bỏ phát hiện giả và xác thực bất biến.

Written by Nguyen Cong Ben Nguyễn Công Ben
Cloudflare Security Audit Skill Architecture Diagram

1. 🛡️ The Illusion of Static Code Auditing with LLMs

When developers prompt traditional LLMs with “Audit this repository for security vulnerabilities,” the result is almost universally disappointing: a barrage of generic checklist items, false positives regarding missing rate-limits on internal functions, and hallucinations of buffer overflows in garbage-collected runtimes.

The root cause is structural: single-pass prompting lacks adversarial pressure, state isolation, and deterministic verification.

flowchart LR
    subgraph Naive ["Naive Agent Prompting"]
        Prompt["Prompt: 'Audit my code'"] --> LLM["Single LLM Context"]
        LLM --> Noise["50+ False Positives & Hallucinations"]
    end

    subgraph Harness ["Cloudflare Security Audit Skill"]
        Repo["Target Repo"] --> Recon["Phase 1: Recon & Coverage Ledger"]
        Recon --> Hunters["Phase 2: Isolated Ledger Hunters"]
        Hunters --> Disprover["Phase 3: Adversarial Disproving"]
        Disprover --> Validator["Phase 4 & 5: Schema & Independent Verifiers"]
        Validator --> ZeroNoise["Zero-Noise Verified Findings"]
    end

To solve this at enterprise scale, Cloudflare developed and open-sourced security-audit-skill (cloudflare/security-audit-skill), the foundational engine seeding Cloudflare’s internal automated vulnerability discovery harness. Rather than treating an LLM as an oracle, the skill transforms autonomous coding agents into a rigorous 6-phase vulnerability laboratory.


2. 🏗️ The 6-Phase Defensive Architecture

The harness coordinates autonomous agents across six strictly decoupled phases, maintaining strict write isolation and deterministic validation checks between each step:

flowchart TD
    P1["Phase 1: Reconnaissance\n• Map trust boundaries & input surfaces\n• Initialize coverage-ledger.json\n• Deterministic schema check"] --> P2["Phase 2: Coverage-Led Hunting\n• Spawn isolated subagents per ledger unit\n• Domain-specific attack classes\n• Coverage critics identify unvisited paths"]
    P2 --> P3["Phase 3: Candidate Validation\n• Adversarial rule: Hunting agent != Verifier\n• Verifier actively attempts to disprove lead\n• Sandboxed reproduction with low quotas"]
    P3 --> P4["Phase 4: Structured Output\n• Output to findings.json (confirmed / needs_validation / rejected)\n• Strict zero-dependency validation via report-schema.json"]
    P4 --> P5["Phase 5: Independent Record Verification\n• Fresh unpolluted agents verify source line claims\n• Replaced records receive secondary independent check"]
    P5 --> P6["Phase 6: Target-Neutral Reporting\n• Generate REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md\n• Derive metrics from coverage ledger"]

Phase Breakdown

PhaseCore ObjectiveKey Artifacts & Gates
1. ReconnaissanceMap trust boundaries, input ingress points, and unauthenticated routes.architecture.md, coverage-ledger.json (Validated by validate-coverage-ledger.cjs).
2. Coverage HuntingDeploy isolated hunters against bounded units with specialized attack vectors.Units mapped across 10 attack classes (e.g. Memory, Web Auth, AI/LLM, Supply Chain).
3. Candidate ValidationActively attempt to falsify and disprove candidates using independent verifiers.Strict separation: the agent that flagged the issue is forbidden from validating it.
4. Structured OutputNormalize findings into three deterministic states: confirmed, needs_validation, rejected.findings.json validated against report-schema.json via validate-findings.cjs.
5. Independent VerificationFinal pass with fresh agents verifying source claims, line numbers, and impact proofs.Material diffs trigger re-verification by an unpolluted model instance.
6. Target-Neutral ReportingSynthesize human-readable executive and developer reports without vendor bias.REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md.

3. 🔒 Core Architectural Disciplines

What separates Cloudflare’s harness from conventional security linters is its adherence to four foundational operational constraints:

1. The Adversarial Verification Axiom

“The agent that checks a finding is never the agent that found it.”

When an agent discovers a potential vulnerability, human cognitive bias causes it to defend its hypothesis. Cloudflare breaks this by instantiating a fresh, unpolluted verifier sub-agent whose explicit objective is to disprove the lead by discovering mitigating defenses, sanitizers, or caller-side constraints.

2. Strict Tri-State Classification

Traditional tools overwhelm teams with “Medium/Low” alerts. Cloudflare’s schema enforces three uncompromising states:

  • confirmed: Must feature a full, unbroken trace from untrusted input to sensitive sink, accompanied by an observed boundary violation.
  • needs_validation: Pinned to an exact, unverified factual question (e.g., “Cannot verify if reverse proxy strips the X-Forwarded-For header”), stripped of arbitrary severity scores.
  • rejected: Explicitly catalogs disproved candidates to prevent repetitive hunting in subsequent audit runs.
{
  "finding_id": "FINDING-001",
  "verdict": "confirmed",
  "title": "Unauthenticated SSRF via Webhook Registration URL",
  "affected_component": "src/services/webhook.ts:42",
  "severity": "high",
  "source_trace": [
    "src/controllers/api.ts:88 (Public POST /webhooks)",
    "src/services/webhook.ts:42 (Unvalidated fetch to user URL)"
  ],
  "remediation": "Validate target URL against private RFC1918 CIDR blocks before socket connection."
}

3. Sandboxed Reproduction with Bounded Scratch Paths

Security scanners must never introduce secondary vulnerabilities. Any build script, test runner, parser, or fixture execution must run in an OS-enforced jail:

  • Network Disabled: Isolated loopback only.
  • Path Isolation: Target source is mounted read-only. Process writes are restricted exclusively to an assigned scratch/ directory.
  • Resource Clamping: Strict CPU, memory, and runtime wall-clock limits prevent denial-of-service against the host machine.

4. 🧠 Domain-Specific Attack Modules

Cloudflare modularized their attack knowledge into distinct specialized markdown matrices:

skills/security-audit/
├── AI-AND-LLM.md                        # Prompt injection, tool-call hijacking, context leakage
├── CLOUD-AND-DEPLOYMENT.md              # IAM misconfigurations, SSRF, ingress policy bypass
├── CLIENT-SIDE.md                       # DOM clobbering, prototype pollution, cross-origin messaging
├── DATA-ISOLATION-AND-LIFECYCLE.md      # Tenant leakage, cache poisoning, soft-delete bypass
├── DESKTOP-MOBILE-AND-LOCAL-IPC.md      # Deep-links, webview bridges, IPC socket hijack
├── MEMORY-SAFETY-AND-BINARY.md          # Bounds checking, unsafe FFI, use-after-free
├── PROTOCOLS-RPC-AND-MESSAGING.md       # Protobuf/gRPC deserialization, broker poisoning
├── RESOURCE-EXHAUSTION-AND-AVAILABILITY.md # ReDoS, zip bombs, unindexed query amplification
├── SUPPLY-CHAIN-AND-RELEASE.md          # Malicious dependencies, CI runner tampering, typosquatting
└── WEB-PROTOCOL-AND-AUTH.md             # HTTP request smuggling, OAuth state bypass, CORS flaws

By decoupling attack classes into isolated references, an agent auditing an Astro web application only ingests CLIENT-SIDE.md and WEB-PROTOCOL-AND-AUTH.md, keeping its reasoning budget focused and context tokens unpolluted.


5. 💡 Key Takeaways for AI-Assisted Engineering

  1. Iterative Runs Compound Value: Cloudflare’s empirical benchmarking revealed that a single LLM pass discovers less than 50% of identifiable vulnerabilities. Additive runs leveraging persistent coverage-ledger.json records discover nearly double the defect volume.
  2. Defense-in-Depth Is Not a Finding: If Layer A (e.g., an API gateway firewall) demonstrably halts an exploit, the absence of validation in Layer B is categorized as a hardening advisory, not an exploitable vulnerability.
  3. Deterministic Scripts Anchor Agent Trajectories: Rather than relying on LLM self-evaluation, Cloudflare enforces pure Node.js validator scripts (validate-coverage-ledger.cjs and validate-findings.cjs). If a JSON record fails schema validation, the agent is halted before reports can be generated.

1. 🛡️ Ảo Tưởng Về Việc Dùng LLM Để Rà Soát Mã Nguồn Bảo Mật

Khi kỹ sư nhắc lệnh một AI thông thường: “Hãy rà soát bảo mật repository này giúp tôi,” kết quả trả về thường gây thất vọng: một danh sách dài các lời khuyên chung chung, báo động giả về việc thiếu rate-limit trên các hàm nội bộ, hoặc tưởng tượng ra lỗi tràn bộ đệm (buffer overflow) ngay trong các ngôn ngữ có bộ thu gom rác tự động.

Nguyên nhân cốt lõi mang tính cấu trúc: prompting một lượt (single-pass) thiếu áp lực phản biện, thiếu cô lập trạng thái và không có cơ chế xác minh tất định (deterministic verification).

flowchart LR
    subgraph ThuCong ["Prompting Thông Thường"]
        Prompt["Prompt: 'Audit code này'"] --> LLM["1 Phiên LLM Duy Nhất"]
        LLM --> Noise["50+ Báo Động Giả & Ảo Giác"]
    end

    subgraph CloudflareSkill ["Cloudflare Security Audit Skill"]
        Repo["Mã Nguồn Cần Khảo Sát"] --> Recon["Pha 1: Trinh Sát & Sổ Cái Bao Phủ"]
        Recon --> Hunters["Pha 2: Thợ Săn Độc Lập Theo Phân Khu"]
        Hunters --> Disprover["Pha 3: Tác Tử Phản Biện Bác Bỏ"]
        Disprover --> Validator["Pha 4 & 5: Kiểm Định Schema & Xác Minh Độc Lập"]
        Validator --> ZeroNoise["Báo Cáo Xác Thực Không Nhiễu"]
    end

Để giải quyết triệt để bài toán này trên quy mô lớn, Cloudflare đã phát triển và mở mã nguồn dự án security-audit-skill (cloudflare/security-audit-skill)—hạt nhân cốt lõi định hình hệ thống dò quét lỗ hổng tự động nội bộ của hãng. Thay vì coi LLM như một nhà tiên tri biết tuốt, công cụ này biến các tác tử AI thành một phòng lab kiểm thử bảo mật 6 giai đoạn nghiêm ngặt.


2. 🏗️ Kiến Trúc Phòng Thủ 6 Giai Đoạn

Hệ thống điều phối các tác tử hoàn toàn tách biệt qua 6 pha làm việc, đảm bảo tính cô lập khi ghi file và kiểm định tất định giữa mỗi bước:

flowchart TD
    P1["Pha 1: Trinh Sát (Reconnaissance)\n• Lập bản đồ ranh giới tin cậy & bề mặt tấn công\n• Khởi tạo coverage-ledger.json\n• Kiểm tra schema bằng script"] --> P2["Pha 2: Săn Tìm Theo Sổ Cái (Hunting)\n• Khởi tạo sub-agent độc lập cho từng module\n• Áp dụng attack classes chuyên biệt\n• Critic giám sát các nhánh code bị bỏ sót"]
    P2 --> P3["Pha 3: Phản Biện Bác Bỏ (Validation)\n• Nguyên tắc: Agent tìm ra KHÔNG được tự duyệt\n• Verifier tìm mọi cách phản biện, phủ định giả thuyết\n• Tái lập trong Sandbox giới hạn tài nguyên"]
    P3 --> P4["Pha 4: Chuẩn Hóa Dữ Liệu (Structured Output)\n• Phân loại vào findings.json (confirmed / needs_validation / rejected)\n• Kiểm tra tính hợp lệ bằng report-schema.json"]
    P4 --> P5["Pha 5: Xác Minh Hồ Sơ Độc Lập (Verification)\n• Tác tử hoàn toàn mới xác minh lại từng dòng code\n• Thay đổi nội dung buộc phải qua Verifier thứ hai"]
    P5 --> P6["Pha 6: Xuất Báo Cáo Khách Quan (Reporting)\n• Tạo REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md\n• Trích xuất chỉ số từ sổ cái bao phủ"]

Chi Tiết Từng Pha

Giai ĐoạnMục Tiêu ChínhHiện Vật & Chốt Chặn Kỹ Thuật
1. Trinh sát (Reconnaissance)Lập sơ đồ ranh giới bảo mật, cổng nhận dữ liệu không xác thực.architecture.md, coverage-ledger.json (Xác thực bởi validate-coverage-ledger.cjs).
2. Săn tìm (Coverage Hunting)Phân bổ thợ săn vào từng đơn vị code với các kịch bản tấn công chuyên biệt.Phân nhóm 10 attack classes (Bộ nhớ, Web Auth, AI/LLM, Chuỗi cung ứng, v.v.).
3. Phản biện bác bỏ (Candidate Validation)Tìm mọi chứng cứ để phủ định các nghi vấn lỗ hổng thông qua tác tử độc lập.Nguyên tắc thép: Tác tử phát hiện không bao giờ được tự thẩm định ứng viên của mình.
4. Chuẩn hóa kết quả (Structured Output)Đưa kết quả vào 3 trạng thái bất biến: confirmed, needs_validation, rejected.findings.json bắt buộc tuân theo report-schema.json qua validate-findings.cjs.
5. Xác minh độc lập (Record Verification)Tác tử với ngữ cảnh sạch kiểm tra lại vị trí dòng code, bằng chứng và tác động thực tế.Mọi sửa đổi bản chất đều kích hoạt lượt kiểm tra độc lập bổ sung.
6. Báo cáo khách quan (Reporting)Tổng hợp báo cáo kỹ thuật và báo cáo quản trị không mang tính thiên vị.REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md.

3. 🔒 3 Quy Chuẩn Hoạt Động Cốt Tử Của Cloudflare

Điểm khác biệt giúp bộ công cụ của Cloudflare vượt trội so với các linter thông thường nằm ở 3 nguyên tắc bất di bất dịch:

1. Tiên Đề Phản Biện Đối Kháng (Adversarial Verification)

“Tác tử thẩm định một phát hiện không bao giờ là tác tử đã tìm ra nó.”

Khi một mô hình AI tìm ra một nghi vấn, nó có xu hướng bảo vệ kết luận ban đầu. Cloudflare phá bỏ điều này bằng cách tạo ra một sub-agent thẩm định hoàn toàn mới với nhiệm vụ duy nhất: chứng minh ứng viên đó là sai bằng cách tìm các bộ lọc, lớp bảo vệ upstream hoặc các ràng buộc nghiệp vụ ngăn chặn đường đi của payload.

2. Phân Định 3 Trạng Thái Nghiêm Ngặt

Thay vì gắn nhãn “Medium/Low” gây rối loạn cho đội ngũ kỹ sư, schema của Cloudflare chỉ chấp nhận 3 kết luận rõ ràng:

  • confirmed: Phải có một chuỗi truy vết liên tục từ đầu vào chưa kiểm duyệt tới hàm đích nguy hiểm, kèm theo vi phạm ranh giới bảo mật thực tế được ghi nhận.
  • needs_validation: Đi kèm với một câu hỏi thực tế chưa thể xác minh (ví dụ: “Không thể xác định liệu reverse proxy có loại bỏ header X-Forwarded-For hay không”), tuyệt đối không gán độ nghiêm trọng tùy tiện.
  • rejected: Ghi nhận các giả thuyết đã bị bác bỏ để các lần quét sau không tốn thời gian lặp lại.
{
  "finding_id": "FINDING-001",
  "verdict": "confirmed",
  "title": "Lỗ Hổng SSRF Chưa Xác Thực Qua URL Đăng Ký Webhook",
  "affected_component": "src/services/webhook.ts:42",
  "severity": "high",
  "source_trace": [
    "src/controllers/api.ts:88 (Public POST /webhooks)",
    "src/services/webhook.ts:42 (Gọi fetch trực tiếp tới URL người dùng)"
  ],
  "remediation": "Kiểm tra và chặn các dải địa chỉ IP nội bộ RFC1918 trước khi khởi tạo kết nối socket."
}

3. Tái Lập An Toàn Trong Sandbox Bị Cô Lập

Một công cụ bảo mật không bao giờ được trở thành nguồn gây nguy hại. Mọi tiến trình chạy thử testcase, parser hoặc build mã nguồn mục tiêu đều phải nằm trong môi trường khép kín:

  • Ngắt Mạng Ngoài: Chỉ cho phép kết nối nội bộ loopback nếu cần trao đổi client/server.
  • Khóa Mã Nguồn Gốc: Mã nguồn repo được mount ở chế độ chỉ đọc (read-only). Mọi thao tác ghi chỉ được phép xảy ra trong thư mục scratch/ chỉ định.
  • Giới Hạn Ngưỡng (Quotas): Áp đặt trần CPU, RAM và thời gian thực thi nhằm ngăn chặn tấn công từ chối dịch vụ vào máy chủ điều khiển.

4. 🧠 10 Ma Trận Tấn Công Chuyên Sâu

Cloudflare đóng gói tri thức bảo mật thành các file tài liệu hướng dẫn độc lập:

skills/security-audit/
├── AI-AND-LLM.md                        # Tấn công prompt injection, chiếm quyền tool call, rò rỉ ngữ cảnh
├── CLOUD-AND-DEPLOYMENT.md              # Lỗi cấu hình IAM, SSRF, vượt mặt chính sách ingress
├── CLIENT-SIDE.md                       # DOM clobbering, prototype pollution, cross-origin messaging
├── DATA-ISOLATION-AND-LIFECYCLE.md      # Rò rỉ dữ liệu đa người thuê (multi-tenant), ngộ độc cache
├── DESKTOP-MOBILE-AND-LOCAL-IPC.md      # Deep-links, cầu nối webview, tấn công socket IPC
├── MEMORY-SAFETY-AND-BINARY.md          # Kiểm tra biên bộ nhớ, FFI không an toàn, use-after-free
├── PROTOCOLS-RPC-AND-MESSAGING.md       # Giải tuần tự hóa Protobuf/gRPC, ngộ độc broker
├── RESOURCE-EXHAUSTION-AND-AVAILABILITY.md # ReDoS, bom giải nén zip, bão hòa truy vấn cơ sở dữ liệu
├── SUPPLY-CHAIN-AND-RELEASE.md          # Thư viện phụ thuộc độc hại, can thiệp CI runner, typosquatting
└── WEB-PROTOCOL-AND-AUTH.md             # Buôn lậu yêu cầu HTTP, vượt kiểm tra trạng thái OAuth

Nhờ cấu trúc này, khi rà soát một ứng dụng web Astro/React, tác tử chỉ cần nạp tài liệu CLIENT-SIDE.md và WEB-PROTOCOL-AND-AUTH.md, giúp tiết kiệm cửa sổ ngữ cảnh và tránh phân tán tư duy của AI.


5. 💡 Bài Học Thực Tiễn Cho Kỹ Sư Công Nghệ

  1. Quét Nhiều Vòng Mang Lại Giá Trị Vượt Trội: Dữ liệu thực nghiệm của Cloudflare chỉ ra rằng một lượt quét đơn lẻ của LLM chỉ phát hiện dưới 50% số lỗ hổng thực tế. Các lượt quét lặp có kế thừa sổ cái coverage-ledger.json giúp tăng gần gấp đôi lượng phát hiện hợp lệ.
  2. Thiếu Lớp Phòng Thủ Dự Phòng Không Phải Lỗ Hổng: Nếu Lớp A (ví dụ: WAF hoặc Gateway) đã chặn đứng khai thác, việc Lớp B thiếu kiểm tra chỉ được xếp vào nhóm Khuyến nghị củng cố (Hardening note) chứ không phải lỗ hổng nghiêm trọng.
  3. Mã Kiểm Tra Tất Định Neo Giữ Tác Tử AI: Thay vì để LLM tự chấm điểm cho chính mình, Cloudflare dùng script Node.js thuần (validate-coverage-ledger.cjs và validate-findings.cjs). Bất kỳ sai lệch định dạng nào cũng bị chặn lại ngay lập tức trước khi bước sang giai đoạn tiếp theo.