Defending Code Reference Harness - AI 기반 취약점 발견과 수정용 Anthropic 오픈소스 프레임워크

참조 파이프라인의 일반 구조, 프롬프트, 샌드박싱 방식은 재사용할 수 있지만, 모든 코드베이스에서 바로 동작하지 않으며 /customize로 언어, 탐지기, 취약점 종류에 맞게 포팅해야 함

/quickstart, /threat-model, /vuln-scan, /triage와 정적 결과에 대한 /patch는 파일 읽기·쓰기만 수행하며, Claude Code에서 각 도구 사용을 검토하고 승인하면 샌드박스 없이 실행 가능함

자율 참조 파이프라인과 파이프라인 결과에 대한 /patch는 대상 코드를 실행하므로, 명시적으로 우회하지 않는 한 gVisor 샌드박스 밖에서는 실행을 거부함

파이프라인 실행에는 scripts/setup_sandbox.sh로 gVisor와 에이전트 이미지를 준비해야 하며, Docker와 ANTHROPIC_API_KEY 또는 CLAUDE_CODE_OAUTH_TOKEN 환경 변수가 필요함

실행 단계는 빌드, recon, find, verify, dedupe, report, patch로 나뉘며, find 에이전트는 격리 컨테이너에서 malformed input을 만들고 ASAN 바이너리가 3회 중 3회 크래시할 때까지 탐색함

verify 단계는 별도 grader 에이전트가 새로운 컨테이너에서 proof of concept만 넘겨받아 크래시를 재현하고, dedupe 단계는 새 버그·기존 버그의 더 나은 예·중복 여부를 판정함

report 단계는 primitive class, reachability, escalation path, severity를 포함한 구조화된 exploitability analysis를 작성하고, patch 단계는 수정안을 만든 뒤 빌드, 원래 proof of concept의 비크래시, 테스트 통과, 우회 가능성 재탐색을 확인함

초기 사용 흐름은 Day 1에 threat model과 정적 scan·triage·candidate patch를 만들고, Day 2에 C/C++ 라이브러리에서 실행 검증된 findings를 생성한 뒤, Days 3-5에 자체 대상용 targets/<your-service>/를 만드는 방식임

자체 스택으로 포팅할 때는 finding 신호, proof of concept 형태, 빌드·실행 방식을 정의해야 하며, C/C++ 참조는 ASAN crash signature, crashing input file, clang+ASAN 기반 Dockerfile을 기준으로 삼음

자율 triage와 patching은 아직 열린 문제이며, /patch의 검증 전략이 기준을 높이지만 severity와 우선순위는 환경별 판단이고 검증된 패치가 항상 upstream 가능하지는 않다는 제약이 있음

이런 건 작업장 지그에 가까움. 원하면 크로스컷 썰매를 살 수는 있지만, 목공인 대부분은 직접 만들어 씀
2년 전에는 자기 하네스를 만드는 비용이 컸으니 상황이 달랐지만, 지금은 이런 걸 아이디어 참고용으로 보고 자기 작업 방식, 인터페이스, 대상과 노력의 정의, 알림 방식에 맞춰 직접 만드는 편이 최선으로 보임

작업장 지그라는 비유가 딱 맞음. 많은 소프트웨어가 범용 사용을 위한 것에서 극도로 개인화된 용도로 바뀌고 있음
AI 이전에는 자기 문제를 푸는 소프트웨어를 만드는 데 사람의 노력이 많이 들어서, 다른 사람도 재사용할 수 있게 일반화하는 수고를 더 하곤 했음. 이제는 거의 노력이 들지 않으니 소프트웨어가 일반화되지 않은 채로 남음
요즘은 내가 만든 것들을 거의 공유하지 않는데[0], 다른 사람에게 도움이 될 가능성이 별로 없고, 비슷한 게 필요하면 내 것을 확장하거나 고치기보다 자기에게 정확히 맞는 걸 만들 수 있기 때문임. 지그처럼
0: https://redfloatplane.lol/blog/17-why-share/ 및 관련 글들

