시크릿 스캐닝 오탐: 왜 생기고 어떻게 없애는가

들어가며

시크릿 스캐닝의 한복판에는 잔인한 아이러니가 있습니다. 도구는 분명히 작동합니다. 봇은 공개된 GitHub 커밋을 몇 초 만에 훑고, AWS는 노출된 액세스 키가 푸시된 지 몇 분 안에 악용되는 경우가 많다고 보고합니다. 탐지는 빠르고, 저렴하고, 어디에나 있습니다. 그런데도 조직들은 몇 달씩 살아있는 크레덴셜을 계속 흘립니다.

이유가 스캐너가 시크릿을 놓쳤기 때문인 경우는 드뭅니다. 대개는 스캐너가 찾아 알림을 올렸고, 그 알림이 결국 아무것도 아닌 것으로 판명된 수천 개의 다른 알림 속에 묻혔기 때문입니다. 보안 운영 팀을 대상으로 한 업계 조사에서는 대다수 알림이 아예 조사조차 되지 않는다는 결과가 반복해서 나옵니다. 도구가 충분히 자주 늑대라고 외치면, 사람들은 그 소리를 향해 달려가기를 멈추고 진짜 늑대 한 마리는 그대로 걸어 들어옵니다.

이것이 오탐 문제입니다. 시크릿 스캐닝에서 오탐은 겉보기의 성가심이 아닙니다. 진짜 유출이 숨는 바로 그 통로입니다. GitGuardian은 한 해에만 공개 GitHub에서 1,200만 건이 넘는 새로운 노출 시크릿을 탐지했습니다. 그 양의 상당 부분이 쓰레기라면 어떤 팀도 사람 손으로는 감당할 수 없습니다. 그러므로 오탐을 줄이는 일은 깔끔함의 문제가 아닙니다. 진짜 탐지 결과가 눈에 띄게 만드는 문제입니다.

이 글에서는 오탐이 실제로 무엇인지 분해하고, 오탐 대부분을 만들어내는 두 가지 근본 원인을 추적하고, 상황을 조용히 악화시키는 과잉 교정을 살펴본 뒤, 시끄러운 스캐너를 믿을 만한 스캐너로 바꾸는 계층적 접근을 정리하겠습니다.

두 종류의 오탐

오탐을 줄이려면 먼저 그것이 무엇인지 정확히 해야 합니다. 이 한 단어가 아주 다른 두 가지 실패를 가리키고, 각각 아주 다른 해법을 요구하기 때문입니다.

첫 번째는 애초에 시크릿이 아닌 경우입니다. 스캐너가 크레덴셜처럼 보이지만 한 번도 크레덴셜이었던 적 없는 문자열을 잡은 것입니다. API 토큰을 닮은 UUID, git 커밋 SHA, base64로 인코딩된 이미지 조각, AWS 문서에서 복사한 AKIAIOSFODNN7EXAMPLE 같은 플레이스홀더가 그렇습니다. 여기서 탐지 결과는 정체부터 틀렸습니다. 애초에 민감한 것이 없었습니다.

두 번째는 더 미묘하고, 잘못 다루면 더 위험합니다. 그 문자열은 진짜 크레덴셜이지만 해를 끼칠 수 없는 경우입니다. 이미 폐기된 키, 만료된 토큰, 로컬 테스트 픽스처용으로 한 번 쓰고 버린 크레덴셜, 실제 접근 권한이 없는 샌드박스에 묶인 데모 키 같은 것들입니다. 패턴 매칭은 맞았습니다. 리스크 판단이 틀렸을 뿐입니다.

이 둘을 구분해야 하는 이유는 이들이 파이프라인의 서로 다른 지점에 있기 때문입니다. 첫 번째는 탐지(detection) 문제입니다. 매처가 너무 헐겁습니다. 두 번째는 검증(validation) 문제입니다. 진짜인 무언가를 찾았지만 그것이 여전히 작동하는지 확인하지 않은 것입니다. 진지한 오탐 감소 노력은 거의 언제나 하나의 이름표를 단 두 개의 작업이며, 이 둘을 하나의 다이얼로 취급해 낮춰버리는 팀은 대개 노이즈와 함께 진짜 시크릿까지 억눌러버립니다.

근본 원인 #1: 경계 없는 패턴 매칭

대부분의 시크릿 탐지는 정규식에서 출발합니다. Stripe 라이브 키는 sk_live_ 뒤에 고정된 길이의 영숫자가 붙고, AWS 액세스 키 ID는 AKIA로 시작해 16자가 이어집니다. 이런 패턴은 정밀하고 잘 고정되어 있어 오작동이 드뭅니다.

