NHI Kill Chain: Zombie Key — 파일은 삭제했다. 크리덴셜은 아직 살아있다.

Secret Scanning Alert: Resolved. 크리덴셜 상태: Active.

2025년 초. 직원 150명 규모의 핀테크 스타트업. 시리즈 B 클로즈 직후, 결제 인프라를 빠르게 확장하는 시기였습니다. GitHub Advanced Security를 도입한 지 6개월 정도 되었고, 보안팀은 secret scanning alert를 주간 단위로 관리하고 있었다.

어느 수요일 오후, secret scanning이 config/database.yml 파일에서 AWS RDS 마스터 비밀번호를 탐지했습니다. Alert이 발생했고, 담당 개발자 J에게 Slack 알림이 갔습니다. J는 경험 많은 백엔드 엔지니어였습니다. 30분 이내에 해당 파일에서 비밀번호를 제거하고 환경변수 참조(ENV['DATABASE_PASSWORD'])로 교체했습니다. 커밋, 푸시. GitHub에서 alert을 "Resolved -- removed from code"로 마감했습니다.

금요일 보안팀 주간 리포트. "Secret scanning alert: 0건. 이번 주 발생한 1건은 수요일에 해결 완료." 보안팀장은 만족스러운 표정으로 리포트를 닫았습니다. 대시보드는 깨끗했습니다. 모든 지표가 녹색이었다.

하지만 현실은 달랐다.

J가 한 것은 config/database.yml에서 비밀번호 문자열을 지운 것입니다. Git 커밋 히스토리에서 git log --all -p -- config/database.yml을 실행하면, 삭제 전 커밋에 비밀번호가 고스란히 남아 있었다. 3개월 전 생성된 CI/CD 빌드 로그에는 해당 비밀번호가 빌드 출력에 그대로 출력된 채로 아카이브되어 있었다. 인프라팀이 2주 전 만든 RDS 스냅샷 복원용 스크립트에도 같은 비밀번호가 하드코딩되어 있었다 -- 다른 리포지토리에서. 그리고 AWS IAM 콘솔에서 해당 RDS 마스터 비밀번호는 여전히 활성 상태였습니다. 아무도 비밀번호를 변경하지 않았습니다. 아무도 로테이션하지 않았습니다.

"코드에서 지웠다"는 것과 "크리덴셜을 폐기했다"는 것은 완전히 다른 행위다. J는 전자만 했습니다. 후자는 누구도 하지 않았습니다.

6개월이 흘렀다. 해당 리포지토리에 read 권한이 있던 외부 컨트리뷰터 M이 과거 커밋 히스토리를 탐색했습니다. 목적은 프로젝트 초기 아키텍처 결정을 참고하기 위해서였습니다. 하지만 git log --all -p 결과물에서 M은 RDS 마스터 비밀번호를 발견했습니다. 호기심이었을 수도 있고, 의도적이었을 수도 있습니다. 어느 쪽이든 결과는 같았습니다. M은 그 비밀번호로 프로덕션 RDS 인스턴스에 직접 접근했습니다. 결제 트랜잭션 데이터 217만 건이 포함된 데이터베이스였습니다.

침해가 발견된 것은 그로부터 3주 후였습니다. CloudWatch에서 RDS 커넥션 수 이상 급증 알림이 발생했고, 보안팀이 역추적을 시작했습니다. 원인 분석에 또 2주. 최종 결론: 6개월 전 "Resolved"로 마감된 secret scanning alert의 크리덴셜이 한 번도 폐기되지 않은 채 프로덕션에서 여전히 작동하고 있었다.

대시보드는 6개월 동안 깨끗했습니다. 그 깨끗함이 문제였습니다.

이 키는 왜 위험한가

Zombie Key는 파일이나 코드에서는 삭제되었지만 크리덴셜 자체는 폐기(revoke)되지 않아 여전히 유효한 NHI 크리덴셜입니다. 이름이 포착하는 핵심은 이것이다: 눈에 보이는 곳에서는 사라졌지만 실제로는 죽지 않았습니다. 코드에서 제거된 비밀번호, alert에서 "Resolved"로 마감된 API 키, PR 리뷰에서 걸려서 삭제된 토큰 -- 이것들이 모두 실제로 무효화되었는지 확인하는 사람은 거의 없습니다.

이 문제가 구조적으로 발생하는 이유는 "삭제"와 "폐기"가 완전히 다른 시스템에서 완전히 다른 사람이 수행하는 완전히 다른 행위이기 때문입니다.

