컨테이너 & 공급망 보안 2026 딥다이브 — Trivy / Grype / Snyk / Sysdig / Tetragon / Falco / Cosign / Sigstore 총정리

"공급망 보안은 더 이상 '체크박스 컴플라이언스'가 아니다. xz 백도어는 우리에게 가장 신뢰받는 오픈소스 메인테이너조차 2년에 걸친 사회공학 공격의 표적이 될 수 있음을 가르쳤다." — Filippo Valsorda, Go 보안 리드, GopherCon 2025 키노트

2024년 3월 29일, Andres Freund는 PostgreSQL 빌드 시간 지연을 디버깅하다가 xz-utils 5.6.0/5.6.1에 숨겨진 백도어(CVE-2024-3094)를 발견했다. 거의 모든 Linux 배포판에 침투할 뻔했던 이 사건은 컨테이너 베이스 이미지 전체의 SBOM 추적 가능성, 서명, 출처(provenance) 요구사항을 단번에 끌어올렸다. 1년 뒤인 2025년 12월, EU Cyber Resilience Act (CRA) 가 발효되면서 EU에 판매되는 모든 디지털 제품에 SBOM 제출과 취약점 공시 의무가 부과됐다. 미국도 EO 14028과 NIST SSDF(SP 800-218)로 같은 길을 가고 있다.

2026년 5월 현재, "컨테이너 보안"은 더 이상 단일 도구 카테고리가 아니다. 이미지 스캔(빌드 시점) / 레지스트리 정책(푸시 시점) / 어드미션 컨트롤(배포 시점) / 런타임 보안(실행 시점) / 서명 & 출처(전 단계) 라는 5겹 방어선이 필요하다. 이 글은 Trivy, Grype, Snyk, Sysdig, Anchore, Twistlock, Tetragon, Falco, Cosign/Sigstore, Notary v2, in-toto, SLSA, CycloneDX, SPDX, distroless, gVisor, Kata Containers, OPA Gatekeeper, Kyverno를 한자리에 모아 정리한다.

1. 2026년 컨테이너 보안 지도 — 5겹 방어선

먼저 카테고리부터 명확히 한다.

xz 사건의 교훈은 한 줄이다 — 이 5겹 중 단 하나에만 의존하면 안 된다. 빌드 시점 CVE 스캔은 미공개 백도어를 잡을 수 없고, 서명 검증은 메인테이너가 직접 서명한 악성 코드는 통과시키며, 런타임 보안은 "정상 syscall로 위장한" 백도어를 놓친다. 다층 방어가 답이다.

2. 이미지 스캐너 비교 — Trivy / Grype / Snyk / Anchore / Docker Scout

Trivy (Aqua Security, Apache 2.0)는 2026년 5월 기준 사실상의 표준이다. GitHub stars 22k+, Kubernetes Security SIG의 권장 도구, EKS/GKE/AKS 보안 가이드에 명시. 강점은 단일 바이너리 + 8개 카테고리 통합 스캔 — OS 패키지 CVE, 언어 의존성, 시크릿, 잘못된 설정, 라이선스, Kubernetes 매니페스트, Terraform, Helm 차트를 한 도구에서 처리한다.

Grype (Anchore, Apache 2.0)는 Trivy와 직접 경쟁한다. 동반 도구 Syft(SBOM 생성기)와 묶여 강력하다. Anchore Engine의 OSS 후속작이고, NVD + GitHub Advisory + 자체 큐레이션 DB를 사용한다.

Snyk Container (상용)는 개발자 워크플로 통합에 강하다. PR에 자동 댓글, JIRA 통합, 자동 fix 제안, base image 자동 추천(취약점 적은 버전으로). 단점은 라이선스 비용 — 100 컨테이너 이상은 보통 연간 수천만원.

Sysdig Secure (상용)는 Falco 발원지 회사의 풀스택 플랫폼. 이미지 스캔 + 런타임 + 컴플라이언스 + IaC 통합. AWS Marketplace 1티어 ISV이며 Fortune 500에서 인기.

Anchore Enterprise (상용)는 정부/금융 시장에 강하다. SBOM 중심 아키텍처, FedRAMP / DISA STIG 인증 보유, 미 국방부 Iron Bank 컨테이너 레지스트리의 게이트키퍼.

Docker Scout는 Docker Hub와 Docker Desktop에 통합된 무료(부분) 도구. 가벼운 진입점이지만 엔터프라이즈 기능은 제한적.

3. Trivy 실전 — 단일 명령으로 이미지부터 SBOM까지

가장 흔한 시나리오를 보자. nginx 공식 이미지를 스캔해 CVE를 찾고, SBOM을 만들고, CI에서 임계치를 넘으면 실패시키는 흐름.

