LLM을 이용한 서비스 취약점 분석 자동화 #2

Context

LLM을 이용한 취약점 분석 자동화 시 대용량 소스코드를 효율적으로 전달하기 어려웠고, Ripgrep 기반의 단순 패턴 매칭으로 인해 토큰 낭비가 발생했습니다. 또한 동일한 취약점 세트(예: XSS 10개)에 대해 일관성 없는 결과(8~10개)가 도출되어 신뢰성이 낮았습니다.

Technical Solution

• MCP 서버 개발: ctags로 심볼 정의를 사전 인덱싱하고 tree-sitter로 함수 범위를 구조적으로 파싱해 AI에게 IDE의 "Go to Definition" 기능 제공
• 4가지 MCP 도구 구성: find_references() (Ripgrep 기반 심볼/패턴 검색), read_definition() (ctags 인덱스에서 정의 조회 + tree-sitter 함수 범위 감지), read_source() (지정 라인 전후 코드 조회), get_project_structure() (프로젝트 디렉터리 구조 반환)
• SAST 도구를 검증 목적이 아닌 후보군 추출에 사용: Semgrep 룰로 모든 Untrusted Input → Sink 도달 경로를 추출하여 AI가 검토해야 할 모든 경로를 누락 없이 제공
• Instructor 라이브러리와 JSON 모드 활용: LLM 응답을 DiscoveryResult 스키마로 강제하고 validation error 발생 시 최대 3회 자동 재시도 구현
• 다중 에이전트 분산 작업: 대규모 경로 분석을 더 잘게 쪼개서 여러 에이전트에게 분산 처리하는 방식으로 안정성 개선

Impact

아티클에 정량적 성능 지표가 명시되지 않았습니다.

Key Takeaway

LLM 기반 보안 분석에서 "취약점을 못 찾은 이유"는 모델의 이해 부족보다는 "분석 대상 코드를 제시하지 못했기 때문"일 가능성이 높으므로, SAST 같은 정적 분석 도구를 "결과 검증"이 아닌 "입력 경로 추출"의 보조 도구로 활용하는 것이 효과적입니다.