모든 탐지기는 같은 질문에 답합니다. 얼마나 확실하고, 왜 그렇게 판단했는가?

Prefix

ghp_

고정 문자열 하나

Alphabet

A–Z a–z 0–9

고정된 바이트 클래스 11개 중 하나

Run

exactly 36

정확히 n자, 또는 n자 이상

Validator

none

추가 검사(선택)

경계

바로 앞뒤 문자는 해당 문자 집합에 속하지 않아야 합니다. 그래야 더 긴 문자열의 일부를 온전한 키로 오인하지 않습니다.

대소문자

문서상 소문자 16진수인 벤더 형식에는 소문자 전용 클래스를 씁니다. 대소문자가 섞인 비슷한 문자열은 매칭하지 않고 걸러 냅니다.

검증기

Confluent 키 끝에는 실제 CRC-32 체크섬이 붙어 있고, 탐지기가 이를 다시 계산합니다. Cloudflare 키는 소문자 16진수인지만 확인합니다.

이 구조로는 표현할 수 없을 만큼 특이한 벤더 두 곳은 문법을 직접 작성했습니다:

sk-proj-⟨74자⟩T3BlbkFJ⟨74자⟩

가운데 표식은 base64("OpenAI")입니다. 발급되는 모든 키에 이 표식이 들어 있으므로, 탐지기는 sk-만 믿지 않고 이 표식을 기준으로 삼습니다.

JWT

점으로 구분된 세 덩어리이고, 앞의 두 덩어리는 eyJ로 시작해야 합니다. base64로 인코딩한 JSON의 특징입니다.

Bearer

Bearer 뒤에 16자 이상이 와야 합니다. 토큰만 잡고 헤더 단어는 그대로 둡니다.

연결 URL

postgres://user:pw@host에서 비밀번호만 골라냅니다. 호스트는 그대로 읽을 수 있습니다.

otpauth URI

스킴과 secret= 파라미터를 봅니다. 라벨과 발급자는 건드리지 않습니다.

의도적인 예외가 하나 있습니다. JWT 페이로드에 Supabase anon 키라고 적혀 있으면 제외합니다. 이 키는 원래 공개용이라 브라우저 번들에 그대로 들어가기 때문입니다. 토큰 내용을 읽는 곳은 여기뿐입니다.

이름

대소문자와 구두점을 먼저 정규화하므로 apiKey, API-KEY, api.key는 같은 이름으로 봅니다.

강한 이름

api_key, password, client_secret, access_token: 값의 무작위성 점수가 3.0 이상이어야 합니다.

애매한 이름

auth, credential, signing_key: 기준이 3.5로 올라갑니다. 단어가 약한 만큼 더 강한 근거가 필요합니다.

길이

최소 8자입니다. 무작위성은 16자를 넘을 때만 측정하고, 4 KB를 넘는 값은 전용 탐지기에 맡깁니다.

token 단독

token이라는 단어만 있는 경우는 일부러 무시합니다. 너무 흔해서 의미가 없습니다.

그다음 대부분을 걸러 냅니다

이 탐지기가 하는 일의 상당 부분은 시크릿이 아닌 것을 알아보는 일입니다. 아래 값은 모두 인식해서 건너뜁니다:

• changeme
• placeholder
• redacted
• <your-key-here>
• ${process.env.KEY}
• $[variables.x]
• `date +%s`
• op://vault/item/field
• :bind_param
• /etc/ssl/key.pem
• true
• 12345

모두 시크릿 자체가 아니라 시크릿을 가리키는 값입니다. 이런 값까지 잡아내면 사람들은 금세 스캐너를 꺼 버립니다.

1 · 심각도

경고만 하는 후보는 차단하는 후보를 밀어낼 수 없습니다. 등급보다도 우선합니다.

2 · 등급

위 등급 순서입니다. private key > provider > structural > contextual > entropy.

3 · 확신도

high, medium, low.

4 · 범위 폭

좁은 범위가 이깁니다. 주변 문단이 아니라 키만 가립니다.

5 · 순서

등록 순서, 그다음 결과가 나온 순서입니다. 내장 탐지기가 사용자 정의 탐지기보다 먼저 등록되므로 답은 항상 하나로 정해집니다.

입력 전체를 볼 때도 탐욕(greedy) 방식으로 승자를 고르지 않습니다. 같은 기준으로 가중치를 매겨 서로 겹치지 않는 탐지 결과 중 근거의 합이 가장 큰 조합을 고릅니다.

11개 문자 집합, 그 외에는 없습니다

• alnum
• alnum-dash
• alnum-dash-dot
• alnum-underscore
• upper-alnum
• lower-alnum
• digit
• hex
• hex-or-dash
• lower-hex
• base64-body

ruleset-revision: 1
detector: acme-internal-token
specificity: contextual
prefix: "ACME_"
alphabet: alnum-dash
run: at-least 20
validator: none

등급 상한

룰은 entropy 또는 contextual 등급만 지정할 수 있습니다. 상위 세 등급은 내장 탐지기 전용이라, 사용자 룰은 탐지 결과를 추가할 수는 있어도 기존 결과를 뒤집을 수는 없습니다.

검증기

정해진 목록에서 이름으로 고릅니다. 직접 작성한 함수, 표현식, 코드는 쓸 수 없습니다.

확신도

항상 medium입니다. 올릴 수 있는 필드가 없습니다.

크기

UTF-8 기준 64 KiB이며, 처음에 한 번 파싱합니다. 실패하면 막습니다. 한 줄만 잘못돼도 파일 전체를 거부합니다.

이 세 가지는 엔진에 처음 들어온 산술 검사입니다. 그전에는 코어 전체의 숫자 검사가 제공자 한 곳의 키에 쓰는 CRC-32 하나뿐이었습니다.