# 1) 이미지 CVE 스캔 (CRITICAL/HIGH만 표시, 수정 가능한 것만)
trivy image \
  --severity CRITICAL,HIGH \
  --ignore-unfixed \
  --format table \
  nginx:1.27-alpine

# 2) SBOM 생성 (CycloneDX 1.5 형식)
trivy image \
  --format cyclonedx \
  --output nginx-sbom.cdx.json \
  nginx:1.27-alpine

# 3) SBOM에서 다시 스캔 (이미지 재pull 불필요)
trivy sbom nginx-sbom.cdx.json

# 4) CI 게이트 — CRITICAL 1개라도 있으면 exit 1
trivy image \
  --severity CRITICAL \
  --exit-code 1 \
  --ignore-unfixed \
  myapp:${GIT_SHA}

# 5) 시크릿 스캔 (.git, .env, AWS 키 등)
trivy fs --scanners secret,misconfig ./

# 6) Kubernetes 매니페스트 스캔
trivy config --severity HIGH,CRITICAL ./k8s/

핵심 옵션은 --ignore-unfixed다. CVE가 있어도 패치가 아직 없으면 막을 방법이 없으니, fixable한 것만 게이트 대상으로 삼는 것이 운영상 합리적이다. 단, 6개월 이상 미수정 CVE는 별도 트래킹이 필요하다.

4. CVE 매칭 DB — NVD / OSV / GitHub Advisory의 차이

스캐너가 "취약점 있다"고 말할 때 어떤 DB를 보는지가 정확도를 좌우한다. 2026년 현재 주요 DB는 세 곳이다.

**NVD (National Vulnerability Database)**는 NIST 운영, CVE 표준. 문제는 백로그다. 2024-2025년 NIST 인력 부족으로 enrichment(CPE 매칭, CVSS 점수)가 6개월 이상 밀려, 신규 CVE 정보 공백이 컸다.

**OSV (Open Source Vulnerabilities)**는 구글이 2021년 출범. 패키지-CVE 매핑이 정확하다(NPM, PyPI, Go, Rust 등 패키지 매니저 네이티브). API 무료, JSON 스키마 명확. Trivy와 Grype 모두 OSV를 보조 소스로 사용한다.

GitHub Advisory Database는 GitHub Security Lab + Dependabot이 큐레이션. NPM/PyPI/RubyGems 영역에서 NVD보다 빠르게 정보가 올라온다.

운영 팁 — Trivy는 3개 모두 합쳐 본다. trivy image --vuln-type os,library --db-repository ghcr.io/aquasecurity/trivy-db로 DB 미러를 사내에 두면 air-gap 환경에서도 동작한다.

5. SBOM 표준 — CycloneDX vs SPDX

SBOM 의무화 시대의 두 표준이다.

CycloneDX (OWASP)는 보안 중심. VEX(Vulnerability Exploitability eXchange)를 같은 문서에 인라인할 수 있다. JSON/XML/protobuf 모두 지원. CISA 2024 가이드라인에서 추천. 미국 의료기기 FDA, EU CRA 모두 CycloneDX를 1차 선택지로 본다.

SPDX (Linux Foundation)는 라이선스 컴플라이언스 중심으로 출발했다. ISO/IEC 5962:2021로 국제 표준화. 라이선스 메타데이터가 더 풍부하고, Kubernetes/CNCF 프로젝트들이 SPDX를 채택했다.

두 형식은 변환 가능하다 — cyclonedx-cli convert --input-format spdxjson --output-format json 또는 반대. Syft는 두 형식을 모두 출력한다.

# Syft로 SBOM 생성
syft nginx:1.27 -o cyclonedx-json=nginx.cdx.json
syft nginx:1.27 -o spdx-json=nginx.spdx.json

# 디렉토리 SBOM
syft dir:./myapp -o cyclonedx-json

# 같은 SBOM을 Grype로 스캔
grype sbom:nginx.cdx.json --fail-on high

6. SLSA — 빌드 출처 보증의 4단계

**SLSA (Supply-chain Levels for Software Artifacts)**는 Google이 시작하고 OpenSSF가 관리하는 빌드 무결성 프레임워크다. 핵심은 "빌드된 아티팩트가 정말 그 소스에서, 그 빌드 시스템으로 만들어졌는가"의 증명. 2026년 SLSA v1.0이 폭넓게 채택됐다.

GitHub Actions는 2023년 SLSA L3 빌더를 출시했다(slsa-framework/slsa-github-generator). Google Cloud Build, AWS CodeBuild도 L3 지원. SLSA Provenance는 in-toto attestation 포맷으로 생성된다.

xz 백도어가 SLSA로 막혔을까? 부분적으로만 그렇다. xz의 빌드 시스템 자체가 침해되진 않았으므로 SLSA L3 attestation은 발급됐을 것이다. 단, 2인 리뷰(L4) 였다면 단독 메인테이너 Jia Tan의 단독 머지가 불가능했다. SLSA L4는 아직 거의 모든 OSS에서 미달성 상태다.

