NHI Kill Chain: Drifted Key — DB 비밀번호가 Jira, GitHub, Docker 이미지에 동시에 존재하는 이유

DB 비밀번호의 7개 플랫폼 여행

2025년 초. 직원 400명 규모의 이커머스 기업. 시리즈 B를 마치고 빠르게 성장 중입니다. 인프라팀, 백엔드팀, 프론트엔드팀, QA팀, SRE팀이 각각의 도구 스택을 운영합니다. 팀마다 사용하는 플랫폼이 다르고, 보안 도구도 다르고, 담당 조직도 다릅니다.

이 기업의 프로덕션 PostgreSQL 마스터 비밀번호는 AWS Secrets Manager에 저장되어 있습니다. 보안팀이 검토한 정책에 따라 Secrets Manager를 통해서만 접근하도록 설계되었다. 여기까지는 정상입니다. 교과서적인 시크릿 관리다.

문제는 그 이후에 시작되었다.

백엔드 개발자 P가 로컬 개발 환경을 세팅하면서 docker-compose.yml에 PostgreSQL 비밀번호를 하드코딩했습니다. Secrets Manager SDK를 매번 호출하는 게 번거로웠기 때문입니다. "로컬에서만 쓸 건데." P는 이 파일을 .gitignore에 추가하려 했지만, 다른 개발자가 "로컬 환경 세팅이 너무 복잡하다"는 이슈를 올렸고, P는 docker-compose 파일을 GitHub 리포에 커밋했습니다. 다른 개발자들이 쉽게 로컬 환경을 구축할 수 있도록.

Jenkins 파이프라인을 관리하는 DevOps 엔지니어 C는 데이터베이스 마이그레이션 자동화를 구축하면서 이 비밀번호를 환경변수로 주입했습니다. 빌드가 실패할 때 디버깅을 위해 환경변수를 로그에 출력하는 옵션을 켜 두었다. 빌드 로그에 비밀번호가 평문으로 기록되었다.

Docker 이미지를 빌드하는 과정에서 이 비밀번호가 ENV 지시문으로 주입되었다. 이미지가 Docker Hub에 push되면서 비밀번호가 이미지 레이어에 포함되었다. 레이어를 삭제해도 이전 레이어 히스토리에 남아 있습니다. Docker 이미지 보안 스캐너는 CVE 취약점은 찾지만, 환경변수에 박힌 평문 비밀번호는 대부분 탐지 대상이 아니다.

어느 날 DB 마이그레이션이 실패했습니다. 개발자 J가 디버깅을 위해 Jira 티켓에 connection string을 통째로 붙여넣었다. postgresql://admin:P@ssw0rd_Pr0d!@prod-db.internal:5432/ecommerce. 티켓에는 인프라팀, 백엔드팀, QA팀 총 15명이 접근 권한을 가지고 있었다.

신입 개발자 온보딩 가이드가 Confluence에 만들어졌습니다. "로컬 DB 세팅" 섹션에 비밀번호가 기록되었다. 작성자의 의도는 좋았습니다. 신입이 빠르게 개발을 시작할 수 있도록.

마지막으로, 신입 개발자가 Slack에서 시니어에게 "DB 접속이 안 됩니다"라고 물었다. 시니어는 DM으로 비밀번호를 전송했습니다. 10초만에 문제가 해결되었다.

하나의 프로덕션 DB 비밀번호가 이제 7개 플랫폼에 존재합니다. AWS Secrets Manager, GitHub, Jenkins, Docker Hub, Jira, Confluence, Slack. 각각의 복사는 합리적인 이유에서 이루어졌습니다. 악의적인 행위는 단 하나도 없습니다. 하지만 결과는 재앙입니다.

GitHub 보안 스캐너는 리포만 봅니다. "리포에서 시크릿 1건 탐지." 이 시크릿이 Jenkins 로그에도, Docker Hub 이미지에도, Jira 티켓에도, Confluence에도, Slack DM에도 있다는 건 모릅니다. Slack DLP 도구는 메시지만 봅니다. Docker 보안 스캐너는 이미지만 봅니다. Jira와 Confluence는 시크릿 스캐닝 자체가 없는 경우가 대부분입니다.

각 도구는 자기 영역에서 "문제 없음" 또는 "1건 발견"을 보고합니다. 하지만 같은 비밀번호가 7개 플랫폼에 걸쳐 존재한다는 전체 그림을 보는 도구는, 사람은, 프로세스는 없습니다.

