PatchHolmes, 리스트 비교 에이전트로 취약점 수정 커밋을 찾다

배경

취약점 정보를 실제 수정 커밋과 연결하면 패치 검증, 영향 버전 추적, 심각도 분석, 소프트웨어 공급망 검사에 활용할 수 있다. 하지만 GitHub Advisory Database와 National Vulnerability Database에 등록된 CVE 가운데 약 60~63%는 수정 패치 링크를 포함하지 않는다. PatchHolmes는 이미 알려진 취약점을 해결한 커밋을 찾아 이 연결을 복원하는 ‘패치 검색’ 문제를 다룬다.

패치 검색이 어려운 이유

검색 공간이 매우 크다는 점이 첫 번째 난관이다. 하나의 저장소에는 최대 약 140만 개의 커밋이 있을 수 있으며, 취약점의 약 49%는 5000개가 넘는 커밋을 가진 저장소와 관련된다. 후보 커밋의 diff도 길다. 연구 대상 코퍼스에서 평균 diff 길이는 약 1만5000토큰으로, 짧은 입력을 전제로 한 인코더는 핵심 변경을 놓칠 수 있다. 또한 취약점 보고서와 커밋 메시지는 같은 문제를 다른 말로 표현한다. 보고서는 ‘버퍼 오버플로’를 언급하지만, 수정 커밋은 ‘범위를 벗어난 읽기’라고 기록할 수 있다.

PatchHolmes의 2단계 방식

PatchHolmes는 검색과 검사를 분리한다.

• 후보 검색: 하이브리드 검색기가 로컬 Git 저장소를 훑어 상위 100개 후보를 만든다.
• 리스트 기반 에이전트 선택: 2단계 에이전트는 후보를 하나씩 독립적으로 평가하지 않고 전체 목록을 함께 본다. 이후 예산이 제한된 네 가지 도구를 사용해 약 3~10개의 커밋만 선택적으로 열어 보고, 최종적으로 가장 적합한 커밋 하나를 제출한다.

이 설계는 비슷한 코드 경로를 수정한 커밋이 여러 개 있을 때 특히 의미가 있다. 점별 분류 방식은 여러 후보에 모두 비슷한 긍정 판단을 내린 뒤 목록의 첫 항목을 고르는 상황에 빠질 수 있다. 반면 전체 목록을 본 에이전트는 변경 의도, 코드 수정 내용, 주변 맥락을 후보 간에 비교할 수 있다.

결과

GitHubAD에서 PatchHolmes의 Recall@1은 59.95%였다. 점별 분류기 Favia는 34.61%, 검색 후 추론을 수행하는 IRCoT는 28.55%였다. 후보 집합을 동일하게 유지한 실험에서도 검색기의 첫 후보를 그대로 선택하는 방식보다 에이전트를 추가했을 때 Recall@1이 27.32%포인트 높아졌다. PatchFinder_top10의 후보 집합으로 별도 변경 없이 옮겼을 때도 PatchFinder의 자체 Top-1 선택 결과인 24.28%가 39.86%로 상승했다.

Qwen 계열에서 언어 모델을 바꿔도 Recall@1 변화는 1%포인트 미만이었다. 다른 모델 계열인 gpt-oss를 사용한 경우에도 에이전트가 없는 기준선보다 크게 높은 성능을 유지했다. 이는 개선 효과가 특정 모델보다는 리스트 전체를 확인하고 비교하는 에이전트 루프에서 나온다는 점을 시사한다. 시스템은 취약점 하나당 약 9만6000개의 입력 토큰, 8회의 도구 호출, 약 5개의 커밋 검사를 사용한다. 파인튜닝이나 외부 검색 API 없이 고정된 오픈웨이트 모델과 로컬 Git 저장소에서 실행된다.

의미와 남은 과제

PatchHolmes의 핵심 기여는 많은 후보를 반환하는 검색을 제한된 예산 안에서 비교·검증하는 에이전트 작업으로 확장했다는 데 있다. 패치 링크가 빠진 취약점 데이터의 보완과 보안 담당자의 수작업 분류 부담 감소에 활용될 가능성이 있다.

다만 Top-1 정확도는 아직 완벽하지 않다. 후보 검색의 품질, 긴 diff 이해, 취약점 보고서와 실제 코드 변경 사이의 용어 차이는 여전히 중요한 과제다. 앞으로는 다양한 저장소와 프로그래밍 언어, 실제 보안 운영 환경에서 안정성을 확인해야 한다.

출처: Hugging Face Daily Papers