삭제는 코드에서 문자열을 지우는 것입니다. IDE에서 해당 라인을 삭제하고, 새 커밋을 만들고, 푸시합니다. 이것은 개발자가 Git 안에서 수행하는 행위다. 반면 폐기는 해당 크리덴셜이 인증에 사용될 수 있는 능력 자체를 무효화하는 것입니다. AWS 콘솔에서 IAM 키를 비활성화하거나, 데이터베이스 비밀번호를 변경하거나, API 토큰을 revoke하는 것입니다. 이것은 인프라 관리자가 클라우드 콘솔이나 관리 API에서 수행하는 행위다.

두 행위 사이에는 자동화된 연결이 없습니다. GitHub에서 secret scanning alert를 "Resolved"로 마감해도 AWS에서 해당 키가 자동으로 비활성화되지 않습니다. 코드에서 비밀번호를 지워도 RDS 인스턴스의 마스터 비밀번호가 자동으로 변경되지 않습니다. "삭제"와 "폐기" 사이에는 사람이 의식적으로 건너야 하는 다리가 있습니다. 대부분의 조직에서 이 다리를 건너는 사람은 없습니다.

Git의 영속성이 이 문제를 더 심각하게 만듭니다. Git은 분산 버전 관리 시스템입니다. 모든 커밋, 모든 변경사항을 영구적으로 보존합니다. 파일에서 비밀번호를 삭제하고 새 커밋을 푸시하면, 최신 커밋에는 비밀번호가 없습니다. 하지만 이전 커밋에는 그대로 있습니다. git log --all -p면 충분합니다. git filter-repo나 BFG Repo-Cleaner를 사용해서 히스토리를 명시적으로 재작성하지 않는 한, 한 번이라도 커밋된 크리덴셜은 리포지토리의 전체 수명 동안 히스토리에 남아 있습니다. 리포지토리에 read 권한이 있는 모든 사람이, 언제든, 열람할 수 있습니다.

"Resolved" 라벨이 만드는 착각이 가장 위험합니다. Secret scanning alert가 "Resolved"로 표시되면, 보안팀은 해당 건이 처리되었다고 인식합니다. 대시보드에서 사라집니다. 주간 리포트에 포함되지 않습니다. 감사 대상에서 빠진다. 하지만 "Resolved"가 의미하는 것은 "코드의 현재 상태에서 해당 시크릿이 제거되었다"는 것뿐입니다. 크리덴셜이 폐기되었는지, 히스토리에서 제거되었는지, 다른 시스템에 동일한 크리덴셜이 잔존하는지는 확인하지 않습니다. "Resolved"는 해결이 아니다. 은폐다.

Kill Chain -- Zombie Key가 침해로 이어지는 5단계

Zombie Key 공격 체인은 다른 NHI 킬 체인과 구별되는 특징이 있다: 공격 시점에서 크리덴셜은 이미 "해결됨"으로 분류되어 있습니다. 보안팀의 레이더에서 완전히 사라진 상태에서 공격이 시작됩니다.

Zombie Key Kill Chain — 크리덴셜 노출에서 탐지 불가 침해까지 5단계

1단계: Credential Exposure (크리덴셜 최초 노출). 크리덴셜이 코드, 설정 파일, CI/CD 로그, 문서 등에 최초로 노출됩니다. 이 단계 자체는 모든 NHI 킬 체인의 공통 시작점입니다. 개발자가 config/database.yml에 RDS 비밀번호를 하드코딩한 순간, 타임라인이 시작됩니다. Secret scanning이 이를 탐지할 수도 있고, 탐지하지 못할 수도 있습니다. 탐지 여부와 관계없이, 크리덴셜이 코드베이스에 존재하는 순간부터 공격 표면이 형성됩니다.

2단계: Surface Remediation (표면적 조치). 누군가 크리덴셜을 발견하고 -- secret scanning alert든, PR 리뷰든, 동료의 지적이든 -- 코드에서 해당 문자열을 제거합니다. 환경변수로 교체하거나, 시크릿 매니저 참조로 바꾸거나, 해당 파일 자체를 삭제합니다. Alert은 "Resolved"로 마감됩니다. Jira 티켓이 있었다면 "Done"으로 전환됩니다. 보안팀의 관점에서 이 건은 종결되었다. 하지만 실제로 수행된 것은 코드의 현재 상태에서 문자열을 지운 것뿐입니다. 크리덴셜 자체는 어떤 조치도 받지 않았습니다.

