Cloudflare Security Audit Skill: quy trình 6 pha kiểm chứng finding từ AI

Security Audit Skill tổ chức code agent theo sáu pha: reconnaissance, săn theo coverage, xác minh độc lập và báo cáo có cấu trúc. Mô hình này giúp đội bảo mật phân biệt finding đã xác nhận, việc còn cần kiểm tra và candidate đã bị bác bỏ.

Một code agent báo có lỗ hổng ngay trước giờ merge có thể dẫn đến hai cực đoan: hoãn release vì một cảnh báo mơ hồ, hoặc bỏ qua vì đội ngũ đã quen với false positive.

Cloudflare Security Audit Skill tập trung vào khoảng trống đó: biến kết quả audit do agent tạo ra thành hồ sơ có cấu trúc, có phạm vi coverage và có bước kiểm chứng độc lập.

Với SOC, security engineer và đội risk & compliance, đây không chỉ là một cách yêu cầu AI tìm lỗi trong code. Nó là một mẫu workflow để phân biệt rõ điều đã được xác nhận, điều còn thiếu bằng chứng và điều đã bị bác bỏ.

Security Audit Skill là gì?

Security Audit Skill là một skill cho coding agent, hướng dẫn agent thực hiện security audit trên một repository theo nhiều pha.

Theo README, đây là điểm khởi đầu ở cấp độ một repository của vulnerability discovery harness tại Cloudflare. Harness sau đó phát triển thành hệ thống nhiều giai đoạn, triển khai ở quy mô rộng hơn.

Điểm đáng chú ý là workflow không coi một đoạn code đáng ngờ là lỗ hổng đã xác nhận. Nó dùng ba verdict riêng biệt:

confirmed: có chuỗi truy vết source hoàn chỉnh và kết quả quan sát được, với phạm vi kết quả đã được giới hạn. needsvalidation: còn một sự thật cụ thể chưa được giải quyết; không gán severity. rejected: candidate đã bị bác bỏ.

Cách phân loại này phù hợp với triage phòng thủ: không phải mọi tín hiệu đều trở thành incident, và không phải mọi nghi ngờ từ agent đều trở thành vulnerability chính thức.

Sáu pha của workflow

1. Reconnaissance: lập bản đồ mục tiêu audit

Pha đầu tạo architecture.md và coverage-ledger.json, bao gồm:

Kiến trúc và ranh giới tin cậy Bề mặt đầu vào Bằng chứng có sẵn Phạm vi kiểm tra có thể xác định

coverage-ledger.json đóng vai trò sổ theo dõi: phần nào đã được kiểm tra, theo hướng nào và phần nào còn trống.

2. Hunting theo coverage

Các hunter được phân công từ những đơn vị trong ledger và được cô lập với nhau. Họ ghi lại các kiểm tra đã thực hiện; coverage critic tiếp tục tìm khoảng trống trong phạm vi audit.

Mục tiêu là tránh tình trạng agent chỉ đọc một số file dễ tiếp cận rồi ngầm coi toàn bộ repository đã được review.

3. Xác minh candidate

Mỗi candidate riêng biệt được chuyển cho một verifier mới, với nhiệm vụ cố gắng bác bỏ finding đó.

Nguyên tắc cốt lõi của skill là: agent xác minh không phải agent đã phát hiện vấn đề. Đây là cơ chế giảm rủi ro tự xác nhận của agent trong một chuỗi audit.

4. Xuất finding có cấu trúc

Các record confirmed, needsvalidation và rejected được ghi vào findings.json, rồi đối chiếu với report-schema.json.

Dự án đi kèm hai validator không phụ thuộc thư viện ngoài:

validate-findings.cjs để kiểm tra findings.json validate-coverage-ledger.cjs để kiểm tra coverage-ledger.json

Parent agent chạy validator coverage ledger sau khi tạo ledger và sau các lần cập nhật tiếp theo. Validator findings được chạy ở pha output và sau mỗi lần thay thế record trong pha xác minh cuối.

5. Kiểm chứng record độc lập

Các claim cuối cùng về source được agent mới kiểm tra lại. Nếu một record bị thay thế trong quá trình này, bản thay thế phải tiếp tục qua một verifier độc lập khác.

