LLM으로 소스 코드 보안 강화하기

모델의 역량은 빠르게, 그리고 고르지 않게 발전하고 있습니다. 저희는 보안 팀들과 협력해 자체 코드와 오픈소스 소프트웨어의 취약점을 탐지하고 수정해왔으며, 이 과정에서 모델을 소스 코드 보안에 어떻게 활용할 수 있는지 더 깊이 이해하게 됐습니다. 가장 중요한 교훈은 이것입니다. 탐지(discovery)는 이제 병렬화하기 쉬워졌고, 병목은 검증·분류·패치 단계로 넘어갔습니다.

이 격차가 얼마나 큰지 보여주는 사례가 있습니다. 저희가 직접 오픈소스 소프트웨어를 스캔한 결과, 2026년 5월 22일 기준으로 총 1,596건의 취약점을 공개했습니다. 그런데 저희가 파악한 바로는 이 중 실제로 패치된 건수는 97건에 불과합니다.

이 가이드는 Claude Opus를 활용해 위협 모델을 구축하고, 코드베이스의 취약점을 탐지한 뒤 이를 검증·분류·패치하는 방법을 단계별로 안내합니다. 모든 답을 알고 있는 건 아니지만, 여러 팀이 탐지를 어떻게 확장했는지, 이후 단계에서 무엇이 도움이 됐는지 공유하겠습니다. 지금 바로 시작하려면 함께 제공되는 리포지터리를 활용해보세요. 인터랙티브 워크플로를 위한 스킬과 자율 스캐닝을 위한 데모 하네스(harness)가 포함되어 있으며, 글을 읽으면서 각 단계를 구현하는 스킬도 함께 안내합니다.

탐지·수정 루프

가장 많은 취약점을 찾고 수정한 팀들은 기존 모범 사례를 변형한 방식에서 공통점을 찾을 수 있었습니다. 저희는 이를 여섯 단계로 정리했습니다.

1. 위협 모델: 스캔을 시작하기 전에 무엇을 취약점으로 볼 것인지 정의합니다.
2. 샌드박스: 에이전트를 격리하고 익스플로잇을 검증할 샌드박스 환경을 구축합니다.
3. 탐지: 모델이 소스 코드에서 취약점을 찾도록 합니다.
4. 검증: 발견된 항목 중 실제로 악용 가능한 것을 독립적으로 확인합니다.
5. 분류(Triage): 중복 항목을 제거하고, 심각도를 부여하며, 수정 우선순위를 정합니다.
6. 패치: 수정 사항을 적용하고, 취약점이 제거됐는지 확인한 뒤, 유사 변종을 탐색합니다.

처음 두 단계인 위협 모델 구축과 샌드박스 설정은 이후 루프 전체의 토대입니다. 보통 코드베이스당 한 번만 수행하며, 기반 시스템이 바뀔 때 재검토합니다. 이후 네 단계인 탐지→검증→분류→패치가 소스 코드를 대상으로 반복 실행되는 루프입니다.

코드베이스를 처음 스캔할 때는 발견 건수가 가장 많습니다. 이후 실행에서는 단순한 취약점이 이미 수정된 만큼 발견 건수가 줄어드는 대신, 더 복잡한 취약점이 나오는 경향이 있습니다. 그렇다고 n^번째 실행에서 신규 발견이 제로가 될 것이라고 기대하진 마세요. 모델은 확률적으로 동작하고, 규모가 큰 코드베이스에는 코드 변경이 없어도 취약점이 계속 조금씩 나올 수 있는 긴 꼬리가 존재합니다.

코드베이스에 처음 적용할 때는 루프를 여러 번 실행하고, 순 신규 발견 건수와 해당 시스템에 대한 위험 허용 기준을 바탕으로 언제 멈출지 결정하세요. 첫 번째 반복을 마친 뒤에는 (1) 주기적으로 또는 (2) 코드에 의미 있는 변경이 생길 때마다 스캔을 이어가세요.

이제 각 단계를 자세히 살펴보겠습니다. 각 단계가 왜 필요한지, 무엇을 산출하는지, 어떻게 구현하는지 설명합니다.

1. 위협 모델: 취약점의 기준을 정의하라

오탐(false positive)의 가장 흔한 원인은 모델이 신뢰 경계(trust boundary)를 제대로 파악하지 못하는 것입니다. 모델은 클라이언트가 손상된 값을 보낼 수 있거나 공격자가 설정을 제어할 수 있다고 가정해 코드를 취약하다고 플래그할 수 있습니다. 하지만 실제 환경에서 이런 입력은 신뢰할 수 있는 것일 수 있습니다. 반대로, 인터넷에 노출된 서비스를 내부 전용으로 잘못 판단해 실제 취약점을 놓치기도 합니다. 두 경우 모두 코드가 아닌 위협 모델에 대한 모델의 이해가 잘못된 것입니다.