3단계: Credential Persistence (크리덴셜 잔존). 이것이 Zombie Key의 핵심 단계다. 코드에서 삭제된 크리덴셜은 최소 네 곳에 여전히 존재합니다. 첫째, Git 커밋 히스토리. git filter-repo를 실행하지 않은 이상, 삭제 전 커밋에 원본이 그대로 남아 있습니다. 둘째, CI/CD 빌드 로그. 크리덴셜이 빌드 출력에 노출된 적이 있다면, 아카이브된 로그에 남아 있을 수 있습니다. 셋째, 다른 시스템. 동일한 크리덴셜이 다른 리포지토리, 스크립트, 문서, Slack 메시지 등에 복사되어 있을 수 있습니다. 넷째, 그리고 가장 중요하게, 인증 시스템 자체. AWS IAM, 데이터베이스, SaaS 플랫폼 -- 크리덴셜이 인증에 사용될 수 있는 시스템에서는 해당 크리덴셜이 여전히 유효한 상태로 등록되어 있습니다. 코드에서 문자열을 지웠을 뿐, 인증 시스템에는 아무런 변경이 가해지지 않았기 때문입니다.

4단계: Historical Discovery (히스토리 탐색을 통한 발견). 공격자 -- 외부 공격자든, 악의적 내부자든, 권한이 있는 외부 컨트리뷰터든 -- 가 "삭제된" 크리덴셜을 발견합니다. 방법은 다양합니다. Git 히스토리 탐색이 가장 직접적입니다. git log --all -p로 전체 히스토리를 검색하면, 삭제된 파일의 이전 내용이 모두 보입니다. TruffleHog, GitLeaks 같은 도구를 사용하면 히스토리 전체에서 크리덴셜 패턴을 자동으로 추출할 수 있습니다. CI/CD 빌드 로그에 접근 권한이 있다면, 아카이브된 로그를 검색할 수도 있습니다. 공격자는 현재 코드에서 크리덴셜을 찾는 것이 아니다. 과거에 존재했다가 "삭제된" 크리덴셜을 찾는 것입니다.

5단계: Zombie Exploitation (좀비 크리덴셜 악용). 발견된 크리덴셜은 아직 유효합니다. 공격자는 이 크리덴셜로 인증합니다. 이 시점에서 가장 위험한 것은 탐지의 부재다. 해당 크리덴셜은 이미 "Resolved"로 마감된 건입니다. 보안팀의 모니터링 대상이 아니다. 비정상 접근이 발생해도 이 크리덴셜과 연관된 알림은 없습니다. 침해 탐지가 극도로 지연됩니다. 공격자는 이미 해결된 것으로 분류된 크리덴셜로, 아무도 감시하지 않는 경로를 통해, 프로덕션 시스템에 접근합니다.

왜 기존 보안 체계로는 잡히지 않는가

Zombie Key가 기존 보안 도구의 사각지대에 놓이는 이유는 명확합니다. 대부분의 보안 도구가 "현재 상태"만 보기 때문입니다.

Secret scanning은 현재 코드만 검사합니다. GitHub Advanced Security, GitLab Secret Detection 등 주요 secret scanning 도구는 최신 커밋의 코드를 스캔합니다. 코드에서 크리덴셜이 제거되면, 스캔 결과에서 사라집니다. Alert이 "Resolved"로 전환됩니다. 이것은 설계 의도대로 동작하는 것입니다. Secret scanning의 목적은 코드에 크리덴셜이 존재하는지 탐지하는 것이지, 크리덴셜의 유효성을 검증하는 것이 아니다. 코드에서 제거되었지만 여전히 유효한 크리덴셜은 secret scanning의 관할 밖입니다.

Git history scanning은 존재하지만 거의 사용되지 않습니다. git log --all -p로 전체 히스토리를 검색하거나, TruffleHog의 --since-commit 옵션으로 과거 커밋을 스캔하는 것은 기술적으로 가능합니다. 하지만 대부분의 조직이 이를 정기적으로 수행하지 않습니다. 히스토리 스캔은 시간이 오래 걸리고, 결과물에 대량의 false positive가 포함되며, 발견된 크리덴셜의 현재 유효성을 자동으로 확인하는 메커니즘이 없습니다. 결과적으로 "가능하지만 실행되지 않는" 방어 계층이 됩니다.