7. Cosign / Sigstore — 키리스 서명의 혁명

Cosign(Sigstore 프로젝트)은 2022년 OCI 이미지 서명의 게임을 바꿨다. 전통적 PKI는 키 관리가 끔찍하게 어렵다 — 키 분실, 키 도용, 키 로테이션. Cosign의 keyless signing은 OIDC ID 토큰으로 단기(10분) 인증서를 발급해 서명한다.

3가지 구성요소:

• Fulcio: 단기 X.509 인증서를 발급하는 CA. OIDC ID 토큰(GitHub OIDC, Google, Okta 등)을 검증해 인증서 발급
• Rekor: append-only 투명성 로그(Tile-Based Merkle Tree). 모든 서명이 공개 기록되어 사후 변조 불가
• Cosign CLI: 클라이언트 도구

# 1) 키리스 서명 (GitHub Actions OIDC 사용)
COSIGN_EXPERIMENTAL=1 cosign sign \
  ghcr.io/myorg/myapp@sha256:abc...

# 2) 검증 — 누가 서명했는지(certificate identity), 어디서(issuer)
cosign verify \
  --certificate-identity-regexp="^https://github.com/myorg/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc...

# 3) attestation 서명 (SLSA provenance 등)
cosign attest \
  --predicate provenance.json \
  --type slsaprovenance \
  ghcr.io/myorg/myapp@sha256:abc...

# 4) SBOM을 OCI artifact로 같이 푸시
cosign attach sbom \
  --sbom nginx-sbom.cdx.json \
  ghcr.io/myorg/myapp@sha256:abc...

2026년 기준 Sigstore Rekor public log에는 1억 5천만 건 이상의 엔트리가 쌓였다. Kubernetes, CNCF 프로젝트 대다수, 그리고 PyPI/RubyGems도 Sigstore 서명을 점진 도입 중이다.

8. Notary v2 vs Cosign — 양대 산맥의 차이

Notary v2는 Docker가 시작한 이미지 서명 표준의 후속작. 2024년 1.0 출시. CNCF Incubating. OCI 1.1 Artifact 사양 위에 직접 구축되어 OCI 호환 레지스트리 어디서나 동작.

Cosign vs Notary v2 비교:

실전 — Kubernetes / CNCF 생태계는 Cosign, 엔터프라이즈/금융 PKI 기반은 Notary v2라는 분기가 굳어지는 중이다. 한 조직에서 둘을 동시 운영도 가능 — Cosign으로 dev, Notary v2로 prod release.

9. in-toto Attestation — provenance의 표준 포맷

in-toto는 CMU 발 공급망 무결성 프레임워크(2016)다. 핵심은 "각 빌드 단계의 메타데이터를 서명된 attestation으로 남기고 체인을 검증한다". 2026년 SLSA Provenance, SBOM attestation, VEX 모두 in-toto envelope으로 표준화됐다.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/myorg/myapp",
    "digest": { "sha256": "abc123..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/heads/main",
          "repository": "https://github.com/myorg/myapp",
          "path": ".github/workflows/release.yml"
        }
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner" },
      "metadata": {
        "invocationId": "https://github.com/myorg/myapp/actions/runs/123"
      }
    }
  }
}

이 statement에 DSSE(Dead Simple Signing Envelope)로 서명하면 attestation 완성이다. Cosign의 cosign attest가 이걸 자동으로 만들어준다.

10. Distroless 이미지 — 공격 표면을 0에 가깝게

distroless는 Google이 시작한 베이스 이미지 철학이다. 핵심: "프로덕션 이미지에는 쉘도, 패키지 매니저도, libc 외 기본 유틸리티도 넣지 마라". 컨테이너 탈출 후 공격자가 사용할 수 있는 도구를 통째로 제거한다.

# 다단계 빌드 — 빌드 스테이지에서는 도구 풀세트, 런타임은 distroless
FROM golang:1.23 AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/app ./cmd/server

# distroless static (nonroot 사용자 내장)
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /out/app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]

distroless 변종 — static (Go 같은 정적 바이너리), base (glibc + 인증서), cc (C/C++ libstdc++), java21-debian12, python3-debian12, nodejs20-debian12.

대안: Wolfi (Chainguard)는 distroless에 패키지 관리자(apk)를 곁들인 "보안 우선 OS". CVE 0 이미지 약속, 24시간 내 패치. Chainguard Images는 상용이지만 인기 폭증 중.

2026년 트렌드는 chiseled containers — Microsoft가 .NET 8부터 도입. Ubuntu 베이스에서 필요한 파일만 추려 100MB → 30MB로 축소.