한 팀은 발견 패턴을 분석하다 공통점을 발견했습니다. 위협 모델, 시스템 설계 문서, 요구사항, 제약 조건이 잘 문서화된 시스템에서 모델의 성능이 가장 좋았다는 것입니다. 위협 모델이 명확히 정의된 경우, 모델의 발견 항목은 "90%가 실제 악용 가능한 것"이었습니다.

Claude와 함께 위협 모델을 구축하는 방법은 두 단계로 나뉩니다.

첫째, 코드·문서·취약점 이력을 바탕으로 초안을 부트스트랩합니다. 신입 보안 엔지니어에게 첫날 건네줄 만한 자료를 모델에게 제공하세요. 아키텍처 문서, 위키, 진입점, git 히스토리, 과거 취약점 등이 이에 해당합니다. 이를 통해 코드만으로는 파악하기 어려운 암묵적 지식, 트레이드오프, 설계 결정을 모델이 이해할 수 있습니다. 그런 다음 시스템 컨텍스트, 자산, 진입점, 신뢰 경계가 포함된 위협 모델을 작성하도록 요청하세요. 마지막으로 과거 버그를 유형별로 묶고 관련 취약점 클래스를 나열하게 합니다. 어떤 취약점을 신경 쓰는지, 그렇지 않은지, 그 이유가 무엇인지를 위협 모델에 명확히 기록해야 합니다.

한 팀은 수백 건의 과거 CVE와 보안 수정 커밋을 검토해 "버그 형태(bug-shape)" 힌트로 정리하고, 모델에게 두 가지 질문을 던졌습니다. 해당 수정이 완전했는지, 그리고 동일한 수정이 다른 곳에도 적용됐는지였습니다. 그 결과 한 시간 만에 악용 가능한 문제 세 건을 발견했습니다. 그들의 표현을 빌리자면: "'과거에 사람들이 무엇을 익스플로잇했는가'라는 질문이 '이 코드베이스에서 취약점을 찾아라'보다 훨씬 효과적인 지름길이 될 때가 있다."

둘째, 시스템을 잘 아는 담당자를 모델이 인터뷰하게 합니다. Shostack의 네 가지 질문을 활용해보세요. 우리는 무엇을 만들고 있는가? 무엇이 잘못될 수 있는가? 우리는 어떻게 대응하고 있는가? 제대로 했는가? 인터뷰 전에 부트스트랩 단계를 먼저 진행하면 담당자가 백지 상태에서 시작하지 않아도 됩니다. 몇 시간을 들여 위협 모델을 처음부터 만드는 대신, 초안에서 출발해 다듬을 수 있습니다. 인터뷰 단계는 선택 사항이지만, 코드나 문서에서는 얻을 수 없는 맥락을 추가해 위협 모델의 완성도를 높여줍니다.

다음 몇 가지 실천 사항이 큰 차이를 만들어냅니다.

• 의존성의 보안 정책을 확인하세요. 많은 오픈소스 프로젝트가 보안 정책을 공개합니다. vLLM의 security.md, SQLite의 "Defense Against the Dark Arts", ImageMagick의 보안 정책이 그 예입니다. 처음부터 정책을 재구성하는 대신, 이를 위협 모델에 직접 반영하세요.
• 신뢰하는 대상을 명시하세요. 설정 파일이나 인증된 클라이언트를 신뢰한다면 위협 모델에 문서화하세요. 이런 전제 조건이 있어야 실제 취약점과 악용 불가능한 버그를 구분할 수 있습니다.
• 코드와 함께 THREAT_MODEL.md를 포함하세요. 리포지터리에 넣어두고 코드가 바뀔 때마다 업데이트하세요. 탐지 에이전트가 검색을 시작하기 전에 이를 읽으면, 이미 알려진 비이슈는 건너뛸 수 있습니다.

위협 모델은 두 곳에서 활용됩니다. 탐지 단계에서는 범위(scope)로 기능합니다. 코드를 파티션하고, 검사 대상 우선순위를 정하며, 범위 밖의 항목은 건너뜁니다. 전체를 스캔하기 어려운 대규모 코드베이스에서 특히 유용합니다. 분류 단계에서는 필터로 활용됩니다. 광범위하게 스캔한 후, 위협 모델을 이용해 심각도를 시스템과 환경에 맞게 보정합니다.

대형 프로젝트를 스캔한 한 팀은 오탐률이 40%에 달했고 그 원인을 파고들었습니다. 발견 항목은 재현 가능했고 PoC로 악용 가능성도 입증됐습니다. 하지만 해당 코드를 담당한 개발 팀은 프로젝트의 위협 모델에 맞지 않는다는 이유로 오탐으로 처리했습니다. 다른 팀의 CISO는 이를 간결하게 표현했습니다. "[모델은] 코드 컨텍스트는 잘 이해하지만, 우리 조직의 컨텍스트는 제대로 파악하지 못한다."

