03 · 지원 표기는 어떻게 정해지나
GitHub이 발급하는 토큰은 여섯 종류입니다. 그중 몇 개를 잡을까요?
이 구조는 그 질문에 정직하게 답하려고 만든 것입니다.
문제
탐지기 이름으로는 셀 수 없습니다
github-token 탐지기가 잡는 형태는 ghp_ | gho_ | ghu_ | ghs_ | ghr_ 다섯 가지입니다. GitHub이 발급하는 토큰은 여섯 가지입니다. 여섯 번째는 오랫동안 아무도 처리하지 않았고, 규칙 목록만 봐서는 그 사실을 알 수 없었습니다.
지원 여부는 “우리가 만든 탐지기” 단위로 세지 않습니다. “제공자가 실제로 발급하는 자격 증명” 단위로 셉니다.
그래서 이 목록은 파일 하나에 따로 적어 둡니다. 코드가 실제로 무엇을 잡는지와는 상관없습니다.
세 가지 입력
파일 세 개가 각기 다른 질문에 답합니다
일부러 나눠 두었습니다. 파일마다 따로 틀릴 수 있고, 작성하는 절차도 서로 다릅니다.
- 작성
- 생성기가 코어의 탐지기 레지스트리에서 만들어 냅니다.
- 고정 기준
- 측정에 쓴 빌드의 커밋 하나.
- 내용
- 탐지기 id와 제목을 나열한 목록. 품질 정보는 없습니다.
- 작성
- 사람이 직접 씁니다. 항목마다 출처 링크나 근거 메모가 붙습니다.
- 고정 기준
- 없음. 우리 코드가 아니라 제공자에 관한 파일입니다.
- 내용
- 탐지 여부와 상관없이 모든 자격 증명 계열.
- 작성
- 벤치마크 코퍼스를 돌려서 측정합니다.
- 고정 기준
- 코퍼스 해시 매니페스트와 측정한 버전.
- 내용
- 탐지기별 판정: 상태, 증거 등급, 그 이유.
결합
측정은 탐지기 단위로, 지원 표기는 계열 단위로
docs/support-matrix.md와 README 표둘 다 생성된 파일입니다. 어느 쪽이든 JSON과 달라지면 npm run ci가 실패합니다.방향은 한쪽뿐입니다. 매트릭스는 taxonomy를 읽지만 taxonomy는 매트릭스를 읽지 않습니다. 코드 리뷰 규칙에도 이렇게 적혀 있습니다. 비슷한 계열 이름을 근거로 변형의 지원 여부를 짐작해서는 안 됩니다. 지원하는 토큰과 접두사가 같다는 것만으로는 근거가 되지 않습니다.
핵심 장치
탐지기가 없는 계열도 표에 한 행으로 남습니다
taxonomy에서 아직 아무도 탐지기를 만들지 않은 자격 증명은 목록이 비어 있습니다: "detectors": []. 이 빈 목록이 공개 표에 unsupported 행을 만들어 냅니다. 그대로 할 일 목록도 됩니다. GitHub의 여섯 번째 토큰도 여기서 출발했습니다.
흔한 방식
규칙 목록만 공개합니다. 규칙이 없는 자격 증명은 아예 언급되지 않습니다. “확인해 봤는데 못 잡는다”와 “생각해 본 적 없다”를 구별할 방법이 없습니다.
이 프로젝트
잡는 것과 못 잡는 것을 같은 표에 싣고, 못 잡는 이유도 함께 적습니다. 현재 탐지기가 없는 계열은 25개이며, 모두 공개되어 있습니다.
테스트로도 강제합니다. 탐지기가 없는 계열에는 반드시 출처 링크나 근거 메모가 있어야 합니다. 이유 없이 unsupported로 표기하면 빌드가 실패하고, 명세는 이를 제공자에 관한 사실이 아니라 taxonomy의 버그로 봅니다.
// 실제 unsupported 행
"provider": "atlassian",
"status": "unsupported",
"detectors": [],
"reason": "the pinned third-party detector targets the distinct ATCT
access-token family, not the ATAT-prefixed API-token shape."닮았다고 다 계열은 아닙니다
일부러 제외한 것들
키처럼 생긴 것을 전부 계열로 올리면 unsupported 목록이 애초에 시크릿이 아닌 것들로 채워집니다. 그래서 몇 가지는 이름을 지정해 제외하고 이유를 기록해 둡니다.
- AWS AIDA…
- Twilio Account SID
- Twilio API Key SID
- Stripe pk_…
- Supabase sb_publishable_…
시크릿이 아닌 식별자
AWS AIDA 값은 IAM 사용자를 가리키는 이름입니다. Twilio SID는 계정 식별자로, 바로 옆 토큰을 탐지할지 판단하는 데 쓰이지만 SID 자체가 노출되는 것은 유출이 아닙니다.
공개용으로 문서화된 키
Stripe와 Supabase의 publishable key는 브라우저 코드에 넣어 배포하도록 만든 키입니다. 두 벤더 모두 문서에 그렇게 적어 두었습니다.
덕분에 unsupported는 항상 “이 프로젝트가 잡지 못하는 실제 자격 증명”이라는 뜻입니다. “우리 패턴과 비슷한 문자열”이라는 뜻으로 쓰이지 않습니다.
행에 담기는 내용
provisional에는 계산 근거가 붙습니다
계열이 기준에 못 미치면 어느 기준을 얼마나 못 채웠는지 숫자로 행에 적힙니다.
// 실제 provisional 행
"provider": "anthropic",
"status": "provisional", "evidenceTier": "T1",
"evidenceBasis": "provider-documented",
"reason":
documented.minimumPositiveCases: 5 < 6
documented.minimumPositiveAxes: 2 < 4
documented.minimumBenignCases: 5 < 8
documented.minimumControlAxes: 3 < 4이 계열의 토큰 형식은 제공자가 문서로 공개한 것이라 증거 등급으로는 최상위입니다. 그런데도 provisional이었던 이유는 이를 뒷받침하는 합성 예제가 양성 사례 1개, benign 대조군 3개만큼 모자랐기 때문입니다. 논쟁할 여지가 없습니다. 누군가 합성 예제 네 개를 더 쓰면 됩니다. 매트릭스 대부분은 이후 실제로 그렇게 채워졌습니다.
상태 분포
출시된 매트릭스 108행
- Stable 83 — 기준 통과, 믿고 써도 됨
- Unsupported 17 — 못 잡지만 이유와 함께 공개
- Provisional 7 — 쓸 만하지만 근거가 아직 부족
- Pending 1 — 탐지 결과도 미탐지 결과도 아직 믿기 어려움
stable 83개는 두 갈래로 나눠 셉니다. 57개는 제공자가 공개한 형식 명세를 근거로 하고, 26개는 벤더 문서가 없어 측정만으로 기준을 넘었습니다. 증거 등급은 이와 별도로 매깁니다(T1 57, T2 29, T3 4, T0 1). 측정으로 기준을 넘었다고 해서 T2 증거가 T1으로 올라가지는 않습니다.
숫자를 정확히 세기
두 숫자가 다르다면 버전 고정이 제대로 작동하는 것입니다
63개 제공자의 계열 수. benchmarks 저장소는 계속 갱신됩니다.
고정된 사본입니다. 누군가 측정을 다시 돌리고 새로 고정해야만 바뀝니다.
한 릴리스 전에는 두 숫자가 정확히 같았습니다. 차이가 난다고 오류는 아닙니다. 고정된 근거가 얼마나 오래되었는지 보여 줄 뿐입니다. 그래서 이 페이지는 두 숫자를 하나로 합치지 않고 나란히 보여 줍니다.
버전도 마찬가지입니다. 출시된 매트릭스는 0.1.0-beta.7에서 측정했고(benchmarks cfaeac4), 현재 릴리스는 0.1.0-beta.10입니다. 이 릴리스의 드리프트 검사는 바로 이 매트릭스로 실행되었습니다. 두 값 모두 제품 저장소 e748d47의 사이트 피드에서 가져왔으며 2026-09-28 기준입니다.