5월 Mini Shai-Hulud 침해 후, 컨테이너 공급망 보안 (Trivy·Sigstore·SBOM)

5월 11일, npm과 PyPI가 동시에 침해됐습니다

컨테이너 보안 점검을 잠시 미뤄둔 팀이 있다면, 5월 11일에 발생한 사건 한 가지를 같이 보셔야 하죠. Microsoft Security 2026년 5월 13일 업데이트는 그날 npm 패키지 170여 개와 PyPI 패키지 2개에 걸쳐 총 404개 악성 버전이 배포됐다고 안내합니다. 이 사건은 Mini Shai-Hulud로 명명됐고, npm과 PyPI를 동시에 침해한 사례로 보고됐어요.

영향 범위 사례로 Microsoft 블로그는 Zapier·PostHog·Postman 등을 안내했습니다. 공격 메커니즘은 preinstall 단계의 set_bun.js가 Bun 런타임을 호출하고, 이어 bun_environment.js가 GitHub Actions Runner를 다운로드·설치한 뒤 TruffleHog로 자격증명을 탈취하는 흐름입니다.

운영 환경에서 우리가 직접 신경 써야 하는 지점은 두 가지예요. 첫째, 사용 중인 라이브러리 버전이 영향 구간에 들어가지 않는지 확인하는 일. 둘째, 빌드·배포 파이프라인이 외부에서 들어오는 패키지·이미지를 어떤 검증 없이 통과시키고 있지 않은지 점검하는 일입니다.

컨테이너 공급망 보안은 세 축으로 정리됩니다

이런 사건 직후 운영팀이 자주 마주치는 질문이 있죠. 어디부터 점검해야 하나요라는 질문입니다. 컨테이너 공급망 보안은 빌드 단계의 이미지 스캐닝, 배포 단계의 이미지 서명, 운영 단계의 SBOM 세 축으로 정리할 수 있어요.

세 축이 각각의 도구로 분리돼 있는 게 아니라, CI/CD 파이프라인 안에서 빌드 → 스캔 → 서명 → SBOM 생성 → 배포 순서로 연결돼야 신뢰 사슬이 완성됩니다.

Trivy 이미지 스캐닝, 3월에는 스캐너 자체가 침해되기도 했습니다

Trivy 공식 사이트는 자체를 다음 한 줄로 안내합니다. All-in-One Security Scanner. Aqua Security가 개발하는 오픈소스(Apache-2.0) 도구이고, 컨테이너 이미지·쿠버네티스 워크로드·코드·바이너리에서 CVE·IaC 설정·시크릿·라이선스·SBOM을 한 번에 다루는 영역입니다.

그런데 2026년 3월에는 그 Trivy 자체가 침해된 사건이 보고됐어요. GitHub Security Advisories GHSA-69fq-xp46-6x23 (CVE-2026-33634)에 따르면, 공격자가 탈취된 자격증명으로 aquasecurity/trivy-action과 setup-trivy의 태그를 변조하고 악성 Trivy v0.69.4부터 v0.69.6까지를 Docker 이미지로 배포했습니다. 노출 윈도우는 3~12시간이었어요.

여기서 짚어둘 지점이 한 가지 있죠. 스캐너 자체도 공급망 일부라는 사실입니다. 스캐너를 신뢰의 출발점으로 두려면, 스캐너 도구 버전·태그·이미지 자체에 대한 검증이 함께 들어가야 해요. Trivy 사고는 그 점을 실증한 케이스입니다.

이미지 스캐닝 도구를 선택할 때 점검할 영역은 다음과 같습니다.

• CVE 데이터베이스 업데이트 주기와 출처

• IaC·시크릿·SBOM 추출 통합 지원 여부

• CI/CD 파이프라인 연동 방식 (GitHub Actions·GitLab CI·Jenkins 등)

• 도구 자체의 버전 관리 정책 (태그 고정 vs 부동 태그)

