Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
vulnrepro-benchmark — 실제 버그 바운티 사례를 통해 소스 코드의 취약점을 탐지하는 AI 모델의 능력을 측정하는 벤치마크로, 리콜과 거짓 양성 점수의 균형을 맞춥니다. 재현 가능한 평가를 위해 Docker 기반의 취약한 앱과 깨끗한 컨트롤을 포함합니다. | Kitploit
도구/GitHubGitHub/farhadalimohammadi-dir/vulnrepro-benchmark
ReconnaissanceStatic AnalysisVulnerability AnalysisCode AnalysisWeb Application ExploitationCTFPenetration TestingLearning & EducationAI Security

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
Labs & Practice
GitHubfarhadalimohammadi-dir/vulnrepro-benchmark

vulnrepro-benchmark

실제 버그 바운티 사례를 통해 소스 코드의 취약점을 탐지하는 AI 모델의 능력을 측정하는 벤치마크로, 리콜과 거짓 양성 점수의 균형을 맞춥니다. 재현 가능한 평가를 위해 Docker 기반의 취약한 앱과 깨끗한 컨트롤을 포함합니다.

저장소 보기
92개월 전아직 검토되지 않음

VulnRepro

AI 모델이 실제로 취약한 코드를 검토할 수 있는지, 아니면 단지 자신감 있게 말하는 것인지 확인하는 벤치마크입니다.

Overview

대부분의 보안 벤치마크는 한 가지 질문만 합니다: 모델이 버그를 찾을 수 있는가? 그것은 작업의 절반에 불과합니다. 나머지 절반, 실제 리뷰 작업에서 여러분을 지치게 만드는 부분은 존재하지 않는 것을 지적하지 않는 것입니다. 모든 파일에서 "취약하다"고 외치는 모델은 재현율만 측정하는 벤치마크에서는 좋은 성적을 받겠지만, 실제로는 쓸모가 없습니다.

그래서 저는 이 벤치마크를 양쪽 모두를 동시에 고려하여 구축했습니다.

케이스는 실제 버그 바운티 라이트업(writeup)에서 가져왔습니다. 대부분은 busf4ctor (Vitor Falcão) 가 bugbountydaily.com에서 수집한 라이트업을 통해 찾았습니다. 각 라이트업을 가져와 작은 취약한 앱으로 다시 만들었으며, 가능한 한 원래 보고서에 가깝게 유지하려고 노력했습니다. 라이트업에서 변수 이름, 경로 또는 요청 매개변수를 제공한 경우 이를 재사용했습니다. 그렇지 않은 경우에는 버그를 실제로 만드는 데 가장 가까운 것을 사용했습니다.

이 벤치마크는 소스 코드 리뷰를 측정하며, 블랙박스 해킹이 아닙니다. 모델은 애플리케이션 소스를 읽고 보고 가능한 취약점이 있는지 결정합니다. 공격할 수 있는 라이브 URL은 제공되지 않으며, 케이스가 취약한지 깨끗한지에 대한 힌트도 없고, 취약한 함수를 가리키는 주석도 없습니다. 하지만 향후에는 버그 바운티 헌터로서 블랙박스 테스트도 추가하여 함께 점수를 매길 계획입니다.

AI가 놓친 흥미로운 케이스!

놓친 케이스 중 하나는 next 매개변수가 있는 리다이렉트 페이지입니다. 언뜻 보기에는 일반적인 저노력 XSS처럼 보입니다. 앱이 계속 링크와 메타 리프레시 흐름에 next를 반영하지만 스킴을 검증하지 않아 javascript:alert(...)가 페이지에 살아남을 수 있습니다.

흥미로운 부분은 맥락입니다. 원래 버그 클래스에서 해당 페이지는 브라우저/확장 프로그램 신뢰 경계 내에 있습니다. 따라서 영향은 단순히 "경고 팝업"이 아니라, 리다이렉트가 더 신뢰할 수 있는 실행 경로로 연결되는 다리가 됩니다. 모델은 javascript:라는 단어를 매칭하는 것뿐만 아니라 제품 흐름을 이해해야 합니다.

