LLM에 질의하는 비밀 스캐너 Klarion 제작 및 성능 테스트 결과

비밀 스캐너는 노이즈 문제가 있습니다. 크고 건강한 코드베이스를 대상으로 하면 수백 개의 경고가 발생합니다: 테스트용 더미(test fixtures), 문서 예제(docs examples), 무작위처럼 보이는 긴 식별자 등이 그것입니다. 사람들은 이러한 경고들을 읽지 않게 되고, 그 사이 실제 유출된 정보는 스윽 빠져나갑니다.

이 문제는 AI 코딩 에이전트가 등장하면서 더욱 심각해졌는데, 이 에이전트들은 사람이 검토하는 속도보다 빠르게 파일을 작성하기 때문입니다. 그래서 저는 Klarion이라는 스캐너를 만들었습니다. 이 스캐너는 경고를 발생시키기 전에 LLM에 질문을 던지며, 이를 일반적인 도구들과 벤치마킹하여 실제로 도움이 되는지 확인했습니다.

테스트 과정

다섯 가지 스캐너와 네 개의 대규모 오픈 소스 저장소(각기 다른 언어)를 선정하고, 모두 특정 커밋에 고정했습니다:

spring-boot (Java), terraform (Go/HCL), next.js (TypeScript), symfony (PHP)
총 61,514개 파일
대조군(Control set): flask와 rails (5,054개 파일)

버전: klarion 0.4.3 (Claude Haiku 사용), gitleaks 8.30.1, trufflehog 3.97.5, detect-secrets 1.5.0, ripsecrets 0.1.11.

이 저장소들에는 실제 자격 증명(live credentials)이 없으므로, 모든 경고는 사람이 직접 확인하고 폐기해야 하는 내용입니다.

Same code. Five secret scanners.

Tool	Alerts on the 4 repos	Per 1k files	Control (flask + rails)
Klarion + model	11	0.18	1
...
그 결과는 동일한 코드에 대해 gitleaks보다 33배 적고, detect-secrets보다 1,000배 이상 적은 경고였습니다. Klarion이 제시하는 11개의 경고 각각에는 모델의 판정(verdict)과 한 줄짜리 이유가 첨부되어 있어, 검토하는 데 하루가 아니라 몇 분밖에 걸리지 않습니다.

왜 엔트로피 스캐너는 타입 지정 언어에서 과도하게 작동하는가

Klarion 자체의 첫 단계를 포함하여 엔트로피 기반 탐지(Entropy-based detection)는 Java, Go, TypeScript 및 PHP 파일당 Python과 Ruby보다 3~4배 더 많은 경고를 발생시킵니다: trufflehog은 3.1배, detect-secrets는 4.0배 증가했습니다. 반면, 규칙에 의존하는 gitleaks와 ripsecrets는 변화가 없었습니다.

이유: Java, Go, TypeScript 및 PHP에는 SseCustomerKeySHA256AttrName처럼 엔트로피가 높아 보이는 긴 식별자(identifier)들이 가득합니다. 엔트로피만으로는 이러한 식별자가 자격 증명(credential)인지 아닌지를 구별할 수 없습니다. 주변 코드를 읽으면 구별할 수 있으며, 이것이 LLM 단계에서 수행하는 작업입니다. 그 후 Klarion의 속도는 타입 지정된 리포지토리에서는 1k 파일당 0.18, 컨트롤 그룹에서는 0.20으로, 언어 효과는 사라집니다.

실제 비밀을 놓치지는 않을까요?

실제 유출(leak)이 누락되면 경고가 적다는 것은 쓸모없기 때문에, 저는 또한 삼성의 CredData를 사용했습니다. 여기에는 337개의 실제 리포지토리에서 라벨링된 라인들이 포함되어 있습니다.

테스트 폴더 외의 코드에 대한 결과:

	재현율 (Recall)	정밀도 (Precision)
Klarion + 모델	0.35	0.89
...
그것은 비슷한 정밀도로 gitleaks가 찾는 실제 비밀보다 약 1.7배 더 많습니다.

작동 방식

탐지(Detect): 키워드 게이트, 81개 정규 표현식 규칙 (regex rules), 정규화된 Rényi 엔트로피를 사용합니다.
판단(Judge): LLM이 주변 코드를 가진 각 후보(candidate)를 읽고 비밀/오탐지(false positive)/불확실함 중 하나로, 그리고 그 이유와 함께 반환합니다.

Anthropic, OpenAI 호환 모델, 로컬 Ollama 모델(어떤 것도 기기를 벗어나지 않음), 또는 Claude Code 로그인이 필요합니다.

실행 위치

Claude Code: 파일이 존재하기 전에 쓰기 작업을 차단하는 플러그인 후크 (파일 편집 및 Bash)
Cursor, Cline 또는 모든 MCP 에이전트: 그들의 MCP 서버를 통해
CI: PR이 추가한 내용만 스캔하는 GitHub Action; GitLab CI도 작동합니다
Git hooks: klarion protect 또는 pre-commit 프레임워크
로컬에서: klarion scan .

사용해보고, 어디가 잘못되었는지 알려주세요

무료 오픈 소스 (MIT): https://github.com/0x1Adi/Klarion

전체 방법론, 고정 커밋(pinned commits) 및 모든 발견 사항은 benchmark/REPORT.md에 있습니다.

LLM에 질의하는 비밀 스캐너 Klarion 제작 및 성능 테스트 결과

요약

핵심 포인트