Cloudflare security-audit 스킬은 에이전트가 찾은 취약점을 다른 에이전트가 반박해 걸러 냅니다 | DAKER 커뮤니티

밝은 작업대 위 소프트웨어 설계도를 작은 점검 로봇들이 나눠 살피고 다른 색 로봇들이 발견 내용을 다시 확인하는 고화질 일러스트에 「코딩 에이전트용 보안 감사 스킬 security-audit」 제목이 얹힌 10초 모션 영상 미리보기이며, 오른쪽 위에 Cloudflare 공식 로고가 있습니다
설명용 생성 이미지입니다. 10초 모션 영상 원본은 글 아래 첨부 파일에 있습니다.

2026년 10월 21일 오전 11시 40분(한국 시간) GitHub Trending 일간 2위는 cloudflare/security-audit-skill입니다. 한 줄로 말하면 코딩 에이전트를 보안 감사관으로 바꾸는 Cloudflare의 오픈소스 스킬입니다. 핵심은 취약점을 찾는 에이전트와 그 결과를 검증하는 에이전트를 끝까지 분리한다는 점입니다. 후보를 찾은 에이전트가 아닌 새 에이전트가 그 후보를 반박해 보고, 살아남은 것만 확정(confirmed) 기록으로 남깁니다. AI 에이전트나 데이터 서비스를 만드는 DAKER 참가자에게는 제출 전 코드 점검 도구이자, 에이전트 검증 구조를 배울 교재가 됩니다.

Cloudflare security-audit 스킬은 무엇인가

저장소 설명은 「검증된 기계 판독형 결과를 내는 다단계 보안 감사용 코딩 에이전트 스킬」입니다. 2026년 10월 21일 오전 11시 40분(KST) GitHub API 기준 스타는 34,391개, 포크는 2,155개이고, 주요 언어는 JavaScript, 라이선스는 MIT입니다. 저장소는 2026년 6월 18일에 공개됐습니다.

README에 따르면 감사는 여섯 단계로 돌아갑니다. 정찰(Reconnaissance) 단계에서 구조·신뢰 경계·입력 지점을 architecture.md와 coverage-ledger.json에 정리하고, 커버리지 중심 탐색(Coverage-led hunting) 단계에서 격리된 탐색 에이전트들이 원장(ledger)의 단위를 나눠 맡습니다. 이어서 후보 검증, findings.json 구조화 출력, 새 에이전트의 독립 기록 검증, 대상 중립 보고서 작성 순서로 이어집니다. 최종 기록은 confirmed, needs_validation, rejected 세 가지 판정으로 나뉘고, 보고서는 REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md 세 파일로 나옵니다.

정보 카드에 GitHub Trending 일간 2위, cloudflare/security-audit-skill, 스타 34,391개, JavaScript, MIT, 오늘 받은 스타 1,712개, Recon에서 Hunt, Validate, findings.json, Re-verify, Report로 이어지는 여섯 단계가 영어로 적힌 이미지입니다
2026년 10월 21일 오전 11시 40분(KST) GitHub 기준 저장소 정보와 감사 여섯 단계입니다.
security-audit 스킬의 쓸모는 취약점을 많이 찾는 데보다, 찾은 에이전트와 확인하는 에이전트를 갈라 근거가 끝까지 남은 결과만 확정으로 기록하는 데 있습니다.

security-audit 스킬이 지금 GitHub 트렌딩에 오른 이유

같은 시각 트렌딩 페이지에는 이 저장소가 하루 동안 받은 스타가 1,712개로 표시됐습니다. 눈에 띄는 배경은 두 가지입니다.

첫째, 실제 대규모 보안 파이프라인의 출발점이라는 점입니다. README는 이 스킬이 Cloudflare의 취약점 탐지 하네스를 처음 키운 씨앗이라고 밝히고, 그 과정은 Cloudflare 블로그 글 Build your own vulnerability harness(2026년 6월 18일)에 정리돼 있습니다. 블로그에 따르면 약 450줄짜리 security-audit 스킬을 저장소 하나에 돌리며 실제 버그가 나올 때까지 프롬프트를 고쳤고, 이 스킬을 128개 저장소를 훑는 전사 스캐너로 키우는 데 약 6주가 걸렸습니다. 지금도 공격 시나리오와 버그 유형 프롬프트는 처음 스킬의 것을 거의 그대로 쓴다고 적었습니다.

