나만의 취약점 테스트 하네스 구축하기 (새 탭에서 열림)
프론티어 모델 하나에 의존하는 대신, 모델을 교체할 수 있는 취약점 분석 하니스(harness)를 구축해야 한다는 글입니다. 하니스는 정찰·탐색·검증·중복 제거·재검증·트리아지를 지속적으로 수행하며, 수천 개의 후보를 실행 가능한 취약점 목록으로 줄입니다. 핵심은 LLM을 상태를 보존하지 않는 계산 엔진으로 취급하고, 분석 상태와 결과를 데이터베이스 및 파이프라인에 외부화하는 것입니다. ## 단일 에이전트 방식의 한계 - 일반적인 코딩 에이전트는 한 번에 하나의 가설만 유지하므로 대규모 저장소의 여러 공격 경로를 동시에 분석하기 어렵습니다. - 컨텍스트 창이 가득 차면 컨텍스트 압축 과정에서 이전에 발견한 버그나 분석 근거를 잃을 수 있습니다. - 단일 저장소만 분석하면 다른 애플리케이션·라이브러리·서비스와의 연결에서 발생하는 취약점을 놓칩니다. - 한 번 실행한 결과는 전체 버그의 약 절반 정도만 찾으며, 비교적 단순한 취약점에 편향되는 경향이 있습니다. - 분석을 여러 번 실행한 뒤 결과를 사람이 직접 비교해야 한다면, 이미 전용 하니스가 필요한 단계에 도달한 것입니다. ## 모델에 독립적인 하니스가 필요한 이유 - 특정 모델에 시스템을 맞추면 해당 모델이 코드를 바라보는 방식에 분석 범위가 고정됩니다. - 서로 다른 모델을 같은 코드에 적용하면 각 모델이 서로 다른 취약점을 발견할 수 있습니다. - 예를 들어 한 모델은 초기 탐색을 담당하고, 다른 모델은 발견된 취약점의 재현 가능성과 타당성을 검증하도록 구성할 수 있습니다. - 모델이 교체되거나 더 뛰어난 모델이 등장해도 하니스의 상태 관리·오케스트레이션·트리아지 구조는 그대로 유지할 수 있습니다. - 따라서 장기적으로 중요한 자산은 특정 프롬프트나 모델보다 모델을 연결하고 결과를 관리하는 하니스입니다. ## 초기 보안 감사 스킬 처음에는 약 450줄 규모의 `security-audit` 스킬을 단일 저장소에서 실행하며 프롬프트를 조정했습니다. 이후 이 스킬의 단계가 전체 하니스의 기본 구조로 확장되었습니다. - **정찰(Recon)** - 세 개의 병렬 연구 에이전트가 저장소 구조와 아키텍처를 조사합니다. - 결과를 `architecture.md`에 기록합니다. - **공격 탐색(Hunt)** - 공격 클래스별로 Hunter 에이전트를 실행합니다. - 코드를 검토하는 데 그치지 않고 실제로 깨뜨리는 시도를 합니다. - **검증(Validate)** - 적대적 검증 에이전트가 각 발견을 반박하려고 시도합니다. - 재현되지 않거나 근거가 약한 후보를 제거합니다. - **보고서 작성(Report)** - 살아남은 취약점을 사람이 읽을 수 있는 보고서로 정리합니다. - **기계적 검증** - `findings.json`을 정해진 스키마에 맞춰 생성합니다. - 파일 형식뿐 아니라 취약점에 언급된 함수와 줄 번호가 실제 소스에 존재하는지도 검사합니다. - **독립 재검증** - 별도의 새로운 에이전트가 소스를 기준으로 모든 발견을 다시 확인합니다. - 최종 생존 항목만 수집 API로 제출합니다. ## 파이프라인으로의 확장 초기 스킬의 단계는 다음과 같이 하니스의 파이프라인으로 대응됩니다. - `architecture.md`를 생성하는 연구 에이전트 → **Recon** - 공격 유형별 Hunter → **Hunt** - 발견을 반박하는 Validator → **Validate** - 검증된 항목의 보고서화 → **Report** - `findings.json`의 스키마 및 소스 위치 검사 → **기계적 검증** - 새로운 에이전트의 최종 확인 → **독립 검증** 이 구조는 한 번의 긴 세션에 모든 작업을 몰아넣지 않고, 각 작업을 독립적으로 실행·저장·재시작할 수 있게 합니다. ## 상태를 외부화해야 하는 이유 - **컨텍스트 고갈** - 장시간 실행하면 모델이 기존 분석 내용을 잊습니다. - 분석 상태, 가설, 조사 결과, 발견 사항을 데이터베이스 등에 저장해 모델의 기억에 의존하지 않도록 해야 합니다. - LLM은 상태를 가진 작업자라기보다 필요할 때 호출되는 계산 엔진으로 취급합니다. - **지속성 부족** - 네트워크 오류, API 제한, 프로세스 충돌이 발생해도 처음부터 다시 시작해서는 안 됩니다. - 각 단계의 진행 상황과 결과를 저장하면 중단된 지점부터 재개할 수 있습니다. - **재범위 지정과 교차 참조** - 독립적인 조사 결과를 나중에 다시 불러오고, 다른 발견이나 저장소와 연결할 수 있어야 합니다. - 수백 개의 조사를 별도의 실행 단위로 유지해야 중복 제거와 후속 검증이 가능합니다. ## 대규모 트리아지와 교차 저장소 분석 - 엔터프라이즈 환경에서는 원시 취약점 후보가 수천 개 생성될 수 있습니다. - 하니스는 후보를 수집하는 것에서 끝나지 않고, 검증·중복 제거·우선순위 지정 과정을 거쳐 신뢰할 수 있는 수정 큐로 줄여야 합니다. - 단일 저장소 분석만으로는 해당 저장소를 사용하는 애플리케이션과의 인터페이스 문제를 볼 수 없습니다. - 여러 저장소 간 의존성과 데이터 흐름을 추적하면 구성 요소 사이에서만 드러나는 취약점을 찾을 수 있습니다. - 다만 교차 저장소 추적은 초기 구현부터 넣기보다, 실제로 중요한 저장소가 여러 개일 때 도입하는 것이 권장됩니다. ## 단계적으로 구축하는 방법 - 최소한의 하니스는 데이터베이스에 상태를 저장하는 **Recon, Hunt, Validate** 세 단계로 시작할 수 있습니다. - 자기 자신이 발견 사항을 제출하지 못하는 별도의 Validator를 두어 검증 편향을 줄입니다. - 먼저 개발 환경에서 단일 스킬로 프롬프트와 공격 시나리오를 충분히 다듬습니다. - 다음 기능은 현재의 병목이 명확해졌을 때만 추가합니다. - 중단 후 재개가 문제라면 영속성 추가 - 결과가 너무 많으면 중복 제거 에이전트 추가 - 여러 저장소가 실제 분석 대상이 되면 교차 저장소 추적 추가 - 초기부터 전부 자동화하기보다, 현재 작업을 가장 느리게 만드는 문제를 해결하는 방향으로 하니스를 확장해야 합니다. 실용적으로는 특정 모델이나 프롬프트에 시스템을 종속시키지 말고, 분석 상태·발견 사항·검증 결과를 저장하는 모델 독립적 파이프라인부터 구축하는 것이 좋습니다.