딱 이거임. “컴퓨터를 쓴다는 게, 컴퓨터가 대신 코드를 작성하고 실행하는 일을 투명하게 포함하게 될 것”이라고 여러 번 말해왔고, 기술자가 아니면 그 사실조차 모를 수 있음. 지금 말한 방향도 거기로 향함
우리 삶에는 목적 전용 도구를 만드는 게 더 나을 때가 많고, 모델이 새로 나올 때마다 그런 도구의 복잡도도 커짐
이런 건 정말 개인 도구임. 다른 사람도 가질 수 있는 문제를 풀지만, 자기만의 작업 방식에 강하게 묶여 있어서 남에게 설명하거나 맞춰주기 어렵다. 그래서 작업장 지그임
나도 이런 맞춤 스크립트와 프로그램이 10개쯤 있는데, 대학 이후 이런 느낌은 처음임. 그때는 설정을 마음껏 커스터마이즈할 시간이 있었고, 지금은 에이전트가 있음
친구들에게 보여주고 싶지만, 실제로 어떻게 설명할지 머릿속으로 따라가 보면 그들이 여러 특이한 점을 이해하지 못할 것 같음. 그건 내 특이함이기 때문임. 내 문제를 아주 잘 푸는 꽤 복잡한 기술 조각들이고, 그 문제들은 더 넓은 문제의 개인적 변형이며, 적어도 지금은 내가 지원할 생각이 없음
우리가 이 방향으로 가고 있다는 건 너무 분명한데도 많은 사람이 아직도 코드는 엘리트의 것이라고 믿음. 제품용 코드는 그럴 수 있지만, 나머지는 곧 부모님 컴퓨터도 자신을 위해 직접 작성한 코드를 실행하게 될 것 같음. 보안 면에서는 무섭지만 생각하면 흥미로움

의지가 있다면 누구나 하네스를 만들 수는 있지만, 대부분은 그럴 의지가 없음
게다가 직접 해도, 내가 몇 달 동안 다듬은 AI 작업 흐름들이 ultracode 때문에 바로 구식이 됐음

이 변화를 어떻게 표현해야 할지 찾고 있었는데, 이 비유가 정확함. 소프트웨어 공학에서 라이브러리와 인프라 구성 요소의 가치는 빠르게 줄어들고 있음
많은 조직에서 이런 일을 담당하는 팀으로 찾아오는 사용자가 점점 줄어들고 있을 거라고 봄

오픈소스의 미래도 대체로 이렇게 봄. 오픈소스 라이브러리를 가져와 쓰기보다는, 우리가 만드는 맞춤 도구의 설계 영감으로 재사용하게 될 것임
자기 것을 만드는 비용은 너무 싸고, 남의 기본 구성 요소에 갇히는 비용은 너무 비쌈
하지만 AI 코딩을 기존 도구에 접지시키는 건 엄청나게 강력함

대략적인 기준으로 에이전트당 분당 캐시되지 않은 입력 토큰 약 10K, 출력 토큰 약 2K를 예상하세요. 계정의 ITPM 한도까지 병렬성을 키울 수 있습니다(대략 100K ITPM당 에이전트 10개)
내 추측으로는 Opus면 수백 달러, Mythos면 수천 달러가 들 것 같음

코드를 작성하는 것보다 코드를 안전하게 만드는 데 더 많은 토큰이 필요하다는 게 점점 분명해짐
어쩌면 한 자릿수 규모 차이까지 날 수도 있음

Opus 비용도 이미 감당하기 어려울 만큼 비싸다고 보는데, Mythos와 어떻게 비교될지는 모르겠음
이 계산기를 보면 개발자 100명인 회사가 연간 토큰 비용 약 250만 달러까지 갈 수 있어서 꽤 충격적임 https://ai-cost-calculator.arnica.io

Claude의 ultra code 모드 작업 흐름도 아주 비슷하게 동작하고, 작업 복잡도에 따라 세션 사용 한도를 적당히 소비함
다만 API로 돌리면 비용이 빠르게 커질 것 같음