이 키는 왜 위험한가

Drifted Key는 원래 저장된 플랫폼 유형의 경계를 넘어 이질적인 플랫폼으로 이동한 크리덴셜입니다. "드리프트(drift)"라는 이름은 의도 없이 떠다닌다는 뜻입니다. 누군가 계획적으로 유출하는 게 아니라, 일상적인 업무 흐름 속에서 자연스럽게 퍼져 나갑니다.

크리덴셜 드리프트가 구조적으로 발생하는 이유는 세 가지다.

첫째, 개발자는 문제를 빠르게 해결해야 합니다. "Secrets Manager API 호출을 세팅하는 데 30분 걸리는데, 비밀번호를 직접 넣으면 3초면 됩니다." 이 30분과 3초의 차이가 드리프트를 만듭니다. 각각의 복사는 합리적 판단입니다. 문제는 합리적 판단이 7번 반복되면 보안 통제가 완전히 무너진다는 것입니다.

둘째, 플랫폼 간에 시크릿 관리 정책이 통합되지 않습니다. GitHub에는 시크릿 스캐닝이 있습니다. Slack에는 DLP가 있습니다. Docker에는 이미지 스캐너가 있습니다. 하지만 "이 세 곳에 같은 비밀번호가 있다"는 사실을 아는 시스템은 없습니다. 각 플랫폼은 독립적으로 운영되고, 보안 정책도 독립적으로 적용됩니다. cross-platform 상관 분석은 존재하지 않습니다.

셋째, 조직 구조가 사일로를 만듭니다. GitHub는 개발팀이 관리합니다. Jenkins는 DevOps팀이 관리합니다. Jira와 Confluence는 PM팀 또는 IT팀이 관리합니다. Slack은 IT팀이 관리합니다. Docker Hub는 인프라팀이 관리합니다. 하나의 크리덴셜이 5개 팀의 관할을 가로지르면, 누가 책임자인가요? 답이 없습니다. 그래서 아무도 책임지지 않습니다.

Over-shared Key와의 차이를 명확히 해 두자. Over-shared Key는 같은 유형의 플랫폼 안에서 과도하게 공유된 크리덴셜입니다. 예를 들어, 하나의 Slack bot token을 10개 리포에서 공유하거나, 하나의 AWS 키를 5개 서비스에서 공유하는 경우다. 같은 유형(리포, 서비스) 내에서 복사본이 늘어나는 문제다. 단일 플랫폼의 접근 제어 도구로 탐지할 수 있습니다.

Drifted Key는 근본적으로 다릅니다. 크리덴셜이 서로 다른 유형의 플랫폼을 넘나든다. 코드 리포에서 CI/CD로, CI/CD에서 컨테이너 이미지로, 이미지에서 이슈 트래커로, 트래커에서 문서 플랫폼으로, 문서에서 메시징 앱으로. 각 이동은 플랫폼 유형의 경계를 넘는다. 그리고 경계를 넘을 때마다 가시성이 사라집니다.

Over-shared Key가 "하나의 방에 열쇠가 너무 많은" 문제라면, Drifted Key는 "열쇠가 건물 전체를 돌아다니면서 아무 방에나 놓여 있는" 문제다. 후자가 탐지하기 훨씬 어렵고, 공격 표면이 훨씬 넓다.

Kill Chain -- Drifted Key가 침해로 이어지는 과정

Drifted Key의 킬체인은 5단계로 진행됩니다. 핵심은 공격자가 7개 플랫폼 중 가장 약한 고리 하나만 뚫으면 된다는 점입니다.

1단계: Authorized Origin (정당한 원점). 크리덴셜이 정당한 위치에 저장됩니다. 이 시나리오에서는 프로덕션 PostgreSQL 마스터 비밀번호가 AWS Secrets Manager에 저장되어 있습니다. 접근 제어가 설정되어 있고, 감사 로그가 활성화되어 있으며, 로테이션 정책이 적용되어 있습니다. 보안팀은 이 상태를 "통제 하"라고 판단합니다. 정확한 판단이다 -- 이 시점까지는.

