출처

개요

코딩 에이전트에게 “이 코드베이스 보안 감사해줘”라고 시키면 흔히 체크리스트성 두루뭉술한 목록만 받게 되는 문제를, Cloudflare가 오픈소스로 공개한 security-audit-skill이 정면으로 다룬다. 실제로 공격 가능한 취약점만 찾아내도록 정찰·사냥·검증·보고·구조화 출력·독립 검증의 6단계 파이프라인을 거치며, 여러 병렬 에이전트가 서로 다른 각도에서 코드를 공격하고 다른 에이전트가 그 발견을 반박하도록 설계됐다. Cloudflare 블로그의 Build your own vulnerability harness에서 소개한 내부 취약점 발견 하네스의 출발점이 된 단일 저장소용 버전이며, 2026년 6월 공개 후 한 달도 안 돼 GitHub 스타 2,200개 이상을 받았다.

핵심 포인트

  • 6단계 파이프라인: (1) 정찰(Recon) — 병렬 리서치 에이전트가 아키텍처·신뢰 경계·입력 표면을 파악해 architecture.md 작성. (2) 사냥(Hunt) — 병렬 에이전트가 인젝션·접근 제어·비즈니스 로직·암호화·기능 오남용·연쇄 공격·와일드카드까지 각기 다른 각도로 공격, 필요시 하위 에이전트 추가 생성. (3) 검증(Validate) — 별도 에이전트가 각 발견을 반박 시도해 오탐을 걸러냄. (4) 보고(Report) — 사람이 읽는 REPORT.md와 MEDIUM 이상 심각도의 상세 추적 FINDINGS-DETAIL.md 생성. (5) 구조화 출력 — report-schema.json을 따르는 findings.json 작성 후 validate-findings.cjs로 검증. (6) 독립 검증 — 새 에이전트가 구조화 출력의 모든 사실 주장을 실제 소스 코드와 재대조.
  • 누적 실행: 같은 저장소를 여러 번 돌리면 이전 findings.json을 읽어 이미 알려진 문제는 건너뛰고 새 코드 경로를 탐색한다. README는 한 번의 실행이 전체 취약점의 대략 절반만 찾아낸다는 테스트 결과를 근거로 여러 번 실행을 권장.
  • 오탐을 줄이는 4대 설계 원칙: ① “실제로 공격할 수 있는 것만 보고” — “이론적으로 ~할 수 있다”는 서술은 발견으로 불인정, 구체적 공격 시나리오 필수. ② 적대적 검증 — 발견 에이전트와 확인 에이전트는 절대 동일하지 않음. ③ 심각도는 체크리스트가 아니라 발생 가능성×영향력으로 산정. ④ 심층 방어(defense-in-depth) 구조에서 한 계층이 빠져도 다른 계층이 실제로 막고 있다면 취약점이 아니라 “강화 필요” 참고사항으로만 취급.
  • 용도와 설치: 방어적 보안 연구, 자신이 소유·감사 권한이 있는 코드베이스 대상. Skills CLInpx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit 설치(--global로 전역 설치 가능). “보안 감사”, “취약점 찾기” 같은 요청과 매칭되면 자동 활성화, 기본 출력 경로는 ~/security-audit-skill/<repo-name>/run-<N>. 병렬 서브 에이전트 지원 모델과 Phase 5 스키마 검증용 Node.js 환경 필요. MIT 라이선스.

왜 중요한가

“이론적 위험 나열” 대신 “적대적 검증을 통과한 것만 보고”하는 설계는 AI 코딩 에이전트의 고질적 문제인 과잉 보고(false positive 남발)를 구조적으로 억제한다. 발견자와 검증자를 분리하는 패턴은 보안 감사를 넘어 다른 고신뢰 에이전트 워크플로(리뷰, 리서치 검증)에도 적용 가능한 일반 원칙이다.

더 읽어보기 (원문 인용)

참고 링크

관련 위키