운영 단계 보안 모니터링은 5월 13일(수) 발행 옵저버빌리티 입문 글에서 정리한 signals 개념과 같이 보면 좋아요. 컨테이너 스캐닝 결과도 운영 관측성 채널로 흘러가야 사건 발생 시 빠른 대응이 가능합니다. 한편 같은 시기에 발견된 PostgreSQL·pgvector 보안 이슈는 5월 19일(화) 발행 PostgreSQL + pgvector RAG 글에서 별도로 정리했습니다.

Sigstore Cosign 서명, 2025년 10월 v3가 출시됐습니다

Sigstore 공식 문서는 컨테이너 이미지 서명을 세 구성요소로 안내합니다. Cosign(클라이언트), Fulcio(code-signing CA·OIDC 검증·단기 인증서), Rekor(immutable append-only ledger). Cosign이 키쌍과 서명을 다루고, Fulcio가 신원 검증으로 단기 인증서를 발급하며, Rekor가 변조 불가 원장에 기록을 남기는 구조예요.

Sigstore 공식 블로그는 2025년 10월 8일 게시글로 Cosign v3 출시를 안내했습니다. 주요 변경은 세 가지입니다.

• 새 번들 형식이 기본값: --new-bundle-format이 기본으로 적용되어 서명 자료가 오프라인 검증 정보까지 한 곳에 모이는 형태

• 새 신뢰 루트 옵션: --trusted-root로 키 로테이션을 지원하는 검증 자료를 한 곳에서 관리

• 서명 설정 사용 옵션: --use-signing-config로 투명성 로그 샤드 로테이션을 클라이언트 업데이트 없이 처리

v2 워크플로를 계속 쓰고 있다면 v3 번들 형식으로 마이그레이션할 시점이에요. 키리스 서명(Fulcio + OIDC) 방식은 사내 IdP·GitHub Actions OIDC와 연결해 적용할 수 있고, 단기 인증서 기반이라 키 노출 위험을 줄이는 설계입니다.

SBOM 표준, CycloneDX 1.7과 SPDX 3.1 RC 시점입니다

SBOM은 소프트웨어 구성요소를 표준 형식으로 명세하는 영역이고, 두 가지 국제 표준이 자리잡았어요.

CycloneDX 공식은 OWASP와 Ecma International TC54가 공동 개발하는 사양이고, 2025년 12월 ECMA-424로 국제표준 지위를 확보했습니다. SPDX 공식은 Linux Foundation이 관리하고 ISO/IEC 5962:2021 표준이며, 2026년 5월 시점 3.1 RC 단계입니다.

두 표준 중 어느 쪽이 항상 우월하다고 보기는 어려워요. 한 환경 안에서 일관된 표준을 채택하고 도구 체인을 맞추는 것이 운영을 단순하게 만드는 방향입니다. Trivy를 사용한다면 두 포맷 모두 출력 가능하고, Cosign으로 SBOM을 attestation 형태로 첨부할 수도 있어요.

CI/CD 통합과 정책 흐름

3축을 운영 가능한 형태로 만들려면 CI/CD 파이프라인 안에서 단계별로 연결돼야 합니다. SLSA Framework v1.2는 이런 신뢰 사슬을 4단계로 정의하는 OpenSSF 운영 프레임워크예요.

정책 흐름도 같이 짚어두면 좋아요. EU Cyber Resilience Act는 2024년 12월 10일 발효됐고, 2026년 9월 11일부터 보고 의무가 시작됩니다. 전면 시행은 2027년 12월 11일이에요.

국내에서는 한국 SW 공급망 보안 가이드라인 1.0이 과학기술정보통신부·국가정보원·디지털플랫폼정부위원회 민관 협력으로 2024년 5월 발표됐고, SBOM 유효성 검증·소프트웨어 구성요소 관리·SBOM 기반 공급망 보안 관리 방안이 안내돼 있어요.

이것만 기억하세요

자주 묻는 질문 (FAQ)