기술 요약: 실세계 웹 취약점 탐지를 위한 LLM 평가

문제 정의

웹 애플리케이션, 특히 워드프레스(WordPress)와 같은 콘텐츠 관리 시스템(CMS)으로 구축된 애플리케이션은 제3자 플러그인의 코드 품질 가변성으로 인해 상당한 보안 위험에 직면해 있습니다. 워드프레스가 전 세계 웹사이트의 42.5% 이상을 구동하고 있으며, 그 플러그인 생태계에 70,000개 이상의 알려진 취약점이 존재한다는 점을 고려할 때, 보안 결함을 조기에 식별하는 것은 매우 중요합니다. 정적 분석 도구(예: Semgrep, ZAP)나 동적 분석 방법이 존재하지만, 이러한 도구들은 상당한 전문 지식을 요구하거나 복잡하고 문맥 의존적인 취약점을 파악하는 데 어려움을 겪는 경우가 많습니다.

에이전트 역량을 갖춘 대규모 언어 모델(LLM)의 등장은 자동화된 취약점 탐지를 위한 잠재적인 경로를 제공합니다. 그러나 프론티어(Frontier) 모델과 오픈 웨이트(Open-weight) 모델이 실세계의 웹 특화 취약점(SQL 인젝션, XSS, 경로 탐색, RCE 등)을 탐지하는 데 있어 얼마나 효과적인지는 아직 충분히 연구되지 않았습니다. 주요 불확실성으로는 모델 아키텍처, 프롬프트 설계, 그리고 추론 일관성이 실제 저장소 규모의 환경에서 탐지율에 어떤 영향을 미치는지 등이 있습니다.

방법론

저자들은 워드프레스 플러그인 내의 취약점 탐지 능력을 평가하기 위해 6개의 LLM을 대상으로 한 종합적인 벤치마킹 연구를 수행했습니다.

실험 설정

• 대상: 네 가지 취약점 클래스를 포함하는 WPScan 취약점 데이터베이스에서 선정된 4개의 워드프레스 플러그인: 경로 탐색(formgent), SQL 인젝션(popup-builder-block), 저장형 XSS(responsive-lightbox), 원격 코드 실행(w3-total-cache). 연구는 재현성을 보장하고 훈련 데이터 오염 위험을 최소ize하기 위해 이 플러그인들의 특정 취약한 버전을 사용했습니다.
• 평가 모델:
  • 프론티어 (폐쇄형 소스): Claude Opus 4.6, Codex GPT-5.4, Gemini 3.1-pro-preview.
  • 오픈 웨이트: Qwen 3.5 (122b), Qwen 3 Coder Next (FP8), MiniMax M2.5.
• 프롬프트 엔지니어링: 세 번의 실험 반복 과정에서 다섯 가지의 뚜렷한 프롬프트 전략을 테스트했습니다:
  1. 저노력(Low effort): 최소한의 지시 ("취약점 찾아줘.").
     2. 단순 일반(Simple general): OWASP Top 10 취약점을 찾도록 하는 역할 기반 지시.
     3. 단순 특정(Simple specific): 플러그인에 존재하는 특정 취약점 클래스로 범위를 좁힌 지시.
  2. 고급 일반(Advanced general): 상세한 분석 단계를 포함한 복잡한 생각의 사슬(Chain-of-Thought, CoT) 워크플로우.
  3. 고급 특정(Advanced specific): 특정 취약점 클래스로 범위를 좁힌 CoT 워크플로우.
• 실행: 자동화된 프레임워크(run_experiment.py)를 사용하여 전용 고성능 가상 머신 상의 CLI 도구를 통해 LLM 에이전트를 실행했습니다. 각 플러그인은 모든 모델과 모든 프롬프트 조합으로 세 차례의 반복 실험을 거쳐 분석되었습니다 (총 360개의 보고서 생성).
• 검증: 두 명의 저자가 생성된 모든 보안 보고서를 수동으로 검토했습니다. 발견된 항목이 취약점 클래스, 엔드포인트, 파라미터 측면에서 공개된 개념 증명(PoC)과 일치하는 경우에만 "탐지됨"으로 표시되었습니다.

주요 기여

1. 벤치마킹 프레임워크: 플러그인 저장소 맥락에서의 정적 분석을 사용하여 실세계 웹 취약점에 대한 LLM을 평가하는 재현 가능한 방법론을 확립했습니다.
2. 비교 분석: 프론티어 모델과 자체 호스팅 가능한 오픈 웨이트 모델 간의 직접적인 비교를 제공하여, 폐쇄형 소스 모델만이 보안 작업에 적합하다는 가설에 도전했습니다.
3. 프롬프트 설계 통찰: 프롬프트의 범위(일반 vs 특정)와 복잡성(단순 vs 고급)이 탐지 효율성에 미치는 영향을 체계적으로 평가했습니다.
4. 일관성 평가: 여러 번의 추론 실행 간의 LLM 출력 안정성을 정량화하여 탐지 결과의 가변성을 강조했습니다.
5. 오픈 사이언스: 향후 연구를 지원하기 위해 모든 코드, 데이터셋, 프롬프트 및 실험 결과를 공개했습니다.