2단계: Cross-Platform Drift (플랫폼 간 확산). 개발 편의, 디버깅, 온보딩, 장애 대응 등의 이유로 크리덴셜이 원래 속한 플랫폼 유형을 벗어나 이질적인 플랫폼으로 복사됩니다. 각 복사에는 합리적인 이유가 있습니다. docker-compose에 하드코딩하는 건 "로컬 개발을 빠르게 시작하기 위해." Jenkins에 환경변수로 넣는 건 "마이그레이션 자동화를 위해." Jira에 붙여넣는 건 "디버깅 컨텍스트를 공유하기 위해." 각각은 타당합니다. 하지만 이 과정이 6번 반복되면 하나의 비밀번호가 7개 플랫폼에 존재하게 됩니다. 보안 정책이 설계한 경계를 완전히 벗어난 상태다.

3단계: Visibility Fragmentation (가시성 파편화). 각 플랫폼의 보안 도구는 자기 영역만 모니터링합니다. GitHub의 시크릿 스캐닝은 리포에서 발견된 시크릿을 보고합니다. Jenkins의 보안 설정은 빌드 환경변수를 점검합니다. Docker 스캐너는 이미지 취약점을 보고합니다. 하지만 이 세 도구가 같은 비밀번호를 각각 탐지했다는 사실을 연결하는 시스템은 없습니다. 더 심각한 건, Jira와 Confluence에는 시크릿 스캐닝 자체가 없는 조직이 대부분이라는 점입니다. Slack DLP가 있더라도 DM까지 스캔하는 경우는 드물다. 7개 플랫폼 중 적어도 3개는 완전한 사각지대다.

4단계: Weakest Platform Breach (가장 약한 플랫폼 침해). 공격자는 7개 플랫폼 중 보안이 가장 약한 곳을 공략합니다. Docker Hub에 push된 이미지가 퍼블릭이었다면, 누구나 이미지를 pull하고 레이어 히스토리에서 환경변수를 추출할 수 있습니다. Jira 티켓에 외부 파트너 접근 권한이 있었다면, 파트너 계정이 탈취되는 순간 비밀번호가 유출됩니다. Slack DM은 계정 피싱 하나로 노출됩니다. 7개 플랫폼의 보안 수준은 가장 약한 한 곳의 수준으로 결정됩니다. 이것이 드리프트의 핵심 위험입니다.

5단계: Cross-Platform Impact (교차 플랫폼 피해). 유출된 비밀번호로 공격자는 프로덕션 데이터베이스에 직접 접근합니다. 하지만 피해는 데이터베이스에 그치지 않습니다. 같은 비밀번호가 Jenkins 환경변수에도 있다는 걸 알면, CI/CD 파이프라인 조작 가능성을 탐색합니다. Docker 이미지에서 추출한 다른 환경변수에 추가 크리덴셜이 있을 수 있습니다. Jira 티켓에 기록된 connection string에서 내부 네트워크 구조를 파악합니다. 하나의 Drifted Key가 만드는 공격 표면은 단일 플랫폼 유출과는 차원이 다릅니다.

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

Drifted Key가 기존 보안 체계를 통과하는 이유는 단순합니다. 기존 보안 도구는 플랫폼 단위로 설계되었고, 드리프트는 플랫폼 경계를 넘는 현상이기 때문입니다.

플랫폼별 보안 도구의 사일로. GitHub Advanced Security는 강력한 시크릿 스캐닝을 제공합니다. 하지만 동일 시크릿이 Jira에도 있는지는 알 수 없습니다. Snyk Container는 Docker 이미지의 취약점을 탐지하지만, 이미지 레이어에 평문 비밀번호가 박혀 있는지는 기본 스캔 범위에 포함하지 않는 경우가 많다. Slack Enterprise DLP는 메시지 내 민감 정보를 탐지할 수 있지만, DM까지 커버하는 설정을 활성화한 조직은 소수다. 각 도구는 자기 영역에서는 우수합니다. 문제는 드리프트가 영역 "사이"에서 발생한다는 것입니다.

cross-platform 상관 분석의 부재. SIEM에 모든 플랫폼의 로그를 모으더라도, "GitHub에서 탐지된 시크릿 X가 Jira 티켓 Y에도 존재하고, Docker Hub 이미지 Z의 레이어에도 포함되어 있다"는 상관 분석은 대부분의 SIEM이 제공하지 않습니다. 이런 분석을 하려면 각 플랫폼에서 발견된 시크릿의 값을 비교해야 하는데, 대부분의 보안 도구는 시크릿 값 자체를 해시 처리하거나 마스킹하여 저장합니다. 비교 자체가 불가능한 구조다.

