harness/ 파이프라인(C/C++ 메모리 취약점 + Docker + ASAN 기준). "제품이 아니라 레퍼런스"임을 명시하고, 타깃 코드를 실행하는 단계는 gVisor 샌드박스 밖에선 돌기를 거부하는 — 보안 도구다운 안전 설계가 인상적입니다. (저장소: anthropics/defending-code-reference-harness · Python · TrendShift 18위(06-05))이 레포가 무엇을 하는 물건인가.
LLM 보안 스캐너의 고질병은 거짓 양성(false positive) 홍수와, 의심스러운 코드를 실행하는 위험입니다. 이 하니스의 답은: 발견은 시작일 뿐 — ASAN(메모리 오류 검출기)으로 실제 크래시를 재현해야 "검증됨"이 되고, 그 실행은 반드시 gVisor 샌드박스 + 송신 허용목록(egress allowlist) 안에서만 일어납니다.
사용 동선이 친절합니다. 레포를 Claude Code로 열고 /quickstart를 치면 30초 소개 + 카나리아(일부러 심어둔 취약점) 타깃으로 첫 실행을 안내받습니다. Day 1엔 읽기/쓰기만 하는 스킬로 위협 모델→정적 스캔→트리아지→패치 초안까지 한 바퀴, Week 2부터 자율 파이프라인 — 이라는 램프업 플랜이 README에 박혀 있습니다. 참고로 이 공개 레포는 유지보수·기여를 받지 않는 스냅샷이며, 관리형이 필요하면 Claude Security 제품을 안내합니다.
트렌딩 이유 · 경쟁 대비 장점.
"AI로 보안 스캔"을 표방하는 도구는 많지만, 대부분 정적 분석 + LLM 의견에 머뭅니다. 이 레포는 실제 보안 팀들과의 협업에서 검증된 전체 루프(발견→동적 검증→중복 제거→리포트→패치→패치 검증)를 프롬프트까지 포함해 통째로 공개했다는 점에서 격이 다릅니다 — 사실상 "Anthropic은 내부적으로 이렇게 한다"의 공개판.
| 비교 항목 | 흔한 LLM 보안 스캐너 | 이 하니스 |
|---|---|---|
| 발견의 근거 | 모델 의견 ("취약해 보임") | ASAN 크래시 재현 = 동적 증거 |
| 거짓 양성 | 사용자 몫 | 다단계: judge·dedup·novelty·grade 모듈 |
| 실행 안전 | 호스트에서 그냥 실행 | gVisor 샌드박스 강제 + egress 프록시 |
| 이식성 | 고정 대상 | /customize 스킬이 언어·탐지기·취약점 클래스 포팅을 안내 |
"여기 취약할지도"가 수백 건 쌓이면 트리아지 비용이 스캔 가치를 잠식합니다. 게다가 PoC를 돌려보려면 의심 코드를 실행해야 하는데, 그 자체가 위험입니다.
find가 후보를 내면 ASAN 빌드에서 실제로 터뜨려 봅니다. 터지지 않으면 등급이 내려가고, 중복(dedup)·기존 알려진 것(novelty)이 걸러진 뒤에야 리포트가 됩니다. 패치도 같은 방식 — 고친 뒤 크래시가 사라지는지 재검증(patch_grade).
Python 하니스 + Docker/ASAN + gVisor + 스킬.
| 레이어 | 기술 | 역할 |
|---|---|---|
| 파이프라인 | Python (harness/ 모듈 20여 개) | recon·find·judge·dedup·novelty·grade·report·patch — 단계별 파일 분리. |
| 에이전트 | Claude (Agent SDK 패턴) | 각 단계를 전용 프롬프트(prompts/ 9종)로 구동. Bedrock·Vertex·Azure 등 아무 Claude API나. |
| 동적 검증 | Docker + ASAN | AddressSanitizer 빌드에서 크래시 재현 — C/C++ 메모리 취약점 기준 구성. |
| 격리 | gVisor + egress 프록시 | 타깃 코드 실행은 샌드박스 강제(bin/vp-sandboxed). 송신은 허용목록만(scripts/egress_proxy.py). |
| 인터랙티브 | .claude/skills/ 6종 | 위협모델 인터뷰·스캔·트리아지·패치 — 읽기/쓰기 전용이라 비샌드박스 안전. |
| 검증 데이터 | .claude/skills/triage/fixtures/canary-findings.json | /triage 스킬의 카나리아 픽스처 — 일부러 심은 취약점으로 파이프라인 자체를 테스트. |
의심 코드 한 줄이 검증된 패치가 되기까지.
읽어볼 가치가 가장 큰 부분은 prompts/ 디렉토리입니다. find(발굴)·judge(심판)·grade(채점)·report_grader(리포트 채점)·patch(수정) — 단계마다 전용 프롬프트가 분리돼 있고, "발굴은 공격적으로, 심판은 회의적으로"라는 역할 분담이 프롬프트 문장에 그대로 구현돼 있습니다. 생성자와 검증자를 분리해 서로 견제시키는 구조는 LLM 파이프라인 일반에 통하는 설계입니다.
제보(find) → 검찰 수사로 물증 확보(ASAN 재현) → 판사의 판결(judge) → 전과 조회(novelty/dedup) → 공소장 작성(report) → 재발 방지 대책과 그 효과 검증(patch_grade) — 형사 절차의 견제와 균형을 보안 스캔에 옮긴 모양새입니다.
어떤 폴더가 무슨 일을 하나.
| 위치 | 주목할 점 |
|---|---|
harness/prompts/ | 실전 검증된 보안 프롬프트 9종 — 이 레포의 진짜 보석. |
docs/security.md + agent-sandbox.md | "무엇을 마운트하면 안 되는가"까지 — 에이전트 샌드박싱 문서의 모범. |
.claude/skills/threat-model/ | 인터뷰→스키마→부트스트랩 3단 구성 — 위협 모델을 대화로 뽑는 형식. |
scripts/egress_proxy.py | 송신 허용목록 프록시 — 데이터 유출 차단의 구체 구현. |
이 레포에서 배울 만한 것 + 어디를 보면 되는지.
find(공격적) ↔ judge(회의적) ↔ ASAN(물증) ↔ dedup/novelty(중복·기지 필터)의 체인은 거짓 양성과 싸우는 LLM 파이프라인의 일반 해법으로 이식 가능합니다.
읽기/쓰기 스킬과 코드 실행 파이프라인의 위험 등급을 갈라, 후자에 gVisor를 강제하고 기본 거부로 설계한 것 — 에이전트 제품의 안전 등급 설계 견본입니다(sandbox.py·bin/vp-sandboxed).
recon은 무엇을 먼저 보는지, judge는 어떤 기준으로 기각하는지 — prompts/를 정독하면 보안 도메인 프롬프트 엔지니어링의 밀도를 체감할 수 있습니다.
"완벽한 파이프라인 설계에 몇 달 쓰지 말고 첫날 손을 더럽혀라" — 신기술 도입 가이드 문서로서도 README가 잘 쓰였습니다.
돌리려면 무엇이 필요한가.
| 항목 | 요구사항 |
|---|---|
| 인터랙티브 스킬 | Claude Code만 — 읽기/쓰기 전용이라 도구 승인하며 쓰면 샌드박스 불필요. |
| 자율 파이프라인 | Python + Docker + gVisor (setup_sandbox.sh로 구성, Linux 권장) + Claude API 접근(직접·Bedrock·Vertex·Azure). |
| 대상 코드 | 기준 구성은 C/C++ + ASAN — 다른 언어는 /customize로 포팅. |
| 주의 | 본인 권한이 있는 코드에만 사용 — 방어 목적의 레퍼런스이며, 레포는 비유지보수 스냅샷. |
난이도별로 손에 익히는 단계.
레포를 Claude Code로 열고 /quickstart → 심어둔 카나리아 취약점을 찾는 첫 실행을 따라갑니다. 파이프라인 전 단계가 무엇을 산출하는지 감 잡기.
/threat-model 인터뷰로 내 코드의 위협 모델을 만들고, 그 범위로 /vuln-scan → /triage까지. 결과 TRIAGE.json의 순위가 납득되는지 직접 검토합니다 (읽기/쓰기 전용이라 안전).
find_prompt와 judge_prompt를 나란히 놓고 "생성자는 어떻게 부추기고 심판은 어떻게 의심하는지" 문장 단위로 분석해, 내 도메인 검증 파이프라인에 쓸 프롬프트 쌍을 설계해 봅니다.
Linux 머신에 setup_sandbox.sh로 gVisor 환경을 만들고 bin/vp-sandboxed로 오픈소스 C 라이브러리 하나를 스캔합니다. egress 프록시 로그로 어떤 통신이 허용/차단되는지도 관찰.
한 주씩 따라가는 계획.
| 주차 | 주제 | 학습 자료 |
|---|---|---|
| 1주차 | 전체 루프 체험 — 스킬 6종 | /quickstart · 실습 1~2 |
| 2주차 | 메모리 취약점·ASAN 기초 | ASAN 문서 · docs/pipeline.md |
| 3주차 | 샌드박싱 — gVisor·egress 통제 | docs/security.md·agent-sandbox.md · 실습 4 |
| 4주차 | 프롬프트·검증 체인 설계 | harness/prompts/ · 실습 3 |
| 5주차 | 내 스택으로 포팅 | /customize · docs/customizing.md |
본문에 나온 용어 빠른 참조.
| 용어 | 의미 |
|---|---|
| 하니스(harness) | 대상을 끼워 자동 실험/검사를 돌리는 틀 — 여기선 취약점 파이프라인. |
| recon | 정찰 — 코드 구조·공격 표면을 먼저 파악하는 단계. |
| 트리아지(triage) | 발견들을 심각도·확실성으로 분류해 처리 순서를 정하는 작업. |
| ASAN | 메모리 오류를 실행 중 잡아내는 컴파일러 장치 — 동적 증거 생산. |
| gVisor | 사용자공간 커널로 시스템 콜을 가로채는 강화 샌드박스. |
| egress allowlist | 나가는 통신을 허용목록으로 제한 — 유출 차단. |
| false positive | 거짓 양성 — 취약하다고 했지만 아닌 것. 다단 필터의 표적. |
| 카나리아 | 일부러 심어둔 결함 — 파이프라인이 제대로 찾는지 검증용. |
| novelty 필터 | 이미 알려진 이슈와의 중복을 걸러 "새 발견"만 남기는 단계. |
| patch grading | 패치 후 크래시 소멸+기능 보존을 재검증하는 채점. |