스캐너가 자기 채점에 끼어들 수는 없습니다

기준 양성 사례

쉬운 것은 찾는가?

나머지 방법이 모두 여기서 출발합니다. 바이트 범위, 증거, 소스 해시를 스캐너를 돌리기 전에 기록합니다. 이것만 통과해서는 지원 표기를 받을 수 없습니다.

음성 쌍둥이

딱 한 곳만 바꾸면 잠잠해지는가?

ACME_KEY=… 잡아야 함
ACMX_KEY=… 잡으면 안 됨

바꾸는 것은 하나뿐입니다. 접두사, 길이, 문자 집합, 경계, 공개 접두사 중 하나를 고릅니다. 두 곳을 바꾸면 쌍둥이가 아닙니다. 두 사례를 한 묶음으로 채점하므로 무엇이든 잡는 탐지기는 점수를 얻지 못합니다.

무해한 닮은꼴

키처럼 보이기만 하는 값에는 반응하지 않는가?

AKIAIOSFODNN7EXAMPLE 벤더 공식 문서의 예시 값
<your-api-key-here>  자리표시자
pk_live_…            publishable, 공개용 키

일부러 진짜와 비슷하게 만들고, 사례마다 과탐지가 일어나는 특정 경로를 노립니다. 정책에 따라 정한 대조군은 출처가 있는 대조군과 분모를 따로 계산합니다. 판단에 기댄 사례가 사실에 기반한 결과를 흐리지 않도록 하기 위해서입니다.

경계 사례

규칙에서 한 글자 모자라거나 넘치면 어떻게 되는가?

문서에 나온 길이와 구분자마다 경계 안쪽과 바깥쪽 사례를 두거나, 그 쌍이 의미 없는 이유를 적어야 합니다. 범위가 하나씩 어긋나는 오류와 의도치 않은 부분 문자열 매치를 잡아냅니다. 파일 끝, 마지막 줄바꿈 없음, CRLF, 다음 토큰과 붙어 있는 경우까지 확인합니다.

문자 변형

본문까지 검사하는가, 접두사와 길이만 보는가?

ACME_a9f3k2… 허용된 문자, 잡아야 함
ACME_a9f!k2… 허용되지 않는 문자, 잡으면 안 됨

한 글자만 바꾸고 나머지는 그대로 둡니다. “접두사가 맞고 길이가 대략 맞으면 통과”로 대충 만든 탐지기는 이 시험에서만 드러납니다.

형식 바꾸기

같은 키를 다른 형식에 넣어도 결과가 같은가?

값만 · .env · JSON · YAML · TOML · 소스 코드 · Markdown · URI · 따옴표 · CRLF. 자격 증명 바이트는 그대로 두고 주변만 바꿉니다. 기대값은 지원하는 모든 형식에서 똑같이 나와야 합니다. 형식별로 따로 보고하므로 큰 계열의 좋은 성적이 약한 형식을 가리지 못합니다.

자동 생성 변형

사람이 일일이 쓰지 않을 수천 가지 변형은 어떤가?

명세가 퍼징과는 다르다고 분명히 밝힙니다. 변형은 스캔보다 먼저 만들고, 하나하나 preserve · invalidate · review-required 중 무엇인지 미리 붙여 두며, 개수와 비용에 상한을 둡니다. operator v3, seed 41, 소스 해시만 있으면 새로 체크아웃한 저장소에서 바이트 하나 다르지 않게 재현됩니다.

경쟁 도구와의 차이

같은 바이트를 두고 우리와 Gitleaks, TruffleHog의 판단은 어디서 갈리는가?

경쟁 도구의 결과는 참고 자료일 뿐 정답의 근거가 아닙니다. 어댑터마다 미리 작성한 기대값과 따로 비교해 채점합니다. 결과가 엇갈리면 사람이 확인할 검토 항목이 생길 뿐, 기대값을 고치지는 않습니다.

홀드아웃 평가

한 번도 맞춰 보지 않은 사례에서는 어떤가?

아무도 미리 보지 못한 시험입니다. 평소 개발용 명령으로는 홀드아웃 코퍼스를 읽을 수도 없고, 사례를 공개하기 전에 후보를 고정하며, 공개 후 후보에 손을 대면 그 실행은 무효입니다. 최근 추가된 규칙이 남은 허점도 막았습니다. 홀드아웃 결과를 보고 채점기의 임계값이나 가중치를 정할 수 없고, 홀드아웃 결과를 보고 다시 조정하면 그 에포크는 오염된 것으로 봅니다.

회귀 고정

다음 달에 모르는 사이 망가뜨릴 수 있는가?

끝난 실행은 바꿀 수 없는 비교 기준이 됩니다(baselines/0.1.0-beta.9.json: 합성 예제 해시, 버전, 모든 결과). 새로 Partial·Miss·오탐이 생기면 빌드가 실패합니다. 의도한 변경이라도 이유를 적고 승인을 받아야 기준선을 옮길 수 있고, 결과가 좋아져도 이전 기록은 지우지 않습니다.