위협 모델 스킬을 사용해보세요. 이 섹션에서 설명한 두 단계를 모두 안내합니다. bootstrap는 코드, CVE, git 히스토리에서 초안을 도출하고, interview는 시스템 담당자와 Shostack의 네 가지 질문을 함께 검토해 위협 모델을 다듬습니다. 결과물은 THREAT_MODEL.md 파일로 저장되며, 탐지 및 분류 단계에서 활용됩니다.

2. 샌드박스: 에이전트를 안전하게 실행하고 악용 가능성을 검증하라

샌드박스의 첫 번째 목적은 시스템을 보호하는 것입니다. 모델이 안전하게 자율적으로 실행되려면 강력한 격리 계층이 필요합니다. 격리 없이는 에이전트가 의도치 않은 동작을 할 수 있습니다.

한 팀은 모델에게 네트워크 접근이 없다고 알려줬지만, 실제로는 접근이 가능한 상태였고, 모델은 GitHub에서 데이터를 가져올 수 있다는 것을 스스로 발견했습니다. 다른 팀은 스캔 도중 에이전트가 GitHub 이슈에 답변을 남기는 것을 목격했습니다. 둘 다 악의적인 행동은 아니었지만, 코드와 설정으로 제약을 강제해야 한다는 점을 잘 보여줍니다.

격리 수준은 위협 모델에 맞게 설정하세요. 코드를 읽는 탐지 에이전트에는 컨테이너로 충분하지만, 대상 시스템과 PoC는 마이크로VM(Firecracker 등)이나 외부 통신이 차단된 풀 VM에서 실행해 프로덕션 시스템에 절대 접근하지 못하도록 해야 합니다. 에이전트가 자격증명(~/.aws, ~/.ssh, .env)에 접근할 수 없도록 하는 것도 필수입니다.

샌드박스에는 설정하는 동안에만 네트워크 접근을 허용하세요. 의존성을 받아오고, 빌드하고, 도구를 설치하고, 대상을 배포하고, 기존 테스트를 실행해 정상 동작을 확인합니다. 그런 다음 환경을 스냅샷으로 저장하고 네트워크 접근을 차단하세요. 스캔 중에는 로컬 프록시를 통해 모델 API로만 트래픽을 허용합니다. 각 실행 시작 시 스냅샷을 로드해 모든 스캔이 동일한 초기 상태에서 시작되도록 하세요.

샌드박스의 두 번째 목적은 악용 가능성을 증명하는 것입니다. 정적 스캔에서 모델은 코드를 읽고 문제 발생 가능성을 추론하지만, 실제 경로가 도달 가능한지, 보완 통제가 존재하는지는 테스트할 수 없습니다. 이 때문에 모델이 실제로 악용 불가능한 코드 정확성 버그를 플래그하기도 합니다. 에이전트가 코드를 컴파일하고, 테스트를 실행하고, PoC를 실행할 수 있는 샌드박스를 구축한 팀들은 악용 불가능한 발견 비율이 크게 줄었다고 보고했습니다.

한 공격적 보안(offensive security) 팀은 에이전트에게 테스트 환경을 제공하는 하네스를 구축하고, 단순한 검증 기준을 적용했습니다. 에이전트가 PoC를 작성해 테스트 환경에서 실행할 수 있을 때만 진양성(true positive)으로 인정하는 것입니다. 6주간의 평가 결과, "모델에 테스트 환경과 라이브 시스템을 주고 PoC를 직접 실행하게 한 것이 가장 큰 효과 레버였다"고 했습니다.

샌드박스를 구축할 때는 가능한 한 많은 요소를 고정하세요. 이미지 태그, 커밋 SHA, 의존성, 빌드 명령 등을 고정하면 모든 실행이 동일한 코드를 동일한 환경에서 사용하게 됩니다. 네트워크 없이도 빌드할 수 있도록 로컬 캐시를 두고, 여러 테스트 루프에서 재사용할 수 있도록 컨테이너를 내구성 있게 설계하세요.

한 팀의 스캔에서 에이전트가 실제 배포된 버전이 아닌 구버전 라이브러리를 다운로드한 탓에 취약점이 오탐으로 잡혔습니다. 이는 트랜스크립트를 검토하던 엔지니어가 다른 의존성이 다운로드되고 있다는 것을 발견하면서 밝혀졌습니다. 이후 이 팀은 프로덕션 환경의 의존성 버전에 맞춰 핀된 Docker 컨테이너를 빌드해, 탐지 에이전트와 검증 에이전트 모두 실제 공격자가 마주하는 것과 동일한 아티팩트에서 동작하도록 했습니다.

프로덕션 환경을 충실히 반영한 샌드박스를 구축하는 것이 중요합니다. 큐나 데이터 저장소 같은 의존성을 제외하면 프로덕션에 실제로 존재하는 버그를 놓칠 수 있습니다. 반대로 WAF나 인증 게이트웨이 같은 프로덕션 방어 수단을 무시하면, 실제 환경에서는 이미 차단된 악용 불가능한 항목을 모델이 보고하게 됩니다.

