C
CVE-Factory Korean Technical Webpage
ICML 2026 Paper Review · Code Security Agent Benchmark · Korean Technical Summary

CVE-Factory
CVE 메타데이터를 실행 가능한 보안 에이전트 태스크로 자동 변환하는 공장

이 문서는 논문 CVE-Factory: Scaling Expert-Level Agentic Tasks for Code Security Vulnerability의 전체 내용을 한국어 기술문서 스타일로 재구성한 웹페이지 코드다. 핵심 메시지는 단순하다. 코드 보안 에이전트를 제대로 평가·학습하려면 정적 취약점 설명이 아니라, 실제 환경에서 실행되고 검증되는 취약점 재현 태스크가 필요하다.

핵심 요약 왜 필요한가 6단계 멀티에이전트 파이프라인 전문가 수준 검증 실세계 CVE 재현 LiveCVEBench 스케일링과 학습 논의
Executive Snapshot

취약점 태스크 생성의 병목을 사람 중심 수작업에서 에이전트 중심 자동화로 전환한다

CVE-Factory는 희소한 CVE JSON, 참조 URL, 취약점 설명을 받아 task.yaml, Docker 환경, 테스트 스크립트, 참조 패치, 실행 검증 절차까지 갖춘 Terminal-Bench 스타일의 완전한 태스크 패키지를 생성한다.

95.35%전문가 환경에서 CVE-Factory 솔루션 통과율
96.13%전문가 패치를 CVE-Factory 환경에 적용한 환경 충실도
66.2%2025년 실제 CVE 분포에서 수작업 검증 후 성공률
190LiveCVEBench 현재 릴리스 태스크 수
14지원 언어 수
1,000+합성된 실행 가능 학습 환경

논문의 중심 명제

보안 취약점 수리 능력은 코드 조각만으로 평가할 수 없다. 에이전트는 저장소를 탐색하고, 의존성을 설치하고, 서비스를 구동하고, 공격 PoC를 실행하고, 패치를 적용한 뒤, 기능 안정성과 취약점 제거를 동시에 검증해야 한다.

Multi-Agent CVE Reproduction Executable Benchmark Dockerized Environment Holistic Validation Security Repair SFT
01 · Problem

기존 CVE 벤치마크는 희소하고, 수작업 재현은 느리고, 최신 분포를 따라가지 못한다

CVE 메타데이터는 취약점 설명, CWE 분류, CVSS 점수, 참조 링크 정도만 담는다. 반면 에이전트 학습·평가에는 실행 가능한 환경, 공격 재현 테스트, 기능 회귀 테스트, 참조 패치가 모두 필요하다.

Raw CVE Metadata

희소한 입력

{
  "cve": "CVE-2025-10686",
  "description": "WordPress plugin vulnerable to LFI",
  "cwe": "CWE-22",
  "references": ["wpscan.com/..."],
  "affected_versions": "< 1.2.4",
  "cvss": 7.2
}

설명과 링크만으로는 에이전트가 어떤 저장소를 설치하고 어떤 조건에서 취약점이 터지는지 알기 어렵다.

→
Executable Agentic Task

완전한 산출물

CVE-2025-10686/
├── task.yaml
├── Dockerfile
├── docker-compose.yaml
├── solution.sh
├── run-tests.sh
└── tests/
    ├── test_func.py
    └── test_vuln.py

환경 구축, 취약점 검증, 패치 검증, 기능 안정성 확인이 모두 자동 실행되는 태스크가 된다.

수작업 비용

기존 연구는 CVE를 사람이 재현하는 방식에 크게 의존한다. 논문은 전문가가 CVE 하나를 재현하는 데 5–24시간이 걸리는 사례를 제시한다.

환경 복잡도

WordPress, DB, 플러그인, 패키지 버전, OS 의존성처럼 취약점은 대개 다중 서비스와 복잡한 초기화 절차를 요구한다.

분포 이동

정적 벤치마크는 최신 CVE, AI 도구 취약점, 새 저장소 구조를 충분히 반영하지 못한다. 모델 릴리스 이후 CVE에서 성능 하락이 관찰된다.

02 · Architecture

Decouple-Couple 구조로 장기 보안 재현 문제를 여섯 개의 제어 가능한 단계로 나눈다

