AI & AUTOMATION

Tìm hiểu về Cloudflare Security Audit: Harness đa agent tự động

Tóm tắt nhanh

security-audit-skill của Cloudflare là một kỹ năng mã nguồn mở dành cho AI coding agent, phát hành theo giấy phép MIT tại kho lưu trữ cloudflare/security-audit-skill. Dự án này chính là nền tảng khởi nguồn cho hệ thống săn lỗ hổng tự động quy mô lớn của Cloudflare (từng được công bố trong bài viết kỹ thuật Build your own vulnerability harness và mô tả tại skills/security-audit/README.md).

Thay vì phụ thuộc vào một câu lệnh prompt đơn lẻ dễ sinh ảo giác và tự chấm điểm sai, kiến trúc này điều phối các sub-agent độc lập qua quy trình 6 giai đoạn: trinh sát (reconnaissance), làn sóng săn tìm theo độ phủ (hunting waves), xác thực đối nghịch (nơi agent kiểm thử mới tìm cách bác bỏ phát hiện), xuất kết quả JSON chuẩn hóa, tái kiểm định dòng mã và tạo báo cáo độc lập.

Quy trình được kiểm soát bởi hai công cụ Node.js CommonJS không phụ thuộc thư viện ngoài (validate-coverage-ledger.cjs và validate-findings.cjs), kết hợp môi trường sandbox hệ điều hành và cơ chế duyệt file qua descriptor (O_NOFOLLOW, fstat) nhằm ngăn chặn mã nguồn mục tiêu tấn công ngược lại hệ thống kiểm thử.

Khi yêu cầu một mô hình ngôn ngữ lớn (LLM) kiểm tra mã nguồn bằng một prompt duy nhất (“hãy tìm lỗi bảo mật trong dự án này”), các kỹ sư thường gặp phải những vấn đề cố hữu:

  • Thiên vị xác nhận và ảo giác: Một agent khi tự mình phát hiện ra một dấu hiệu khả nghi thường có xu hướng bảo vệ phát hiện đó. Nó dễ nhầm lẫn các cấu hình mặc định an toàn của framework thành lỗ hổng có thể khai thác trong thực tế.
  • Thổi phồng mức độ nghiêm trọng (Severity Inflation): Các vi phạm phong cách viết code, thiếu tiêu đề HTTP tùy chọn hoặc khoảng trống phòng thủ chiều sâu (defense-in-depth) thường bị gán nhãn “Critical” hoặc “High” mà không chứng minh được đường dẫn dữ liệu từ đầu vào không tin cậy tới điểm thực thi nguy hiểm (sink).
  • Thiếu kiểm soát độ phủ: Agent không có cấu trúc thường chỉ đọc lướt các file chính ở thư mục gốc, tuyên bố đã “kiểm thử toàn diện”, nhưng bỏ qua các ranh giới RPC nội bộ, hàng đợi nền, tác vụ xử lý theo lô và luồng giải tuần tự hóa.
  • Rủi ro khi chạy mã nguồn không an toàn: Việc để agent chạy trực tiếp kịch bản build hoặc kiểm thử do kho lưu trữ mục tiêu cung cấp có thể khiến máy chủ kiểm thử bị chiếm quyền điều khiển qua liên kết mềm (symlink), leo thang tiến trình hoặc duyệt thư mục tùy ý nếu thiếu cơ chế bảo vệ trong skills/security-audit/SKILL.md.
[Kiểm thử AI bằng Prompt đơn lẻ]
  │
  ├── Prompt tự do ──────> Đọc lướt bề mặt & bỏ qua các module phức tạp
  ├── Tự chấm điểm ──────> Thổi phồng lỗi cấu hình nhỏ thành lỗ hổng Critical
  ├── Ảo giác điểm chìm ─> Tự suy diễn lỗi mà không có luồng lan truyền thực tế
  └── Chạy trực tiếp ────> Chạy mã không an toàn ngay trên máy host

==================================== VS ====================================