그렇더라도 클라우드 의존성이나 데이터 저장소 등 현실적인 복잡성 때문에 대표적인 샌드박스 구축이 어렵다면, 아래의 탐지 단계부터 시작하세요. PoC를 반드시 샌드박스에서 실행해야 하는 것은 아닙니다. 프론티어 모델은 소스 코드 분석만으로도 취약점을 잘 발견합니다. 저희 팀을 포함한 여러 팀이 이 방식의 효과를 확인했습니다. 다만 트레이드오프가 있습니다. 실행 중인 대상이 없으면 검증 단계에서 PoC로 발견을 증명할 수 없기 때문에, 검증에 더 많은 시간을 투입해야 합니다. 발견 건수가 충분히 쌓이면 그때 샌드박스에 투자해도 됩니다.

참고용 샌드박스로는 하네스 README.md 를 참고하세요. 이 구현에서 에이전트와 대상은 gVisor 격리 컨테이너에서 실행되며, 외부 통신은 모델 API로만 제한됩니다. 대상은 특정 커밋에 고정된 Dockerfile로 빌드되며, setup_sandbox.sh이 설정 단계를 담당합니다.

3. 탐지: 풍부한 컨텍스트, 간결한 프롬프트, 유용한 도구를 제공하라

탐지 에이전트에게 필요할 때 불러올 수 있는 컨텍스트를 제공하세요. 위협 모델, 아키텍처 문서, 과거 스캔 결과 등이 여기에 해당합니다. 에이전트가 신뢰 경계와 실제 배포 방식을 이해하면, 해당 시스템에 특화된 취약점을 더 잘 찾아낼 수 있습니다.

탐지 단계에서 프론티어 모델은 오히려 프롬프트가 단순할수록 더 좋은 성능을 냅니다. 직관에 반하지만, 지나치게 구체적인 프롬프트는 탐지를 오히려 저하시킵니다. 긴 체크리스트는 모델의 창의성을 제한해 새로운 버그 발견을 줄이는 경향이 있습니다. 탐지 단계에서 도움이 된 프롬프팅 팁을 소개합니다.

• 목표와 컨텍스트를 제공하세요. 스캔하는 이유와 검토할 대상, 의미 있는 발견이 무엇인지 등 '왜'와 '무엇'을 명확히 하고, '어떻게 취약점을 찾을지'는 모델에게 맡기세요. 프론티어 모델은 보안 작업에 점점 더 능숙해지고 있으며, 과도하게 구체적인 지시는 오히려 탐색 범위를 좁힐 수 있습니다.
• 특정 취약점 클래스를 명시해보세요. 과거 CVE나 코드베이스의 언어 특성에 따라 특정 취약점 유형에 집중하고 싶다면, 해당 취약점 클래스가 무엇이고 어디에서 자주 발생하는지 설명하세요. 그래야 모델이 코드베이스에서 이를 인식할 수 있습니다.
• 출력 형식을 정의하세요. 미리 정의된 필드를 갖춘 구조화된 보고서를 요청하고, 각 필드가 순서대로 모델의 추론을 이어나가도록 구성하세요. 예시 필드로는 근거, 발견 내용, 영향, 심각도 등이 있습니다. 발견이 미약할 경우 조기에 종료할 수 있는 탈출구도 포함하세요.

모델에게 코드베이스를 탐색하고 읽을 수 있는 도구(grep, glob 등)를 제공하세요. SAST 스캐너나 퍼저처럼 팀에서 사용하는 보안 특화 도구도 활용할 수 있게 하세요. 특정 작업에 어떤 도구가 필요한지 모델에게 직접 물어보고 해당 도구를 제공하세요. 그리고 모델이 필요한 도구를 직접 만들도록 허용하세요. 최근 프론티어 모델은 필요한 도구를 스스로 작성하는 능력이 점점 뛰어나지고 있습니다.

한 펜테스팅 팀은 탐지 에이전트에게 요청 전송, 응답 확인, 트래픽 로그 조회 도구를 추가로 제공했습니다. 덕분에 에이전트는 경로 접근 가능 여부를 추측할 필요 없이, 후보 항목마다 실행 중인 애플리케이션에서 직접 테스트할 수 있었고, 진양성 비율이 거의 100%에 가까워졌습니다.

모델이 공격 표면, 엔드포인트, 컴포넌트 등의 기준으로 시스템을 먼저 분할(파티셔닝)하도록 하세요. 그런 다음 각 파티션을 병렬 탐지 에이전트에게 할당해 동일한 표면적인 버그에 집중하는 것을 방지하세요. 마지막으로 파티션별 발견 내용을 컨텍스트로 활용하는 시스템 수준 패스를 실행해 교차 컴포넌트 취약점을 탐색합니다.