CI/CD 로그 관리에 크리덴셜 잔존 정책이 없습니다. 대부분의 CI/CD 시스템은 빌드 로그를 30일, 90일, 또는 무기한 보관합니다. 로그에 크리덴셜이 포함되어 있는지 체크하는 조직은 극소수다. 마스킹 기능이 존재하지만 완벽하지 않다. 비밀번호가 빌드 스크립트의 출력에 노출된 경우, 로그 마스킹은 적용되지 않습니다. 3개월 전 빌드 로그에 비밀번호가 평문으로 저장되어 있는 것은 아무도 확인하지 않는 현실입니다.

"Resolved" 상태가 추적을 종료시킨다. 이것이 가장 근본적인 문제다. Alert이 "Resolved"로 마감되면, 해당 크리덴셜은 보안팀의 추적 대상에서 완전히 빠진다. 주간 리포트에 나타나지 않습니다. 감사 대상 목록에 포함되지 않습니다. 대시보드에서 사라집니다. 보안팀이 보는 세계에서 이 크리덴셜은 더 이상 존재하지 않습니다. 하지만 AWS IAM 콘솔에서, RDS 인스턴스에서, 해당 크리덴셜은 여전히 활성 상태다. "Resolved"는 보안팀의 인식을 변경하는 것이지, 현실을 변경하는 것이 아니다.

PR 리뷰는 과거 커밋을 다루지 않습니다. PR 리뷰에서 크리덴셜을 체크하는 것은 좋은 관행입니다. 하지만 PR 리뷰는 새로운 변경사항만 검토합니다. 이미 머지된 과거 커밋, 6개월 전의 커밋, 이전 개발자가 작성한 커밋은 리뷰 대상이 아니다. 과거에 노출되었다가 "삭제"된 크리덴셜은 PR 리뷰로는 발견할 수 없습니다.

실제 침해 사례와 업계 데이터

Zombie Key는 이론적 위험 분류가 아니다. 문서화된 침해 사례와 업계 통계가 이 위험의 규모를 보여줍니다.

GitGuardian의 2025 State of Secrets Sprawl 리포트는 핵심 통계를 제공합니다. GitHub 리포지토리에서 탐지된 시크릿의 90% 이상이 5일 후에도 여전히 유효한 상태였습니다. 이 통계가 말하는 것은 명확하다: 시크릿을 탐지하는 것과 시크릿을 무효화하는 것 사이에 거대한 격차가 존재합니다. 탐지는 빨라지고 있습니다. 무효화는 거의 이루어지지 않고 있습니다.

같은 리포트에 따르면, 2024년에 GitHub에서 새로 탐지된 시크릿은 1,290만 건 이상입니다. 이 숫자는 전년 대비 증가 추세에 있습니다. 시크릿이 코드에 노출되는 빈도는 줄어들지 않고 있으며, 노출된 시크릿이 제때 폐기되는 비율은 극히 낮다.

CSA의 2026 State of NHI Security 리포트는 NHI 크리덴셜 관리의 성숙도를 보여줍니다. 시크릿 로테이션에 대해 높은 자신감을 표시한 조직은 12%에 불과했습니다. 이 수치는 "삭제 후 폐기"라는 완전한 워크플로우를 갖춘 조직이 극소수임을 시사합니다. 크리덴셜을 코드에서 제거한 후 실제로 로테이션까지 완료하는 조직은 예외적 사례다.

Uber의 2022년 침해 사건은 Zombie Key 패턴의 변형입니다. 공격자는 Uber 내부 시스템의 PowerShell 스크립트와 네트워크 공유에서 크리덴셜을 발견했습니다. 이 크리덴셜들은 코드에서는 관리되고 있었을 수 있지만, 스크립트와 공유 폴더에 잔존한 복사본이 공격 경로가 되었다. 하나의 시스템에서 크리덴셜을 제거하는 것은 모든 시스템에서 제거하는 것과 같지 않다.

2023년 1월 CircleCI 침해 사건은 크리덴셜 잔존의 위험을 극적으로 보여주었다. 침해 후 CircleCI는 모든 고객에게 시크릿 로테이션을 권고했습니다. 하지만 CircleCI의 사고 리포트에 따르면, 실제로 시크릿을 로테이션한 고객의 비율은 제한적이었다. 크리덴셜을 "폐기"하는 것은 기술적으로 어려운 작업이 아니다. 하지만 조직적으로 실행되는 경우는 드물다.