Docker 이미지 내 시크릿 문제의 특수성. Docker 이미지는 레이어 기반입니다. docker history로 모든 레이어의 명령어를 확인할 수 있습니다. ENV DB_PASSWORD=P@ssw0rd_Pr0d!로 비밀번호를 주입하면, 이후에 ENV DB_PASSWORD=로 덮어써도 이전 레이어에 기록이 남는다. 멀티스테이지 빌드를 사용하면 해결할 수 있지만, 레거시 Dockerfile을 그대로 사용하는 조직이 상당수다. Docker의 공식 문서에서도 빌드 시 시크릿 주입에는 --mount=type=secret을 사용하라고 권고하지만, 실무에서 이 권고를 따르는 비율은 높지 않다.

CI/CD 빌드 로그의 시크릿 노출. Jenkins, GitHub Actions, GitLab CI 모두 시크릿 마스킹 기능을 제공합니다. 하지만 마스킹은 명시적으로 "시크릿"으로 등록된 값에만 적용됩니다. 환경변수에 직접 넣은 값, 스크립트에서 echo로 출력한 값, 에러 메시지에 포함된 connection string은 마스킹 대상이 아니다. 빌드가 실패하면 개발자가 로그를 공유하면서 시크릿이 추가로 드리프트됩니다.

Jira와 Confluence의 보안 사각지대. Atlassian 플랫폼은 시크릿 스캐닝을 기본 제공하지 않습니다. Jira 티켓이나 Confluence 페이지에 비밀번호가 평문으로 기록되어 있어도 경고가 발생하지 않습니다. 접근 제어는 프로젝트 단위로 설정되지만, 대부분의 조직에서 Jira 프로젝트는 넓은 범위의 팀원에게 열려 있습니다. "디버깅 컨텍스트를 공유하기 위해" 붙여넣어진 비밀번호는 수십 명이 접근할 수 있는 티켓에 무기한 존재합니다.

실제 사례와 업계 데이터

크리덴셜 드리프트는 이론적 위험이 아니다. 반복적으로 발생하는 실제 침해의 원인입니다.

2023년 Docker Hub에 push된 퍼블릭 이미지를 대규모로 분석한 연구에서, 이미지의 약 8.5%에서 시크릿이 발견되었다. AWS 키, 데이터베이스 비밀번호, API 토큰이 이미지 레이어에 평문으로 포함되어 있었다. 이 시크릿들 중 상당수는 프라이빗 인프라에서 Docker Hub로 드리프트된 크리덴셜입니다. 원래는 내부 시스템에만 존재해야 할 비밀번호가 퍼블릭 이미지를 통해 전 세계에 노출된 것입니다.

GitGuardian의 2025 State of Secrets Sprawl 리포트는 GitHub에서 발견된 시크릿의 90% 이상이 탐지 5일 후에도 여전히 유효한 상태라고 보고했습니다. 이는 시크릿이 탐지되더라도 로테이션이 이루어지지 않는다는 뜻입니다. 시크릿이 다른 플랫폼에도 드리프트되어 있다면, 한 곳에서 로테이션하더라도 나머지 6곳에서는 이전 값이 그대로 남아 있을 가능성이 높다.

CircleCI의 2023년 보안 사고는 CI/CD 환경이 크리덴셜 드리프트의 허브가 될 수 있음을 보여주었다. 공격자가 CircleCI 엔지니어의 노트북에서 세션 토큰을 탈취한 후, CircleCI의 프로덕션 환경에 접근하여 고객사의 시크릿을 유출했습니다. CI/CD 시스템에 저장된 시크릿은 원래 플랫폼에서 드리프트되어 온 것들이 대부분입니다. CI/CD가 침해되면, 그곳에 드리프트되어 있던 모든 시크릿이 동시에 유출됩니다.

CSA의 2026 State of NHI Security 리포트에 따르면, 조직의 73%가 3개 이상의 클라우드 및 SaaS 플랫폼에 걸쳐 NHI 크리덴셜을 운영하고 있습니다. 그러나 이 크리덴셜들이 플랫폼 간에 어떻게 이동하고 복사되는지를 추적하는 프로세스를 갖춘 조직은 15% 미만입니다. 드리프트는 보편적이지만, 드리프트를 탐지하는 역량은 보편적이지 않다.