11. gVisor / Kata Containers — 샌드박스 런타임

기본 OCI 런타임(runc, containerd)은 Linux 커널을 호스트와 공유한다. 커널 취약점이 곧 컨테이너 탈출이다. 샌드박스 런타임은 그 사이에 격리 레이어를 추가한다.

gVisor (Google, Apache 2.0)는 Go로 작성된 사용자공간 커널. 컨테이너 syscall을 가로채 자체 구현 커널이 처리. 빠른 시작, mid-tier 격리. GKE Sandbox, App Engine 표준 환경에서 사용.

Kata Containers (OpenStack Foundation)는 경량 VM. 컨테이너마다 KVM 마이크로VM 실행. 부팅 0.5초 수준, 격리도 VM급. Intel Clear Containers + Hyper.sh를 합친 후속작. Azure Confidential Containers, Alibaba Cloud Sandboxed Container 사용.

# Kubernetes RuntimeClass — pod별 샌드박스 선택
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: untrusted-workload
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: ghcr.io/myorg/user-code:latest

12. Falco — eBPF 기반 런타임 위협 탐지

Falco (CNCF Graduated, 2024년 졸업)는 컨테이너 런타임 보안의 사실상 표준이다. Sysdig가 만들어 CNCF에 기증. 핵심은 syscall 레벨 룰 엔진 — /etc/shadow 읽기, nsenter 실행, 컨테이너 안에서 패키지 매니저 실행 같은 의심 행동을 즉시 알린다.

2026년 Falco는 modern eBPF probe(libbpf-based)를 기본으로 한다. 커널 5.8+ 필요. 과거의 커널 모듈 / kprobe는 deprecated.

Falco rule 예시:

- rule: Shell Spawned in Container
  desc: A shell was spawned in a container — likely interactive intrusion
  condition: >
    spawned_process and container
    and shell_procs
    and proc.tty != 0
    and not user_known_shell_spawn_activities
  output: >
    Shell spawned in container (user=%user.name container_id=%container.id
    container_name=%container.name shell=%proc.name parent=%proc.pname
    cmdline=%proc.cmdline image=%container.image.repository)
  priority: WARNING
  tags: [container, shell, mitre_execution]

- rule: Write Below Etc
  desc: Write to /etc directory — possible persistence attempt
  condition: >
    write_etc and not proc.name in (allowed_etc_writers)
  output: >
    File below /etc opened for writing (user=%user.name
    command=%proc.cmdline file=%fd.name container=%container.id)
  priority: ERROR
  tags: [filesystem, mitre_persistence]

Falco는 syscall 발생 시점에 평가하므로 거의 실시간(microsecond)이다. 출력은 stdout, syslog, gRPC, HTTP(SOC 통합), Slack/PagerDuty 모두 가능.

13. Tetragon — eBPF 기반 차세대 런타임 보안

Tetragon (Isovalent / Cilium 패밀리, Apache 2.0)은 Falco에 대한 강력한 대안이다. 2023년 출범했고 2025년 v1.3에서 안정화됐다. 차이는 두 가지.

첫째, eBPF 풀활용. Falco는 syscall 후크 중심, Tetragon은 syscall + LSM hook + kprobe + uprobe 다 활용한다. 둘째, 실시간 차단(prevention). Falco는 탐지 후 알람이 기본이지만, Tetragon은 eBPF에서 직접 sigkill, syscall return value 변조 등 강제 차단이 가능하다.

# TracingPolicy CRD — Tetragon 룰
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-cryptominer
spec:
  kprobes:
  - call: "fd_install"
    syscall: false
    args:
    - index: 0
      type: int
    - index: 1
      type: "file"
    selectors:
    - matchArgs:
      - index: 1
        operator: "Postfix"
        values:
        - "xmrig"
        - "minerd"
      matchActions:
      - action: Sigkill

이 정책은 xmrig 또는 minerd 바이너리가 열리면 즉시 SIGKILL을 날린다. Falco로는 탐지 후 외부 시스템이 kill 해야 하지만, Tetragon은 커널 안에서 끝낸다 — 지연 0.

14. OPA Gatekeeper vs Kyverno — 어드미션 컨트롤러 양대 산맥

Kubernetes 어드미션 단계 — pod이 etcd에 저장되기 전 마지막 게이트 — 에서 정책 강제는 두 도구가 양분한다.

OPA Gatekeeper (CNCF Graduated)는 OPA 정책 엔진을 Kubernetes에 통합. Rego 언어로 정책 작성. 풍부한 표현력, 모든 Kubernetes 리소스에 동작, 외부 데이터(LDAP, Vault 등) 참조 가능.