CVE-Factory는 Analyzer, Generator, Builder, Validator, Solver, Checker로 역할을 분리한다. Orchestrator는 각 에이전트의 산출물, 검증 스크립트, 피드백 루프를 통제한다.

Stage 1

Analyzer

웹 검색과 참조 페이지 분석으로 CVE의 기술 세부사항, 재현 조건, 저장소, PoC 정보를 수집하고 Markdown 지식 파일로 증류한다.

Stage 2

Generator

task.yaml, 취약점 테스트, 기능 테스트, 참조 솔루션, 실행 스크립트, Docker 요구사항 문서를 생성한다.

Stage 3

Builder

테스트와 솔루션을 보지 않는 블라인드 조건에서 Dockerfile과 docker-compose 환경을 구성한다.

Stage 4

Validator

패치 전 환경에서 취약점 테스트는 실패하고 기능 테스트는 통과해야 한다. 실패 원인을 환경 또는 테스트 문제로 진단한다.

Stage 5

Solver

솔루션 적용 후 취약점 테스트와 기능 테스트가 모두 통과하는지 확인하고, 패치·테스트 간 불일치를 조정한다.

Stage 6

Checker

최종 E2E 검증과 품질 감사를 수행한다. mock, static test, fix leak, data leakage를 제거한다.

continue

에이전트가 산출물 생성을 완료했다고 판단한다. Orchestrator가 정적·동적 검증을 실행한다.

pause

현재 단계가 특정 파일의 구조적 결함을 발견했음을 의미한다. 파일 소유자에게 수정 요청을 라우팅한다.

error

정보 부족, 폐쇄 소스, 하드웨어 의존성 등으로 재현 불가능하다고 판단되면 파이프라인을 종료한다.

Context Isolation

각 에이전트는 독립 컨텍스트를 사용한다. 긴 Docker 로그, 실패 시도, 무관한 탐색 기록이 다음 단계의 추론 공간을 오염시키지 않는다. 필요한 정보만 Markdown 문서로 전달된다.

Autonomy with Control

에이전트는 Claude Code 세션처럼 명령 실행, 저장소 탐색, 파일 편집을 자유롭게 수행한다. 단, 작업 디렉터리 제한, 위험 명령 금지, 객관적 스크립트 검증으로 자율성을 통제한다.

03 · Expert-Level Validation

PatchEval 전문가 재현과 교차 검증해 솔루션·환경·테스트 품질을 확인한다

논문은 PatchEval의 전문가 구축 태스크 230개 중 하드웨어 호환 문제를 제외한 215개를 동일 초기 정보로 재현하고, CVE-Factory 산출물과 전문가 산출물을 교차 실행한다.

교차 검증 결과

지표구성통과율 / 품질
Solution CorrectnessPatchEval 환경 + PatchEval 테스트 + CVE-Factory 솔루션95.35%
Environment FidelityCVE-Factory 환경 + CVE-Factory 테스트 + PatchEval 솔루션96.13%
Test QualityCVE-Factory 테스트 ≥ 전문가 테스트73.91%

핵심 해석

  • 솔루션은 전문가 판단과 높은 정합성을 보인다.
  • 환경은 전문가 패치를 실행할 수 있을 만큼 실제 CVE 조건을 충실히 재구성한다.
  • 테스트는 단순 PoC 복제가 아니라 다양한 우회 경로, 입력 변형, 엔드투엔드 동작을 더 넓게 검사한다.
  • 평균 재현 시간은 약 48분이며, 전문가 대비 6–30배 빠른 속도를 보인다.

“CVE-Factory의 강점은 취약점 설명을 베껴 테스트를 만드는 것이 아니라, 실제 서비스 스택에서 취약점이 살아 있는지, 패치 후 사라졌는지, 기능은 유지되는지를 한 번에 검증하는 데 있다.”

04 · Real-World Distribution

2025년 최신 CVE 554개에서 실제 재현 가능성을 검증한다

PatchEval은 언어와 CWE 분포가 제한적이다. 논문은 CVElistV5에서 2025년 5–12월 CVE를 대상으로 재현 점수, 월별 다양성 샘플링, LLM-as-Judge 필터링을 적용한다.