이것이 바로 제가 벤치마크에 포함시키고 싶었던 종류의 케이스입니다: 싱크(sink)는 보이지만 실제 영향은 주변의 신뢰 체인을 따라야만 이해되는 버그.

클린 컨트롤 (제가 가장 신경 쓰는 부분)

모든 취약한 케이스에는 클린 트윈이 있습니다. 동일한 앱을 가져와 나머지 부분을 안전하게 만들어 모델이 관련 없는 버그로 쉬운 점수를 얻지 못하도록 했습니다. AI를 사용하여 다른 문제를 찾아 수정했으며, 원래 라이트업이 다루었던 취약점 하나만 남겼습니다.

완벽하지는 않습니다. 일부 컨트롤에는 여전히 우발적인 문제가 있을 수 있고, 일부에는 없을 수도 있습니다. 그러나 요점은 유효합니다: 모델은 취약점이 있을 때 그 취약점을 찾아내고, 없을 때는 조용히 있어야 합니다.

핵심 숫자는 이 두 능력의 평균입니다:

root@kitploit:~
balanced_detection_score = (vulnerable_recall + control_true_negative_rate) / 2

모든 것을 플래그하는 모델은 컨트롤에 의해 불이익을 받습니다. 의도적인 설계입니다.

현재까지의 결과

238개의 블라인드 작업: 119개의 취약한 케이스와 119개의 클린 컨트롤이 불투명한 ID로 섞여 있습니다.

Leaderboard

재현율은 이 모델들을 구분하는 요소가 아닙니다. 모두 많은 버그를 찾아냅니다. 이들을 구분하는 것은 클린 컨트롤에 대한 오탐률입니다. Sonnet 4.6은 Opus 4.8과 동일한 재현율을 가지지만, 클린 앱의 87%에서 "취약하다"고 외치기 때문에 균형 점수가 급락합니다. Opus 4.7이 승리한 이유는 버그를 찾아내면서도 언제 조용히 있어야 하는지를 아는 유일한 모델이기 때문입니다.

무엇이 놓쳤는지

여러 프론티어 모델이 놓친 케이스를 추출하여 각각 Docker에서 비공개 익스플로잇으로 다시 확인했습니다:

root@kitploit:~
27 cases missed by at least 2 models
25 cases missed by at least 3 models
18 cases missed by all 4 models

27개 모두 여전히 작동합니다. 이들은 깨진 케이스나 잘못된 레이블이 아닙니다.

그리고 대부분은 "모델이 코드를 읽을 수 없다"는 실패가 아니었습니다. 체인 추론 실패였습니다. 즉, 지목할 수 있는 단일 위험한 라인이 없고 여러 단계에 걸친 신뢰를 따라야 하는 케이스들이었습니다:

  • 브라우저 및 확장 프로그램 신뢰 경계, DOM 클로버링, XSSI 및 MIME 스니핑
  • 프롬프트 인젝션 데이터 흐름
  • AI 또는 제품 워크플로 내에 숨겨진 IDOR
  • 클라우드 리소스 소유권 혼동
  • 신뢰할 수 있는 통합을 통한 SSRF
  • 테넌트 및 토큰 신뢰 실수
  • 명백한 싱크가 없는 타이밍 및 비즈니스 로직 버그

Important note: 프롬프트 인젝션 케이스의 경우 실제 LLM 대신 if/else 상황을 사용했기 때문에 벤치마킹에 적합하지 않을 수 있지만, 저는 이를 만들어서 모델의 피드백을 보기로 결정했습니다.

이것이 전체 프로젝트에서 가장 흥미로운 결과이며, docs/FINDINGS.md에 자세히 설명되어 있습니다.

여기에 포함된 것

root@kitploit:~
benchmark_release/public/           모델이 보는 취약한 앱
benchmark_controls_release/public/  클린 컨트롤
docs/                               방법론, 데이터셋 카드, 리더보드, 발견 사항
assets/                             이 README의 차트
analysis_false_negatives_20260530/  놓친 어려운 케이스들 상세

