앤트로픽, Claude로 취약점 찾고 고치는 오픈소스 하네스 공개

• 앤트로픽이 Claude로 취약점을 찾고 고치는 오픈소스 참조 하네스를 공개함

  • 이름 그대로 제품이라기보단 보안팀이 자기 파이프라인을 만들 때 참고하라는 구현체에 가까움
  • 저장소도 “유지보수 안 함, 기여 안 받음”이라고 명시돼 있음. 즉, 바로 사내 표준 도구로 들고 오기보단 구조를 뜯어보는 용도

• 파이프라인은 recon → find → verify → report → patch 흐름으로 돌아감

  • 정찰 단계에선 코드베이스를 읽고 “입력 파싱 서브시스템을 N개로 나누면 어디를 따로 공격해볼 만한가”를 제안함
  • 탐색 단계에선 N개의 에이전트가 각각 격리된 컨테이너에서 malformed input을 만들고 ASAN 바이너리를 돌림
  • 크래시는 그냥 한 번 터졌다고 끝이 아니라, 같은 입력이 3번 중 3번 재현돼야 후보로 올라감

• 검증 이후에도 중복 제거와 리포트 단계가 따로 있음

  • verify 단계에선 find 에이전트가 만진 환경과 분리된 새 컨테이너에서 크래시를 재현함
  • dedupe 단계에선 이미 보고된 버그인지, 기존 버그의 더 좋은 재현 사례인지, 진짜 새 버그인지 판정함
  • report 단계에선 primitive class, reachability, escalation path, severity 같은 exploitability 분석을 구조화해서 남김

• 패치도 그냥 diff 생성으로 끝내지 않음

  • 패치 에이전트가 수정안을 만들면 grader 에이전트가 빌드 성공 여부를 확인함
  • 원래 proof of concept 입력이 더는 크래시를 내지 않는지도 확인함
  • 테스트 스위트가 계속 통과하는지, 새 find 에이전트가 패치를 우회하는 방법을 찾지 못하는지도 본다고 함

• 기본 타깃은 C/C++ 메모리 취약점임

  • Docker로 타깃을 빌드하고, clang과 ASAN을 써서 메모리 오류를 잡는 구조
  • finding 신호는 ASAN crash signature, proof of concept은 crashing input file, 실행 환경은 타깃별 Dockerfile이 기준
  • 다른 언어나 취약점 유형으로 옮기려면 “무엇을 finding으로 볼 건가”, “PoC는 어떤 형태인가”, “타깃을 어떻게 빌드하고 실행할 건가”를 바꿔야 함

• 앤트로픽이 제안하는 도입 속도가 꽤 공격적임

  • Day 1: threat model을 만들고 정적 스캔, triage, 후보 패치까지 한 바퀴 돌림
  • Day 2: 알려진 취약점이 있는 오픈소스 C/C++ 라이브러리에 자율 파이프라인을 돌림
  • Days 3-5: 자기 코드베이스에 맞게 하네스를 커스터마이징함
  • Week 2: 여러 번 스캔하고, 결과를 모아 triage하고, 우선순위대로 패치하는 outer loop를 돌림

• 보안 모델 쪽 디테일도 꽤 현실적임

  • /quickstart, /threat-model, /vuln-scan, /triage는 파일 읽기와 쓰기만 해서 인터랙티브 승인 기반으로 샌드박스 없이도 쓸 수 있다고 설명함
  • 반면 자율 에이전트가 도는 reference pipeline과 pipeline 결과에 대한 /patch는 타깃 코드를 실행하므로 샌드박스가 필수에 가까움
  • setup은 scripts/setup_sandbox.sh를 한 번 실행한 뒤 bin/vp-sandboxed로 파이프라인을 돌리는 식

• 앤트로픽이 은근히 강조하는 건 “처음부터 완벽한 파이프라인 설계하지 말고 Day 1에 손부터 대라”는 태도임

  • 정적 리뷰 결과는 false positive가 많을 수 있으니, 빠르게 전체 루프를 경험한 뒤 실행 검증으로 넘어가라는 흐름
  • 실제 운영에선 한 번의 pipeline run이 자체적으로 검증과 중복 제거를 하더라도, 여러 run을 묶어 triage하는 바깥 루프가 필요하다고 봄
  • 버그를 빨리 고치면 모델이 같은 버그를 다시 찾지 않고 더 깊은 이슈를 찾게 된다는 설명도 흥미로움

• 그래도 자율 triage와 patching은 아직 병목이라고 솔직히 말함

  • severity와 우선순위는 결국 각 조직의 위협 모델과 운영 환경 판단이 들어감
  • 검증된 패치라고 해도 항상 upstream 가능한 품질이라는 보장은 없음
  • 많은 파트너가 triage와 patching을 현재 병목으로 보고 있어서, 실제 엔지니어링 시간을 따로 잡으라고 함

---

기술 맥락

• 이 구현의 선택은 LLM을 ‘코드 리뷰어’로만 쓰지 않고, 실행 가능한 취약점 탐색 루프 안에 넣은 거예요. 보안팀이 진짜 원하는 건 그럴듯한 지적이 아니라 재현 가능한 크래시와 우선순위거든요.

• ASAN을 신호로 삼은 이유도 명확해요. C/C++ 메모리 버그는 크래시가 비교적 강한 증거가 될 수 있고, 같은 입력이 반복 재현되면 false positive를 꽤 줄일 수 있어요. 대신 이 방식은 웹 앱 논리 버그나 권한 우회 같은 이슈엔 그대로 맞지 않아서, finding 신호와 PoC 형식을 바꿔야 해요.

• gVisor 샌드박스를 강하게 요구하는 것도 중요한 결정이에요. 에이전트가 취약점을 찾겠다고 타깃 코드를 실행하다 보면, 테스트 대상 코드가 곧 공격 표면이 돼요. 그래서 네트워크를 Claude API로 제한하고, 컨테이너 격리를 추가하는 설계가 들어간 거예요.

• 패치 검증에서 새 find 에이전트를 다시 돌리는 점도 재밌어요. 단순히 “기존 PoC가 안 터짐”은 회귀 테스트 하나를 통과한 것뿐이라서, 비슷한 입력으로 우회가 되는지 한 번 더 압박하는 구조예요. 실무에서 자동 패치가 위험한 이유를 꽤 잘 알고 만든 흐름이에요.