Verizon의 2025 Data Breach Investigations Report에 따르면, 크리덴셜 기반 공격은 전체 분석된 침해의 약 20%에서 주요 요인으로 작용했습니다. 도난, 유출, 잔존 크리덴셜을 포함하는 이 카테고리는 매년 가장 일관되게 나타나는 침해 벡터 중 하나다. Zombie Key는 이 카테고리의 하위 유형이다 -- "삭제했다고 생각했지만 유효한" 크리덴셜.

OWASP의 NHI Top 10은 Secret Leakage를 주요 위험 항목으로 포함하며, 시크릿이 코드, 로그, 히스토리에 잔존하는 문제를 명시적으로 다룬다. "코드에서 시크릿을 제거하는 것으로는 충분하지 않으며, 시크릿 자체를 무효화하고, 히스토리에서 제거하고, 로테이션해야 한다"는 것이 OWASP의 가이드라인입니다.

탐지 및 대응 가이드

Zombie Key를 탐지하고 제거하는 것은 기존의 "탐지 후 삭제" 패러다임을 "탐지, 폐기, 검증" 패러다임으로 전환하는 것을 의미합니다. 삭제는 충분하지 않다. 폐기와 검증이 따라와야 합니다.

"삭제"가 아닌 "폐기" 워크플로우를 강제하세요. Secret scanning alert가 발생하면, 해당 alert의 해결 조건을 "코드에서 제거"가 아닌 "크리덴셜 폐기 확인"으로 재정의해야 합니다. 구체적으로: 코드에서 시크릿을 제거합니다. 해당 크리덴셜을 즉시 폐기(revoke)하거나 로테이션합니다. 폐기 완료를 확인하는 증거(스크린샷, API 응답, 로그)를 alert에 첨부합니다. 이 세 단계가 모두 완료되었을 때만 alert을 "Resolved"로 마감합니다. 첫 번째 단계만으로 마감하는 현재의 관행이 Zombie Key를 양산하는 직접적 원인입니다.

Git history 스캐닝을 정기적으로 수행하세요. TruffleHog의 --since-commit 옵션이나 GitLeaks의 --log-opts 플래그를 사용하여 전체 커밋 히스토리를 주기적으로 스캔해야 합니다. 발견된 크리덴셜에 대해 현재 유효성을 검증하는 프로세스가 필요합니다. AWS 키라면 sts:GetCallerIdentity를 호출하여 유효 여부를 확인합니다. 데이터베이스 비밀번호라면 연결 시도로 유효 여부를 확인합니다. 유효한 크리덴셜이 히스토리에서 발견되면, 즉시 폐기합니다. Secret scanning의 커버리지 범위에 대한 심층 가이드는 시크릿 탐지: 2026년 완벽 가이드를 참조하세요.

자동 로테이션을 도입하세요. 수동 로테이션은 실행되지 않습니다. AWS Secrets Manager, HashiCorp Vault, Azure Key Vault 등의 자동 로테이션 기능을 활용하여 크리덴셜이 일정 주기(최대 90일)마다 자동으로 교체되도록 설정해야 합니다. 자동 로테이션이 적용된 크리덴셜은 설령 히스토리에 잔존하더라도 유효 기간이 제한됩니다. Zombie Key의 위험을 시간적으로 봉쇄하는 가장 효과적인 방법입니다.

CI/CD 빌드 로그에서 크리덴셜을 제거하세요. 빌드 로그 보존 정책을 검토하고, 크리덴셜이 포함된 로그를 식별하여 제거해야 합니다. 향후 빌드에서는 시크릿 마스킹을 강제 적용하고, 마스킹이 적용되지 않는 경로(커스텀 스크립트 출력, 디버그 로그 등)를 점검해야 합니다.

git filter-repo를 사용하여 히스토리를 정리하세요. 민감한 크리덴셜이 커밋 히스토리에 있다면, git filter-repo를 사용하여 해당 내용을 히스토리에서 완전히 제거해야 합니다. 이 작업은 리포지토리의 커밋 해시를 변경하므로, 모든 클론/포크에 force push와 재클론이 필요합니다. 운영 부담이 크지만, 히스토리에 유효한 크리덴셜이 남아 있는 것보다는 낫다. Git Secret Scanning: 완벽 구현 가이드에서 구체적인 실행 방법을 다룬다.