[Pipeline Kiểm thử Đa Agent của Cloudflare]
  │
  ├── Giai đoạn 1: Trinh sát ───> Khởi tạo coverage-ledger.json với ID chuẩn hóa
  ├── Giai đoạn 2: Săn tìm ─────> Phân bổ Hunter độc lập với 10 module tấn công
  ├── Giai đoạn 3: Xác thực ────> Verifier độc lập tìm cách BÁC BỎ phát hiện
  ├── Giai đoạn 4: Xuất JSON ───> findings.json chuẩn hóa 3 nhánh verdict
  ├── Giai đoạn 5: Tái thẩm định ─> Fresh Eyes đối soát dòng code và bất biến
  └── Sandbox & Thăng cấp file ─> Khóa descriptor POSIX (O_NOFOLLOW / fstat)

Kiến trúc: từ kỹ năng coding agent đến harness quy mô lớn

Theo chia sẻ trong skills/security-audit/README.md từ đội ngũ bảo mật của Cloudflare, security-audit-skill là điểm xuất phát trực tiếp để họ xây dựng hệ thống tự động quét lỗ hổng trên toàn bộ các kho mã nguồn nội bộ. Mặc dù Cloudflare đã mở rộng hệ thống nội bộ thành một hạ tầng phân tán nhiều tầng, toàn bộ nguyên lý cốt lõi vẫn được đóng gói trọn vẹn trong skills/security-audit/SKILL.md.

Quy trình hoạt động dựa trên hai chế độ được định nghĩa tại skills/security-audit/SKILL.md:

  1. Chế độ hướng dẫn (Guidance mode – mặc định): Dành cho việc trả lời câu hỏi bảo mật, hỗ trợ rà soát pull request hoặc kiểm tra nhanh một hàm cụ thể. Chế độ này không tự ý tạo thư mục hay kích hoạt toàn bộ luồng đa agent.
  2. Chế độ kiểm thử toàn diện (Full audit mode): Kích hoạt khi người dùng yêu cầu kiểm thử bảo mật toàn diện hoặc pen-test một codebase. Hệ thống sẽ thực thi tuần tự cả 6 giai đoạn và xuất các tệp dữ liệu có thể kiểm chứng bằng máy.
Kho mã nguồn mục tiêu
        │
        ▼
[Giai đoạn 1: Trinh sát]    ───> 4 Research Agent song song (Stack, Auth, Sinks, Sandbox)
        │                        Tạo tệp: architecture.md & coverage-ledger.json
        ▼
[Giai đoạn 2: Làn sóng săn] ───> General Hunter độc lập + Coverage Critic đánh giá lỗ hổng
        │                        Gắn kèm tài liệu chuyên biệt: Web, AI, Binary, Cloud...
        ▼
[Giai đoạn 3: Xác thực]     ───> Verifier đối nghịch (Tìm cách BÁC BỎ phát hiện)
        │                        Kiểm chứng bằng fixture sandbox và dữ liệu giả lập
        ▼
[Giai đoạn 4: Xuất JSON]    ───> findings.json (confirmed / needs_validation / rejected)
        │                        Xác minh bằng validate-findings.cjs & schema
        ▼
[Giai đoạn 5: Tái thẩm định]───> Fresh Eyes kiểm tra lại số dòng và bất biến bảo mật
        │
        ▼
[Giai đoạn 6: Báo cáo]      ───> REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md

Phân định vai trò agent và cô lập ghi dữ liệu

Framework phân chia các vai trò agent rõ ràng trong skills/security-audit/SKILL.md để có thể chạy trên nhiều nền tảng (Claude Code, Google Antigravity, OpenAI Codex):

  • Parent Orchestrator: Tiến trình điều phối trung tâm quản lý trạng thái chia sẻ, ngân sách token/agent, sổ cái độ phủ và là tiến trình đáng tin cậy duy nhất được phép thăng cấp file từ vùng đệm (scratch/) của sub-agent lên thư mục lưu trữ (artifacts/).
  • Research Agent (subagent_type: research): Các agent chỉ đọc chạy trong Giai đoạn 1 để lập bản đồ ngăn xếp công nghệ, ranh giới định danh, bề mặt đầu vào và khả năng kiểm thử ngoại tuyến mà không thay đổi hệ thống tệp.
  • General Hunter (subagent_type: general): Các agent săn tìm lỗ hổng được phân công theo từng đơn vị trong sổ cái độ phủ. Mỗi hunter sở hữu một thư mục scratch/ riêng biệt, phân tích sâu mã nguồn và trả về đúng một đối tượng JSON cấu trúc.
  • Adversarial Verifier: Các agent kiểm chứng độc lập trong Giai đoạn 3. Nguyên tắc bất di bất dịch của Cloudflare trong skills/security-audit/VALIDATION-AND-REPORTING.md là: Agent kiểm tra một phát hiện tuyệt đối không phải là agent đã tìm ra nó. Verifier nhận phát hiện ứng viên kèm chỉ thị rõ ràng trong prompt: tìm mọi cách để bác bỏ phát hiện đó dựa trên mã nguồn và fixture cục bộ.

