미국 사이버보안 기관이 GitHub에 비밀키를 노출했다는 사건의 전말

보안 지키라는 기관이 비밀키를 흘렸다고요?

조금 황당하게 들릴 수도 있는데, 미국의 사이버보안 담당 기관인 CISA(Cybersecurity and Infrastructure Security Agency)가 자기들의 공식 GitHub 리포지토리에 민감한 자격 증명(credential)을 그대로 올려뒀다는 사실이 외부 연구자에 의해 발견됐어요. 보안의 "수호자" 역할을 하는 기관이 가장 기초적인 실수인 "비밀키 커밋"을 했다는 점에서 업계가 충격을 받은 사건이에요.

비밀키 노출이 뭐냐면, 데이터베이스 비밀번호나 API 토큰, 클라우드 접근 키 같은 "이걸 알면 그 시스템에 들어갈 수 있는 열쇠"를 실수로 공개 저장소에 올려놓는 걸 말해요. 누구나 git clone 한 번이면 가져갈 수 있게 되는 거죠. 신입 개발자 실수담의 단골 메뉴인데, 그게 국가 사이버보안 기관에서 일어났다는 게 이번 사건의 핵심이에요.

어떤 키가, 어떻게 노출됐을까

보도된 내용에 따르면 노출된 자격 증명에는 클라우드 인프라 접근에 쓰이는 키, 내부 시스템과 연결되는 토큰 같은 항목이 포함돼 있었다고 해요. 외부 보안 연구자가 우연히 발견해서 CISA에 신고했고, CISA가 부랴부랴 해당 커밋을 삭제했지만 GitHub의 특성상 한번 푸시된 커밋은 완전히 사라지지 않거든요. 포크된 사본이나 캐시에 남아 있을 수 있고, 누군가 이미 받아갔을 가능성도 배제할 수 없어요.

이런 사건이 무서운 이유는 "공개된 시간"이 짧아도 자동 스캐너들이 24시간 GitHub를 훑고 있기 때문이에요. AWS 키 같은 건 푸시된 지 몇 분 안에 봇들이 발견해서 암호화폐 채굴 같은 데 악용하기도 하거든요. 그래서 노출된 키는 무조건 "이미 유출된 것"으로 간주하고 즉시 폐기(rotate)해야 합니다. CISA도 해당 키들을 모두 무효화하고 새 키로 교체했다고 밝혔어요.

왜 자꾸 이런 일이 벌어질까

사실 비밀키 누출은 대기업, 정부 기관, 빅테크 가릴 것 없이 끊임없이 발생하는 사고예요. Uber, Twitter, Microsoft, NASA 같은 곳도 다 한 번씩은 겪었어요. 이유는 단순해요. 개발자가 빠르게 일하다 보면 .env 파일이나 설정 JSON을 무심코 커밋해버리는 경우가 생기는데, 코드 리뷰에서도 놓치기 쉽거든요. 특히 대규모 PR이나 자동 생성된 파일에 키가 섞여 있으면 더 그래요.

그래서 업계 표준 대응은 "커밋 전 단계에서 막는다"는 방향으로 굳어졌어요. git-secrets, gitleaks, truffleHog 같은 도구가 대표적이에요. 이런 도구들은 커밋하려는 파일 안에 "AWS_SECRET_ACCESS_KEY"처럼 보이는 문자열이 있으면 커밋 자체를 차단해요. GitHub도 자체적으로 Push Protection이라는 기능을 제공해서, 알려진 패턴의 비밀키가 들어 있는 푸시를 거부할 수 있어요.

또 클라우드 쪽은 "키를 아예 안 쓰는 방향"으로 가고 있어요. AWS의 IAM Role, GCP의 Workload Identity, GitHub Actions의 OIDC 같은 메커니즘은 정적인 키 대신 "이 워크로드는 이 ID로 인증해"라는 단기 토큰을 발급해주거든요. 그러면 코드에 키를 박을 일 자체가 없어져요. 이번 사건도 만약 OIDC 기반 인증이 적용돼 있었다면 애초에 노출될 키가 없었을 거예요.

한국 개발자에게 주는 교훈

한국 회사도 이런 사고에서 자유롭지 않아요. 실제로 국내 스타트업이나 공공기관 리포지토리에서 키가 노출돼 클라우드 비용 폭탄을 맞거나, 개인정보가 유출되는 사건이 종종 발생해요. 그래서 개인 프로젝트라도 다음 두 가지는 꼭 챙기시면 좋겠어요.

첫째, 로컬에 pre-commit 훅을 걸어두세요. gitleaks를 brew로 설치하고 pre-commit 프레임워크에 등록하면, 키가 들어간 파일을 커밋하려 할 때 자동으로 막아줘요. 5분이면 설정 끝나는데, 한 번이라도 도움받으면 본전을 뽑고도 남아요.

둘째, CI 파이프라인에 비밀 스캔을 추가하세요. 회사 단위라면 GitHub의 Secret Scanning 기능을 켜두는 것만으로도 큰 안전망이 돼요. 무료 플랜에서도 공개 리포지토리는 지원하고, 유료 플랜에서는 비공개 리포지토리까지 확장됩니다.

그리고 가장 중요한 마음가짐이 있는데요, "이미 유출됐다고 가정하고 키를 자주 교체하라"는 거예요. 노출되지 않게 막는 것도 중요하지만, 노출됐을 때 피해를 최소화하는 게 더 현실적인 전략이거든요. 운영 환경의 키는 분기별로라도 교체하는 정책을 두는 게 좋아요.

마무리

사이버보안 기관도 이런 실수를 한다는 건, 누구든 할 수 있다는 뜻이기도 해요. 자동화된 안전망 없이 사람의 주의력에만 의존하면 결국 언젠가는 사고가 납니다. 여러분의 리포지토리에는 비밀 스캔 도구가 걸려 있나요? 아직이라면 오늘 하루 30분만 투자해서 설정해보시는 건 어떨까요?