그들의 관리형 서비스와 비교하면, 이 추정치는 코드베이스에 따라 기대 비용의 10분의 1일 가능성이 있음
하지만 더 큰 숫자로 잡아도, 이런 도구가 노리는 발견을 위한 정식 보안 계약 비용의 약 10분의 1일 수 있음. PR 리뷰나 /security-review만으로는 나오지 않고, 전문가가 오픈소스 프레임워크의 사전 작업을 이끌어야 나오는 종류의 결과들임. 그런 계약을 어떻게 진행할지 알아내는 시간과 지연은 계산에 넣지도 않았음
직설적으로 말하면, 중요하다면 단일 스캔에 한 달짜리 바이브 코딩 예산이 들더라도 “달러 대비 몇 센트” 수준으로 매우 쌈
동시에 그 결과에는 여전히 전문가가 필요함. 제안이 도움이 될 수도 있고 적극적으로 해로울 수도 있으며, 사전 작업 품질에 달려 있음
IT 부서장에게는 몇천 달러를 써서 이걸 돌리고, 무서운 결과 페이지로 예산을 확보한 뒤, 취약점을 찾고 분류하고 필요하면 수정까지 도우며 내부 팀을 보안 지향적으로 훈련시킬 수 있는 레드팀과 관계를 만들라고 권하고 싶음

