GitHub, 시크릿 스캐닝 9개월 운영 사례 공개…2만건 경보 ‘제로’로

GitHub 공식 보안 블로그에 따르면 회사는 내부 시크릿 위생 개선 과정에서 1만5천개 이상 저장소에 걸쳐 2만건 이상의 시크릿 스캐닝 경보를 발견했고, 9개월 동안 이를 정리해 미해결 경보를 없앴다. GitHub는 이 과정을 통해 대규모 개발 조직이 노출 자격 증명을 어떻게 선별하고, 소유자를 찾고, 반복 가능한 보안 운영으로 연결할 수 있는지 공개했다.

시크릿은 API 키, 토큰, 인증서처럼 시스템 접근 권한을 줄 수 있는 민감한 값이다. 소스코드나 이슈, 문서, 지원 티켓에 잘못 노출되면 공격자가 시스템에 접근하는 통로가 될 수 있다. GitHub가 공개한 사례는 단순히 경보를 많이 줄였다는 발표가 아니라, 보안 탐지 이후의 운영 체계를 어떻게 설계해야 하는지 보여주는 내부 실험에 가깝다.

GitHub는 처음 확인한 2만건 이상의 경보가 모두 같은 위험을 뜻하지는 않았다고 설명했다. 약 1만8천건은 5개 저장소에 몰려 있었고, 테스트 픽스처나 비활성화된 자격 증명처럼 실제 위험이 낮은 항목이었다. 이 때문에 회사는 경보 수 자체보다 저장소, 시크릿 유형, 생성 시점, 활성 여부를 기준으로 우선순위를 나누는 방식이 중요하다고 강조했다.

운영 방식도 단계적으로 정리됐다. GitHub는 먼저 모든 엔터프라이즈와 조직에 시크릿 스캐닝과 푸시 보호를 적용해 새 경보가 계속 쌓이지 않도록 했다. 이후 저장소와 시크릿 유형별로 경보를 분류하고, 실제로 작동하는 자격 증명인지 확인한 뒤, 소유자에게 전달하는 절차를 만들었다. 단순히 보안팀이 수작업으로 경보를 닫는 방식이 아니라, 반복 가능한 백로그 관리 문제로 접근한 것이다.

특히 GitHub는 시크릿이 코드 저장소에만 존재하지 않는다는 점을 언급했다. 지원 티켓, 버그바운티 보고서, 사고 대응 기록, 위키 페이지에도 토큰이나 API 요청 예시가 남을 수 있다. 이에 따라 고객지원, 사고대응, 버그바운티 운영팀과 함께 공유 플레이북을 만들고, 새 이슈나 커밋을 만들면서 다시 시크릿을 노출하지 않도록 절차를 조정했다.

자격 증명 유효성 확인도 핵심 단계로 제시됐다. GitHub는 당시 시크릿 스캐닝에 기본 유효성 확인 기능이 없었기 때문에 최소한의 요청으로 해당 자격 증명이 아직 살아 있는지 판단하는 내부 방식을 만들었다고 밝혔다. 다만 읽기 전용 확인이라도 타인의 자격 증명을 다루는 문제가 생길 수 있어, 개인정보와 법무 검토가 함께 필요했다고 설명했다.

이번 사례가 개발 조직에 주는 메시지는 탐지 도구 도입만으로 보안 문제가 끝나지 않는다는 점이다. 경보가 누구의 책임인지, 어느 시스템을 잠그는 값인지, 회전이나 폐기 이후 어느 정도의 잔여 위험을 받아들일지 판단하는 운영 체계가 뒤따라야 한다. GitHub는 저장소 소유권과 자격 증명 소유권을 명확히 하고, 경보 처리를 엔지니어링 건강 지표와 연결했다고 밝혔다.

시크릿 유출은 오픈소스와 기업 내부 개발 모두에서 반복되는 공급망 보안 위험이다. AI 코딩 도구와 자동화가 개발 속도를 높이는 환경에서는 실수로 포함된 토큰이 더 넓게 복제될 수 있다. GitHub의 이번 공개는 시크릿 스캐닝을 단순 탐지 기능이 아니라 조직적 보안 운영과 개발 문화의 문제로 다뤄야 한다는 점을 보여준다.

출처: GitHub Blog https://github.blog/security/application-security/how-github-used-secret-scanning-to-reach-inbox-zero/