탐지를 단순히 수평 확장으로 해결하려 한 팀들은 금세 수확 체감에 부딪혔습니다. 한 팀의 사례: "처음에는 에이전트를 더 많이 병렬 실행하는 방식을 시도했는데, 효과가 점점 줄어드는 것을 경험했습니다." 또 다른 팀은 집중 영역과 병렬 에이전트 수를 늘렸더니 "엄청난 수의 이슈"가 나왔지만, 대부분이 서로 중복이었다고 했습니다.

대상 시스템을 실행할 샌드박스가 있다면, 탐지 에이전트에게 발견에 대한 PoC(스크립트, 크래시 입력, 실패 테스트 등)를 작성하도록 요청하세요. PoC를 만드는 과정에서 에이전트가 발견을 더 정밀하게 검증할 수 있고, 그 결과물은 검증 에이전트에게 구체적인 근거가 됩니다. 단, 에이전트가 재현하지 못한 발견도 '미검증'으로 표시해 보고에 포함하면, 재현율(recall)을 높게 유지할 수 있습니다.

vuln-scan 스킬이 이 단계에서 유용합니다. THREAT_MODEL.md를 읽어 대상을 집중 영역으로 나누고, 영역별로 병렬 검토 에이전트를 실행합니다. 결과물은 다음 단계에서 바로 사용할 수 있는 구조화된 발견 목록입니다.

4. 검증: 악용 불가능한 발견을 걸러내라

탐지는 재현율(recall) 극대화에, 검증은 정밀도(precision) 극대화에 초점을 둡니다. 다시 말해, 탐지는 가능성이 낮더라도 최대한 많은 취약점을 찾아내야 하고, 검증은 실제로 악용 불가능한 발견을 제외해야 합니다. 한 에이전트가 두 작업을 동시에 수행하면 자기 검열이 발생해 악용 가능한 진양성까지 배제할 수 있습니다. 실제로 탐지 에이전트에게 검증까지 맡겼더니, 별도의 검증 단계였다면 확인됐을 진양성을 스스로 걸러내는 문제를 경험했습니다.

검증 에이전트는 탐지 에이전트와 독립적으로 운영되어야 합니다. 파일 시스템이나 대화 기록을 공유하지 않는 새 컨테이너에서 검증 에이전트를 실행하세요. 탐지 에이전트의 추론 과정에 노출되면 검증 에이전트가 단순히 동의할 수 있기 때문입니다. 따라서 검증 에이전트에게는 (1) PoC 또는 서면 발견 내용과 (2) 코드베이스만 제공하세요. 이를 통해 탐지 에이전트가 놓친 완화 요소(상위 유효성 검사, 인증 게이트, 타입 제약, 도달 불가 코드 등)를 독립적으로 탐색할 수 있습니다.

단일 검증 패스만으로 악용 불가능한 발견이 너무 많이 통과된다면, 독립적인 검증 에이전트를 여러 개 실행해보세요. 서로 다른 각도에서 검토하거나 다른 모델을 사용할 수 있습니다. 그런 다음 다수결로 결정하세요. 탐지 에이전트와 검증 에이전트의 결과 사이를 조율하는 별도의 판단 에이전트를 두는 것도 고려해볼 수 있습니다.

검증 에이전트에게 탐지 에이전트의 발견을 반증하도록 프롬프팅하세요. 각 발견이 오탐이라고 가정하고 그 근거를 찾도록 지시하세요. 진양성 여부를 판단하는 명확한 기준도 포함하세요. 이는 탐지 에이전트의 결과에 PoC가 없을 때 특히 중요합니다. 악용 불가능한 발견을 최대한 걸러내 수동 검토 부담을 줄이는 것이 목표입니다.

저희가 함께한 팀들의 경험에 따르면, 대립적 검증 에이전트를 추가하는 것만으로 탐지 단계에서 나온 악용 불가능한 발견 비율이 절반가량 줄었습니다. 여기에 검증 에이전트가 익스플로잇을 확인하는 PoC까지 작성하도록 요구하자 오탐률이 거의 0에 가까워졌습니다. 이 두 단계의 조합은 이후 분류와 패치 작업의 부담을 크게 줄여줬습니다.

프로덕션 환경을 충분히 재현한 샌드박스를 구축했다면(2단계 참고), 검증 에이전트에게 재현 가능한 PoC를 작성하고 실행하도록 프롬프팅하세요. PoC가 성공하면 해당 발견이 악용 가능하다는 결론을 내릴 수 있습니다. 단, 역은 성립하지 않습니다. PoC 작성 실패가 오탐의 증거는 아닙니다.

오픈소스 패키지를 스캔한 한 팀은 루프를 완결하는 검증 단계를 구축했습니다. 패키지를 스캔하고 PoC를 생성한 뒤, 해당 패키지를 사용해 PoC를 트리거하는 모의 애플리케이션을 배포하는 방식입니다. 그들의 결론은 이랬습니다. "검증이 가장 큰 병목이고, PoC가 바로 그 검증 수단이다."

5. 분류: 근본 원인별로 중복 제거하고, 전제 조건과 영향에 따라 우선순위를 정하라

