코딩 에이전트는 보안 버그를 얼마나 잘 찾아내고 증명할 수 있을까?

코딩 에이전트는 보안 버그를 몇 초 만에 작성할 수 있습니다. 흥미로운 질문은 그것을 포착하고, 거짓말 없이 증명해낼 수 있느냐는 것입니다.

Cloudflare가 내부 버그 탐지 시스템을 시작하게 한 스킬을 오픈소스로 공개했으며, 오늘날 이 스킬은 GitHub 트렌딩 상위권을 차지하고 있습니다.

WHAT IT IS

security-audit는 코딩 에이전트를 위한 MIT 라이선스 스킬입니다. 이 스킬은 에이전트를 보안 감사자(security auditor)로 변모시켜 6단계에 걸친 구조화된 감사를 수행합니다:

1. 정찰(Reconnaissance): 아키텍처, 신뢰 경계(trust boundaries), 입력 표면(input surfaces)을 architecture.md와 coverage-ledger.json에 매핑합니다.
2. 커버리지 기반 탐지(Coverage-led hunting): 격리된 탐지자 에이전트가 레저를 따라 작업합니다.
3. 후보 검증(Candidate validation): 모든 후보는 이를 반증하려는 새로운 검증자(verifier)에게 전달됩니다.
4. 구조화된 출력(Structured output): findings.json을 스키마에 따라 확인합니다.
5. 독립적인 기록 검증(Independent record verification): 새로운 에이전트가 최종 소스 주장을 재확인합니다.
6. 보고서 작성(Reporting): REPORT.md, FINDINGS-DETAIL.md, 그리고 NEEDS-VALIDATION.md를 생성합니다.

핵심 규칙: 발견된 내용을 확인하는 에이전트는 절대 그것을 발견한 에이전트가 아닙니다. 모든 결과는 '확인됨(confirmed)', '검증 필요(needs_validation)', 또는 '거부됨(rejected)'으로 라벨링됩니다. '확인됨' 판정을 받은 발견은 완전한 소스 추적(source trace)이 필요합니다.

Cloudflare에 따르면 이 스킬은 취약점 탐지 하네스(vulnerability discovery harness)의 시초가 되었으며, 이후 128개의 리포지토리(repos)를 스캔하는 시스템으로 성장했습니다.

A DETAILED USE CASE

주말에 작은 웹 앱을 만들었고, 곧 이 리포지토리를 공개할 예정입니다. 코드를 너무 자주 읽어서 그 구멍들을 볼 수 없습니다.

리포지토리에서 코딩 에이전트를 열고 다음과 같이 요청합니다:
do a security review, output to ~/audits/my-project

이 스킬은 먼저 앱을 매핑한 다음, 다양한 공격 클래스에 대해 별도의 탐지자들을 보냅니다. 웹 및 인증(auth), 클라이언트 측면, 공급망(supply chain), 그리고 LLM 앱을 위한 프롬프트 인젝션(prompt injection)에 대한 전용 플레이북을 제공합니다. 탐지자가 플래그를 지정한 모든 내용은 그것이 틀렸음을 증명하는 것이 유일한 임무인 검증자(verifier)를 통과해야 합니다.

사용자는 조치할 수 있는 보고서와 인간의 도움이 여전히 필요한 리드 목록을 받게 됩니다. 이 목록은 잡음(noise)이 아니라 작업 대기열(work queue)입니다.

그런 다음 다시 실행합니다. README에 따르면 한 번의 실행으로는 반복적인 실행이 찾아낸 것의 약 절반만을 발견했으며, 후속 실행은 이전 기록(ledger)과 발견 사항을 기반으로 격차를 목표로 삼습니다.

사용 방법 (HOW TO RUN IT)
Skills CLI로 설치하기:

npx skills add https://t.co/124vxA2wqT
--skill security-audit

사용자 레벨 설치를 위해:

npx skills add https://t.co/124vxA2wqT
--skill security-audit
--global

그런 다음 에이전트에게 요청하기만 하면 됩니다:

security audit this codebase

또는

find security vulnerabilities in ./src

요구 사항: 도구 사용(tool use) 및 병렬 서브 에이전트(parallel sub-agents)를 지원하는 모델을 가진 에이전트, 제로 의존성 검증기(zero-dependency validators)를 위한 Node.js, 그리고 대상 코드를 실행하려면 OS가 강제하는 샌드박스(sandbox)가 필요합니다. 이러한 샌드박스가 없으면, 실제로 아무것도 실행하지 않고도 lead를 needs_validation으로 유지합니다.

중요한 이유 (WHY IT MATTERS)
Cloudflare 자체의 글에는 훌륭한 세부 사항이 하나 있습니다: 그들은 Semgrep을 하니스(harness)에 연결했고, 헌터 에이전트(hunter agents)는 한 달 동안 이를 단 한 번도 호출하지 않았습니다. 그들은 코드를 읽고 실행하는 것을 선호했습니다.

배울 점은 "더 나은 모델을 사용하라"가 아닙니다. 그것은 모델의 말을 절대적으로 신뢰하지 않는 프로세스를 구축하는 것입니다. #AppSec #AI