GitHub Secret Scanning 공부 정리 | 알림 2만 개 정리한 이야기
GitHub이 내부 저장소에 쌓인 시크릿 스캔 알림 2만 개를 9개월 만에 정리한 과정을 공부했다.
GitHub 블로그에 흥미로운 글이 올라왔다. 직접 Secret Scanning을 내부에서 운영한 경험을 정리한 글인데, 새 기능 발표가 아니라 ‘어떻게 2만 개 넘는 알림을 정리했는가’에 대한 이야기라 눈길이 갔다.
Secret Scanning은 저장소 안에 실수로 올라간 API 키, 토큰, 비밀번호 같은 민감 정보를 자동으로 감지해주는 기능이다. GitHub이 내부 15,000개 이상의 저장소에 이걸 켜놨더니 알림이 20,000개 넘게 쌓였다고 한다. 처음 이 숫자를 보면 당연히 압도되겠지만, 글에서 첫 번째로 짚은 게 바로 이 지점이었다 — 그중 90% 가까이는 이미 무효화된 것들이었다는 것.
1️⃣ 이게 뭐냐?
핵심 전략을 정리하면 세 단계 정도로 요약할 수 있었다.
첫 번째는 유효성 검증(Validity Checking)이다. 알림이 떴다고 해서 모두 위험한 건 아닌 것 같다. 이미 만료된 토큰인지, 지금도 살아 있는 토큰인지를 먼저 구분해야 한다. 예시로 든 방식이 단순했다 — GitHub 토큰에 API 요청을 날려서 200이 오면 활성, 401이면 무효. 최근에는 이 유효성 검증이 Secret Scanning 안에 내장 기능으로 들어왔다고 한다. 이전에는 직접 구현해야 했던 걸.
두 번째는 소유권 파악이다. 알림이 발생해도 누가 처리할지 모르면 그냥 묻히기 마련이다. GitHub은 Custom Properties라는 기능으로 저장소마다 담당 팀을 태그해놓고, 알림이 뜨면 해당 팀으로 자동 라우팅되는 구조를 만들었다. 메타데이터가 자동으로 붙으면서 소유자 파악에 쓰던 시간이 줄었다고 한다.
세 번째는 추적 시스템 연동이다. 발견 → 라우팅 → 종료까지 이어지는 흐름을 취약점 관리 플랫폼과 연결해서 자동화했다. 사람이 매번 판단하는 게 아니라 구조가 흐름을 이끄는 방식이었다.
2️⃣ 내가 든 생각
보안 이야기인데도 이게 흥미로웠던 건, 읽다 보니 결국 알림 설계 문제처럼 느껴졌기 때문이었다.
👉🏻 알림이 너무 많으면 다 무시하게 된다. 이건 보안 툴만의 문제가 아니라 모든 시스템 설계에서 반복되는 패턴인 것 같다. 중요한 게 뭔지 모르면 아무것도 처리 안 하게 되고, 결국 시스템 전체가 무의미해진다.
소유권 파악 문제도 인상적이었다. 알림이 생겼을 때 ‘이건 내 담당이야’라고 느끼게 만드는 게 얼마나 중요한지를, 이 글은 저장소 태깅과 자동 라우팅으로 구현했다는 식으로 설명하고 있었다. 책임을 명확히 만드는 걸 구조로 해결한다는 생각이 인상에 남았다.
💡 글에서 계속 나오는 질문이 있었다 — “알림이 많으면 어떻게 할 것인가”가 아니라 “왜 많아졌는가”를 먼저 볼 수 있는가?
리더십이 보는 대시보드가 팀을 움직인다는 부분도 좋았다. 지표가 보이면 사람이 움직인다는 건 경험적으로 느끼던 거지만, 이 글에서 그걸 꽤 실용적으로 풀어낸 점이 인상적이었다.
⭐️ 마지막으로, 보안 운영 이야기를 공부하며 든 생각
정리해보니 이 글은 보안 기능 설명이라기보다 운영 체계 설계에 더 가까운 이야기였다. 감지 자체보다 감지 이후 흐름 — 누가 받고, 뭘 먼저 보고, 어디서 종료되는가 — 를 어떻게 구조화하느냐가 핵심이었던 것 같다.
이런 류의 사례를 볼 때마다 자꾸 같은 질문이 남는다 — 좋은 툴보다 그 툴을 운영하는 방법이 더 어렵다는 걸, 왜 나중에야 깨닫게 되는 걸까.