Anthropic 보안 하네스, 취약점 대응을 제품화하다

발견보다 검증이 병목이 됐다

Anthropic의 Defending Code Reference Harness는 Claude 기반 취약점 발견과 패치 과정을 공개한 참조 구현이다. README는 이 저장소가 유지보수되는 제품이 아니라, 보안팀과 협업하며 얻은 일반적 패턴을 담은 오픈소스 참고 구현이라고 못박는다. 핵심 구성은 Claude Code 스킬과 autonomous pipeline이다. 전자는 threat model, vuln scan, triage, patch 같은 상호작용 워크플로를 제공하고, 후자는 C와 C++ 메모리 취약점을 대상으로 Docker, ASAN, gVisor 샌드박스를 엮어 recon, find, verify, report, patch 단계를 돈다.

중요한 메시지는 단순하다. AI는 취약점 후보를 많이 찾을 수 있게 만들었지만, 보안팀의 진짜 비용은 후보를 재현하고, 중복을 제거하고, 패치가 실제로 막았는지 확인하는 데로 옮겨갔다. Anthropic의 동반 글 Using LLMs to secure source code는 2026년 5월 22일 기준 오픈소스 스캔에서 1,596건을 공개했고 97건이 패치됐다고 설명한다. 이 숫자는 발견량과 실제 수정량 사이의 간극을 보여주는 지표다.

CISA 키 유출, 에이전트 시대 비밀관리 경고, Copilot Cowork 유출 실험, 에이전트 보안의 경고, 도메인 위장 프롬프트 공격은 모두 에이전트가 보안 경계를 흐릴 때 생기는 문제를 다뤘다. 이번 하네스는 공격 표면이 아니라 방어 운영 자체가 에이전트화되는 장면이다.

하네스의 설계가 말하는 것

하네스는 보안 업무를 하나의 거대한 프롬프트로 처리하지 않는다. 위협 모델을 만들고, 탐색 범위를 나누고, 발견 에이전트와 검증 에이전트를 분리하고, 패치 뒤 다시 공격해 보는 루프로 만든다. README에 따르면 autonomous pipeline은 target code를 실행하기 때문에 gVisor 샌드박스 밖에서는 실행을 거부하도록 설계됐다. 에이전트에게 말로 네트워크를 쓰지 말라고 하는 것이 아니라, 네트워크와 파일시스템을 실제로 제한하는 구조다.

이 점은 한국 보안팀에도 중요하다. 사내 소스와 비밀키, 테스트 데이터가 섞인 저장소에서 AI 보안 스캔을 돌릴 때 가장 위험한 선택은 "믿을 만한 모델이니까 괜찮다"는 접근이다. 모델이 선의로 움직여도 PoC를 실행하고 의존성을 내려받고 로그를 읽는 순간 권한 사고가 생긴다. 따라서 격리, 재현성, egress 제한은 옵션이 아니라 기본이다.

Anthropic의 사업 신호

이 저장소는 공개 참고 구현이지만, README는 관리형 옵션으로 Claude Security를 연결한다. 즉 Anthropic은 보안 에이전트를 단순 데모가 아니라 제품 카테고리로 보고 있다. SAST, DAST, bug bounty, code review가 나뉘어 있던 시장에서 AI 에이전트는 "찾기-검증-패치"를 하나의 운영 루프로 묶으려 한다.

경쟁 구도도 바뀐다. GitHub Advanced Security, Snyk, Semgrep, HackerOne 같은 기존 플레이어는 이미 개발 워크플로에 깊게 들어와 있다. Anthropic의 차별점은 프런티어 모델과 Claude Code 생태계를 보안 워크플로의 실행 주체로 삼는 데 있다. 다만 모델이 잘 찾는다는 주장만으로는 부족하다. 보안 구매자는 발견 수보다 검증률, 재현 가능한 PoC, triage 비용, 패치 회귀율을 본다.

한국 기업이 바로 볼 체크포인트

첫째, AI 보안 스캔은 위협 모델 파일을 먼저 요구해야 한다. 인증된 내부 사용자, 관리자 설정, 외부 입력, batch job의 신뢰 수준을 문서화하지 않으면 모델은 위험도를 과장하거나 실제 공격 경로를 놓친다. 둘째, 샌드박스는 격리와 재현성을 동시에 만족해야 한다. Docker만으로 충분한지, gVisor나 Firecracker 같은 더 강한 경계가 필요한지는 코드의 위험도와 PoC 실행 범위에 따라 정해야 한다.

셋째, 발견량을 KPI로 삼지 말아야 한다. 발견량은 곧 triage 부채가 된다. 개발팀이 하루에 소화할 수 있는 high-confidence 결과를 만드는 것이 더 중요하다. Runtime, 팀 단위 코딩 에이전트 운영체제를 겨냥하다에서 봤듯 에이전트 운영은 병렬화보다 검증과 소유권 설계가 더 어렵다.

자주 묻는 질문

Q1: 이 저장소를 그대로 운영에 쓰면 되나요?

A: 아니다. README도 reference harness라고 설명한다. 조직의 언어, 프레임워크, 취약점 클래스, 배포 구조에 맞게 커스터마이즈해야 한다.

Q2: 왜 gVisor 같은 샌드박스가 필요한가요?

A: autonomous pipeline은 target code와 PoC를 실행한다. 네트워크, 비밀키, 홈 디렉터리 접근을 코드 수준에서 막지 않으면 에이전트 행동을 통제하기 어렵다.

Q3: AI 보안 스캔의 KPI는 무엇이 좋나요?

A: 후보 수보다 검증된 취약점 비율, 중복률, 패치 성공률, 회귀 테스트 통과율, 개발팀 triage 시간을 보는 편이 낫다.

Q4: 기존 SAST와 대체 관계인가요?

A: 완전 대체보다 보완에 가깝다. SAST가 안정적 규칙을 담당하고, 에이전트는 복합 경로 분석, PoC 작성, 패치 검증에 강점을 가질 수 있다.

Q5: 한국 기업은 어디서 시작하면 되나요?

A: 민감도가 낮은 내부 서비스 하나를 고르고 threat model, sandbox, 독립 verifier, patch review 체계를 작은 루프로 만든 뒤 범위를 넓히는 것이 현실적이다.