검증이 발견 항목의 악용 가능 여부를 확인한다면, 분류는 패치 우선순위를 평가합니다. 예전에는 탐지 자체에 많은 노력이 들었기 때문에, 버그를 발견한 엔지니어가 분류도 함께 담당했습니다. 이제 모델이 오전 중에만 수백 개의 후보를 찾아낼 수 있게 되면서, 분류가 새로운 병목이 됐습니다.

체계적인 분류는 경보 피로(alert fatigue)를 예방합니다. 중복되거나 심각도가 과장된 버그 보고가 쌓이면 제품 엔지니어들이 보고서를 더 이상 읽지 않게 됩니다. 즉각 패치가 필요한 항목도 외면받을 수 있습니다. 오픈소스 메인테이너는 특히 여러 사용자로부터 분류되지 않은 보고를 받기 때문에 압도당하기 쉽습니다.

여러 팀이 같은 교훈을 공유했습니다. 악용 불가능한 항목이 대다수인 발견 더미를 제품 엔지니어에게 넘기면 보고 자체에 대한 신뢰를 잃고 포기하게 된다는 것입니다. 또한 후속 엔지니어들이 압도되지 않도록 치명적(critical)·고(high) 심각도 항목을 우선시했습니다. 반면 모델을 기존 백로그(이전 스캐너, 이전 모델, 버그 바운티 접수 항목 등)에 투입해 수백 건의 오래된 항목을 며칠 만에 정리한 팀들도 있었습니다.

발견 항목을 중복 제거할 때는 근본 원인을 기준으로 삼으세요. 스캐너는 동일한 버그를 여러 호출 지점에서 플래그하거나, 하나의 근본 원인에서 비롯된 여러 증상을 별개로 보고하는 경우가 많습니다. 실용적인 접근법을 소개합니다. 먼저 결정론적인 저비용 패스를 실행하세요. 같은 파일, 같은 카테고리, 취약점 라인 번호가 10줄 이내인 경우를 중복으로 처리합니다. 그다음 모델에 정성적 규칙을 적용합니다.

• 중복으로 처리할 것: 다른 표현으로 쓴 동일 근본 원인; 여러 호출 지점에서 보고된 동일 취약점; 전역 보호(예: 인증 체크) 누락이 엔드포인트별로 보고된 경우; 동일 경로에서 원인과 그 결과가 함께 플래그된 경우.
• 별개로 처리할 것: 같은 파일 내 서로 다른 취약점 클래스; 서로 다른 싱크에 도달하는 서로 다른 변수; 하나의 헬퍼 함수 안에 있는 독립적인 두 버그; 동일한 체크가 두 엔드포인트에서 누락됐지만 각각 별도의 수정이 필요한 경우.

하네스가 각 발견에 대해 PoC와 패치를 생성한다면, 한 발견의 패치가 다른 발견의 PoC도 무력화하는지 확인하는 방식으로 중복을 제거하는 것도 가능합니다.

중복 제거 후에는 다음 기준에 따라 각 발견의 심각도를 평가하세요.

• 도달 가능성(Reachability). 공격자가 실제 진입점에서 이 코드에 접근할 수 있는가, 아니면 내부 코드와 엔드포인트에서만 접근 가능한가?
• 공격자 제어(Attacker control). 신뢰할 수 없는 입력이 손상되지 않고 싱크까지 도달하는가, 아니면 상위에서 정제(sanitize)되거나 제약되는가?
• 전제 조건(Preconditions). 버그가 발동되려면 비기본 설정, 특정 기능 플래그, 공격자가 맞춰야 하는 좁은 시간 창 등 어떤 조건이 갖춰져야 하는가?
• 인증(Authentication). 비인증 공격자가 트리거할 수 있는가, 아니면 로그인된 사용자나 관리자가 필요한가?
• 읽기 vs. 쓰기(Read vs. write). 공격자가 데이터를 읽기만 할 수 있는가, 아니면 수정도 가능한가?
• 영향 범위(Blast radius). PoC가 실행되면 누가 영향을 받는가? 한 명의 사용자인가 전체 사용자인가, 한 테넌트인가 플랫폼 전체인가, 사용자 공간인가 커널인가?

이 평가 기준을 점수로 환산할 때는, 심각도를 할당하기 전에 모델이 각 질문에 대한 답변을 먼저 도출하도록 하세요. 증거를 먼저 검토하면 버그 클래스만 보고 심각도를 단정 짓는 고착 효과("SQL 인젝션이니까 치명적")를 방지할 수 있습니다. 기준점으로 삼을 만한 예시: 전제 조건이 없고 비인증 원격 접근이 가능하면 치명적(critical) 또는 고(high) 심각도. 전제 조건이 하나나 둘이거나 인증된 경로라면 중간(medium). 전제 조건이 셋 이상이거나 로컬 전용이면 낮음(low). 임계값은 시스템에 맞게 조정하세요.