Zombie Key가 발견되면, 이미 침해되었다고 가정하고 대응하세요. 크리덴셜을 즉시 폐기합니다. 해당 크리덴셜의 접근 로그를 alert 발생 시점까지 소급하여 감사합니다. 크리덴셜이 접근할 수 있었던 모든 서비스와 데이터를 파악합니다. 공격자가 추가 크리덴셜을 생성했거나, 다른 시스템으로 이동했을 가능성을 점검합니다. 동일한 크리덴셜이 다른 시스템에 잔존하는지 확인합니다.

Cremit Argus가 Zombie Key를 탐지하는 방법

Zombie Key가 지속되는 근본 원인 -- "삭제"와 "폐기" 사이의 격차, 히스토리 잔존, 유효성 미검증 -- 은 Cremit Argus가 해결하도록 설계된 문제다.

Argus는 크리덴셜의 유효성을 검증합니다. 코드에서 크리덴셜이 제거되었는지가 아니라, 크리덴셜이 여전히 인증에 사용될 수 있는지를 확인합니다. Secret scanning alert가 "Resolved"로 마감되었더라도, 해당 크리덴셜이 AWS, GCP, Azure, GitHub 등의 플랫폼에서 여전히 활성 상태라면, Argus는 이를 탐지하고 경고합니다. "Resolved"가 실제로 해결을 의미하는지 검증하는 계층입니다.

Argus는 삭제 후에도 활성 상태인 크리덴셜을 자동으로 식별합니다. 코드에서 제거된 시점과 크리덴셜의 실제 상태를 교차 검증합니다. 코드에서는 6개월 전에 제거되었지만 AWS IAM에서 여전히 활성인 키, alert에서는 "Resolved"이지만 데이터베이스에서 여전히 유효한 비밀번호 -- 이런 불일치를 자동으로 탐지합니다.

Argus는 Git 히스토리와 코드 외부의 잔존 크리덴셜을 포함한 전체 표면을 스캔합니다. GitHub 리포지토리의 현재 코드뿐만 아니라, 커밋 히스토리, CI/CD 설정, Slack 메시지, Confluence 문서 등 크리덴셜이 잔존할 수 있는 모든 표면을 커버합니다. 하나의 크리덴셜이 여러 시스템에 분산되어 있을 때, 하나만 제거하고 나머지를 놓치는 문제를 방지합니다.

Cremit Argus가 Zombie Key를 어떻게 탐지하고 제거하는지 확인하세요.

NHI Kill Chain 시리즈 안내

이 글은 NHI Kill Chain 시리즈의 다섯 번째 글입니다. 총 아홉 편에 걸쳐 조직 내부에 숨어 있는 가장 위험한 NHI 크리덴셜 유형을 분석합니다. 각 유형은 독립적인 동시에 서로 연결된 위험입니다.

코드에서 삭제했지만 폐기하지 않은 크리덴셜(Zombie Key)이 git history에 남아 있다면, 그것은 동시에 Public Key가 됩니다. 폐기하지 않은 채 시간이 지나면 Aged Key가 됩니다. 하나의 크리덴셜 관리 실패가 다른 위험 유형으로 연쇄되는 구조를 이해하는 것이 이 시리즈의 핵심입니다.

Ghost Key -- 퇴사한 개발자의 AWS 키는 아직 출근 중이다
Shadow Key -- 시크릿 매니저 바로 옆에 하드코딩되어 있다 (coming soon)
Aged Key -- 3년간 프로덕션을 지탱한 마스터 키 (coming soon)
Over-shared Key -- 10명이 하나의 Slack Bot 토큰을 공유하면 (coming soon)
Zombie Key -- 파일은 삭제했습니다. 크리덴셜은 아직 살아있습니다. (현재 글)
Drifted Key -- CI/CD 봇이 DB 비밀번호를 Jira에 첨부했을 때 (coming soon)
Public Key -- .env가 GitHub에 올라간 뒤 4분 동안 일어나는 일
Unattributed Key -- 누가 만들었는지 아무도 모르는 키 (coming soon)
Vault Bypass Key -- Vault가 있는데 우회해서 만든 키 (coming soon)

이전 글: [NHI Kill Chain: Over-shared Key -- 10명이 하나의 Slack Bot 토큰을 공유하면](/ko/blog/nhi-kill-chain-over-shared-key)

다음 글: NHI Kill Chain: Drifted Key -- CI/CD 봇이 DB 비밀번호를 Jira에 첨부했을 때

Cremit은 NHI 보안 회사입니다. [cremit.io에서 더 알아보세요.](https://cremit.io)