시크릿 스캔을 걸어뒀는데 AWS 키가 그냥 통과했다
회사에서 보안점검을 하자는 이야기가 내려왔다. 티빙 유출 건 때문이었다. 다니는 곳이 미디어 쪽이라 남의 일처럼 읽히지 않았고, 점검 항목이 돌기 시작하면서 사내 맥에는 MDM이 들어왔다. 소스가 회사 밖 클라우드로 나가는 경로를 통제하는 쪽이었다. 코드가 저장소에 들어가는 순간에도 검사를 거치게 만드는 작업도 같이 진행됐다. 나는 그 흐름을 보면서 개인 레포는 이미 대비가 돼 있다고 생각했다. 이 블로그를 굴리는 레포에는 커밋 직전에 도는 훅이 하나 있다. 시크릿이 스테이지되면 커밋을 막는다. 몇 달 전에 직접 짜서 붙였고, 그 뒤로 한 번도 의심해본 적이 없었다. 실제로 잘 돌긴 했다. scripts/credentials.json 을 실수로 git add 한 적이 있었는데 그때 정확히 막혔다. 막힌 경험이 있으니 신뢰가 생겼다. 그래서 이번엔 순서를 바꿔봤다. 훅이 있다는 걸 확인하는 게 아니라, 훅이 무엇을 잡는지 확인해봤다. 사내 보안 점검 스킬을 내 레포에 그대로 돌리고, 훅이 쓰는 정규식만 따로 떼어내 가짜 시크릿 여섯 개에 던졌다. 탐지 0건이었다. 훅은 자기가 아는 것만 알고 있었다 내 훅이 찾던 건 다섯 가지였다. GOOGLE_API_KEY 계열, OAuth JSON의 client_secret 과 refresh_token , 그리고 sk- 로 시작하는 OpenAI 키와 sk-ant- 로 시작하는 Anthropic 키. 이 목록을 짤 때의 나를 기억한다. 이 레포에서 실제로 쓰는 자격증명이 Google OAuth와 두 LLM API 키뿐이었으니까, 내가 가진 걸 기준으로 목록을 만든 것이다. 논리적으로는 틀린 데가 없다. 문제는 사고가 내가 가진 것 안에서만 나지 않는다는 데 있다. 던져본 여섯 개는 이런 것들이었다. AWS_ACCESS_KEY_ID = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEYxx GITHUB_TOKEN ...