보안 점검을 맡겼더니 의심스러운 코드 목록은 길어졌는데, 무엇부터 고쳐야 할지 더 어려워지는 경우가 있다. 실제로 다른 고객의 데이터에 접근할 수 있는 결함인지, 배포 설정을 더 알아야 하는지, 이미 다른 방어 장치가 막고 있는지를 나누지 않으면 개발팀은 확인되지 않은 문제를 좇게 된다.
Cloudflare의 security-audit는 코딩 에이전트에 이런 구분 절차를 더하는 공개 스킬이다. 별도 보안 제품을 띄우는 대신, 코드를 읽고 도구를 실행하는 에이전트에 조사·반증·기록 방법을 제공한다. 설치 후 얻을 것은 ‘안전하다’는 인증이 아니라, 확인된 결함과 추가 확인할 조건, 아직 살펴보지 못한 범위가 나뉜 점검 기록이다.
security-audit 설치 방법과 설치 확인
먼저 도구 사용과 병렬 서브에이전트를 지원하는 코딩 에이전트가 있어야 한다. 서브에이전트는 조사할 일을 나눠 맡는 별도 작업자다. Node.js도 필요하다. 설치 명령에 쓰는 npx와 결과 검사 스크립트가 이 실행 환경을 사용한다. 터미널에서 node --version과 npx --version을 실행해 버전이 표시되는지 확인한다. 이미 코딩 에이전트로 프로젝트를 다루는 독자를 위한 절차이며, Node.js를 설치하는 과정과 에이전트 자체 설치는 별개다.
점검할 저장소의 폴더에서 공식 README의 다음 명령을 실행한다. 설치 대상 에이전트와 프로젝트 범위를 선택하는 안내가 나온다. 처음에는 해당 프로젝트에만 설치하면 다른 작업에 영향을 덜 준다.
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit사용자 계정의 여러 프로젝트에서 공통으로 쓰려면 같은 명령 끝에 --global을 붙인다. 설치 대상과 확인 절차를 고정하는 옵션은 npx skills --help로 확인할 수 있다. Claude Code에 프로젝트 범위로 설치하는 비대화식 예시는 다음과 같다.
npx --yes skills add https://github.com/cloudflare/security-audit-skill --skill security-audit --agent claude-code --yes
npx skills list --json목록에 security-audit, 선택한 에이전트, 프로젝트 범위가 표시되면 등록을 확인할 수 있다. 별도 임시 폴더에서 위 경로로 설치했을 때 Claude Code용 스킬 폴더와 검사 스크립트가 생성됐고, 목록의 범위는 project였다. 이는 설치 확인 결과이며 서비스의 취약점 검사 결과는 아니다.
기존 에이전트 세션이 새 스킬을 읽지 않으면 해당 프로젝트에서 새 세션을 연다. 이후 저장소 전체의 보안 점검을 요청하거나, do a security review, output to ~/audits/my-project처럼 결과 폴더를 명시한다. 전체 점검의 기본 출력 경로는 ~/security-audit-skill/<repo-name>/run-<N>이다. 대상 저장소 안에 결과를 남기려면 사용자가 그 위치를 지정하고 버전 관리에서 제외됐는지 확인해야 한다.
발견한 작업자에게 확인까지 맡기지 않는다
전체 점검은 먼저 구조와 신뢰 경계를 파악한다. 신뢰 경계란 일반 사용자가 관리자 기능을 호출하거나 한 고객이 다른 고객의 자료를 읽는 것처럼, 권한이 달라지는 지점이다. 어느 입력과 경계를 어떤 공격 유형으로 살펴볼지 장부에 기록한 뒤 조사 작업을 나눈다. 결과가 없었다는 말만으로 검사 완료를 표시하지 않는다.
의심 후보가 나오면 이를 찾지 않은 새 작업자가 반증한다. 요청이 실제로 문제의 함수까지 도달하는지, 앞단의 권한 검사나 정규화가 막는지, 관찰한 결과가 다른 사용자의 권리를 침해하는지 현재 소스에서 다시 살핀다. ‘추가 방어 장치가 없다’는 사실만으로 취약점으로 확정하지 않는 이유다.
최종 기록은 세 갈래다. confirmed는 전체 소스 경로와 제한된 범위의 관찰 결과가 갖춰진 경우다. needs_validation은 소스가 뒷받침하는 가설이지만 배포 설정 등 결정적인 사실이 남은 경우이며 심각도를 붙이지 않는다. rejected에는 반증된 후보와 이유를 남긴다. 아직 검증자에게 넘기지 못한 후보를 미확인 판정으로 바꿔 완료 처리해서도 안 된다.
예를 들어 파일 조회 함수에서 소유자 확인이 보이지 않아도, 모든 요청이 그 앞의 공통 권한 검사를 통과한다면 우회가 성립하는지부터 다시 따져야 한다. 배포 환경의 접근 정책이 결정적이지만 코드에 없다면 그 정책을 확인할 과제로 남긴다. 이런 구분이 있어야 개발팀이 소스 수정과 운영 설정 확인을 다른 담당자에게 넘길 수 있다.
검사 스크립트의 통과는 취약점 입증과 다르다
기록은 findings.json, 검사 범위는 coverage-ledger.json에 남긴다. 이를 바탕으로 요약 보고서 REPORT.md, 상세 근거 FINDINGS-DETAIL.md, 추가 확인 과제 NEEDS-VALIDATION.md를 작성한다. 다음 명령의 <skill-dir>는 설치된 스킬 폴더, <output-dir>는 이번 점검의 결과 폴더로 바꾼다.
node <skill-dir>/validate-findings.cjs <output-dir>/findings.json
node <skill-dir>/validate-coverage-ledger.cjs <output-dir>/coverage-ledger.json검사기는 추가 패키지 없이 Node.js로 실행된다. 판정에 맞지 않는 필드나 검사 장부의 모순을 걸러내지만, 기록된 취약점이 진짜인지는 별도 검증자가 확인해야 한다. 공식 저장소의 두 검사기 테스트를 실행했을 때 65개가 통과하고 실패는 0개였다. 이 수치는 검사기 테스트의 결과이지 특정 서비스의 안전성을 측정한 값이 아니다.
코드를 실행하기 전에 격리 환경부터 갖춘다
의심스러운 저장소의 빌드·테스트 자체가 코드를 실행한다. 스킬은 대상 코드 실행에 운영체제가 강제하는 샌드박스를 요구한다. 외부 네트워크를 차단하고, 허용한 값만 넣은 빈 환경에서 시작하며, 대상 소스와 도구는 읽기 전용으로 둬야 한다. 쓰기는 지정한 임시 경로에 한정하고 CPU·메모리·프로세스·파일 크기·디스크·실행 시간에 제한을 건다. 단순히 ‘임시 폴더에서 실행하라’고 요청하는 것으로는 이 조건을 충족하지 않는다.
이 통제가 없으면 대상 코드를 실행하지 않고, 빠진 격리 기능을 추가 확인의 차단 조건으로 남기는 것이 정해진 흐름이다. 운영 중인 주소나 다른 이용자의 데이터를 상대로 시험하지 않으며, 재현에는 가짜 계정과 데이터를 쓴다. 코드와 설정을 읽는 점검도 모델에 자료를 전달할 수 있으므로 사내 소스 취급 정책과 에이전트의 도구 권한을 먼저 정해야 한다.
한 저장소의 시작점과 사내 대규모 시스템을 구분한다
Cloudflare는 이 스킬을 출발점으로 여러 저장소를 지속적으로 조사하는 사내 시스템을 만들었다. 2026년 6월 공개한 운영 사례에서는 탐색 시스템의 원시 후보 20,799건 중 12,057건이 독립 검증을 통과했다. 나머지에는 수동 재현이 필요한 건, 검증 중 반려된 건, 중복과 별도 경로로 이관된 건이 포함된다. 이 숫자는 공개 스킬을 설치하면 얻는 성능이나 취약점 탐지율이 아니라 당시 사내 운영의 누적 집계다.
현재 공개 저장소는 여섯 단계의 작업 흐름을 설명하며, 과거 사내 시스템 소개 글의 단계 수·자동 수정 기능을 그대로 설치 기능으로 보면 안 된다. 공개 스킬의 점검은 수정 방향을 보고하지만 대상 소스를 직접 고치지는 않는다. 보고서를 받은 팀이 재현 조건과 변경안을 검토하고 회귀 테스트를 붙이는 후속 작업이 남는다.
처음에는 담당자가 이해하는 작은 저장소나 특정 경로를 골라 검사 범위를 좁히는 편이 낫다. quick 모드는 조사 폭과 중복 검사를 줄이되 증거 기준은 유지하며, 전체 점검의 기본 모드는 standard다. 에이전트 호출 예산이 있다면 탐색뿐 아니라 반증과 최종 확인에 쓸 몫도 포함해야 한다. 무료 공개 스킬이라는 사실은 모델 사용료나 작업 시간이 무료라는 뜻이 아니다.
같은 저장소를 다시 살펴볼 때는 이전 장부와 현재 소스를 대조해 미검사 범위와 바뀐 경로를 조사한다. 한 번의 실행에서 확인된 문제가 없었다면 보고서에 적힌 범위 안에서 그렇게 읽어야 한다. 출시 전 검토나 정기 보안 점검에 붙일 때도, 팀이 받을 산출물을 ‘발견 개수’보다 확인 근거와 남은 과제로 정해 두는 편이 후속 조치를 나누기 쉽다.
출처: Cloudflare security-audit-skill · Cloudflare 취약점 점검 시스템 운영 사례