결과

탐지율

• 모델 성능: 모든 모델이 유효한 보안 문제를 탐지할 수 있는 능력을 보여주었으나, 비율은 크게 달랐습니다.
  • Claude Opus 4.6은 **63%**의 가장 높은 전체 탐지율을 기록했습니다.
  • MiniMax M2.5(오픈 웨이트)는 Gemini(48%) 및 Codex(47%)와 같은 프론티어 모델과 대등한 **48%**를 달로 달성했습니다.
  • Qwen 3.5(자체 호스팅)는 **35%**로 가장 낮은 성능을 보였습니다.
• 프롬프트의 영향: 범위가 지정된 프롬프트(특정 취약점 클래스)가 개방형 프롬프트보다 일관되게 우수한 성능을 보였습니다. "단순 특정" 프로프트는 6개 모델 중 3개 모델에서 가장 좋은 결과를 냈습니다. 반대로, 프롬프트의 복잡성(고급 vs 단순)은 탐지율에 일관된 영향을 미치지 않았으나, 실행 시간과 환각(hallucination) 발생률에는 영향을 주었습니다.
• 플러그인 편차: 탐지율은 특정 플러그인에 따라 크게 달라졌습니다. 예를 들어, formgent의 경로 탐색 취약점은 모든 모델이 탐지했으나, responsive-lightbox의 저장형 XSS는 90회의 반복 실험 동안 어떤 모델도 탐지하지 못했습니다.

일관성 및 신뢰성

• 불일치성: 어떤 모델도 세 번의 실험 반복 과정에서 100% 일관성을 달성하지 못했습니다.
  • Gemini는 가장 높은 일관성(95%)을 보였으나, 동시에 가장 높은 미탐지율을 기록했습니다.
  • Qwen 모델은 가장 낮은 일관성(50%)을 보였으며, 종종 "혼합된" 결과(어떤 실행에서는 탐지하고 어떤 실행에서는 탐지하지 못함)를 생성했습니다.
  • Claude나 Codex와 같은 상위 성능 모델조차 불일치를 보였으며, 이는 단 한 번의 실행만으로는 신뢰할 수 있는 취약점 평가가 불충분함을 시사합니다.

실행 시간 및 발견 사항 수

• 실행 시간: Codex와 MiniMax가 가장 빨랐습니다. Qwen 3.5는 가장 느렸습니다.
• 환각/노이즈: Claude와 Qwen 같은 모델은 Gemini나 Codex에 비해 훨씬 많은 수의 발견 사항(때로는 보고서당 48개 이상)을 보고했습니다. "저노력" 프롬프트는 더 많은 오탐(false positive)을 생성하여 수동 검증 부담을 가중시키는 경 경향이 있었습니다.

전통적인 도구와의 비교

Semgrep(Community Edition)과 비교했을 때, LLM 기반 접근 방식은 이 특정 맥락에서 전통적인 도구보다 우수한 성능을 보였습니다. Semgrep은 네 가지 기본 취약점을 하나도 식별하지 못한 반면, LLM은 네 가지 중 세 가지를 탐지했습니다(최대 63% 탐지율). 그러나 두 방식 모두 수동 검토를 필요로 하는 높은 오탐율 문제를 안고 있었습니다.

의의 및 한계

본 논문은 LLM 기반 웹 취약점 탐지가 실행 가능하지만 아직 독립적인 솔루션은 아니다라고 결론짓습니다. 연구의 핵심 요점은 다음과 같습니다:

• 오픈 웨이트 모델(특히 MiniMax M2.5)은 자체 호스팅을 위한 충분한 하드웨어 자원이 있다면 프론티어 모델의 성능을 따라잡을 수 있습니다.
• 프롬프트 엔지니어링이 매우 중요합니다. 취약점 클래스로 범위를 좁히는 것이 탐지율을 높이고 노이즈를 줄이는 데 도움이 되지만, 복잡한 CoT 프롬프트가 반드시 더 나은 결과를 가져오는 것은 아닙니다.
• 일관성은 주요한 장애물입니다. 반복 실행 간의 결과 가변성 때문에 신뢰할 수 있는 결과를 얻으려면 여러 번의 실행이 필수적입니다.
• 복잡성의 한계: (정제된 입력값에 대한 복잡한 정규식 조작 및 특정 설정 요구사항으로 인한) responsive-lightbox의 XSS 탐지 실패는 LLM이 여전히 미묘하고 문맥 의존적인 코드 경로를 다루는 데 어려움이 있음을 보여줍니다.

저자들은 LLM을 전통적인 정적 애플리케이션 보안 테스트(SAST)의 보완적인 도구로 간주해야 한다고 강조합니다. 이는 특정 취약점 클래스에 대해 탐지율을 개선할 잠재력을 제공하지만, 검증 오버헤드와 결과 일관성이라는 새로운 과제를 도입하기도 합니다. 향후 연구는 발견된 사항을 검증하고 수동 노력을 줄이기 위해 익스플로잇(exploit) 검증을 자동화하는 데 집중할 것을 제안합니다.