---
title: "앤트로픽, Claude로 취약점 찾고 고치는 오픈소스 하네스 공개"
published: 2026-06-04T20:11:20.000Z
canonical: https://jeff.news/article/3715
---
# 앤트로픽, Claude로 취약점 찾고 고치는 오픈소스 하네스 공개

앤트로픽이 Claude를 이용해 코드 취약점을 찾고, 검증하고, 리포트하고, 패치까지 이어가는 참조 구현을 공개했다. 핵심은 정적 리뷰만 던지는 게 아니라, C/C++ 타깃을 Docker와 ASAN으로 빌드한 뒤 여러 에이전트가 재현 가능한 크래시를 찾고 별도 에이전트가 검증하는 파이프라인이다. 다만 저장소 자체는 제품이 아니라 참고용이며, 유지보수와 기여도 받지 않는다고 못 박았다.

- 앤트로픽이 Claude로 취약점을 찾고 고치는 오픈소스 참조 하네스를 공개함
  - 이름 그대로 제품이라기보단 보안팀이 자기 파이프라인을 만들 때 참고하라는 구현체에 가까움
  - 저장소도 “유지보수 안 함, 기여 안 받음”이라고 명시돼 있음. 즉, 바로 사내 표준 도구로 들고 오기보단 구조를 뜯어보는 용도

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

> [!IMPORTANT]
> 이 하네스의 핵심은 ‘취약점 같아 보이는 코드’를 찾는 데서 멈추지 않는다는 점임. 별도 검증 에이전트가 깨끗한 컨테이너에서 proof of concept만 받아 다시 재현해 봄.

- 검증 이후에도 중복 제거와 리포트 단계가 따로 있음
  - `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를 돌림

> [!WARNING]
> 자율 파이프라인은 타깃 코드를 실제로 실행함. 그래서 gVisor 샌드박스 밖에서는 기본적으로 실행을 거부하고, 네트워크도 Claude API 쪽으로만 제한하는 설계를 깔고 감.

- 보안 모델 쪽 디테일도 꽤 현실적임
  - `/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가 안 터짐”은 회귀 테스트 하나를 통과한 것뿐이라서, 비슷한 입력으로 우회가 되는지 한 번 더 압박하는 구조예요. 실무에서 자동 패치가 위험한 이유를 꽤 잘 알고 만든 흐름이에요.

## 핵심 포인트

- Claude 기반 취약점 탐색 흐름을 정찰, 탐색, 검증, 중복 제거, 리포트, 패치 단계로 나눠 공개
- 자율 에이전트 실행은 gVisor 샌드박스와 Claude API로 제한된 네트워크 접근을 전제로 설계
- C/C++ 메모리 취약점에는 ASAN 크래시를 신호로 쓰지만, 다른 언어나 취약점 유형으로 포팅할 수 있게 구성
- 앤트로픽은 첫날 정적 스캔부터 둘째 날 자율 파이프라인, 첫 주 커스터마이징, 둘째 주 반복 운영으로 가는 도입 로드맵을 제안

## 인사이트

보안팀 입장에선 ‘AI가 취약점 찾아줌’ 같은 마케팅보다 훨씬 볼 만한 자료다. 특히 false positive를 줄이려고 별도 컨테이너에서 재현 검증을 거치고, 패치 후에도 새 탐색 에이전트로 우회 가능성을 보는 구조가 꽤 현실적이다.