좋은 하네스가 없으면 codex/claude에서 별로 얻을 게 없다는 게 우리 경험임. 그리고 코딩 에이전트가 왜 사람이 찾는 버그를 못 찾는지 알아내는 데 시간과 에너지를 써야 함
감사자로서 매주 우리 하네스(https://zkao.io/)가 못 찾는 버그를 보고, 도구가 그 버그를 찾게 만들기 위해 꽤 흥미로운 기법을 찾아야 함. 여기서 말하는 건 주로 암호학적 취약점이지 단순 웹앱 버그가 아님
그래서 회사들이 자기 하네스도 갖고, 경험을 바탕으로 좋은 하네스를 만드는 데 집중하는 서비스에도 비용을 내는 게 타당해질 것 같음. 많은 버그를 보고 그 버그들을 하네스에 “가르칠” 시간을 쓸 수 있는 감사 업체들이 이런 일을 가장 잘할 가능성이 큼
반대로 분류도 그만큼 좋은 기법이 필요함. 그렇지 않으면 내가 바이브 감사라고 부르는 기계가 생겨서, 이미 버그 바운티의 조악한 AI 제출물과 모든 PR을 리뷰하는 AI 도구에 지친 개발자들을 더 피곤하게 만들 만큼의 오탐만 쏟아냄
결국 하네스가 아무 버그도 반환하지 않으면 “그럼 버그가 없다는 뜻인가?”라고 고민하게 됨. 결국 최고의 도구나 최고의 팀, 즉 최고의 도구가 무엇인지 아는 팀을 고르고, 그게 누구인지 알아내야 하는 평판 게임으로 돌아온 셈임

보안은 확실히 AI/LLM 활용 사례로 훌륭함. 작업의 큰 부분이 알려진 보안 문제 패턴을 분석 대상이 매우 정밀한 프로그래밍 언어 텍스트와 맞춰보는 일이기 때문임
눈에 띄는 건, 가장 강력한 활용 사례에서는 AI 회사들이 원시 출력물을 팔기보다 그 기법을 서비스로 팔려 한다는 점임. 출력의 가치가 낮은 경우에는 토큰을 팜
AI 토큰이 일반적인 소프트웨어 애플리케이션 개발에서 새 가치를 만드는 데 정말 마법 같다면, 토큰을 직접 팔지 않을 것임. 토큰을 쌓아두고 원하는 모든 산업의 SaaS 소프트웨어를 장악하는 데 쓸 것임
주식 시장에서 비싼 강의를 파는 사람이, 자기 지식으로 직접 주식 시장에서 돈을 버는 것보다 강의를 파는 쪽에서 더 얻을 게 많다는 신호를 보내는 것과 비슷함

아니면 다각화를 원할 수도 있음
AI 토큰으로 제품을 만들려면 그들이 경험이 적은 전체 제품을 만들고 팔아야 하며, 자기 고객들과 경쟁하게 됨. 아직 자리 잡는 중인 AI 공급업체에게 좋은 위치가 아님. 기존 사업만으로도 처리할 일이 많은데 큰 산만함이 되고, 전략적으로도 그다지 가치가 크지 않음

“토큰을 쌓아두고 원하는 모든 산업의 SaaS 소프트웨어를 장악해야 한다”는 논리는 이해가 안 됨
준수하게 성공한 SaaS를 운영하고 매각해봤는데, 지치고 답답한 부분은 LLM이 도와줄 수 없는 것들임. 제품을 코딩하는 건 병목도 아니고 성공을 보장하는 요소도 아님

그 결론은 전혀 따라오지 않음. Anthropic은 토큰 판매로 매출이 전년 대비 10배 성장하고 있음
그들의 토큰이 정말 마법 같고, 기존 산업에 들어가 기존 업체를 밀어내며 그 산업에서 연 100% 성장할 수 있다고 해도, 토큰 판매를 우선하는 편이 여전히 더 나음. 그 자체가 훌륭한 사업이기 때문임
이 논리가 보여주는 건 한계가 있다는 정도임. 토큰이 소프트웨어 모든 영역에서 즉시 무한한 돈을 만들 만큼 강력하지는 않음. 그건 사실로 보임

다른 해석으로는 생태계 구축이 장기적으로 더 가치 있다는 것일 수 있음
처음에는 많은 회사가 보안 우려 때문에 직원들이 원격 LLM에 소스 코드를 쓰는 걸 금지했음. 이제는 보안 우려 때문에 모든 소스 코드를 원격 LLM으로 분석해야 한다고 믿기 시작하는 회사가 많아짐
Anthropic을 신뢰하는 일이 정상화되면, 소스 코드 접근이 필요한 더 많은 서비스를 팔 수 있게 됨

회사 안의 수많은 사람에게 전화하고 메시지를 보내다가 취약해 보이는 사람을 찾기 시작하면 인간 레드팀원이 넘겨받거나 더 직접 지휘하는 식의 통합 MetaSploit AI 업데이트가 아직 안 나온 게 놀라움

약간 다른 얘기지만, 누군가 이 글의 GitHub 좋은 링크들을 dead/flag로 다 죽이고 있는 것 같은데 왜 그러는지 모르겠음

구멍 하나를 찾는 일은 언제나 모든 구멍을 막는 일보다 쉬움. 해커들도 같은 도구를 갖고 있으니, 이건 이길 수 없는 군비 경쟁임

LLM이 위협 모델의 계산을 크게 바꾼다는 건 분명하지만, 이 관찰만으로는 어떻게 또는 왜 바뀌는지 설명하지 못함
말한 비대칭성은 LLM 이전 소프트웨어에도 있던 속성임

방어자에게는 공격자가 모르는 맥락이 있음

꽤 흥미로움. 한동안 비슷한 도구를 만들고 써왔음: https://github.com/bobinson/vulture
오탐 때문에 고생했고, Claude + MCP를 가난한 사람의 감사 도구처럼 써왔음. 최근 며칠 사이에는 Nvidia 호스팅 모델에서 더 나은 결과를 얻었음

Claude가 이 하네스로 토큰을 효율적으로 쓰는지 알기 전에는, 들리는 것만큼 유용하지 않을 수 있음

Anthropic이 이제 특정 활용 사례용 하네스를 만들고 제품화하고 있다는 게 분명함
보안용 Claude Design에 해당하는 셈임
하네스가 다르고, 패키징이 다르며, 대상 페르소나가 다르니 유통 방식도 당연히 다름
재미있는 건 Mythos에 대해 보고한 회사 글을 보면 모두가 자기 하네스를 만들고 있다는 점임. Cisco는 아예 그중 하나의 명세를 공개했음
하지만 이를 패키징하고 유통하는 방법을 알아낸 쪽은 Anthropic임. 훌륭한 시장 진입 전략임