둘째, 한 번 돌린 결과를 과신하지 말라는 솔직한 수치입니다. README는 「테스트 실행에서 한 번의 실행은 여러 번 반복한 실행이 찾은 전체 취약점의 대략 절반을 찾았다」고 적습니다. 그래서 같은 저장소에 여러 번 돌리면 이전 원장과 결과를 이어받아 빈 곳을 겨냥하도록 설계했습니다.

security-audit 스킬을 써 보는 순서

README 기준 준비물은 도구 호출과 병렬 서브에이전트를 지원하는 모델을 쓰는 코딩 에이전트, 의존성 없는 검증기를 돌릴 Node.js, 그리고 대상 코드를 실행할 때 쓸 운영체제 수준 샌드박스입니다. 샌드박스는 외부 네트워크를 막고, 허용 목록으로 정리한 환경 변수만 쓰고, 자원 한도를 걸고, 지정한 임시 경로에만 쓰기를 허용해야 합니다. 이런 통제가 없으면 스킬은 대상 코드를 실행하지 않고 해당 단서를 needs_validation으로 남깁니다.

설치는 README의 Installation 절대로 Skills CLI 한 줄이면 됩니다. 사용자 전체에 설치하려면 끝에 --global을 붙입니다.

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

설치한 뒤에는 감사할 코드베이스에서 코딩 에이전트를 열고 README 예시처럼 평범한 문장으로 요청합니다.

security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project

코드베이스 전체 감사나 침투 테스트를 요청하면 전체 감사 모드로, 보안 질문이나 특정 취약점 작업은 안내 모드로 동작합니다. 출력 폴더를 지정하지 않으면 결과는 ~/security-audit-skill/<저장소 이름>/run-<N> 아래에 쌓이고, 버전 관리가 무시하는 폴더를 직접 지정했을 때만 대상 저장소 안에 씁니다. 상위 에이전트는 원장을 만들거나 고칠 때마다 validate-coverage-ledger.cjs를, 4단계와 5단계에서는 validate-findings.cjs를 돌려 결과 파일이 report-schema.json을 지키는지 확인합니다.

security-audit 스킬을 어디에 쓰면 좋은가

첫째, 해커톤 제출물 점검입니다. 스킬 폴더에는 AI-AND-LLM.md(프롬프트 인젝션, 에이전트·도구 사용, 출력 처리), WEB-PROTOCOL-AND-AUTH.md(HTTP·인증), CLOUD-AND-DEPLOYMENT.md(IAM·컨테이너·서버리스), SUPPLY-CHAIN-AND-RELEASE.md(의존성·CI·릴리스) 같은 공격 유형 문서가 나뉘어 있습니다. LLM 기반 서비스나 웹 데모를 내는 팀이라면 이 목록만 읽어도 놓치기 쉬운 지점을 짚을 수 있습니다.

둘째, 에이전트 평가 설계 공부입니다. README의 설계 원칙은 「결과를 확인하는 에이전트는 그 결과를 찾은 에이전트가 절대 아니다」, 「심각도는 체크리스트 위반이 아니라 가능성과 영향으로 매긴다」, 「다른 방어층이 공격을 막는다면 이 층이 없는 것은 취약점이 아니라 보강 메모다」로 요약됩니다. 생성 결과를 다른 모델이나 새 맥락의 에이전트로 반박해 보는 구조는 RAG 답변 검증이나 에이전트 대회의 자동 채점에도 그대로 옮겨 쓸 만합니다.

다만 스타 수와 트렌딩 순위가 감사 품질을 보장하지는 않습니다. 남의 코드를 감사할 때는 반드시 권한이 있는 저장소에만 쓰고, needs_validation으로 남은 항목은 사람이 직접 확인해야 합니다. 여러분은 코딩 에이전트가 만든 코드를 어떤 방식으로 검증하고 계신가요? security-audit 스킬을 자기 프로젝트에 돌려 본 경험이 있다면 댓글로 나눠 주세요.

출처