활성 자격증명 집계: 발견 건수·고유 키·검증 상태

2026년 10월 4일 대폭 수정. 이전 글은 탐지 약 1만 4천 건, 활성 자격증명 525개, 4만 곳 이상에 발견된 웹훅, 담당자 지정 비율을 Cremit의 실측 결과처럼 소개했습니다. 하지만 재현 가능한 조사 대상, 기간, 중복 제거 기준과 원자료를 확인할 수 없어 수치를 모두 뺐습니다. 남길 만한 질문은 하나입니다. 각 숫자가 무엇을 세고 있나요?

먼저 집계 단위를 정하기

한 자격증명이 저장소 파일, 커밋 기록, 티켓에 남아 있을 수 있습니다. 발견 위치는 여러 곳이어도 자격증명은 하나일 수 있습니다. 탐지기가 작동하지 않는 문자열을 후보로 잡을 수도 있습니다. 발견 위치, 중복을 정리한 자격증명 기록, 마지막 유효성 확인 결과를 따로 기록하세요. 어느 것도 해당 키를 쓰는 계정이나 운영 작업의 수와 같지 않습니다.

합계를 보고하기 전에 대상 조직과 연결된 소스, 스캔 기간, 마지막 유효성 확인 시각, 발급처 검증을 지원하는 키 유형, 같은 값이 여러 곳에 있을 때 묶는 기준을 명시합니다. 새 소스를 연결하면 키가 새로 생기지 않아도 발견 건수가 늘 수 있습니다. 검증 상태가 바뀌어도 발견 위치는 그대로일 수 있습니다.

활성·미확인·비활성 근거를 나누기

Cremit은 자격증명 기록의 마지막 상태가 ACTIVE 또는 MANUAL_ACTIVE일 때 활성으로 셉니다. 후자는 사람이 확인한 상태이므로 발급처 자동 검증 결과로 표현하면 안 됩니다. PENDING과 UNVERIFIED는 결론이 나지 않은 상태이고, MANUAL_REVIEW_REQUIRED는 사람이 직접 살펴야 하는 유형입니다. 발급처가 거부한 값처럼 위험 집계에서 빼면 안 됩니다.

REVOKED와 MANUAL_REVOKED도 맥락이 필요합니다. Cremit은 과거에 활성으로 확인됐다가 현재 비활성으로 표시된 값과, 활성으로 확인된 적 없는 값을 구분합니다. 사람이 폐기했다고 표시한 경우에는 발급처나 담당자의 근거 기록을 남겨야 합니다. 지금 통하지 않거나 소스에서 지웠다는 사실만으로 과거에 노출·사용되지 않았다고 결론 낼 수는 없습니다.

GitHub의 유효성 확인 문서도 지원 패턴에 대해 active, inactive, unknown을 구분합니다. unknown에는 지원하지 않거나 확인에 실패한 경우가 포함됩니다. 따라서 작은 ‘활성’ 숫자가 전체 노출 규모를 뜻하지는 않습니다. 지원 범위는 저장소 설정과 요금제에 따라 다릅니다.

숫자 다음에 확인할 것

활성 자격증명은 발급 서비스, 확인 가능한 권한·접근 범위, 공개 및 내부 발견 위치, 마지막 검증 시각, 대응 담당자를 함께 적습니다. Cremit은 지원하는 AWS·GCP 키의 접근 분석을 보여줄 수 있지만 발급처 사용 로그를 대체하지는 않습니다. 노출 파일의 작성자는 조사 단서이지 현재 소유자라는 보장은 없습니다.

미확인 또는 수동 검토 건은 무엇이 빠졌는지 적습니다. 지원하지 않는 유형인지, 일시적인 발급처 오류인지, 검증에 필요한 맥락이 없는지, 사람의 확인이 남았는지 구분하세요. 발견 위치가 공개됐거나 값이 민감하다면 깔끔한 숫자가 나올 때까지 기다리지 말고 발급처와 서비스 담당자에게 차단을 조율해야 합니다. 폐기된 값은 이전 값의 거부 여부와 관련 접근 기간, 복사본을 확인합니다.

검증할 수 있는 보고 방식

발견 위치 수, 고유 자격증명 기록 수, 현재 활성(수동 활성은 별도 표기), 대기·검증 실패, 수동 검토, 과거 활성 후 폐기, 활성 확인 이력 없음으로 줄을 나눠 보고하세요. 기준 시각, 연결 소스 범위, 검증 근거와 미해결 건도 함께 적습니다. 비율을 쓸 때는 분자와 분모가 같은 기간·대상인지 확인해야 합니다.

Cremit은 연결된 지원 소스를 스캔하고 지원하는 유형의 유효성을 확인합니다. 인벤토리에는 스캔 발견 기록이나 자동 유효성 상태가 없는 볼트 전용·수동 등록 항목도 들어갈 수 있습니다. 모든 시스템을 검사하거나, 악용 여부나 실제 사용처 전체를 증명하거나, 키를 자동으로 교체·폐기하지는 않습니다. 대시보드는 발급처 중심 조사의 출발점으로 사용하세요.