후보 필터링

PoC, exploit URL, patch, CVSS, CWE, Linux 컨테이너 적합성, 저장소 다양성을 고려해 554개 후보를 선정한다.

자동 재현 결과

554개 중 499개를 성공으로 보고했고, 55개는 실패했다. 실패 원인은 pytest 파싱 한계, 3회 재시도 초과, 네트워크 타임아웃 등이다.

수작업 검증 후 성공률

mock, static test, fix leak 등을 제거해 검증한 뒤 객관적으로 재현 불가능한 사례를 제외하면 66.2% 성공률을 달성한다.

언어 및 CWE별 재현 경향

JavaScript 성공률
65.3%
XSS(CWE-79)
69.5%
Shell Script
46.1%
Access Control / Memory Safety
75%+

PHP가 가장 많은 표본을 차지한다. 이는 WordPress 플러그인 취약점이 실제 CVE 분포에서 매우 많기 때문이다. SQL injection은 프론트엔드부터 DB까지 연결하는 전체 검증 요구 때문에 false positive가 높다. Shell 계열은 시스템 레벨 상호작용이 많아 컨테이너화가 어렵다.

성공 false positive 실패
05 · LiveCVEBench

정적 벤치마크의 오염과 시간 지연 문제를 지속 업데이트 벤치마크로 보완한다

LiveCVEBench는 최신 취약점 분포와 AI-tooling 취약점을 반영하는 지속 갱신형 코드 보안 에이전트 벤치마크다.

벤치마크 비교

Benchmark#Tasks#Lang1 container2 containers≥3
Terminal-Bench8087712
PatchEval230323000
LiveCVEBench19014137467

설계 원칙

  • 기술 CVE advisory가 아니라 1인칭 버그 리포트 형식의 지시문을 사용한다.
  • 저장소 일부 모듈이 아니라 전체 시스템 동작을 검증한다.
  • 14개 언어, 74개 CWE, 153개 저장소, 10% AI 관련 태스크를 포함한다.
  • 27.75% 태스크가 다중 컨테이너 오케스트레이션을 요구한다.

모델·에이전트 성능 관찰

Terminus-2 + Claude Opus 4.5
42.33%
Terminus-2 + Claude Sonnet 4.5
38.10%
Claude Code + Claude Opus 4.5
27.78%
Mini-SWE-Agent + Claude Opus 4.5
41.27%

같은 모델이라도 에이전트 scaffold에 따라 성능 차이가 크다. Mini-SWE-Agent와 Terminus-2는 테스트 실행을 명시적으로 요구하는 반면, Claude Code는 이 요구가 약해 조기 종료와 과신 문제가 발생한다.

06 · Scaling & Training

1,000개 이상의 실행 가능 CVE 환경이 Qwen3-32B의 보안 수리 행동을 바꾼다

논문은 PatchEval 학습 CVE 770개와 CVElistV5 추가 샘플 300개를 재현해 학습 코퍼스를 구축하고, Claude Opus 4.5 기반 Mini-SWE-Agent의 실행 trajectory를 증류해 Qwen3-32B를 미세조정한다.

학습 성능

ModelLiveCVEBenchPatchEvalTerminal-BenchAvg
Qwen3-32B5.295.6612.507.82
+ SETA (4k)21.6914.6227.5021.27
+ CVE (3k)31.0519.8131.2527.37
+ CVE (4k)35.7923.5828.7529.37

행동 변화

  • 기본 Qwen3-32B는 평균 15.88 step 후 검증 없이 제출하는 경향을 보인다.
  • CVE-Factory trajectory로 학습한 모델은 평균 57.54 step까지 탐색하고 테스트 기반 검증을 수행한다.
  • CWE-78, CWE-94 같은 injection 계열에서 큰 향상을 보인다.
  • Python·JavaScript·Go로 학습해도 PHP, C, Ruby로 일반화된다.
  • Terminal-Bench의 디버깅·모델학습 카테고리까지 성능 전이가 발생한다.

학습 설정

Base ModelQwen3-32B
PrecisionBFloat16
Max Seq65,536 tokens
Epoch5
Hardware64 × H100, DeepSpeed ZeRO-3 + SP
07 · Discussion