Verizon의 2025 DBIR은 크리덴셜 기반 공격이 전체 침해의 약 20%를 차지한다고 분석했습니다. 이 중 상당수는 탈취된 크리덴셜이 여러 시스템에 걸쳐 재사용되거나 드리프트된 경우다. 공격자가 하나의 크리덴셜을 획득하면, 그 크리덴셜이 다른 어디에 존재하는지를 탐색하는 것은 공격의 기본 과정입니다.

OWASP NHI Top 10은 Secret Exposure를 주요 위험으로 분류하면서, 시크릿이 코드, 로그, 설정 파일, 티켓 시스템 등 다양한 위치로 확산되는 것을 핵심 원인으로 지목합니다. 단일 플랫폼에서의 노출이 아니라 cross-platform 확산이 실제 피해 규모를 결정한다는 분석입니다.

탐지 및 대응 가이드

크리덴셜 드리프트를 탐지하고 대응하려면 개별 플랫폼 스캐닝을 넘어서는 접근이 필요합니다.

cross-platform 시크릿 인벤토리를 구축하세요. 조직이 사용하는 모든 플랫폼 -- 코드 리포, CI/CD, 컨테이너 레지스트리, 이슈 트래커, 문서 플랫폼, 메시징 도구 -- 에서 시크릿을 스캐닝하고, 발견된 시크릿을 통합 인벤토리에 등록하세요. 핵심은 같은 시크릿이 여러 플랫폼에 존재하는지를 식별하는 것입니다. 개별 플랫폼에서 "1건 탐지"가 아니라, "이 시크릿은 7개 플랫폼에 걸쳐 존재한다"는 전체 그림을 보는 것이 목표다.

Docker 빌드 시크릿 관리를 강화하세요. ENV나 ARG로 시크릿을 전달하지 말라. Docker BuildKit의 --mount=type=secret을 사용하면 시크릿이 이미지 레이어에 기록되지 않습니다. 멀티스테이지 빌드를 활용하여 빌드 타임 시크릿이 최종 이미지에 포함되지 않도록 하세요. 기존에 push된 이미지 중 시크릿이 포함된 이미지가 있는지 점검하고, 발견되면 이미지 삭제와 크리덴셜 로테이션을 병행하세요.

CI/CD 로그 마스킹을 점검하세요. Jenkins의 Mask Passwords 플러그인, GitHub Actions의 ::add-mask::, GitLab CI의 masked variables 기능이 실제로 모든 시크릿을 커버하는지 확인하세요. 환경변수에 직접 주입된 값, 스크립트에서 출력된 값, 에러 메시지에 포함된 값은 마스킹 대상에서 누락되기 쉽다. 빌드 로그의 보관 기간도 검토하세요. 오래된 로그에 시크릿이 남아 있을 수 있습니다.

Jira, Confluence, Slack에서의 시크릿 공유를 통제하세요. 기술적 통제와 문화적 통제를 병행해야 합니다. Atlassian Guard (구 Atlassian Access)의 DLP 기능으로 Jira/Confluence에서 시크릿 패턴을 탐지할 수 있습니다. Slack Enterprise Grid의 DLP도 DM을 포함한 전체 메시지를 스캔할 수 있습니다. 하지만 대부분의 조직이 이 기능을 활성화하지 않았거나, Enterprise 플랜을 사용하지 않습니다. 기술적 통제가 어려운 경우, 최소한 "비밀번호를 티켓이나 DM으로 공유하지 말 것"이라는 정책을 명문화하고, 시크릿 공유에는 Secrets Manager 링크를 사용하도록 교육하세요.

시크릿 로테이션 시 모든 드리프트 지점을 동시에 업데이트하세요. 시크릿을 로테이션할 때, Secrets Manager의 값만 변경하고 끝내면 안 됩니다. 드리프트된 모든 위치 -- docker-compose, Jenkins 환경변수, Docker 이미지, Jira 티켓, Confluence 페이지, Slack 메시지 -- 에서 이전 값을 제거하거나 무효화해야 합니다. 하나라도 남으면 드리프트가 재발합니다. 이것이 cross-platform 인벤토리가 필요한 이유다.