Kyverno (CNCF Graduated, 2025년 졸업)는 Kubernetes 네이티브 정책 엔진. YAML로 정책 작성 (Rego 학습 불필요). Mutate / Validate / Generate / Cleanup 4종 작업. 2026년 기준 신규 채택은 Kyverno가 우세.

# Kyverno — 서명 안 된 이미지 차단
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  webhookTimeoutSeconds: 30
  rules:
  - name: check-image-signature
    match:
      any:
      - resources:
          kinds:
          - Pod
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/myorg/*"
            issuer: "https://token.actions.githubusercontent.com"
            rekor:
              url: https://rekor.sigstore.dev

같은 정책을 OPA Gatekeeper로 쓰면 Rego가 필요하다:

package kubernetes.admission

import future.keywords.if

deny contains msg if {
  input.request.kind.kind == "Pod"
  image := input.request.object.spec.containers[_].image
  not signature_valid(image)
  msg := sprintf("image %v lacks valid signature", [image])
}

signature_valid(image) if {
  startswith(image, "ghcr.io/myorg/")
  # ... external data 또는 Sigstore 검증 호출
}

15. 정책 실전 — Pod Security Standards + Kyverno

Kubernetes 1.25에서 PSP(Pod Security Policy)가 제거된 뒤, Pod Security Standards (PSS) + Pod Security Admission이 표준. 그러나 PSS는 3개 프리셋(privileged / baseline / restricted)만 제공, 세밀한 커스터마이즈는 Kyverno로 보완하는 것이 2026년 베스트 프랙티스.

# Kyverno — 5가지 핵심 베이스라인 강제
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: pod-security-baseline
spec:
  validationFailureAction: Enforce
  rules:
  - name: disallow-privileged
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "privileged containers are forbidden"
      pattern:
        spec:
          =(securityContext):
            =(privileged): "false"
          containers:
          - name: "*"
            =(securityContext):
              =(privileged): "false"
  - name: disallow-host-namespaces
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "hostNetwork / hostPID / hostIPC are forbidden"
      pattern:
        spec:
          =(hostNetwork): "false"
          =(hostPID): "false"
          =(hostIPC): "false"
  - name: require-non-root
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "containers must run as non-root"
      pattern:
        spec:
          =(securityContext):
            =(runAsNonRoot): true
          containers:
          - name: "*"
            =(securityContext):
              =(runAsNonRoot): true
  - name: disallow-hostpath
    match: { any: [{ resources: { kinds: [Pod] }}]}
    validate:
      message: "hostPath volumes are forbidden"
      pattern:
        spec:
          =(volumes):
          - X(hostPath): "null"

16. xz 백도어 2024 — 무엇을 막을 수 있었는가

CVE-2024-3094를 시간순으로 복기해본다.

• 2021: "Jia Tan" 이라는 신원이 xz-utils 프로젝트에 등장, 2년간 신뢰 구축
• 2023 말: 메인테이너 Lasse Collin이 번아웃, Jia Tan에 commit access 부여
• 2024-02: 5.6.0 릴리스에 백도어 삽입 (테스트 파일에 숨김)
• 2024-03-29: Andres Freund가 SSH 로그인 지연 디버깅 중 발견

각 방어선의 효과를 평가하면:

결론 — 사회공학으로 메인테이너가 되면 거의 모든 자동화는 무력해진다. 답은 코드 리뷰 문화 + 신원 검증 + 빌드 후 행위 분석(Falco/Tetragon)의 조합이다.

17. npm 타이포스쿼팅 / 의존성 혼동 공격

xz와 별개로 가장 빈번한 공급망 공격은 npm/PyPI 타이포스쿼팅과 dependency confusion이다. 2024년에만 Sonatype은 51만 건 이상의 악성 패키지를 탐지했다.

대표 패턴:

• 타이포스쿼팅: loadash (정상은 lodash), colorz (정상은 colors)
• Dependency confusion: 사내 NPM 레지스트리에 있는 패키지 이름과 같은 이름을 public npm에 더 높은 버전으로 푸시 → 내부 빌드가 public을 끌어가는 사건 (Alex Birsan, 2021 발견)
• Account takeover: 메인테이너 npm 계정 탈취 → 정상 패키지에 악성 버전 푸시
• Postinstall hooks: npm install 시 자동 실행되는 postinstall 스크립트로 악성코드 실행

방어:

# 1) lock file 신뢰 (package-lock.json / pnpm-lock.yaml)
npm ci  # npm install 대신

# 2) postinstall 스크립트 비활성
npm config set ignore-scripts true

# 3) 사내 패키지는 scope 사용 (@myorg/foo)
# 4) npm audit signatures — 서명 검증
npm audit signatures

# 5) Socket / Snyk / Phylum로 사전 행위 분석

PyPI는 2024년부터 Sigstore 통합 시작, 2025년 인기 패키지에 attestation 의무화. npm은 2026년 OIDC trusted publishing이 표준이 되어가는 중.

18. 한국 상황 — SBOM 의무화 동향

한국도 글로벌 흐름에 합류 중이다. 2024년 과기정통부는 SW 공급망 보안 가이드라인을 발표, SBOM 권고 단계에서 점진 의무화로 가는 로드맵을 제시했다. 2025년 정보보호산업진흥법 개정안에 따라 공공기관 발주 SW에 SBOM 제출이 단계 의무화되기 시작했다.

국내 사례:

• LINE: LINE Engineering Blog (2024)에 의하면 사내 Container Registry에 Trivy 통합, push 시 자동 스캔, CRITICAL/HIGH 차단. 이미지 서명은 Notary v2 자체 운영.
• 카카오: KakaoTalk 인프라 컨테이너에 Falco 도입(2023). 2024년 Sysdig Secure 도입하여 멀티 클러스터 통합 관리.
• 쿠팡: AWS Fargate(Firecracker 기반) 중심 운영, 자체 빌드 시스템에 SBOM 자동 생성, Snyk Container를 PR gate로 사용.
• 토스: 2025년 Tetragon 도입 사례 발표(if(kakao) 컨퍼런스). PCI-DSS 컨테이너 격리에 활용.

한국 특화 도구는 KISA의 CSAP(Cloud Security Assurance Program) 컨테이너 보안 항목 준수가 공공 클라우드 진출의 게이트가 되고 있다.

19. 일본 상황 — IPA 가이드라인 + Mercari / 라쿠텐 사례

일본 **IPA(情報処理推進機構)**는 2024년 コンテナセキュリティガイドライン v2.0을 발표했다. 핵심은 NIST SP 800-190의 일본어 현지화 + 일본 금융청 FISC 가이드라인 정합성. SBOM은 2025년 경제산업성 가이드라인에서 권고 → 2026년 일부 공공 조달에서 의무화 단계.

기업 사례:

• 메르카리(Mercari): 멀티 클러스터 GKE 환경에서 Trivy + Cosign 키리스 서명 + Kyverno 정책 검증을 표준 파이프라인으로 운영. Mercari Engineering Blog 2025년 "Container Security at Scale" 시리즈 참고.
• 라쿠텐(Rakuten): 자체 데이터센터 + 퍼블릭 클라우드 하이브리드. Anchore Enterprise + Sysdig 조합. 금융 자회사는 FIPS 140-3 컴플라이언스로 Notary v2 사용.
• DeNA: 게임 컨테이너에 Falco 도입, 부정행위/봇 탐지에 활용한다는 사례 (2024 SRE Lounge).
• SmartHR: HR SaaS, GKE + Tetragon (2025 도입). 직원 PII 처리 컨테이너에 강한 격리 필요.

일본 특이점은 금융청 FISC 안전대책 기준. 컨테이너 격리 등급, 로그 보존(원칙 7년), 외부감사 의무가 한국보다 엄격해 Kata Containers / gVisor 등 강한 격리 런타임 채택률이 높다.

20. EU CRA (Cyber Resilience Act) — 2025년 발효의 충격

2024년 10월 EU 의회 통과, 2027년 12월 완전 적용 (2026년 5월 현재 SBOM 제출 등 일부 조항 발효 중). 핵심 요구:

• EU에 판매되는 모든 digital product에 적용 (SaaS는 제외 가능성 — 협의 진행 중)
• 취약점 처리 의무: 발견 즉시 공개 — 24시간 내 ENISA에 보고, 72시간 내 패치 또는 mitigation 안내
• SBOM 제공 의무: 시장 출시 시점부터 5년 또는 제품 수명 중 긴 쪽
• 무단 수정 방지: 디지털 서명, 보안 부팅 등
• 위반 시 최대 1500만 유로 또는 글로벌 매출 2.5% 과징금

CRA가 컨테이너 보안에 미치는 영향은 직접적이다 — EU 시장에서 컨테이너 이미지를 판매하면 SBOM 제출은 옵션이 아니다. 무료 OSS는 일정 조건(개인이 1인 운영 등)에서 면제되지만, 기업이 OSS를 임베드해 제품화하면 그 책임은 기업에 온다.

실무 대응 — cosign attach sbom 또는 OCI artifact로 SBOM을 이미지와 함께 푸시해 두면 EU 감사관이 cosign download sbom 한 줄로 검증 가능하다.

21. CI/CD 통합 — GitHub Actions 풀스택 예제

엔드투엔드 파이프라인 — 빌드 → SBOM → 스캔 → 서명 → 어드미션 정책 검증까지.

name: secure-build
on:
  push:
    tags: ['v*']

permissions:
  contents: read
  id-token: write   # Sigstore OIDC
  packages: write   # GHCR push
  attestations: write

jobs:
  build-and-sign:
    runs-on: ubuntu-24.04
    steps:
    - uses: actions/checkout@v4
    - uses: docker/setup-buildx-action@v3
    - uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

    # 1) 빌드 + 푸시
    - id: build
      uses: docker/build-push-action@v6
      with:
        context: .
        push: true
        tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}
        provenance: mode=max
        sbom: true

    # 2) Trivy 스캔 — CRITICAL 1개라도 있으면 실패
    - uses: aquasecurity/trivy-action@master
      with:
        image-ref: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        format: sarif
        output: trivy-results.sarif
        severity: CRITICAL
        exit-code: 1
        ignore-unfixed: true

    # 3) SBOM 별도 생성 (Syft)
    - uses: anchore/sbom-action@v0
      with:
        image: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        format: cyclonedx-json
        output-file: sbom.cdx.json

    # 4) Cosign 키리스 서명 + SBOM attestation
    - uses: sigstore/cosign-installer@v3
    - run: |
        cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        cosign attest --yes \
          --predicate sbom.cdx.json \
          --type cyclonedx \
          ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

    # 5) SLSA L3 provenance (GitHub OIDC + slsa-github-generator)
    - uses: actions/attest-build-provenance@v1
      with:
        subject-name: ghcr.io/${{ github.repository }}
        subject-digest: ${{ steps.build.outputs.digest }}
        push-to-registry: true

이 파이프라인이 끝나면 GHCR에는 이미지 + Cosign 서명 + SBOM attestation + SLSA provenance가 모두 OCI artifact로 함께 저장된다.

22. 모니터링 — Falco/Tetragon 알람을 어디로 보낼 것인가

탐지만 하고 사람이 안 보면 의미가 없다. 알람 라우팅 전략:

• stdout/syslog → Loki/Elastic: 모든 이벤트 영구 저장(컴플라이언스). 7년 보관 의무 있는 금융은 필수.
• 고심각도 → PagerDuty/Opsgenie: 즉시 호출. ERROR+ 이상.
• 중심각도 → Slack #security-alerts: 트리아지. 시간당 50건 넘으면 알람 피로 — 룰 튜닝 필요.
• 저심각도 → SIEM (Splunk/Datadog): 룰 학습 및 패턴 탐지.

Falcosidekick(Falco 보조 도구)은 알람을 50개 이상의 외부 대상에 라우팅한다 — Slack, Teams, PagerDuty, OpenSearch, Splunk, Loki, S3, GCS, AWS SQS, Kafka 등.

알람 피로 방지 — Falco의 rules-tuning.yaml에서 user_known_* 매크로를 적극 활용해 정상적인 운영 행동을 화이트리스트화하라. 처음 한 달은 알람 폭주를 견디며 매크로를 키워나가는 것이 정석이다.

23. Confidential Containers — TEE 기반 메모리 암호화

2026년 트렌드는 Confidential Computing 이다. AMD SEV-SNP, Intel TDX, ARM CCA 같은 TEE(Trusted Execution Environment)에서 컨테이너 실행 시 메모리가 호스트 OS에도 보이지 않는다. CSP 직원조차 워크로드 메모리에 접근할 수 없는 격리 수준.

Confidential Containers (CoCo) 프로젝트는 CNCF Sandbox에서 Incubating으로 승격(2025). Kata Containers + TEE 조합. Azure Confidential Containers, Google Cloud Confidential Space, IBM Cloud HPVS가 동일 기반.

사용처 — 헬스케어 PHI, 금융 PCI 데이터, AI 모델 가중치 보호. 한국 NICE신용평가(2025년 도입 사례 발표), 일본 노무라증권 일부 워크로드 적용.

오버헤드는 5-15%이지만 H100/MI300X 같은 confidential-aware GPU도 등장 — AI 추론 컨테이너에 적합.

24. 안티패턴 — 흔한 실수 8가지

운영 현장에서 반복적으로 보이는 실수.

1. latest 태그 사용: 재현 불가 + 서명 검증 무력화. 항상 digest(@sha256:...)로 핀.
2. root 사용자 컨테이너: USER nonroot 또는 distroless 사용. runAsNonRoot: true 어드미션 강제.
3. :로 빈 패스워드 컨테이너 이미지: 베이스 이미지에 빈 password 계정이 있으면 사회공학에 취약.
4. 민감 정보를 ENV로 주입: docker inspect로 추출됨. Vault/AWS Secrets Manager + sidecar 또는 SPIFFE.
5. --privileged 무분별 사용: 호스트 root 동등. 정말 필요한 capability만 추가 (--cap-add NET_ADMIN 등).
6. CI Runner에 docker.sock 마운트: runner 침해 시 호스트 컨테이너 전체 장악. Sysbox / kaniko / buildah rootless로 교체.
7. CVE 게이트만 운영: SBOM 추적, 서명 검증, 런타임 보안이 없으면 미공개 백도어에 무방비. xz 교훈.
8. 알람 무시: Falco/Tetragon 알람을 1주만 무시하면 그 다음에는 아예 안 본다. 트리아지 SLA가 없으면 보안 인프라는 무의미.

25. 향후 6-12개월 전망

• 2026 Q3-Q4: EU CRA 부분 발효의 본격적 영향. EU 매출 있는 모든 SW 벤더가 SBOM 표준화 가속.
• NIST SP 800-218 SSDF 의무화: 미국 연방 SW 조달에 SLSA L3 동등 수준 요구 본격화.
• Rust 베이스 이미지: glibc/musl 의존성 더 줄인 cargo-chef + scratch 패턴 확산.
• Kyverno > OPA Gatekeeper: 신규 채택 비율에서 격차 더 벌어질 전망.
• eBPF LSM 표준화: Tetragon 류의 인라인 차단이 Falco에도 백포팅될 가능성.
• AI 워크로드 보안: 모델 가중치 무결성, 추론 컨테이너 격리, prompt injection 탐지에 컨테이너 보안 도구 확장.
• Sigstore Trusted Publishing: PyPI/npm/RubyGems 모두 OIDC 기반 publishing으로 전환 — 토큰 유출 사고 격감 기대.

26. 결론 — 자동화는 도구가 아니라 문화다

xz 백도어가 가르친 가장 큰 교훈은 도구가 아니라 운영 문화다. 메인테이너 한 명에 권한이 집중되면, 그가 사회공학에 당하는 순간 모든 자동화 방어가 무력화된다. 답은:

1. 5겹 방어선 모두 운영하라 — 스캔/SBOM/서명/어드미션/런타임 중 하나라도 빼면 xz 같은 사건에 노출
2. 알람을 사람이 봐야 한다 — 자동 차단이 안 되는 영역은 사람이 24시간 안에 트리아지
3. 2인 리뷰를 정착시켜라 — SLSA L4의 본질. 자동화로는 만들 수 없는 보안 layer
4. 레거시 의존성을 정기적으로 청산하라 — 활동 없는 OSS는 다음 xz 후보
5. 컴플라이언스를 핑계로 삼지 말라 — CRA, SBOM 의무화는 최소선. 실제 보안과 컴플라이언스는 다른 문제

도구는 매년 바뀐다. 2026년의 Trivy/Tetragon/Cosign이 2030년에도 1위일지는 모른다. 하지만 위 5가지 운영 원칙은 도구가 어떻게 바뀌어도 그대로다.

References

• Trivy 공식 문서 — https://trivy.dev/
• Aqua Security Trivy GitHub — https://github.com/aquasecurity/trivy
• Anchore Grype — https://github.com/anchore/grype
• Anchore Syft (SBOM) — https://github.com/anchore/syft
• Snyk Container — https://snyk.io/product/container-vulnerability-management/
• Sysdig Secure — https://sysdig.com/products/secure/
• Anchore Enterprise — https://anchore.com/enterprise/
• Sigstore 공식 — https://www.sigstore.dev/
• Cosign GitHub — https://github.com/sigstore/cosign
• SLSA 공식 — https://slsa.dev/
• in-toto attestation — https://in-toto.io/
• CycloneDX 사양 — https://cyclonedx.org/
• SPDX 사양 — https://spdx.dev/
• Falco 공식 — https://falco.org/
• Falco docs — https://falco.org/docs/
• Tetragon — https://tetragon.io/
• Isovalent Tetragon docs — https://isovalent.com/blog/post/tetragon-release-1/
• gVisor — https://gvisor.dev/
• Kata Containers — https://katacontainers.io/
• Confidential Containers — https://confidentialcontainers.org/
• OPA Gatekeeper — https://open-policy-agent.github.io/gatekeeper/website/docs/
• Kyverno — https://kyverno.io/
• Distroless 이미지 — https://github.com/GoogleContainerTools/distroless
• Chainguard Wolfi — https://github.com/wolfi-dev/
• xz-utils 백도어 분석 (Andres Freund) — https://www.openwall.com/lists/oss-security/2024/03/29/4
• NIST SP 800-190 컨테이너 가이드라인 — https://csrc.nist.gov/publications/detail/sp/800-190/final
• EU Cyber Resilience Act — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CISA SBOM 자료 — https://www.cisa.gov/sbom
• Standard Webhooks (참조 비교용) — https://www.standardwebhooks.com/
• Notary v2 / Notation CLI — https://notaryproject.dev/
• IPA コンテナセキュリティガイドライン — https://www.ipa.go.jp/security/
• 과학기술정보통신부 SW 공급망 보안 — https://www.msit.go.kr/