Cloudflare 보안 감사 스킬 security-audit 오픈소스 공개

서문

"독립적으로 검증되고 기계가 읽을 수 있는 결과를 내놓는, 다단계 보안 감사를 위한 코딩 에이전트 스킬."

이것은 「매일 하나의 오픈소스 프로젝트」 시리즈의 제222번째 글입니다. 오늘의 프로젝트는 security-audit —— Cloudflare가 만든 coding-agent skill로, 13,825개의 Star, MIT 라이선스입니다.

security-audit은 하나의 핵심 문제를 해결합니다. 어떻게 하면 AI Agent가 수행한 보안 감사의 결과를 보안 팀에 검토를 맡길 수 있을 만큼 신뢰할 수 있게 만들 것인가? 답은 "모델을 더 똑똑하게 만드는 것"이 아니라, 하나의 구조화된 프로세스——6단계 감사, 적대적 검증, 기계가 읽을 수 있는 발견 기록——를 통해 "모델이 여기에 문제가 있다고 말한다"를 "여기에 소스 증거가 있고, 재현 가능한 경로가 있고, 우선순위가 정렬된 확인된 취약점이 있다"로 바꾸는 것입니다.

무엇을 배우게 되는가

- 6단계 보안 감사 프로세스: 정찰부터 목표 중립 보고까지

- 적대적 검증의 설계 원칙 (검사자는 결코 발견자가 아니다)

- 세 가지 verdict의 차이: confirmed / needs_validation / rejected

- 커버리지 원장(coverage-ledger)이 어떻게 여러 차례의 감사 결과를 누적 가능하게 만드는가

- 샌드박스 요구사항: 왜 "대상 코드를 실행할 수 없을" 때 needs_validation으로만 표시할 수 있는가

사전 지식

- Claude Code 또는 이와 유사한 coding agent와 skill 메커니즘을 사용해 본 경험

- 기본적인 보안 감사 개념(공격 표면, 신뢰 경계, 취약점 확인)에 대한 이해

- Node.js 기초 사용 경험

프로젝트 배경

개요

이 skill은 Cloudflare 취약점 발견 harness의 단일 저장소 출발점입니다. Cloudflare는 공식 블로그 Build your own vulnerability harness에서 이 시스템이 어떻게 다단계의, 전체 fleet을 커버하는 취약점 발견 플랫폼으로 진화했는지 설명했는데, security-audit은 바로 그 최초의 단일 저장소 버전입니다.

이것은 "보안 보고서를 생성하는" prompt 템플릿이 아니라, 하나의 오케스트레이션 시스템입니다. 격리된 하위 Agent로 정찰, 사냥, 검증, 확인을 실행하며, 각 단계의 산출물에는 구조화된 기록과 독립된 검증기가 있습니다.

프로젝트 정보

- 조직: Cloudflare

- 주요 언어: JavaScript (검증기는 의존성 제로, Node.js로 작성)

- 라이선스: MIT

- 생성 시각: 2026-06-18

프로젝트 데이터

- ⭐ GitHub Stars: 13,825+

- 🍴 Forks: 740+

빠른 시작

설치

Skills CLI로 설치 npx skills add https://github.com/cloudflare/security-audit-skill \ --skill security-audit # 사용자 레벨 설치 npx skills add https://github.com/cloudflare/security-audit-skill \ --skill security-audit \ --global

사용

당신의 coding agent를 시작하고, 감사할 코드베이스를 가리킨 다음, 이렇게 말하세요:

security audit this codebase

또는:

find security vulnerabilities in ./src

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

요청이 트리거 단어(security audit / find vulnerabilities / pen-test 등)와 일치하면, skill이 자동으로 활성화됩니다.

두 가지 모드

모드 트리거 조건 동작 guidance 보안 문제, 집중 검토, 방법론 상담 관련 부분만 사용하고, 전체 프로세스를 돌리지 않으며, 파일을 쓰지 않음 full audit 감사/침투 테스트, 엔드투엔드 검토를 명확히 요구 전체 6단계를 돌리고, 보고서 파일을 씀

핵심: 6단계 감사 프로세스

Phase 1: 정찰(Reconnaissance)

여러 research Agent를 병렬로 시작하고, 각각은 구조화된 소스 사실(file:line 인용 포함)을 반환합니다:

- Agent 1a: 제품 유형, 기술 스택, 빌드 명령, 하위 시스템 경계

- Agent 1b: 주체(principal), 권한, 신뢰 경계, 통제 지점

- Agent 1c: 진입면, 복제본, sink(데이터 싱크)

architecture.md(아키텍처 다이어그램)와 coverage-ledger.json(커버리지 원장)을 산출합니다. 정찰 단계는 읽기 전용이며, 외부 서비스에 접촉하지 않습니다.

