공개 GitHub 저장소에 push된 AWS 크리덴셜은 평균 4분 이내에 자동화된 공격자 봇이 탐지한다
2023년 한 해 동안 공개 GitHub에서 발견된 시크릿은 1,280만 건이며, 발견 후에도 90% 이상이 여전히 유효한 상태로 남아 있다
git rm으로 파일을 삭제해도 git 히스토리에는 크리덴셜이 그대로 남아 있어, 단순 삭제만으로는 노출이 해결되지 않는다
OWASP에 따르면 기업 환경에서 비인간 아이덴티티(NHI) 크리덴셜은 인간 계정 대비 약 100:1 비율로 존재하며, NHI 공격 방어에 높은 자신감을 가진 조직은 12%에 불과하다
크리덴셜 기반 침해는 평균 식별 및 억제에 258일이 소요되며, 전체 침해 유형 중 가장 높은 비용을 발생시킨다
노출된 키의 즉각적인 로테이션, 접근 로그 감사, 폭발 반경 평가가 대응의 핵심이다
사전 예방을 위해 pre-commit 훅, CI 파이프라인 스캐닝, 시크릿 매니저 도입이 필수적이다
금요일 오후 5시 47분, 그 push
2024년 가을, 서울의 한 스타트업. 시리즈 B 투자를 받은 지 3개월 된 이 회사는 20명 남짓한 개발팀이 SaaS 플랫폼을 빠르게 확장하고 있었습니다. 금요일 오후, 입사 2주 차 주니어 개발자 J는 로컬 개발 환경을 세팅하던 중이었습니다. 선임이 전달해준 .env 파일에는 AWS Access Key, RDS 데이터베이스 접속 정보, Stripe API 키가 포함되어 있었습니다.
J는 새로운 기능 브랜치를 만들고 코드를 작성했습니다. 커밋, 푸시. 평범한 금요일 오후의 루틴이었습니다. 다만 한 가지 문제가 있었습니다. 이 저장소는 퍼블릭이었습니다. 그리고 .gitignore에 .env가 포함되어 있지 않았습니다.
오후 5시 47분, git push가 완료되었습니다.
오후 5시 51분, GitHub Events API를 실시간으로 모니터링하던 자동화 봇이 해당 커밋에서 AWS Access Key 패턴을 감지했습니다. 4분. 커피 한 잔을 내리기도 전에 공격자의 시스템은 이미 이 크리덴셜을 수집하고 있었습니다.
오후 6시 12분, 공격자는 탈취한 AWS 키로 sts:GetCallerIdentity를 호출해 키의 유효성을 확인했습니다. 키는 살아 있었고, IAM 사용자에 연결된 권한은 예상보다 넓었습니다. EC2 인스턴스를 생성할 수 있었고, S3 버킷에 접근할 수 있었으며, RDS 스냅샷을 읽을 수 있었습니다.
오후 7시 30분, 미국 동부 리전에서 p3.2xlarge 인스턴스 8대가 가동되기 시작했습니다. GPU 최적화 인스턴스였습니다. 암호화폐 채굴에 최적화된 구성이었습니다. 동시에 공격자는 S3 버킷에 저장된 고객 데이터 백업본을 자신의 인프라로 복사하기 시작했습니다.
J는 이미 퇴근한 뒤였습니다. 누구도 이 사실을 알지 못했습니다.
월요일 아침, 출근한 DevOps 엔지니어가 AWS 비용 알림 이메일을 확인했을 때, 주말 동안 발생한 클라우드 비용은 평소의 40배를 넘어서 있었습니다. 하지만 진짜 문제는 비용이 아니었습니다. 고객 데이터가 이미 외부로 유출된 후였습니다.
.env 파일 하나. 4분의 노출. 그리고 한 조직의 데이터와 신뢰가 무너지기까지 걸린 시간은 하룻밤이었습니다.
Credential 노출 공격 타이람인
이 키는 왜 위험한가
먼저 용어 정리부터 하겠습니다. 이 시리즈에서 말하는 "Public Key"는 암호학의 공개키(public key cryptography)와는 전혀 다른 개념입니다. 공개 저장소, 공개 채널, 공개 문서처럼 누구나 접근할 수 있는 공간에 노출된 활성 크리덴셜을 말합니다. GitHub 퍼블릭 리포지토리에 올라간 .env 파일, Stack Overflow에 붙여넣기된 API 키, 공개 Confluence 페이지에 적혀 있는 데이터베이스 비밀번호, 모두 여기에 해당합니다.
사실 노출 경로가 생각보다 다양합니다. 가장 흔한 건 .gitignore 설정 누락입니다. 새 프로젝트 만들면서 .gitignore를 빠뜨리거나, .env 항목을 넣는 걸 잊는 거죠. 프라이빗 저장소를 퍼블릭으로 전환할 때도 자주 터집니다. 프라이빗에서는 잘 관리되던 크리덴셜이 퍼블릭으로 바뀌는 순간 전 세계에 공개됩니다. 모노레포를 분리할 때 히스토리를 통째로 가져가면 과거 커밋 속 시크릿까지 따라옵니다. 그리고 앞서 본 시나리오처럼, 시크릿 위생(secret hygiene)에 대한 교육 없이 신규 개발자가 투입되는 경우도 마찬가지입니다.
이 문제가 특히 까다로운 건 git의 특성 때문입니다. git은 모든 변경 이력을 보존하도록 설계된 시스템입니다. 실수를 알아채고 다음 커밋에서 .env를 삭제해도, 이전 커밋 히스토리에는 해당 파일이 고스란히 남아 있습니다. git rm은 현재 작업 디렉토리에서만 파일을 제거할 뿐 과거 기록은 건드리지 않습니다. git filter-repo 같은 히스토리 재작성 도구로 모든 커밋에서 크리덴셜을 제거해야만 완전한 삭제가 가능한데, 이 작업이 복잡하고 리스크가 높아서 대부분의 개발자가 시도조차 하지 않습니다.
"내 저장소를 누가 보겠어"라고 생각하기 쉽습니다. 솔직히 저도 처음엔 그렇게 생각했습니다. 하지만 현실은 정반대입니다. GitHub Events API는 모든 공개 이벤트를 실시간 스트림으로 제공합니다. 공격자들은 이 피드를 24시간 모니터링하면서 새로 push된 커밋에서 크리덴셜 패턴을 스캔합니다. "작은 저장소"나 "유명하지 않은 프로젝트"라는 구분은 없습니다. 자동화된 봇에게는 모든 퍼블릭 커밋이 동등한 사냥감입니다.
규모의 문제도 있습니다. OWASP NHI Top 10에 따르면, 현대 기업 환경에서 비인간 아이덴티티(Non-Human Identity, NHI) 크리덴셜은 인간 계정 대비 약 100:1 비율로 존재합니다. API 키, 서비스 계정 토큰, OAuth 시크릿, 데이터베이스 접속 정보, CI/CD 파이프라인 토큰… 하나의 서비스를 운영하는 데 필요한 비인간 크리덴셜의 수는 생각보다 훨씬 많습니다. 그런데 CSA(Cloud Security Alliance)의 2026년 NHI 보안 보고서에 따르면 NHI를 통한 공격 방어에 높은 자신감을 가진 조직은 12%에 불과하고, 크리덴셜 노출 후 로테이션에 24시간 이상 걸리는 조직이 24%에 달합니다. 이 중 단 하나라도 공개 공간에 노출되면, 그게 곧 조직 인프라로 들어오는 문이 됩니다.
Kill Chain, 공격자는 이 키로 무엇을 하는가
공격자 입장에서 공개 저장소에 노출된 크리덴셜은 이미 절반은 완성된 공격입니다. 발견에서 침해까지의 경로는 체계적이고 완전히 자동화되어 있습니다. 각 단계를 짚어보겠습니다.
노출된 Credential 공격 흐름
1단계: 발견(Discovery)
공격자들은 GitHub Events API의 실시간 피드를 구독해 매 초 수천 건의 push 이벤트를 수신합니다. 여기에 정규표현식 패턴 매칭, 엔트로피 분석 등 자동화된 탐지 기법을 적용하면 AWS Access Key(AKIA로 시작하는 20자 문자열), GCP 서비스 계정 JSON, Stripe API 키 같은 크리덴셜 패턴을 즉시 골라낼 수 있습니다. Palo Alto Networks Unit 42의 연구에 따르면 유효한 AWS 키가 push된 후 공격자 봇이 탐지하기까지 평균 4분이 걸립니다. 이건 수동 공격이 아닙니다. 산업화된 크리덴셜 수확(credential harvesting)입니다.
2단계: 검증(Validation)
발견된 크리덴셜이 실제로 살아 있는지 확인합니다. AWS 키라면 sts:GetCallerIdentity API를 호출합니다. 이 API는 어떤 권한도 없이 키 유효성과 연결 계정 정보를 반환합니다. GitHub 토큰이라면 /user 엔드포인트를, Stripe 키라면 /v1/charges를 찌릅니다. 검증 실패한 키는 버리고, 살아 있는 키만 다음 단계로 넘깁니다. 이 과정도 완전히 자동화되어 있고, 대부분의 서비스 제공자는 이런 API 호출을 비정상으로 잡아내지 못합니다.
3단계: 초기 접근(Initial Access)
검증된 크리덴셜은 그 종류에 따라 다른 문을 엽니다. AWS IAM 키는 클라우드 콘솔 전체로, 데이터베이스 접속 정보는 고객 데이터로, SaaS API 키는 해당 서비스 기능 전체로 연결됩니다. 공격자는 키에 부여된 권한 범위를 파악하기 위해 가능한 모든 API를 체계적으로 호출합니다. 이 단계에서 공격자가 관심 갖는 건 단순한 데이터 접근만이 아닙니다. "이 키로 더 많은 키를 찾을 수 있는가"입니다.
4단계: 측면 이동(Lateral Movement)
하나의 크리덴셜에서 시작해 추가 크리덴셜을 발굴하는 이른바 크리덴셜 체이닝(credential chaining)입니다. AWS에서 하나의 IAM 키로 들어가면 Systems Manager Parameter Store에서 다른 서비스 접속 정보를 찾을 수 있고, S3 버킷 설정 파일에서 데이터베이스 비밀번호를 발견할 수 있으며, Lambda 환경 변수에서 외부 API 키를 뽑아낼 수 있습니다. 크리덴셜 관리가 허술한 조직일수록 이 확산 속도는 빨라집니다.
5단계: 영향(Impact)
공격자의 최종 행동은 동기에 따라 갈립니다. 돈이 목적이라면 GPU 인스턴스를 대량으로 띄워 피해 조직 비용으로 암호화폐를 채굴합니다. 데이터가 목표라면 고객 정보, 지적 재산, 내부 문서를 유출합니다. 더 정교한 공격자는 백도어를 심습니다. 추가 IAM 사용자를 만들거나, Lambda 함수에 악성 코드를 넣거나, S3 버킷 정책을 수정해서 원래 키가 로테이션되어도 접근을 유지합니다. 최악의 경우 공급망 공격으로 이어집니다. CI/CD 파이프라인에 악성 코드를 심으면 피해는 해당 조직을 넘어 그 고객들에게까지 번집니다.
.env 파일 하나에서 시작된 이 체인, 단계를 거칠수록 복잡해지고 피해 범위는 기하급수적으로 커집니다.
왜 기존 보안 체계로는 잡히지 않는가
"우리는 이미 GitHub 시크릿 스캐닝 쓰고 있는데요?", 맞습니다. 하지만 실제 침해 사례를 보면 기존 장치들 사이에 치명적인 빈틈이 있습니다.
GitHub 시크릿 스캐닝의 한계
GitHub은 200개 이상의 서비스 제공자와 파트너십을 맺고 크리덴셜 패턴을 탐지합니다. 유용한 기능이지만, 파트너 프로그램에 포함되지 않은 서비스의 API 키, 조직 내부에서 자체 생성한 토큰, 커스텀 인증 시스템의 크리덴셜은 탐지 대상 자체에 없습니다. 또 패턴 기반으로 동작하다 보니 형식이 불규칙한 크리덴셜이나 환경 변수에 분산 저장된 인증 정보는 많이 놓칩니다. 데이터베이스 접속 문자열 안에 숨겨진 비밀번호, YAML의 중첩 구조 속 토큰처럼 맥락 의존적(context-dependent) 크리덴셜은 패턴 매칭만으로는 잡기 어렵습니다.
pre-commit 훅의 함정
이론적으로는 완벽한 방어선입니다. 시크릿 스캐닝 도구를 pre-commit 훅으로 설정하면 크리덴셜이 커밋에 포함되기 전에 막을 수 있으니까요. 문제는 훅의 설치와 유지가 개발자 개인에게 달려 있다는 점입니다. 새 머신 세팅할 때 훅을 빠뜨리거나, 급할 때 --no-verify로 우회하거나, 오탐(false positive)이 자꾸 나와서 그냥 무시하는 습관이 생기는 경우가 흔합니다. 조직 차원에서 강제하는 메커니즘이 없으면, 이건 방어선이 아니라 권장 사항일 뿐입니다.
git rm으로는 부족하다
실수를 발견하고 git rm으로 파일을 삭제한 뒤 새 커밋을 push하면 해결됐다고 생각하기 쉽습니다. 하지만 git clone --mirror로 전체 히스토리를 복제하면, 삭제 이전 커밋에서 크리덴셜을 추출하는 건 기본 git 명령어만으로 가능합니다. 더 중요한 건, 공격자 봇이 push 이벤트를 실시간으로 감시하기 때문에 크리덴셜이 포함된 커밋이 push되는 그 순간 이미 수집이 시작됩니다. 나중에 삭제 커밋을 올려도, 공격자는 이미 원본을 확보한 상태입니다.
핵심 문제: 실시간 모니터링의 부재
대부분의 조직이 공개 저장소 크리덴셜 노출을 실시간으로 모니터링하지 않습니다. Git Secret Scanning을 주기적으로 실행하는 곳도 있지만, 일 단위나 주 단위가 대부분입니다. 공격자의 평균 탐지 시간이 4분인데, 이 간격이면 방어의 의미가 없습니다. 기존 보안 도구가 주는 건 "언젠가 발견하는 능력"이지, "공격자보다 먼저 발견하는 능력"이 아닙니다.
공격자와 방어자, 실제 탐지의 갭
실제 침해 사례와 업계 데이터
이게 이론적인 위험이 아닙니다. 매년 반복되고, 매번 더 큰 규모로 터지는 현실의 문제입니다.
GitGuardian의 2024 State of Secrets Sprawl 보고서를 보면 규모가 실감납니다. 2023년 한 해 공개 GitHub 저장소에서 발견된 시크릿은 1,280만 건입니다. 전년 대비 28% 증가했습니다. 그런데 더 충격적인 건 발견된 시크릿의 90% 이상이 5일이 지나도 여전히 유효하다는 점입니다. 노출된 걸 알고도 로테이션하지 않거나, 아예 노출 사실조차 모르는 조직이 대다수라는 뜻입니다. 참고로 이 보고서에 따르면 GitHub에서 커밋하는 개발자의 약 12.8%가 한 번 이상 시크릿을 노출한 경험이 있습니다.
Palo Alto Networks Unit 42는 EleKtra-Leak 캠페인 분석을 통해 공격자의 속도를 직접 측정했습니다. 공개 저장소에 push된 유효한 AWS 키가 자동화 봇에 탐지되기까지 평균 4분이 걸렸습니다. Comparitech의 허니팟 실험에서는 가장 빠른 경우 1분 이내에 키가 악용되었습니다. GitHub Events API를 모니터링하는 봇 인프라가 이미 산업화 수준이라는 걸 보여주는 결과입니다.
2022년 Uber 침해 사건은 크리덴셜 하나가 어떻게 인프라 전체 장악으로 이어지는지 잘 보여줍니다. 공격자는 내부 시스템에서 크리덴셜을 탈취해 Uber의 AWS 계정, Google Workspace, Slack, HackerOne 버그 바운티 플랫폼까지 접근했습니다. 크리덴셜 체이닝의 교과서적인 사례입니다.
IBM의 2024 Cost of a Data Breach 보고서는 비용 측면을 짚어줍니다. 크리덴셜 도용 침해는 식별에서 억제까지 평균 258일이 걸립니다. 전체 침해 유형 중 가장 긴 수준입니다. 오래 걸릴수록 비용이 커지는 건 당연하고, 크리덴셜 기반 침해의 평균 비용은 전체 데이터 침해 평균을 상회합니다.
OWASP는 2024년 NHI Top 10을 발표하며 비인간 아이덴티티 보안을 독립적인 위협 카테고리로 공식화했습니다. 시크릿 노출(Secret Exposure)과 부적절한 오프보딩(Improper Offboarding)이 상위 항목으로 분류된 건, 이게 더 이상 개별 개발자의 실수가 아닌 조직 수준의 구조적 문제로 인식되고 있음을 보여줍니다.
결론은 간단합니다. 크리덴셜 노출은 빈번하고, 탐지가 느리고, 비용이 크고, 점점 악화되고 있습니다.
탐지 및 대응 가이드
무엇을, 어디서 스캔해야 하는가
효과적인 탐지는 "무엇을 스캔할 것인가"부터 다시 생각해야 합니다. 많은 조직이 활성 브랜치의 HEAD 커밋만 스캔하는데, 이걸로는 부족합니다. git 히스토리 전체를 봐야 합니다. 과거에 삭제된 파일에도 여전히 유효한 크리덴셜이 남아 있을 수 있거든요. 포크된 저장소도 놓치기 쉬운 영역입니다. 프라이빗 저장소를 포크할 때 히스토리도 함께 복제되고, 그 포크가 퍼블릭으로 설정되면 원본의 시크릿이 그대로 노출됩니다. CI/CD 빌드 로그도 마찬가지입니다. 디버그 모드로 실행된 파이프라인이 환경 변수를 로그에 뿌리면, 팀 전체가 볼 수 있는 크리덴셜이 됩니다.
어디를 살펴야 하는지도 중요합니다. .env 파일은 대표적이지만 유일한 위치가 아닙니다. terraform.tfstate에는 데이터베이스 비밀번호와 API 키가 평문으로 박혀 있는 경우가 많고, docker-compose.yml의 environment 섹션, GitHub Actions 워크플로우 파일, Jupyter 노트북 셀 출력까지 크리덴셜이 숨어 있을 위치는 생각보다 훨씬 다양합니다. Secret Detection 완벽 가이드에서 더 자세한 내용을 확인할 수 있습니다.
노출이 확인됐다면: 즉각 대응 순서
Credential 노출 시 사고 대응
시간이 없습니다. 해야 할 일을 순서대로 정리하면 이렇습니다.
즉시 키 로테이션, 저장소에서 파일 삭제하는 게 아닙니다. 크리덴셜 자체를 무효화하고 새 키를 발급해야 합니다. 파일을 삭제해도 공격자가 이미 키를 가져갔을 가능성이 높습니다. 키를 무효화하지 않으면 대응이 의미 없습니다.
접근 로그 감사, AWS CloudTrail, GCP Audit Log, Azure Activity Log 등을 확인해서 노출 시점 이후 비정상적인 API 호출이 있었는지 파악합니다.
폭발 반경(blast radius) 평가, 노출된 키로 접근 가능한 모든 서비스, 데이터, 인프라를 식별하고 침해 여부를 확인합니다.
담당자 즉시 통보, 영향받는 서비스 담당자에게 알리고 추가적인 크리덴셜 체이닝이 없었는지 확인합니다.
예방이 훨씬 싸다
사후 대응보다 사전 예방이 훨씬 비용이 적게 드는 건 당연합니다. pre-commit 훅에 시크릿 스캐닝을 설정해서 로컬 커밋 전에 차단하는 것, 이걸 개인 선택이 아닌 조직 표준으로 만드는 것이 중요합니다. 저장소 템플릿에 .gitignore를 포함하고, CI 파이프라인에 시크릿 스캐닝 단계를 추가해서 크리덴셜이 포함된 커밋은 빌드를 아예 실패시키는 것도 필수입니다. 가장 근본적인 방법은 시크릿 매니저를 도입해서 크리덴셜이 코드에 직접 들어가지 않는 아키텍처를 만드는 것입니다. 그리고 이 모든 것의 기반은 결국 개발자 온보딩 시 시크릿 위생 교육입니다. 앞선 시나리오에서 J가 첫날 .env 파일의 위험성을 배웠다면, 금요일 오후의 사고는 없었을 겁니다.
Cremit Argus는 이걸 어떻게 탐지하는가
지금까지 살펴본 기존 도구의 한계, 알려진 패턴에만 의존하는 탐지, 실시간 모니터링 부재, 맥락 의존적 크리덴셜의 사각지대, 이게 바로 Argus가 만들어진 이유입니다.
Argus는 공개 GitHub 저장소를 실시간으로 모니터링합니다. GitHub Events API 피드를 지속적으로 분석해서 크리덴셜이 노출되는 순간 바로 탐지하고 알림을 보냅니다. 핵심은 공격자 봇보다 빠르거나, 최소한 같은 속도로 노출을 잡아내는 것입니다. 공격자의 평균 탐지 시간이 4분이라면, 방어자도 그 시간 안에 먼저 발견해야 합니다. Argus는 이 속도를 목표로 설계되었습니다.
GitHub 내장 스캐닝이 파트너 프로그램에 등록된 서비스 패턴에 한정되는 것과 달리, Argus는 커스텀 패턴과 서드파티 토큰까지 탐지 범위를 확장합니다. 조직 내부에서 만든 API 키, 파트너사 인증 토큰, 비표준 형식의 데이터베이스 접속 정보 등 기존 스캐닝이 놓치는 영역을 커버합니다. 패턴 매칭만이 아니라 엔트로피 분석과 맥락 분석을 함께 사용해서, 크리덴셜이 코드 안에서 어떤 역할을 하는지까지 파악합니다.
모니터링 범위도 GitHub에 국한되지 않습니다. 사실 시크릿이 유통되는 경로는 코드 저장소만이 아닙니다. 개발자가 Slack DM으로 API 키를 전달하고, Confluence에 온보딩 가이드와 함께 접속 정보를 기록하고, Jira 티켓에 디버깅 크리덴셜을 첨부하는 일은 일상적으로 일어납니다. Argus는 Slack, Confluence, CI/CD 빌드 로그까지, 노출이 발생할 수 있는 모든 채널을 하나의 플랫폼에서 통합 관리합니다.