문제는 뚜렷한 접두사가 없는 크레덴셜의 긴 꼬리에서 시작됩니다. 이런 것들을 잡으려고 탐지 규칙은 키워드 매칭에 기댑니다. token, secret, apikey, 또는 벤더 이름 같은 단어 근처의 문자열을 찾는 것입니다. 키워드 규칙이야말로 경계가 무너지는 곳입니다.

키워드가 예컨대 audd인 서비스를 잡으려는 규칙을 생각해 봅시다. 대소문자 구분 없는 부분 문자열로 대충 작성하면, 이 키워드는 fraudDetection, audit_log, inaudible 안에서도 매칭됩니다. 하나하나가 전부 오탐이고, 규모 있는 코드베이스에는 이런 게 수천 개 있습니다. 해법은 거의 우스울 만큼 작습니다. 표현식에 단어 경계 하나면 됩니다. 그런데 그렇게 작성된 규칙에는 처음부터 그게 없었습니다. 이걸 수백 개의 키워드 규칙에 곱하면, 평범한 소스 코드의 상당 부분을 잡아내는 스캐너가 됩니다.

오픈소스 스캐너의 룰셋을 가져오는 순간 이 문제는 더 커집니다. TruffleHog, Kingfisher 같은 프로젝트는 오랜 세월 여러 사람이 기여한 방대한 규칙 모음을 함께 제공합니다. 훌륭한 출발점이자 생태계에 대한 진짜 선물이지만, 이 규칙들은 저마다 다른 정밀도 기준으로 작성되었고, 상당수 키워드 패턴에는 경계나 문맥 제약이 빠져 있습니다. 커뮤니티 규칙 천 개를 손대지 않고 가져오면, "이 정도면 충분히 가깝다"에 대한 천 명의 서로 다른 가정을 그대로 물려받는 셈입니다. 엔진이 고장 난 게 아닙니다. 규칙이 규모에서 만들어내는 오탐에 대해 한 번도 린트된 적이 없을 뿐입니다.

패턴 기반 탐지의 또 다른 축인 엔트로피 분석에도 고유한 오탐 서명이 있습니다. 무작위성이 높은 문자열은 시크릿을 가리키는 유용한 휴리스틱이지만, 동시에 UUID, 콘텐츠 해시, 압축된 JavaScript, base64 블롭에도 완벽하게 들어맞습니다. 순수한 엔트로피 임계값은 유출된 개인 키와 컴파일된 자산을 구분하지 못합니다. 너무 좁게 잡으면 진짜 시크릿을 놓치고, 너무 넓게 잡으면 lock 파일 속 모든 해시를 잡습니다.

근본 원인 #1의 교훈은, 패턴 품질이 공짜로 물려받는 이미 해결된 문제가 아니라는 것입니다. 경계를 인식하는 표현식, 문맥 요구 조건, 그리고 각 패턴이 실제 저장소에서 무엇을 잡는지에 대한 규칙별 검증. 이것이 신호와 소방 호스를 가릅니다.

근본 원인 #2: 탐지는 검증이 아니다

이제 더 중요한 절반이자, 대부분의 도구가 틀리는 부분입니다.

패턴 매칭이 완벽하다고 해 봅시다. 누가 봐도 Stripe 시크릿 키 형태인 문자열을 찾았습니다. 그래서 실제로 무엇을 알게 됐나요? Stripe 키처럼 보인다는 것뿐입니다. 그것이 살아있는지, 폐기됐는지, 만료됐는지, 테스트 키인지, 누군가 예시로 주석에 붙여넣은 조각인지는 아직 모릅니다. 패턴 매칭은 "이것이 크레덴셜을 닮았는가"에 답할 뿐, "이 크레덴셜이 지금 위험한가"라는 물음에는 아무 답도 주지 않습니다.

그 간극을 메우는 유일한 방법은 능동 검증(active validation) 입니다. 후보 크레덴셜을 발급 서비스에 보내 작동하는지 물어보는 것입니다. 바로 여기서 두 번째, 더 조용한 종류의 오탐이 태어납니다. 잘못된 검증은 검증하지 않은 것과 별반 다르지 않기 때문입니다.