6. Sinh báo cáo từ record đã kiểm chứng

Workflow tạo các tài liệu:

REPORT.md FINDINGS-DETAIL.md NEEDS-VALIDATION.md

Các báo cáo này được suy ra từ record đã xác minh và coverage ledger, thay vì chỉ từ phần tóm tắt tự do của một agent.

Cách thử trên repository được phép audit

README hướng dẫn cài skill qua Skills CLI:

bash npx skills add https://github.com/cloudflare/security-audit-skill \ --skill security-audit

Có thể cài ở phạm vi người dùng với --global:

bash npx skills add https://github.com/cloudflare/security-audit-skill \ --skill security-audit \ --global

Sau đó, khởi động coding agent trong repository hoặc trỏ agent đến codebase cần review. Một số yêu cầu mẫu được README nêu gồm:

text security audit this codebase

text find security vulnerabilities in ./src

text do a security review, output to ~/audits/my-project

Skill được kích hoạt khi yêu cầu khớp với các trigger liên quan đến security audit hoặc tìm vulnerability. Một yêu cầu audit trực tiếp hoặc pen-test codebase sẽ dùng full audit mode; câu hỏi bảo mật hoặc công việc tập trung có thể dùng guidance mode, trừ khi người dùng yêu cầu artefact báo cáo.

Trong full audit mode, nếu chưa chỉ định thư mục output, đường dẫn mặc định là:

text ~/security-audit-skill/<repo-name>/run-<N>

Workflow chỉ ghi trong repository đích khi người dùng chủ động chọn một thư mục đã được version control bỏ qua.

Cách đọc kết quả cho đội bảo mật

Khi agent hoàn tất, phần tóm tắt không nên là điểm dừng của triage. Thứ tự xem xét hợp lý là:

Đọc findings.json, bắt đầu với record confirmed. Kiểm tra chuỗi truy vết source và kết quả quan sát được của từng finding. Đưa needsvalidation vào hàng chờ xác minh thủ công, vì các record này phải nêu rõ sự thật còn thiếu và không có severity. Xem coverage-ledger.json để nhận diện trust boundary, input surface hoặc thành phần chưa được kiểm tra. Lưu rejected khi cần truy vết việc một candidate đã được xem xét và bị bác bỏ.

Về vận hành, tổ chức có thể chỉ cho phép confirmed đi vào luồng quản lý vulnerability; còn needsvalidation nên là đầu vào triage, không phải alert hoặc ticket có mức độ nghiêm trọng.

Điều kiện an toàn không thể bỏ qua

Skill yêu cầu sandbox do hệ điều hành thực thi khi workflow cần chạy build, test, process, browser, emulator, fuzzer hoặc fixture do target kiểm soát.

Sandbox này phải:

Tắt kết nối mạng bên ngoài Dùng môi trường đã được làm sạch và allowlist Áp dụng giới hạn tài nguyên Chỉ cho phép ghi vào scratch path được chỉ định

Nếu không có các kiểm soát đó, workflow giữ lead ở trạng thái needsvalidation thay vì thực thi code đích.

Đây là điểm cần đặc biệt lưu ý khi đánh giá việc dùng coding agent trong CI hoặc môi trường có quyền truy cập nhạy cảm. Code do mục tiêu audit kiểm soát không nên được tự động chạy trong một môi trường không có cô lập phù hợp.

Coverage không phải chứng nhận an toàn

README cũng nêu hai nguyên tắc quan trọng:

Severity dựa trên likelihood x impact, không chỉ dựa vào việc code lệch checklist. Một khoảng trống defense-in-depth không tự động là vulnerability nếu một lớp bảo vệ khác đã chặn được đường tấn công.

Dự án cho biết trong các lần chạy thử của họ, một lần chạy đơn lẻ chỉ tìm được khoảng một nửa số vulnerability so với tổng số được phát hiện qua nhiều lần chạy. Vì vậy, coverage ledger và các lần audit lặp là một phần của workflow, không phải chi tiết phụ.

Security Audit Skill không thay thế đánh giá của con người hay chứng minh repository an toàn. Giá trị của nó nằm ở kỷ luật quy trình: AI có thể đề xuất candidate, nhưng kết luận cần dựa trên bằng chứng được kiểm chứng độc lập.