Phase 2: 커버리지 지향 취약점 사냥

원장에 따라 "커버리지 단위"를 격리된 general Agent에 할당합니다. 각 hunter는 자신이 맡은 소스 블록만 읽고, 자신의 scratch/ 디렉토리에만 쓰며, 하나의 구조화된 결과를 반환합니다.

핵심: coverage critic이 사냥 커버리지의 결손을 찾아냅니다——어떤 단위가 누락되었는지, 어떤 할당이 중복되는지.

Phase 3: 후보 독립 검증

각 고유 후보(중복 제거 후)는 그것을 사냥한 적 없는 완전히 새로운 verifier에게 넘겨져, 그것을 반증하려 시도합니다.

검증기의 prompt는 분명히 말합니다: "당신은 이 후보를 작성하지 않았으니, 소스와 경계가 정해진 로컬 증거로 그것을 반박하라."

Phase 4: 구조화된 출력

세 가지 verdict의 기록을 findings.json에 쓰고, validate-findings.cjs로 검증합니다.

Phase 5: 독립 기록 확인

완전히 새로운 Agent가 최종 소스 주장을 확인합니다. 실질적인 대체가 있으면, 대체된 내용은 다시 또 다른 독립 verifier에게 넘겨집니다.

Phase 6: 목표 중립 보고

검증된 기록과 커버리지 원장으로부터 REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md를 도출합니다.

세 가지 Verdict: 의미의 명료함

이것이 security-audit의 설계에서 가장 배울 만한 점입니다——verdict는 "고/중/저 위험"이 아니라 "증거 완전도"입니다:

Verdict 의미 confirmed 완전한 소스 trace가 있고, 경계가 정해진 재현 가능한 관찰 결과가 있음 needs_validation 하나의 정확한 미해결 사실이 있으나, 심각도가 표시되지 않음 rejected 반증된 후보(그것을 왜 부정했는지 기록함)

핵심 원칙: "하나의 소스 증거가 뒷받침하는 의혹" ≠ "확인된 취약점". 어떤 lead가 샌드박스 제한 때문에 검증을 실행할 수 없을 때, 그것은 needs_validation으로 유지되며, 성급하게 confirmed로 표시되거나 버려지지 않습니다.

설계 원칙

1. 적대적 검증

발견을 검사하는 Agent는, 결코 그것을 발견한 Agent가 아닙니다. 이는 모델의 "자기 확인"을 방지합니다——자기가 발견한 문제를 자기가 다시 검증하면, 확인 쪽으로 기우는 경향이 있기 때문입니다.

2. 심각도에는 영향이 필요하다

심각도 = 가능성 × 영향이며, "checklist에서 얼마나 벗어났는가"가 아닙니다. 목록에는 맞지만 실제 영향이 없는 문제는 취약점이 아닙니다.

3. 심층 방어의 결손은 취약점이 아니다

만약 Layer A가 이미 공격을 막고 있다면, Layer B의 부재는 단지 강화 권고(hardening note)일 뿐, 취약점이 아닙니다.

4. 여러 차례 실행이 커버리지를 높인다

Cloudflare의 실측: 단일 실행으로 찾은 취약점은, 여러 차례 실행으로 누적해 찾은 것의 대략 절반에 불과합니다. 그래서 skill은 "같은 저장소에 대한 여러 차례 실행이 누적 가능하도록" 설계되었습니다——매 회차는 이전 회차의 원장과 발견을 사용해 결손을 찾아냅니다.

커버리지 원장: 감사를 누적 가능하게 만들기

coverage-ledger.json은 이 skill의 핵심 데이터 자산입니다.

일반적인 보안 감사는 일회성입니다——한 번 돌리고, 보고서 한 부를 내고, 다음에 다시 돌리면 영에서 시작하는 것과 같습니다. security-audit의 원장은 감사를 증분 가능하게 만듭니다:

첫 번째 감사: → coverage-ledger.json 생성(어떤 단위가 커버되었는지, 어떤 것이 확인되었는지, 어떤 것이 의혹인지 기록) → N개의 취약점 발견 두 번째 감사(같은 저장소): → 이전 회차의 원장과 findings를 읽음 → "미커버 결손"과 "변경된 소스"만을 대상으로 다시 사냥 → "현재 소스에 여전히 증거가 뒷받침되는" 옛 발견을 이어서 가져옴 → "오래되었거나 미해결인 옛 발견"을 이미 커버된 것으로 취급하지 않음

