💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> "공급망 보안은 더 이상 '체크박스 컴플라이언스'가 아니다. 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겹 방어선

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

| 단계 | 대표 도구 | 무엇을 막는가 |

|---|---|---|

| 이미지 스캔 (Build) | Trivy, Grype, Snyk Container, Anchore, Docker Scout | 알려진 CVE, 잘못된 설정, 시크릿 누출 |

| SBOM 생성 (Build) | Syft, Trivy SBOM, Snyk SBOM, CycloneDX-CLI | 컴포넌트 인벤토리 — 새 CVE 공개시 영향 추적 |

| 서명 & 출처 (CI/CD) | Cosign, Sigstore, Notary v2, in-toto, SLSA | 빌드 후 변조 / 가짜 이미지 푸시 |

| 어드미션 정책 (Deploy) | OPA Gatekeeper, Kyverno, Polaris, Sigstore policy-controller | 서명 안 된 이미지, root user, hostPath 마운트 차단 |

| 런타임 보안 (Run) | Falco, Tetragon, Sysdig Secure, Cilium, AppArmor | 컨테이너 탈출, suspicious syscall, 권한 상승 |

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에 통합된 무료(부분) 도구. 가벼운 진입점이지만 엔터프라이즈 기능은 제한적.

| 도구 | 라이선스 | 강점 | 약점 |

|---|---|---|---|

| Snyk Container | 상용 | DevEx 최강, base image 추천 | 비쌈 |

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보다 빠르게 정보가 올라온다.

| DB | 운영 | 강점 | 약점 |

|---|---|---|---|

운영 팁 — 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이 폭넓게 채택됐다.

| 레벨 | 요구사항 | 무엇을 막는가 |

|---|---|---|

| L1 | 빌드 프로세스 문서화, provenance 생성 | 우발적 수동 빌드 |

| L2 | 호스팅된 빌드 서비스, 서명된 provenance | 빌드 머신 변조 |

| L3 | 격리된 빌드, 검증 가능한 provenance, 비변조 가능 | 빌드 시스템 침해 |

| L4 | 2인 리뷰, 재현 가능 빌드 (목표) | 단일 메인테이너 risky 변경 |

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** 비교:

| 항목 | Cosign / Sigstore | Notary v2 |

|---|---|---|

| 키 관리 | 키리스 (OIDC) 권장 | 사용자 PKI |

| 투명성 로그 | Rekor (필수) | 옵션 |

| OCI 사양 | tag 기반 + referrers | 1.1 referrers API |

| 채택 | Kubernetes, CNCF 다수 | Azure, AWS Signer |

| 정부 인증 | 진행중 (FIPS 140-3) | FIPS 140-3 보유 (Notation CLI) |

실전 — 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:

handler: runsc

apiVersion: v1

kind: Pod

metadata:

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:

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.

| 항목 | Falco | Tetragon |

|---|---|---|

| 시작 | 2016 (Sysdig) | 2022 (Isovalent) |

| 라이선스 | Apache 2.0 | Apache 2.0 |

| 거버넌스 | CNCF Graduated | CNCF Incubating |

| 정책 언어 | YAML 룰 (자체 DSL) | YAML CRD (TracingPolicy) |

| 차단 | 알람만 (별도 도구 연동) | 인라인 차단 가능 |

| eBPF 깊이 | syscall 위주 | LSM, kprobe, uprobe 다 활용 |

| 성숙도 | 더 검증됨 | 더 빠른 진화 |

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:

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

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 검증 호출

}

| 항목 | OPA Gatekeeper | Kyverno |

|---|---|---|

| 언어 | Rego (학습 필요) | YAML (네이티브) |

| 작업 종류 | Validate, Mutate | Validate, Mutate, Generate, Cleanup |

| 외부 데이터 | 풍부 (HTTP, LDAP, OCI) | 제한적이지만 늘어남 |

| 이미지 서명 검증 | 별도 controller 필요 | 내장 |

| 학습곡선 | 가파름 | 완만 |

| 생태계 | 더 큼 | 빠르게 성장 |

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:

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 로그인 지연 디버깅 중 발견

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

| 방어선 | 효과 | 이유 |

|---|---|---|

| Trivy/Grype CVE 스캔 | 0 | CVE가 없었음 — 미공개 백도어 |

| SBOM | 일부 | 영향받는 이미지 추적은 가능, 사전 방어 X |

| Cosign 서명 | 0 | 메인테이너가 직접 서명한 악성 코드 |

| SLSA L3 | 0 | 빌드 시스템 침해 아님 |

| SLSA L4 (2인 리뷰) | 가능성 | Jia Tan 단독 머지 차단 가능 |

| Falco/Tetragon | 잠재 | sshd 자식 프로세스 이상 syscall 탐지 가능 |

| distroless | 일부 | xz-utils 없는 이미지는 영향 없음 |

결론 — **사회공학으로 메인테이너가 되면 거의 모든 자동화는 무력**해진다. 답은 코드 리뷰 문화 + 신원 검증 + 빌드 후 행위 분석(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 → 스캔 → 서명 → 어드미션 정책 검증까지.

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/`