Cơ chế sandbox và thăng cấp file an toàn bằng descriptor POSIX

Khi cần chạy thử mã nguồn, script dựng build hoặc fixture kiểm thử parser, tài liệu skills/security-audit/SKILL.md bắt buộc phải áp dụng sandbox cấp hệ điều hành:

  • Không cho phép kết nối mạng ngoài (chỉ dùng loopback namespace biệt lập cho giao tiếp client/server nội bộ).
  • Môi trường thực thi trống rỗng, chỉ nạp các biến môi trường trong danh sách cho phép (allowlist), trỏ HOME và thư mục tạm vào vùng scratch/ riêng.
  • Gắn kết mã nguồn mục tiêu và công cụ biên dịch dưới dạng chỉ đọc (read-only).
  • Áp đặt giới hạn chặt chẽ về CPU, RAM, số lượng tiến trình con, dung lượng đĩa và thời gian chạy tối đa.

Để loại bỏ hoàn toàn nguy cơ tấn công tranh chấp liên kết mềm (symlink TOCTOU) và duyệt thư mục tùy ý (../), tài liệu skills/security-audit/SKILL.md quy định các sub-agent chỉ được ghi vào thư mục scratch/ của mình. Tiến trình Parent đáng tin cậy sẽ kiểm tra và sao chép các tệp kết quả sang artifacts/ bằng các lệnh gọi hệ thống dựa trên file descriptor:

  1. Mở và giữ các file descriptor không kế thừa cho thư mục scratch/ và artifacts/ trước khi chạy sandbox.
  2. Duyệt từng phần của đường dẫn tương đối bằng các thao tác tương đối với thư mục mở sẵn theo quy trình skills/security-audit/VALIDATION-AND-REPORTING.md, cấm hoàn toàn việc đi theo symlink (O_NOFOLLOW).
  3. Dùng lệnh fstat trên descriptor của tệp lá, kiểm tra chắc chắn tệp đó là regular file, có số lượng liên kết cứng chính xác bằng một (st_nlink == 1) và nằm trong giới hạn byte quy định.
  4. Tạo thư mục đích và tệp đích theo cơ chế độc quyền, từ chối sao chép các pipe FIFO, socket, device file hoặc các tệp đang bị thay đổi kích thước.

Vòng đời kiểm thử qua 6 giai đoạn

Một phiên kiểm thử hoàn chỉnh phải đi qua đầy đủ 6 giai đoạn tuần tự. Việc tự ý dừng giữa chừng bị nghiêm cấm; phiên làm việc chỉ được kết thúc khi toàn bộ tệp báo cáo Giai đoạn 6 được sinh ra và vượt qua các bộ kiểm tra, hoặc phải ghi nhận rõ trạng thái run_status: "incomplete" kèm lý do chặn.

Giai đoạn 1: Trinh sát và cổng ngân sách

Trước khi kích hoạt trinh sát, Parent kiểm tra cổng ngân sách để đảm bảo đủ tài nguyên cho các vòng kiểm định sau. Bốn research agent chạy song song:

  • Agent 1a (Sản phẩm & Ngăn xếp): Xác định ngôn ngữ, framework, lệnh build ngoại tuyến và các điểm nhập cảnh (entrypoint).
  • Agent 1b (Quyền hạn & Danh tính): Lập bản đồ các chủ thể có mức độ tin cậy thấp, middleware xác thực, cổng phân quyền và phạm vi tenant.
  • Agent 1c (Bề mặt & Điểm chìm nguy hiểm): Liệt kê toàn bộ dữ liệu từ bên ngoài (HTTP, RPC, CLI, tệp tin, webview, hàng đợi tin nhắn) và lần vết tới các điểm chìm (sink).
  • Agent 1d (Khả năng thực thi an toàn): Đánh giá các bộ test fixture có thể chạy offline với dữ liệu giả lập và kiểm tra điều kiện sandbox.

