Docker Security Dispatch — 제3호: 취리히, 웜(Worms), 그리고 AI 프런티어 🏔️

아름다운 마요르카 섬에서 작성된 Docker Security Dispatch의 세 번째 호에 오신 것을 환영합니다. 5월은 SBOM(Software Bill of Materials)을 정복하고 그 너머로 나아가는 달이었습니다. 공급망 사고, 보안 연구, 그리고 운영 AI(Operational AI) 뉴스가 뒤섞인 롤러코스터 같은 한 달이었습니다.

TanStack과 Nx Console을 통한 대규모 공급망 연쇄 사고가 있었고, Mini Shai-Hulud의 긴 꼬리가 개발 환경에 계속 나타났으며, Docker는 커널 레벨의 컨테이너 탈출(Container Breakout) 클래스에 대응해야 했고, 저는 DevOpsDays Zurich 무대에 Commandos를 데려갔습니다.

결코 조용한 한 달은 아니었습니다.

핵심 요약 (Key Takeaways)

• DevOpsDays Zurich 2026에서 진행된 'Beyond SBOMs' 강연 요약.
• TanStack 및 Nx Console 침해 사고가 OIDC, 출처(Provenance), CI 캐시(CI caches), 그리고 개발자 워크스테이션에 대해 가르쳐 주는 것.
• Mini Shai-Hulud의 IDE 및 에이전트 지속성(Persistence)이 왜 여전히 AI 보조 개발(AI-assisted development)에 대한 올바른 경고 신호인지.
• Copy Fail, Docker Engine 완화 조치, AI 워크로드(AI workloads), 그리고 WeAreDevelopers Berlin으로 가는 길에 대한 실질적인 고찰.

🏔️ DevOpsDays Zurich: Beyond SBOMs

5월 6일, 저는 DevOpsDays Zurich 2026에서 다음과 같은 주제로 강연을 진행했습니다: Beyond SBOMs: The Future of Container Supply Chain Security (SBOM을 넘어: 컨테이너 공급망 보안의 미래):

Beyond SBOMs: The Future of Container Supply Chain Security — Mohammad-Ali A'râbi의 강연 - Docker 및 Kubernetes 보안

단 한 명의 피싱 당한 NPM 유지 관리자로 인해 Chalk와 Debug를 포함하여 매주 수십억 번 다운로드되는 18개의 라이브러리가 침해되었을 때, 한 가지 사실이 증명되었습니다. 기본적인 SBOM만으로는 충분하지 않다는 것입니다. 하지만 최근

강연 마지막에 제시했던 체크리스트가 몇 차례 사진으로 찍혔기에, 여기 텍스트 형태로 정리해 두었습니다:

SBOM을 넘어선 체크리스트 (Beyond SBOMs Checklist)