각 단위에는 상태가 있습니다: planned(계획) → in_progress(진행 중) → completed(완료) / deferred(예산 때문에 연기). 어떤 단위가 agent 수 제한 때문에 할당될 수 없다면, 그것은 명시적으로 deferred로 표시되며, 조용히 버려지지 않습니다.

기계가 읽을 수 있는 발견 기록

findings.json은 report-schema.json이 정의한 schema를 따르며, 의존성 제로의 검증기와 함께 동작합니다:

파일 역할 report-schema.json 세 가지 verdict의 JSON schema validate-findings.cjs 의존성 제로 검증기(Phase 4/5에서 사용) validate-coverage-ledger.cjs 커버리지 원장 검증기(Phase 1-5에서 사용)

부모 Agent는 원장을 생성한 후, 그리고 원장을 갱신할 때마다 validate-coverage-ledger.cjs를 실행합니다; Phase 4에서, 그리고 매 Phase 5 대체 후에 validate-findings.cjs를 실행합니다.

이 "기계가 읽을 수 있음 + 독립 검증" 설계 덕분에, 감사 산출물은 사람만 볼 수 있는 PDF 한 부가 아니라, 하위 도구 체인에 연결될 수 있습니다.

샌드박스 요구사항: 정직한 경계

security-audit은 명확히 요구합니다: 대상이 통제하는 코드를 실행할 때는, 반드시 OS가 강제하는 샌드박스 안에서 해야 합니다.

샌드박스는 반드시:

- 외부 네트워크를 금지

- 정화된 allowlist 환경을 사용

- 리소스 제한을 강제

- 지정된 scratch 경로에만 쓰기를 허용

이러한 통제가 가용하지 않으면, 워크플로는 대상 코드를 실행하지 않고, lead를 needs_validation으로 유지합니다.

이것은 매우 정직한 엔지니어링 결정입니다: 확인하지 않는 한이 있더라도, 안전 경계 없이 악성일 수 있는 코드를 실행하지 않는다. AI 보안 감사 도구에서 "검증 경계"에 대한 이런 명확한 태도는 "나는 PoC를 자동으로 돌릴 수 있다"보다 더 신뢰할 만합니다.

참고 자료

- 🌟 GitHub: cloudflare/security-audit-skill

- 📝 배경 블로그: Build your own vulnerability harness

- 🔧 Skills CLI: skills.sh

- ✉️ 연락처: security-ai-research@cloudflare.com

총평

security-audit은 하나의 판단을 대표합니다: AI 보안 감사의 병목은 "모델이 취약점을 발견할 수 있는가"가 아니라 "발견한 결과를 신뢰할 수 있는가"에 있습니다.

세 가지 점이 주목할 만합니다:

적대적 검증은 신뢰도의 핵심이다. 많은 AI 감사 도구의 문제는 발견과 검증을 같은 모델이 수행한다는 것입니다——모델이 찾은 "취약점"을 모델이 다시 검증하면, 필연적으로 확인 편향이 생깁니다. security-audit은 "검사자≠발견자"라는 구조화된 제약으로, 이런 편향을 프로세스 차원에서 잘라냅니다.

Verdict 의미 = 증거 완전도이며, 위험 등급이 아니다. confirmed / needs_validation / rejected 세 상태가 서술하는 것은 "증거 사슬이 어느 단계에서 끊겼는가"이지, "이 문제가 얼마나 심각한가"가 아닙니다. 심각도(가능성×영향)는 confirmed 내부의 하나의 필드입니다. 이런 분리는 감사 결과를 기계가 처리할 수 있게 하고, 보안 팀이 신뢰할 수 있게 합니다.

커버리지의 누적 가능성은 "감사는 일회성"이라는 오래된 문제를 해결한다. 전통적인 보안 감사는 끝나면 곧 낡아집니다. security-audit의 커버리지 원장은 감사를 증분 가능하게 만듭니다: 매번 실행이 이전 커버리지 기반 위에 세워지고, 결손만 보충하고, 변경만 재검증합니다. 이는 "주기적 감사"보다 "지속적 보안"에 더 가깝습니다.

만약 당신이 coding agent로 보안 관련 작업을 하고 있거나, AI가 산출한 보안 결론을 어떻게 신뢰할 수 있게 만들지 이해하고 싶다면, security-audit은 현재 가장 완성도 높은 오픈소스 참고 자료입니다.

PrimeSkills 탐색 —— 엄선된 AI 에이전트와 스킬 도구, 각각 실제 워크플로로 검증되었습니다. 과장은 없고, 정말 유용한 도구만 있습니다.

더 많은 인사이트와 흥미로운 제품을 보려면 제 개인 홈페이지를 방문하세요.

冬奇Lab

소프트웨어 아키텍처

글 512

조회수 325k

팔로워 753