Dữ liệu được tổng hợp thành tệp architecture.md và khởi tạo sổ cái độ phủ coverage-ledger.json.

Giai đoạn 2: Các làn sóng săn tìm theo độ phủ

Parent giao các đơn vị kiểm thử ở trạng thái planned cho các general hunter. Các bề mặt công khai không cần xác thực sẽ được ưu tiên kiểm tra trước các API nội bộ.

Bên cạnh các lớp tấn công cốt lõi trong skills/security-audit/ATTACK-CLASSES.md (Injection, Access Control, File Handling, Cryptography, Business Logic), Parent sẽ nạp thêm các tài liệu hướng dẫn chuyên sâu tương ứng với kiến trúc mục tiêu:

  • AI-AND-LLM.md: Tấn công prompt injection gián tiếp, đầu độc bộ nhớ, nhầm lẫn server/tool trong giao thức MCP, ràng buộc phê duyệt hành động và sai lệch giữa schema với dispatcher.
  • MEMORY-SAFETY-AND-BINARY.md: Tràn bộ đệm, use-after-free, tràn số nguyên, tranh chấp luồng và nạp nhị phân trong C/C++/Rust.
  • WEB-PROTOCOL-AND-AUTH.md: HTTP request smuggling, đầu độc bộ nhớ đệm, lỗi xác thực JWT/OAuth và cố định phiên làm việc.
  • CLIENT-SIDE.md: DOM XSS, ô nhiễm nguyên mẫu (prototype pollution), tin cậy tin nhắn postMessage và cầu nối webview.
  • SUPPLY-CHAIN-AND-RELEASE.md: Luồng CI/CD, ghim phiên bản dependency, ký số artifact và kênh cập nhật plugin.
  • CLOUD-AND-DEPLOYMENT.md: Cấu hình hạ tầng dạng mã (IaC), chính sách assume role của IAM, thoát container và định tuyến ingress.
  • PROTOCOLS-RPC-AND-MESSAGING.md: Bảo mật gRPC, GraphQL, Protobuf/Cap’n Proto, xác thực webhook và hàng đợi tin nhắn.
  • RESOURCE-EXHAUSTION-AND-AVAILABILITY.md: Lỗ hổng ReDoS, cạn kiệt hàng đợi worker, vượt giới hạn rate limit và khuếch đại chi phí dịch vụ đám mây.
  • DATA-ISOLATION-AND-LIFECYCLE.md: Rò rỉ bộ nhớ cache giữa các tenant, lộ dữ liệu qua chỉ mục tìm kiếm và phục hồi dữ liệu đã xóa mềm.
  • DESKTOP-MOBILE-AND-LOCAL-IPC.md: Liên kết sâu (deep link), socket Unix nội bộ, giao tiếp IPC (XPC, Binder, D-Bus) và đặc quyền daemon.

Sau mỗi đợt săn tìm, Coverage Critic sẽ rà soát lại để phát hiện các góc khuất bị bỏ quên và đưa chúng vào mục lưu trữ attempts để tái phân bổ.

Giai đoạn 3: Xác thực đối nghịch các ứng viên

Mọi ứng viên phát hiện đều được chuyển cho một verifier hoàn toàn mới. Verifier đọc lại từng dòng mã trên đường dẫn lan truyền, tìm kiếm các cơ chế kiểm soát bù trừ và tái hiện lỗi bằng fixture với dữ liệu giả lập. Nếu mã nguồn đã có lớp bảo vệ chặn đứng luồng tấn công, phát hiện sẽ bị bác bỏ (rejected). Nếu điều kiện khai thác phụ thuộc vào một cấu hình hạ tầng không thể quan sát được trong code, phát hiện được chuyển sang needs_validation.

Giai đoạn 4: Xuất và kiểm định tệp JSON cấu trúc