모델이 심각도를 과장하는 것은 컨텍스트가 부족하기 때문입니다. 공격자가 실제로 어떤 입력을 제어할 수 있는지 모르거나, 보완 통제를 파악하지 못할 수 있습니다. 전자의 예로, SQL 인젝션은 비인증 요청으로 트리거되면 치명적이지만 관리자 전용 설정 파일로만 트리거된다면 문제가 아닙니다. 후자의 예로, 상위 WAF나 인증이 익스플로잇을 차단하더라도 소스 코드만으로는 이를 파악하지 못할 수 있습니다.

해결책은 분류 시 위협 모델을 제공해 어떤 유형의 취약점에 신경 쓰는지, 그렇지 않은지를 모델에게 알려주는 것입니다. 예를 들어 "인증된 클라이언트를 신뢰한다"는 점을 명확히 하면 치명적 항목 전체가 간소화되거나 제거될 수 있습니다.

한 팀은 검증할 근거가 없거나 위협 모델상 예상된 동작인지 판단할 컨텍스트가 부족할 때 모델이 과도하게 자신감을 갖는 경향이 있다고 발견했습니다. 이들의 해결책은 분류 에이전트에게도 탐지 에이전트와 동일한 위협 모델을 제공하는 것이었습니다.

triage 스킬을 사용해보세요. 검증과 분류를 모두 처리합니다. 발견별 다중 투표 검증, 실행 간 중복 제거, 악용 가능성 기반 재순위 매기기를 수행합니다. 결과물은 원시 데이터 덤프가 아닌, 간결하게 순위가 매겨진 담당자 배정 목록입니다.

6. 패치: 루프를 완결하고 다음 사이클의 컨텍스트를 개선하라

패치는 루프를 완결하고 취약점을 실제로 수정하는 단계입니다. 동시에 검증된 발견을 바탕으로 위협 모델을 개선하는 것도 중요합니다. 신뢰 경계나 더 면밀히 검토가 필요한 컴포넌트를 업데이트하고, 과거 발견을 다음 스캔의 컨텍스트로 활용하세요. 사이클이 반복될수록 코드베이스는 강화되고 다음 스캔은 더 나은 정보를 바탕으로 수행됩니다.

패치 전에 기존 코드에서 실패하는 새 테스트를 먼저 작성하세요. 그런 다음 수정을 적용하고, 같은 테스트가 통과되면서 다른 것을 깨트리지 않는지 확인하세요. (테스트 주도 개발(TDD)이 맞습니다.) 테스트를 추가하지 않으면 수정이 조용히 회귀될 수 있고, 나중에 버그가 실제로 존재했다는 것을 증명하기도 어려워집니다.

한 펜테스터는 생성된 패치의 품질이 들쭉날쭉했다고 했습니다. 일부는 좋았고 일부는 나빴는데, 하네스가 패치된 코드에 대해 PoC를 다시 실행해 패치를 검증하도록 모델에게 지시하자 상황이 달라졌습니다. 반복할 피드백이 생기자 패치 품질이 높아졌고, 사람이 검토에 쓰는 시간도 줄었습니다.

모델은 근본 원인 대신 특정 호출 지점의 증상만 좁게 수정하는 경향이 있습니다. 단순히 근본 원인을 파악하고 수정하도록 프롬프팅하는 것만으로도 효과적일 수 있습니다. 그런 다음 두 수준의 변종 탐색을 진행하세요. (1) 동일 패턴 수준: 동일한 버그가 있는 다른 호출 지점이나 코드 복사본이 있는지, (2) 동일 클래스 수준: SQL 인젝션 취약점이 하나 있는 코드베이스에는 더 있을 가능성이 높습니다. 검증된 발견과 패치로 위협 모델을 업데이트해 루프를 닫으세요.

패치를 배포하기 전에 대립적 검사를 실행하세요. 새로운 탐지 에이전트가 공격자 관점에서 패치를 검토해 패치가 충분한지 확인합니다. 그런 다음 지나치게 침습적인 패치는 단순화하세요. 최소한의 패치는 검토가 쉽고 새로운 버그를 도입할 가능성도 낮습니다. 근본 원인을 수정하는 가장 작은 변경만 요청하세요. 리팩터링, 수정과 무관한 정리, 서식 변경은 하지 않아야 합니다.

한 팀이 가장 흔한 패치 실패 유형을 이렇게 설명했습니다. "권장된 패치가 지나치게 제한적이어서 다른 서비스와의 연결을 끊어버리는 경우가 많습니다. 문제는 해결하지만, 서비스가 동작하는 데 필요한 의존성을 망가뜨립니다."

각 패치는 비용이 낮은 것부터 시작하는 단계별 검증으로 확인할 수 있습니다.