침해 의심 시, 드리프트 맵 전체를 기준으로 영향 범위를 평가하세요. 드리프트된 크리덴셜이 유출되면, 해당 크리덴셜이 존재했던 모든 플랫폼이 영향 범위에 포함됩니다. Docker Hub에서 유출된 경우라도, 같은 비밀번호로 접근 가능한 PostgreSQL, Jenkins 파이프라인, 내부 문서까지 모두 점검해야 합니다. 시크릿 탐지 및 대응에 대한 더 자세한 가이드는 Secret Detection: 2026년 완벽 가이드를 참고하세요.

Cremit Argus는 Drifted Key를 어떻게 탐지하는가

Drifted Key의 핵심 문제 -- 플랫폼별 사일로, cross-platform 가시성 부재, 드리프트 경로 추적 불가 -- 는 Cremit Argus가 해결하도록 설계된 정확한 문제다.

Argus는 코드 리포, CI/CD 파이프라인, 컨테이너 레지스트리, 이슈 트래커, 문서 플랫폼, 메시징 도구를 통합 스캐닝합니다. 개별 플랫폼 도구와의 결정적 차이는, Argus가 발견한 시크릿을 플랫폼 간에 상관 분석한다는 점입니다. GitHub에서 발견된 시크릿 값이 Jira 티켓에도, Docker 이미지에도, Slack 메시지에도 존재하는지를 자동으로 확인합니다. 결과는 "GitHub에서 1건"이 아니라, "이 시크릿은 7개 플랫폼에 걸쳐 존재하며, 드리프트 경로는 Secrets Manager → docker-compose → Jenkins → Docker Hub → Jira → Confluence → Slack DM이다"라는 전체 그림입니다.

Argus는 크리덴셜의 드리프트 경로를 시각화합니다. 원래 어디에 저장되어야 하는 크리덴셜이 어떤 경로를 거쳐 어디까지 확산되었는지를 맵으로 보여줍니다. 보안팀은 이 맵을 보고 즉시 두 가지를 판단할 수 있습니다. 첫째, 어떤 시크릿이 가장 넓게 드리프트되었는지(우선순위). 둘째, 어떤 플랫폼이 드리프트의 허브가 되고 있는지(구조적 문제). 단일 시크릿의 대응이 아니라, 조직의 크리덴셜 관리 체계 전체를 개선하는 기반이 됩니다.

로테이션 시에도 Argus의 cross-platform 인벤토리가 활용됩니다. 시크릿을 로테이션할 때, 해당 시크릿이 존재하는 모든 플랫폼 목록을 즉시 제공하여 하나의 드리프트 지점도 누락하지 않도록 합니다.

cremit.io에서 Argus의 cross-platform 시크릿 탐지 기능을 확인하세요.

NHI Kill Chain 시리즈 안내

이 글은 NHI Kill Chain 시리즈의 여섯 번째 글입니다. 9편의 시리즈를 통해 조직 내부에 숨어 있는 가장 위험한 NHI 크리덴셜 유형을 분석합니다. 각 유형은 고유한 위험이면서, 동시에 서로 연결되어 있습니다.

공개 리포에 노출된 키가 로테이션되지 않으면 Aged Key가 됩니다. 퇴사자의 키가 해지되지 않으면 Ghost Key가 됩니다. 하나의 키가 여러 플랫폼을 떠돌면 Drifted Key가 됩니다. 하나의 크리덴셜 관리 실패가 어떻게 다른 위험 범주로 연쇄되는지를 이해하는 것이 이 시리즈의 핵심 목적입니다.

Public Key -- .env 파일이 GitHub에 올라간 후 4분 동안 벌어지는 일
Ghost Key -- 퇴사한 개발자의 AWS 키는 아직 출근 중이다
Shadow Key -- Secrets Manager 바로 옆에 하드코딩된 키
Aged Key -- 3년간 프로덕션을 지탱한 마스터 키
Over-shared Key -- 10명이 하나의 Slack Bot Token을 공유할 때
Zombie Key -- 코드에서 삭제해도 살아 있는 키
Drifted Key -- DB 비밀번호가 Jira, GitHub, Docker 이미지에 동시에 존재하는 이유 (현재 글)
Unattributed Key -- 누가 만들었는지 아무도 모르는 키 (출간 예정)
Compound Risk -- 하나의 키에 5가지 위험이 겹칠 때 (출간 예정)

이전 글: [NHI Kill Chain: Zombie Key -- 코드에서 삭제해도 살아 있는 키](/ko/blog/nhi-kill-chain-zombie-key)

다음 글: NHI Kill Chain: Unattributed Key -- 누가 만들었는지 아무도 모르는 키

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