흔한 실수는 HTTP 상태 코드를 답으로 취급하는 것입니다. 키를 벤더 API로 보내고, 200 OK를 받고, 유효하다고 표시합니다. 문제는 아주 많은 API가 유효하지 않거나 인식되지 않는 크레덴셜을 담은 요청에도 200을 돌려준다는 점입니다. 어떤 API는 본문에 에러 객체를 담아 200을 주고, 어떤 API는 인증과 무관하게 200으로 답하는 공개 엔드포인트를 둡니다. 상태 줄만 읽는 검증기는 죽은 키를 살아있다고 태연히 확정하고, 그만큼 자주 정반대의 오류도 냅니다. 진짜 검증은 응답 본문(response body) 을 들여다봐야 합니다. 전송 계층이 돌려준 상태 코드가 아니라, 그 특정 서비스에서 진짜 인증된 응답이 갖는 구체적인 형태를 확인해야 합니다.

이것은 시크릿 스캐닝의 신뢰도를 좌우하는 가장 큰 지렛대이자, 대부분의 팀이 끝내 당기지 않는 지렛대입니다. 수백 개 서비스의 응답 본문 검증기를 만들고 유지하는 일은 실제로 끝없이 이어지는 엔지니어링 작업이기 때문입니다. 하지만 그 대가는 질적으로 다릅니다. "진짜 문자열이지만 죽은" 오탐 부류 전체를 무너뜨립니다. 실서비스를 상대로 본문 수준 검사를 거친 탐지 결과는 더 이상 뭔가 위험해 보인다는 추측이 아닙니다. 확인된, 작동하는 크레덴셜입니다. 이 구분이 승부의 전부입니다.

과잉 교정의 함정

선의로 나선 팀이 오히려 상황을 악화시키는 지점이 여기입니다.

시끄러운 스캐너 앞에서 본능은 민감도를 낮추는 것입니다. 엔트로피 임계값을 올리고, 수다스러운 규칙을 끄고, 넓은 allowlist를 추가합니다. 이를 충분히 밀어붙이면 오탐을 미탐(false negative) 과 맞바꾼 것이고, 이건 명백히 더 나쁜 거래입니다. 오탐은 분류에 몇 분을 쓰게 합니다. 미탐은 침해를 부릅니다. 억눌러서 조용해진 대시보드는 안전한 것과 다릅니다. 그저 더 편안하게 눈먼 상태일 뿐입니다.

자동 대응에서 나타나는, 더 위험한 두 번째 과잉 교정이 있습니다. 팀이 파이프라인을 충분히 믿어 자동으로 행동하기 시작하면, 즉 플래그된 크레덴셜을 폐기하고, 삭제하고, 회전시키기 시작하면, 잘못된 판단의 비용이 완전히 달라집니다. 많은 자동화가 "확인할 수 없었다"를 조용히 "유효하지 않다"와 똑같이 취급합니다. 검증 규칙의 이름이 바뀌거나 삭제되고, 혹은 어떤 서비스에는 검증기가 아예 없어서 검사가 맨 실패값을 반환하는데, 파이프라인은 그 실패를 "죽은 크레덴셜"로 읽고 폐기합니다. 하지만 그 크레덴셜은 죽지 않았습니다. 검증 불가였을 뿐이고, 자동화는 방금 프로덕션에서 돌아가던 살아있는 키를 죽였습니다.

해법은 말하고 나면 당연해 보이지만 끊임없이 어겨지는 규율입니다. 검증에는 두 가지가 아니라 세 가지 결과가 있습니다. 유효, 무효, 그리고 판단 불가(indeterminate). 서비스가 나쁘다고 확인해 준 크레덴셜은 무효이고, 조치할 수 있습니다. 그저 확인할 수 없었던 크레덴셜은, 검증기가 없어서든 네트워크가 끊겨서든 규칙이 바뀌어서든, 판단 불가이며, 판단 불가를 무효로 취급해서는 절대 안 됩니다. 결론이 나지 않은 결과에 대해 폐기하거나 삭제하거나 비활성화하지 마십시오. 사람이 보도록 올리고, 재시도하되, 운영상의 공백이 보안 판정 행세를 하게 두지 마십시오. "모른다"를 "죽었다"와 혼동하는 것이, 오탐 감소 프로그램이 스스로 장애를 일으키는 방식입니다.

오탐을 줄이는 계층적 접근

이걸 고치는 단 하나의 설정은 없습니다. 믿을 만한 탐지는 필터를 쌓는 데서 나옵니다. 각 필터가 특정 오탐 부류를 겨냥하고, 탐지 결과가 사람에게 닿기 전에 모든 계층을 통과해야 하도록 만드는 것입니다.