1. 빌드. 패치가 컴파일되고 새 테스트가 통과됩니다.
2. 재현 시도. 원래의 PoC가 더 이상 작동하지 않아야 합니다. 비효과적인 패치를 잡아냅니다.
3. 회귀 확인. 기존 테스트 스위트가 여전히 통과돼야 합니다. 깨진 패치나 과도하게 제한적인 패치를 잡아냅니다.
4. 재공격. 새로운 탐지 에이전트가 대립적 검사를 실행합니다. 불완전한 패치를 잡아냅니다.

마지막으로, 모델이 패치를 작성하더라도 이를 책임지는 것은 사람이어야 합니다. 생성된 패치는 예측 가능한 방식으로 실패할 수 있습니다. 근본 원인이 아닌 증상만 수정하거나, 유효한 입력을 차단하거나, 의존 서비스 접근을 끊는 경우가 그 예입니다. 목표는 각 패치를 최대한 자동으로 검증해 사람의 검토 부담을 줄이는 것입니다. 개발 팀이 모델이 인식하지 못할 수 있는 부분(예: 진행 중인 변경 사항, 코드 스타일)에 집중할 수 있도록 최소한의 검토와 수정으로도 충분한 환경을 만드는 것이 궁극적인 목표입니다.

patch 스킬을 사용해보세요. 분류 결과를 입력으로 받아 발견별 패치 후보 diff를 생성하고, 독립적인 검토 에이전트가 각각을 확인합니다.

시작하기

직접 루프를 실행해보세요. defending-code-reference-harness를 클론한 뒤 Claude Code에서 run /quickstart을 실행하세요. 데모 대상을 활용해 위협 모델링부터 스캐닝, 분류까지 인터랙티브 워크플로를 단계별로 안내합니다. 리포지터리에는 자율 하네스와 사용자 환경에 맞게 하네스를 수정하는 /customize 스킬도 포함되어 있습니다.

그런 다음 직접 만든 코드에 적용해보세요. 서비스나 패키지를 하나 선택하세요. 코드와 문서에서 위협 모델 초안을 만들고 인터뷰를 진행하세요. 환경에 맞는 샌드박스 구축에 투자하세요. 스캔하세요. 독립적인 에이전트로 발견을 검증하세요. 기준에 따라 분류하고 고 이상으로 평가된 모든 항목을 검토하세요. 패치하세요. 그리고 주기적으로 다시 스캔하세요.

첫 스캔에서는 예상보다 훨씬 많은 발견이 나올 것입니다. 대부분은 검증과 분류가 필요합니다. 스캔 확대에 예산을 쓰기 전에, 스캔 이후 파이프라인에 먼저 예산을 배정하세요.

도움이 될 만한 리소스를 소개합니다.

• Claude Security: 에이전트 기반 취약점 탐지 및 패치를 위한 Anthropic의 관리형 제품.
• defending-code-reference-harness: 인터랙티브 워크플로를 위한 스킬과 자율 실행을 위한 데모 하네스가 포함된 동반 리포지터리.
• claude-code-security-review action: 모든 풀 리퀘스트에서 Claude가 보안 검토자로 동작하는 GitHub 액션.
• 위협 인텔리전스 강화 에이전트(Threat Intelligence Enrichment Agent): 침해 지표(IoC)를 위협 인텔 피드와 대조해 강화하는 에이전트 구축 쿡북.
• 취약점 탐지 에이전트(Vulnerability Detection Agent): 위협 모델 구축, 취약점 스캐닝, 발견 분류를 구조화된 보고서로 출력하는 에이전트 구축 쿡북.

앞으로 나아가며

모델이 코드의 취약점을 발견하고 악용하는 것이 점점 쉬워지고 있습니다. 따라서 방어자로서 우리의 과제는 공격자가 악용하기 전에 코드의 취약점을 먼저 찾아 수정하는 것입니다. 일부 팀들은 이미 하네스를 이벤트와 연결하는 수준까지 나아갔습니다. 버그 바운티 보고가 접수되면 자동으로 변종 분석이 시작되고, 보안 검토가 트리거되면 스캔과 함께 후보 발견이 첨부되며, 검증된 취약점이 발견되면 향후 재발 방지를 위해 정적 분석 도구가 자동으로 업데이트됩니다.

이 작업은 중요하고 높은 위험이 따릅니다. 하지만 제대로 수행된다면, 이는 더 크고 희망적인 전환의 시작점이 됩니다. 공격자가 악용하기 전에 취약점을 먼저 찾고 수정할 수 있는 세상으로의 전환입니다.

사이버보안 분야에서 저희의 작업 소식을 계속 받아보고 싶다면 이곳에서 메일링 리스트에 가입해주세요.

감사의 말

Eugene Yan과 Henna Dattani가 작성하고, Michael Molash, Abel Ribbink, Justin Young, Ben Morris, David Dworken, Hasnain Lakhani가 기여했습니다. 이 글은 Anthropic에서 보안을 위한 모델 활용 경험과, 파트너 및 고객이 공유해주신 소중한 인사이트를 바탕으로 작성됐습니다. 깊이 감사드립니다.

‍