Parent tổng hợp các phát hiện đã qua kiểm chứng vào findings.json và chạy script skills/security-audit/validate-findings.cjs để xác thực với report-schema.json.

Giai đoạn 5: Tái thẩm định độc lập

Một agent mới rà soát lại ngữ cảnh dòng mã của từng phát hiện để đảm bảo số dòng chính xác, xác nhận lỗi chưa bị sửa bởi các thay đổi gần đây và kiểm tra xem giải pháp khắc phục có phải là can thiệp nhỏ nhất, hiệu quả nhất tại điểm ra quyết định đáng tin cậy cuối cùng hay không.

Giai đoạn 6: Xuất báo cáo độc lập với môi trường

Parent tổng hợp 3 báo cáo markdown từ dữ liệu JSON đã được chuẩn hóa:

  • REPORT.md: Tóm tắt điều hành, thống kê độ phủ kiểm thử, phương pháp luận và bảng tổng hợp rủi ro.
  • FINDINGS-DETAIL.md: Chi tiết từng lỗ hổng đã xác nhận, luồng lan truyền dữ liệu, các bước tái hiện, định nghĩa bất biến bảo mật và bản vá mẫu.
  • NEEDS-VALIDATION.md: Các giả thuyết khả thi bị chặn do thiếu thông tin môi trường thực tế, kèm quy trình kiểm tra an toàn, không phá hủy dành cho chủ sở hữu hệ thống.

Mô hình kết luận 3 nhánh và kiểm soát schema

Script skills/security-audit/validate-findings.cjs thực thi một schema JSON nghiêm ngặt gồm đúng 3 nhánh kết luận loại trừ lẫn nhau:

                     [Ứng viên lỗ hổng từ Hunter]
│
▼
[Xác thực đối nghịch]
│
┌─────────────────────────┼─────────────────────────┐
▼ ▼ ▼
"confirmed" "needs_validation" "rejected"
────────────── ──────────────────── ────────────
• Đủ vết mã nguồn • Giả thuyết có cơ sở • Bị code bác bỏ
• Chứng minh tác động • Thiếu thông tin hạ tầng • Lỗi phòng thủ sâu
• Có test POC cục bộ • CẤM gán mức nghiêm trọng • Hành vi chủ đích
• Có bản vá cụ thể • Có kế hoạch kiểm tra • Ghi rõ lý do loại
  1. confirmed: Yêu cầu đường dẫn hoàn chỉnh từ entrypoint qua các bước propagation tới sink, minh chứng tác động thực tế trên dữ liệu giả lập và chiến lược khắc phục rõ ràng.
  2. needs_validation: Theo schema skills/security-audit/report-schema.json, trạng thái này đại diện cho các giả thuyết có cơ sở trong mã nguồn nhưng bị chặn bởi các yếu tố triển khai thực tế (như luật WAF trên Cloudflare, tiêu đề cache của CDN hoặc cấu hình Identity Provider). Schema nghiêm cấm tuyệt đối việc gán điểm mức độ nghiêm trọng (severity) cho phát hiện ở trạng thái này.
  3. rejected: Ghi nhận các ứng viên bị bác bỏ bởi cơ chế phòng vệ có sẵn hoặc hành vi chủ đích của hệ thống. Việc ghi nhận này giúp tránh lặp lại cùng một giả thuyết sai trong các vòng săn tìm tiếp theo.

Kiểm định trần mức độ nghiêm trọng và cấu trúc luồng

Để ngăn chặn các sai sót thường gặp trong báo cáo bảo mật, validate-findings.cjs lập trình sẵn các luật kiểm tra:

  • Trần mức độ nghiêm trọng: Giá trị overall_severity không bao giờ được vượt quá điểm tác động chứng minh được (impact.score). Một lỗi có phạm vi ảnh hưởng hẹp không thể bị thổi phồng thành mức High hay Critical.
  • Hình thái luồng lan truyền: Với luồng lan truyền nhiều dòng, phần tử đầu tiên bắt buộc phải có kind: "entrypoint", phần tử cuối cùng phải là kind: "sink" và tất cả các bước trung gian phải là kind: "propagation".
  • Thứ tự sắp xếp: Toàn bộ phát hiện phải được sắp xếp theo thứ tự từ điển của mã băm vân tay (fingerprint SHA-256) để đảm bảo kết quả nhất quán giữa các lần chạy.