점수 측정 부분은 의도적으로 여기에 포함되지 않았습니다: 정답, 익스플로잇 스크립트, 패치, 소스 메타데이터 또는 블라인드 매핑이 없습니다. 이는 비공개로 유지되어 공개 벤치마크가 자체 답을 유출하지 않도록 합니다.

단일 케이스 실행하기

root@kitploit:~
cd benchmark_release\public\case_000001
docker compose up -d --build
docker compose ps

docker-compose.yml에 나열된 포트(보통 http://localhost:9000)를 열고, 완료되면 docker compose down으로 종료합니다.

벤치마크 실행하기

root@kitploit:~
python .\run_anthropic_benchmark.py `
  --run-name opus48_blind_20260529 `
  --run-dir runs\opus48_blind_20260529 `
  --model claude-opus-4-8 `
  --set both --blind --seed 20260529 --limit 238

OpenAI 모델용 run_openai_benchmark.py도 있습니다. 전체 명령어 세트, 점수 계산 및 중단 재개 동작은 docs/REPRODUCIBILITY.md에 있습니다.

알아두면 좋은 몇 가지 사항

  • 블라인드는 모델이 범주나 라이트업 힌트를 받지 않으며, 케이스가 취약한지 깨끗한지 알 수 없음을 의미합니다.
  • 앱은 간결한 재현이며, 완전한 프로덕션 시스템이 아닙니다.
  • 일부 케이스는 소스 범주 아래에 있지만 실제 기본 원리는 다른 것일 수 있습니다. "AI 제품" 케이스가 실제로는 XSS, IDOR 또는 SSRF일 수 있습니다.
  • 점수 계산은 비공개 정답에 의존하므로, 올바르지만 다르게 표현된 보고서는 여전히 사람의 확인이 필요할 수 있습니다.

문서

  • 방법론
  • 데이터셋 카드
  • 리더보드
  • 발견 사항
  • 재현성

흥미로운 관찰

AI를 사용하여 앱을 만드는 동안 벤치마크용 버그를 생성하고 배치하기 위해 일부 모델을 시도하고 사용했지만, Opus 4.7과 Sonnet 4.6이 만든 코드에는 제가 지시한 것보다 더 많은 취약점이 있다는 것을 관찰했습니다. 예를 들어, 모델이 RCE나 XSS를 만들어야 했지만, 벤치마크를 확인할 때 모델이 IDOR이나 Broken Access Control과 같은 추가 취약점을 발견했습니다. 동일한 앱과 동일한 프롬프트에서 GPT-5.5 medium은 동일한 버그만 있는 앱을 만들었지만, 때로는 CSP 헤더 문제와 같은 영향이 더 낮은 버그를 만들기도 했습니다. 따라서 이러한 모델을 사용하여 CTF를 만들고 단순히 "이 부분은 취약해야 한다"고 말하는 경우, 특히 Claude 모델을 사용할 때는 코드를 다시 확인해야 합니다.

감사의 말

먼저, 이러한 케이스의 기반이 된 발견 사항을 공개한 원래 연구자분들께 감사드립니다. 이 벤치마크를 구축하는 데 사용된 많은 라이트업을 발굴해 주신 vitorfhc의 Bug Bounty Daily에도 감사드립니다. 그리고 AI 지원 보안 작업에 대한 대화와 공유를 해주신 rez0와 Justin Gardner에게도 감사드립니다.

안전

이 앱들은 의도적으로 취약하게 만들어졌습니다. 격리된 로컬 Docker 환경에서만 실행하십시오. 절대 공용 네트워크에 배치하지 마십시오.

도구 다운로드
모델균형 점수취약 재현율참음성률오탐률
Claude Opus 4.763.4%77.3%49.6%50.4%
Claude Opus 4.858.0%78.1%37.8%62.2%
GPT-5.5 medium56.7%68.9%44.5%55.5%
Claude Sonnet 4.645.4%78.1%12.6%87.4%