• 1. 빌드 강화 (Harden build). 빌드와 그 자격 증명 (Credentials)을 보호하기 위해 SLSA 레벨 3를 구현하세요.
• 2. 버전 고정 (Pin your versions). 고정된 의존성 (Pinned dependencies)과 고정된 베이스 이미지 (Pinned base images)를 사용하세요.
• 3. 냉각기 갖기 (Cool down). 새로 게시된 패키지나 이미지를 설치하기 전에 냉각기 (Cool-down period)를 가지세요.
• 4. AI를 신뢰하지 마세요 (Don't trust AI). AI 에이전트를 Docker Sandboxes와 같은 샌드박스 (Sandbox)에 배치하세요.
• 5. 수명이 짧은 키 사용 (Short-lived keys). 자격 증명이 침해되었을 때의 피해 범위 (Blast radius)를 제한하기 위해 수명이 짧은 키를 사용하세요.
• 6. 라이프사이클 스크립트 비활성화 (Disable lifecycle scripts). 기본적으로 --ignore-scripts 옵션을 사용하여 의존성을 설치하세요.
• 7. 사고 대응 플레이북 마련 (Have an incident playbook). 공급망 (Supply chain)에서 악성 패키지나 이미지를 발견했을 때 어떻게 대응해야 하는지 숙지하세요.

더 자세한 맥락이나 스위스 독일어, 혹은 할인 코드가 궁금하시다면 전체 강연을 시청해 보세요.

🧨 TanStack, Nx Console, 그리고 역습한 캐시

5월의 가장 큰 공급망 (Supply chain) 사건은 TanStack npm 침해에서 Nx Console 침해로 이어지는 연쇄 사건이었습니다. 저처럼 매일 프런트엔드 툴링 (Frontend tooling) 세계에 머물지 않는 분들을 위해 빠르게 맥락을 설명해 드리자면 다음과 같습니다:

• TanStack은 TanStack Query, Router, Table, Start와 같은 인기 있는 JavaScript 및 TypeScript 라이브러리들을 보유한 오픈 소스 프로젝트 제품군입니다.
• Nx Console은 많은 JavaScript 및 TypeScript 팀에서 사용하는 빌드 시스템이자 모노레포 (Monorepo) 도구인 Nx를 위한 IDE 확장 프로그램입니다.

요약하자면: 공격자들은 CI/CD 신뢰 경계 (Trust boundaries)를 악용하고, 패키지 매니저 캐시 (Package-manager cache)를 오염시킨 뒤, 권한이 있는 릴리스 워크플로 (Release workflow)를 기다렸다가, 결국 악성 패키지와 확장 프로그램 릴리스를 게시했습니다. 불편한 사실은 일부 악성 패키지들이 여전히 정당한 게시 경로를 통해 나온 것처럼 보였다는 점인데, 이는 공격자가 빌드 과정 중에 유효한 수명이 짧은 자격 증명 (Short-lived credentials)을 확보했기 때문입니다.

더 자세히 알고 싶다면, 사후 분석 보고서 (Postmortems)를 읽어보세요:

• TanStack npm 공급망 침해 사후 분석 보고서
• Nx Console v18.95.0 공급망 침해 사후 분석 보고서
• Microsoft의 악성 npm 패키지에 대한 설명

공급망에서 얻은 교훈 (Supply Chain Takeaways)

• CI 캐시를 실행 가능한 신뢰 경계(executable trust boundaries)로 취급해야 합니다. 오염된 캐시는 오염된 종속성만큼 위험할 수 있습니다.
• 개발자 워크스테이션과 IDE도 공급망의 일부로 간주해야 합니다. 더 이상 폭발 반경 밖에 있는 것이 아닙니다.

🪱 미니 샤이-훌루드: 여전히 벽 안에 (Mini Shai-Hulud: Still in the Walls)

Issue 2에서 저는 제 생일에 도착했던 NPM 공급망 웜인 **미니 샤이-훌루드(Mini Shai-Hulud)**에 대해 작성한 적이 있습니다. 이 웜은 심지어 제가 취리히에서 진행한 강연 슬라이드에도 포함되어 저작권 문제를 일으키기도 했습니다!

배경. _샤이 훌루드(Shai Hulud)_는 Dune 세계관의 거대한 모래 벌레입니다.

Mini Shai-Hulud는 **Bun 런타임 (Bun runtime)**을 악용하여 Node 중심의 보안 도구들을 우회했습니다. 더 중요한 점은, 개발자들이 신뢰하는 위치에 후크 (hooks)를 심어두었다는 것입니다:

점검해야 할 위치

• "runOn": "folderOpen" 설정이 포함된 .vscode/tasks.json
• SessionStart가 포함된 .claude/settings.json
• 패키지 라이프사이클 스크립트 (package lifecycle scripts)
• 워크플로 파일 (workflow files) 및 로컬 헬퍼 스크립트 (local helper scripts)

이는 node_modules를 삭제하는 것만으로는 충분하지 않음을 의미합니다. 만약 저장소 (repository) 자체가 수정되었다면, 누군가 폴더를 열거나 AI 코딩 세션을 시작할 때 감염이 다시 발생할 수 있습니다.

따라서 6월을 위한 실질적인 권고 사항은 다음과 같습니다:

rg -n "runOn|folderOpen|SessionStart|bun|curl|wget" .vscode .claude package.json .github

그리고 신뢰할 수 없는 저장소나 AI 에이전트 (AI-agent) 작업 시에는 계속해서 격리 (isolation)를 사용하십시오. Docker 샌드박스 (Docker Sandboxes)가 이 작업에 매우 자연스럽게 부합하는데, 에이전트가 호스트 머신을 모든 실험이 자유롭게 실행되는 장소로 만들지 않고도 코드를 조사, 빌드 및 실행할 수 있기 때문입니다.

sbx run claude

사람들은 샤이 훌루드 (Shai-Hulud)를 죽이려면 모래 상자에 넣고 물을 부으라고 말합니다. 저는 여전히 그 문장을 좋아합니다.

재밌게도, Mini Shai-Hulud가 등장하기 전에 저는 이미 작은 샤이 훌루드에 대해 글을 쓴 적이 있습니다. 저의 JAVAPRO 기사인 **"The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale"**에는 아주 작은 샤이 훌루드가 등장하며, Mini Shai-Hulud를 방어하는 방법과 놀라울 정도로 잘 맞아떨어지는 완화 조치 (mitigation practices)들을 다루고 있습니다. 아마도 저는 점술을 시작해야 할지도 모르겠군요.

The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale - JAVAPRO International

javapro.io

이 기사는 JAVAPRO의 특별판에도 게재되었습니다. JAVAPRO에서 PDF 버전을 다운로드할 수 있습니다:

항상 최신 상태 유지 - 모든 새로운 무료 PDF 에디션과 함께! - JAVAPRO International

javapro.io

🧱 Copy Fail과 심층 방어 (Defense in Depth)의 지루한 아름다움

5월은 JavaScript 패키지와 IDE에 관한 것만이 아니었습니다. 컨테이너 런타임 (container runtime) 레이어 또한 CVE-2026-31431, 일명 Copy Fail과 함께 자신만의 순간을 맞이했습니다.

다음은 Python 개발자 버전의 설명입니다.

Linux에는 사용자 프로그램이 표준 라이브러리 모듈을 임포트(import)하는 것과 비슷하게 호출할 수 있는 커널 (kernel) 기능들이 있습니다. 그 기능 중 하나가 AF_ALG로, 프로그램이 커널에 암호화 연산 (cryptographic operations)을 요청할 수 있게 해주는 인터페이스입니다. 예를 들어, "이 버퍼 (buffer)를 암호화해 주세요"라고 요청하는 식입니다.

Copy Fail은 입력과 출력 메모리가 겹칠 때 커널이 이러한 암호화 연산 중 하나를 처리하는 방식에서 발생한 버그였습니다. 만약 다음과 같이 Python 코드를 작성해 본 적이 있다면:

buffer = bytearray(b"important data")
view = memoryview(buffer)

...

여러분은 이미 문제의 형태를 이해하고 있는 것입니다. 코드는 바이트 (bytes)를 안전하게 복사하거나 변환하고 있다고 생각하지만, 읽기 측과 쓰기 측이 함수가 올바르게 처리하지 못한 방식으로 메모리를 가리키고 있는 상황입니다.

커널에서 이러한 종류의 실수는 손상된 Python bytearray보다 훨씬 더 심각합니다. 커널은 공유 캐시 (shared caches)와 호스트 리소스 (host resources)를 관리합니다. 잘못된 조건 하에서, 권한이 낮은 로컬 공격자 (low-privileged local attacker)는 이 버그를 이용해 쓰기 권한이 없는 곳에 데이터를 쓸 수 있습니다. 컨테이너 관점에서 이는 무서운 질문을 던집니다. 컨테이너 내부의 프로세스가 호스트 (host)에 영향을 미칠 수 있는가?

Docker는 Docker Engine에 완화 조치(mitigations)를 발표했습니다. 먼저 기본 seccomp 프로필을 강화한 다음, alg 소켓 패밀리에 대해 더 강력한 AppArmor 및 SELinux 적용 범위를 추가했습니다.

AppArmor와 SELinux는 저의 저서인 Docker and Kubernetes Security에서 다루고 있습니다. 이들은 프로세스가 수행할 수 있는 작업을 제한하는 정책을 작성할 수 있게 해주는 Linux 보안 모듈(Linux Security Modules)입니다.

흥미로운 점은 단지 CVE뿐만이 아닙니다. 바로 완화(mitigation) 과정에 담긴 이야기입니다.

컨테이너 보안은 다음과 같이 계층이 중첩되어 작동하기 때문에 효과적입니다:

• 네임스페이스(namespaces)와 cgroups는 프로세스가 볼 수 있는 것과 소비할 수 있는 것을 줄입니다.
• seccomp는 위험한 시스템 호출(syscall) 경로를 필터링합니다.
• AppArmor 또는 SELinux는 Linux 보안 모듈 계층에서 정책을 추가합니다.
• 최소화되고 강화된(hardened) 이미지는 컨테이너 내부의 유용한 도구들을 줄여줍니다.
• 런타임 모니터링(runtime monitoring)은 정적 스캐닝(static scanning)이 잡아낼 수 없는 동작을 포착합니다.