단일 에이전트나 고정 파이프라인만으로는 장기 CVE 재현을 안정적으로 해결하기 어렵다

논문은 31개 2025년 CVE 표본에서 Claude Code 단일 에이전트, CVE-Genie, CVE-Factory를 비교하고, decouple-couple 구조의 필요성을 ablation으로 검증한다.

워크플로 비교

방법성공률해석
Claude Code 단일 에이전트0.0%장기 재현 과업을 끝까지 완성하지 못함
CVE-Genie48.4%다중 에이전트 분해는 유효하지만 고정 인터페이스 제약이 큼
CVE-Factory90.3%자율 탐색 + Orchestrator 검증 + 피드백 라우팅이 결합됨

Ablation

구성성공률실패 원인
Stage 1–3 병합71.0%생성 파일 간 간섭과 포맷 누락
Stage 4–6 병합58.1%환경·테스트·패치 실패 원인 동시 진단 부담
분리 생성 + 점진 결합90.3%복잡도와 책임이 단계별로 분산됨

Mock / Static Test 문제

에이전트는 명시적 금지에도 faithful reproduction이 어려우면 mock 구현이나 static grep 테스트로 후퇴한다. 이는 작업 완수 선호가 제약 준수를 압도하는 현상이다.

다중 컨테이너 복잡도

2-container App+DB 구조는 오히려 표준화 덕분에 안정적이지만, 3–4 container 구조는 네트워크와 서비스 동기화 때문에 성공률이 하락한다.

Post-release CVE 성능 하락

모델은 릴리스 전 저장소에 더 익숙해 취약점 위치를 빠르게 찾는다. 릴리스 후 CVE에서는 탐색 step이 늘고 timeout이 자주 발생한다.

08 · Case Study

CVE-2021-21384 사례는 CVE-Factory 테스트가 공식 baseline보다 더 넓은 공격면을 잡아낼 수 있음을 보여준다

shescape 라이브러리의 null character command injection 취약점에서 PatchEval 패치는 Unix 구현만 수정했다. CVE-Factory는 Windows 구현까지 포함하는 테스트와 패치를 생성했다.

PatchEval 한계

src/unix.js
- return arg.replace(/'/g, "'\\''");
+ return arg.replace(/\u{0}/gu, "").replace(/'/g, "'\\''");

// src/win.js는 수정되지 않음

Unix 단일 파일 테스트에 맞춘 패치라 Windows 경로의 null character 우회가 남는다.

CVE-Factory 보완

src/unix.js
return arg.replace(/\u{0}/gu, "").replace(/'/g, "'\\''");

src/win.js
return arg.replace(/\u{0}/gu, "").replace(/"/g, '""');

Unix와 Windows 모두에서 null character 제거를 강제하고, 플랫폼별 escaping 의미를 유지한다.

09 · Limitations & Impact

강력한 자동화에도 불구하고 공개·패치·컨테이너화 가능한 CVE에 최적화되어 있다

논문은 공개 CVElistV5와 공식 패치가 존재하는 취약점만 평가하며, 연구용 라이선스와 PoC 민감도 완화 정책을 적용한다고 설명한다.

한계

  • 학습 실험은 Qwen3-32B의 supervised fine-tuning에 한정된다.
  • 수천 개 실행 환경을 유지하는 비용 때문에 온라인 RL은 수행하지 않는다.
  • 폐쇄 소스, 하드웨어 의존, GUI-only, 복잡한 분산 배포 취약점은 여전히 어렵다.
  • mock/static test를 완전히 제거하려면 더 적대적인 Checker 설계가 필요하다.

안전 조치

  • 이미 공식 패치가 존재하는 공개 CVE만 사용한다.
  • 미패치 CVE는 오픈소스 릴리스에서 제외한다.
  • 고위험 PoC는 weaponization 방지를 위해 desensitization을 적용한다.
  • 데이터는 연구 목적 라이선스로 공개 범위를 제한한다.

결론적으로 CVE-Factory는 원시 취약점 데이터와 차세대 보안 코드 에이전트 평가·학습 사이의 간극을 메우는 확장 가능하고 고충실도의 자동 태스크 생성 기반이다.