경계와 문맥을 인식하는 패턴. 키워드 규칙은 단어 경계를 요구해야 하고, 가능하면 구조적 문맥, 즉 할당 형태나 근처의 알려진 키 포맷을 요구해야 합니다. 맨 부분 문자열이 아니라요. 이것이 fraudDetection이 audd에 걸리는 부류를 근원에서 제거합니다.

타입을 인식하는 보정된 엔트로피. 엔트로피는 여러 신호 중 하나로 쓰고, 본질적으로 무작위성이 높은 것이 정상인 문자열은 제외합니다. UUID, 커밋 해시, 알려진 자산 포맷, 의존성 lock 파일 같은 것들입니다.

경로와 파일에 대한 문맥 필터. test/fixtures, examples/, 벤더링된 의존성, 문서 스니펫 안의 키는 프로덕션 설정 안의 키와 다르게 다뤄야 합니다. 문맥이 무시할 핑계는 아니지만, 신호이긴 합니다.

알려진 무해 값에 대한 큐레이션된 allowlist. 문서 예시 키나 공유 샌드박스 토큰은 규칙을 조용히 헐겁게 만드는 대신, 명시적이고 감사 가능한 allowlist를 받을 자격이 있습니다.

능동적인, 본문 수준의 검증. 결정적인 계층입니다. 패턴 필터링을 통과한 모든 후보는 응답 본문 검증기로 발급 서비스를 상대로 확인받아, "크레덴셜처럼 보인다"와 "작동하는 크레덴셜이다"를 가릅니다. 이것이 패턴 필터링이 물리적으로 손댈 수 없는 "진짜지만 죽은" 오탐 부류를 제거합니다.

이진 플래그 대신 신뢰도 점수. 형식이 온전하고, 엔트로피가 높고, 프로덕션 경로에 있으며, 살아있다고 검증된 탐지 결과는, 테스트 파일에 있고 검증에 실패한 저엔트로피 문자열과 같은 알림이 아닙니다. 탐지 결과를 신뢰도로 정렬하면 팀은 중요한 곳에 주의를 쓸 수 있고, 진짜 탐지를 파묻지 않으면서 판단 불가 결과를 계속 눈에 띄게 둘 수 있습니다.

이 계층들은 중복이 아니라 서로를 보완합니다. 경계는 "시크릿이 아닌" 부류를 고치고, 검증은 "죽은 시크릿" 부류를 고치며, 세 가지 상태 규율은 대응이 새로운 사고를 만들지 않게 막습니다. 어느 계층 하나를 빼면 그에 해당하는 별개의 오탐이 되돌아옵니다.

Cremit은 이 문제를 어떻게 다루는가

Cremit의 탐지는 바로 이 이유로 검증 우선으로 설계되었습니다. 패턴 매칭은 무엇을 확인할 가치가 있는지를 정할 뿐, 무엇이 보고될지는 결코 정하지 않습니다. 모든 후보 크레덴셜은 상태 코드가 아니라 응답 본문 검사로 실서비스를 상대로 검증되며, 그래서 팀에 닿는 것은 시크릿을 닮은 문자열이 아니라 작동한다고 확인된 크레덴셜입니다. 확정적으로 검증할 수 없는 탐지 결과는 판단 불가로 올라오고 결코 조용히 조치되지 않으며, 그 덕분에 자동 대응이 실제로 죽었다고 확인하지 못한 키를 폐기하는 일이 없습니다. 그 결과는 신뢰할 수 있는 큐입니다. 알림이 곧 진짜로 노출된, 작동하는 크레덴셜을 뜻하고, 진짜 탐지가 그저 놀라워 보이기만 하는 것들 아래 더는 묻히지 않는 큐 말입니다.

마치며

오탐 감소는 결국 신뢰의 문제입니다. 충분히 자주 맞는 스캐너는 사람들이 움직이게 하고, 충분히 자주 틀리는 스캐너는 무시당하며, 무시당하는 스캐너는 탐지 엔진이 아무리 좋아도 아무런 보안도 제공하지 못합니다. 노이즈에서 신호로 가는 길은 더 나은 패턴 위생, 실서비스를 상대로 한 진짜 능동 검증, 그리고 "확인할 수 없었다"를 "죽여도 안전하다"와 절대 혼동하지 않는 규율을 지나갑니다. 이것들을 제대로 해내면, 큐는 진짜 유출이 숨는 자리가 아니라 진짜 유출이 잡히는 자리가 됩니다.