Quản lý độ phủ định lượng bằng Node.js độc lập

Thay vì đưa ra những ước lượng mơ hồ, công cụ skills/security-audit/validate-coverage-ledger.cjs theo dõi trạng thái kiểm thử theo một máy trạng thái chặt chẽ:

    ┌──────────┐
│ planned │
└────┬─────┘
│
▼
┌─────────────┐
│ in_progress │
└──┬───────┬──┘
│ │
▼ ▼
┌─────────┐ ┌───────────┐ ┌─────────┐ ┌──────────┐ ┌──────────────┐ ┌──────────┐
│ covered │ │ candidate │ │ blocked │ │ deferred │ │ out_of_scope │ │ not_app. │
└─────────┘ └───────────┘ └─────────┘ └──────────┘ └──────────────┘ └──────────┘

Script tự động tạo mã coverage_id duy nhất và không trùng lặp cho từng đơn vị bằng cách mã hóa phần trăm (percent-encoding) theo chuẩn RFC 3986:

function canonicalCoverageId(refs) {
  const fields = hasOwn(refs, "lifecycle") 
    ? ["surface", "boundary", "subsystem", "attack_class", "lifecycle"] 
    : ["surface", "boundary", "subsystem", "attack_class"];
  return fields.map((field) => encodeCanonicalRef(refs[field])).join("::");
}

Nhờ cơ chế này, các bề mặt kiến trúc khác nhau không bao giờ bị hợp nhất nhầm. Hơn nữa, việc chạy kiểm thử nhiều lần trên cùng một kho mã nguồn mang tính chất cộng dồn (additive): hệ thống sẽ nạp lại sổ cái và phát hiện cũ để tập trung quét các phần mã mới thay đổi, tránh lãng phí tài nguyên tính toán vào những phần code giữ nguyên.

Hướng dẫn cài đặt, câu lệnh và áp dụng thực tế

Kỹ năng được đóng gói theo chuẩn mở Skills và có thể cài đặt dễ dàng qua công cụ npx skills:

# Cài đặt cục bộ vào dự án hiện tại
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

# Cài đặt toàn cục cho tài khoản người dùng
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit --global

Sau khi cài đặt, bạn có thể điều phối AI agent thực hiện kiểm thử bằng các câu lệnh tự nhiên:

# Thực hiện kiểm thử toàn diện và xuất báo cáo vào thư mục chỉ định
security audit this codebase, output to ~/audits/my-project

# Yêu cầu rà soát bảo mật có trọng tâm cho module xác thực
review the authentication flow in ./src/auth for authorization bypasses

Khi nào nên áp dụng Cloudflare Security Audit Skill

  • Các hệ thống đòi hỏi độ tin cậy cao: Rất phù hợp cho các dịch vụ microservice, thư viện mã hóa, API tài chính và nền tảng hạ tầng đám mây nơi các công cụ quét tĩnh thông thường tạo ra quá nhiều cảnh báo rác.
  • Ứng dụng tích hợp AI và LLM: Cần thiết cho các framework agent, máy chủ MCP và ứng dụng RAG nơi dữ liệu người dùng đi qua template prompt và bộ điều phối công cụ (tool dispatcher).
  • Cổng kiểm soát bảo mật CI/CD: Xuất tệp JSON chuẩn hóa (findings.json) giúp tích hợp trực tiếp vào đường ống triển khai tự động mà không phụ thuộc vào dịch vụ bên thứ ba.

Bằng cách phân tách vai trò săn tìm khỏi vai trò kiểm chứng đối nghịch trong skills/security-audit/VALIDATION-AND-REPORTING.md và ràng buộc mọi kết luận bằng công cụ thẩm định tự động, security-audit-skill của Cloudflare đã thiết lập một tiêu chuẩn kỹ thuật vững chắc cho việc ứng dụng AI vào an ninh ứng dụng hiện đại.

Duy Nghiện
Hãy làm khán giả, đừng làm nhân vật chính :)

You may also like

Nhận thông báo qua email
Nhận thông báo cho
guest

0 Bình luận
Mới nhất
Cũ nhất Nhiều like nhất