컨테이너 & 클라우드네이티브 보안 2026 — Trivy·Grype·Snyk·Aikido·Wiz·Sysdig·Tetragon 심층 비교 (Shift-Left부터 Runtime까지)

프롤로그 — "스캔은 돌고 있어요"는 보안이 아니다

2026년 어느 플랫폼팀이든 한 번쯤 겪는 대화.

CISO: "컨테이너 보안 어떻게 돼?" DevOps 리드: "Trivy 스캔이 CI에 돌고 있어요. 매일 도커파일 빌드할 때마다." CISO: "그래서 production에 critical CVE가 몇 개 있어?" DevOps 리드: "음... 그건 따로 안 봐요."

이게 2026년에도 흔한 풍경이다. 스캔은 도는데 결과를 아무도 안 본다. 이미지에 critical이 47개 떠 있어도, 그게 우리 클러스터에 실제로 어떤 위험인지 모른다. runtime에서 어떤 컨테이너가 외부로 호출을 던지는지도 모른다. 누가 IAM * 권한을 들고 있는지도 모른다. 빌드 시점의 스캔은 하나의 신호일 뿐, 그것만으로는 보안 자세(security posture) 가 안 잡힌다.

문제는 도구가 너무 많아졌다는 것이다. Trivy·Grype·Snyk만 봐도 셋이 겹친다. 거기에 Aikido가 "AppSec + Cloud 통합"으로 치고 올라오고, Wiz·Orca는 CNAPP으로 클라우드 전체를 본다고 하고, Sysdig·Tetragon은 eBPF로 runtime을 본다고 한다. JFrog Xray는 artifact 쪽이고, Cosign·Sigstore는 서명, SLSA는 공급망, Wolfi/Chainguard는 distroless. 이걸 다 깔면 7개 회사 라이선스와 7개 대시보드가 생긴다.

이 글은 2026년 5월 기준 컨테이너 & 클라우드네이티브 보안 도구의 지도를 그린다. 각 도구가 어디를 보고 무엇을 놓치는지, OSS-only 스택으로 어디까지 갈 수 있는지, 상용 CNAPP가 정말로 추가하는 값이 무엇인지 — 마케팅 페이지가 아니라 실제 사용자 관점에서.

1장 · 지형도 — 보안 도구는 어디를 보는가

먼저 카테고리부터 잘라야 한다. "컨테이너 보안"이라는 단일 카테고리는 없다. 적어도 6개 다른 문제가 한 단어에 묶여 있다.

단계	측정 대상	대표 도구 (OSS)	대표 도구 (상용)
Source / IDE	코드 시크릿, SAST	Semgrep, Gitleaks	Snyk Code, Aikido
Dependency (OSS)	라이브러리 CVE	Trivy, Grype, OSV-Scanner	Snyk Open Source, Mend
Container Image	이미지 레이어 CVE	Trivy, Grype, Syft	Snyk Container, Aikido
IaC / K8s manifest	misconfig	Trivy, Checkov, Kyverno	Snyk IaC, Aikido
Artifact / Registry	저장된 binary/SBOM	OSV, Grype + Harbor	JFrog Xray, Aqua
Cloud Posture (CSPM)	AWS/GCP/Azure 설정	Prowler, ScoutSuite	Wiz, Orca, Aikido
Workload (CWPP)	클러스터 안 워크로드	Falco, Tetragon	Sysdig Secure, Wiz
Identity (CIEM)	IAM 권한 분석	(제한적)	Wiz, Orca
Data (DSPM)	데이터 위치/분류	(제한적)	Wiz, Orca, Cyera
Runtime detection	실행 중 이상 행동	Falco, Tetragon	Sysdig Secure, Wiz Runtime
Supply chain	빌드 출처/서명	Sigstore Cosign, SLSA	(위 도구 다수가 통합)

핵심: 하나의 도구가 모든 단계를 잡지 않는다. Trivy는 image/IaC/SBOM에서 최강이지만 runtime은 못 본다. Wiz는 cloud posture에서 최강이지만 image build 단계에선 약하다. Sysdig는 runtime에서 최강이지만 빌드 시점은 약하다. 그래서 조합이 필요하다.

다만 2026년 트렌드는 수렴이다. Wiz는 image 스캔까지 흡수하고, Aikido는 CSPM까지 흡수하고, Snyk는 cloud posture를 붙였다. 이 수렴이 CNAPP(Cloud Native Application Protection Platform) 카테고리다.

2장 · Trivy (Aqua Security) — OSS의 사실상 표준

2026년 컨테이너 스캔의 첫 도구를 하나만 고르라면 Trivy다. Aqua Security가 후원하지만 Apache 2.0 라이선스, GitHub star 26k+, 사실상 모든 CI에서 한 번씩은 만나는 이름이다.

버전: 2026년 5월 기준 v0.60+ 라인. 분기 단위 메이저 릴리즈, vulnerability DB는 매시간 업데이트.

스캔 가능 대상:

컨테이너 이미지 (Docker, OCI, containerd)
파일시스템 (로컬 디렉토리)
Git 리포지토리
가상머신 이미지 (AMI, VMDK)
Kubernetes 클러스터 (in-cluster scan)
IaC (Terraform, CloudFormation, Helm, Kustomize, Dockerfile)
SBOM 생성 (SPDX, CycloneDX)
라이선스 (사용 라이브러리의 라이선스 추출)

한 줄 사용법.

# 이미지 스캔
trivy image alpine:3.19

# Critical/High만, 종료 코드 사용 (CI 게이트)
trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:latest

# SBOM 생성 (CycloneDX)
trivy image --format cyclonedx --output sbom.json myapp:latest

# K8s 클러스터 전체 스캔
trivy k8s --report summary cluster

# IaC
trivy config ./infra/terraform

강점:

빠르다 — Go 단일 바이너리, 의존성 없음. 평균 이미지 스캔 5초 이하.
DB가 좋다 — NVD + GHSA + Red Hat OVAL + Alpine secdb + Debian DSA + Ubuntu USN + Wolfi advisory 등 16+ 출처 통합.
misconfig 빌트인 — IaC 룰셋 600+ (Checkov 수준).
Aqua가 후원하지만 OSS 우선 — 회사 제품(Aqua Platform)이 있어도 Trivy 자체는 진짜 OSS.

약점:

runtime을 못 본다 — 빌드/배포 시점만.
클라우드 계정 단위 posture를 못 본다 (Trivy AWS는 제한적).
false positive 처리가 수동적 — .trivyignore 파일로 묵음 처리.

언제 쓰나: 거의 모든 팀의 첫 도구. OSS 스택의 코어. 거의 모든 CI에 5분이면 붙는다.

3장 · Grype + Syft (Anchore) — SBOM 전문가

Syft가 SBOM을 만들고, Grype가 그 SBOM(또는 이미지)을 스캔한다. Anchore(상용 회사)가 후원하지만 Apache 2.0 OSS.

# Syft로 SBOM 생성
syft alpine:3.19 -o cyclonedx-json > sbom.json

# Grype로 SBOM 스캔 (이미지가 아니라 SBOM을 입력)
grype sbom:./sbom.json

# 직접 이미지 스캔도 가능
grype alpine:3.19

Trivy와의 차이:

분리된 책임 — Syft는 인벤토리만, Grype는 매칭만. 작은 단위 컴포저블.
SBOM-first 워크플로 — 한 번 만든 SBOM을 여러 시점에 다시 스캔할 수 있다 (DB가 업데이트되면 동일 이미지의 새 CVE를 찾을 수 있다).
언어 생태계 지원이 깊다 — Java, Python, JavaScript, Go, Ruby, Rust, Swift, .NET 등 패키지 매니저별 인식이 세밀하다.

언제 Grype/Syft를 쓰나:

SBOM을 빌드 산출물로 정식 관리하고 싶을 때 (SLSA 준수)
등록된 image의 retro-scan이 필요할 때
Trivy와 더블체크 (서로 다른 DB가 다른 CVE를 잡는다)

많은 팀이 Trivy + Syft 조합을 쓴다 — Trivy는 스캔, Syft는 SBOM 산출.

4장 · Snyk — Developer-First, 다 본다

Snyk는 다 본다. Code(SAST), Open Source(SCA), Container, IaC. 2026년 기준 가장 광범위한 developer-first 보안 플랫폼. 무료 tier(월 200건)부터 enterprise까지.

제품 라인:

Snyk Open Source — 라이브러리 CVE + 라이선스. npm/PyPI/Maven 등.
Snyk Container — 이미지 스캔 + 베이스 이미지 추천("Alpine 3.19로 옮기면 CVE 12개 사라짐").
Snyk Code — SAST. Semgrep 스타일.
Snyk IaC — Terraform/CloudFormation/K8s manifest misconfig.
Snyk AppRisk (2025년 출시) — 위 결과를 비즈니스 컨텍스트로 우선순위화.

강점:

개발자 UX가 좋다 — IDE 플러그인, GitHub PR check, 자동 fix PR.
Vulnerability DB가 좋다 — Snyk 자체 보안팀이 NVD보다 빨리 advisory를 낸다.
CVE 설명이 풍부하다 — exploit 정보, 패치 경로, 워크어라운드.

약점/논쟁점:

가격이 비싸다 — 개발자 수 기반, enterprise는 수만 달러/년 쉽게 넘어간다.
2024-2025년 데이터 라이선스 논쟁 — Snyk 일부 사용자가 무료 plan에서 가격 인상에 불만 표출, 일부 OSS 프로젝트는 Snyk 의존을 줄였다.
자체 DB의 unique advisory 의존 — vendor lock-in 의식.

Snyk vs Mend (구 WhiteSource): Mend는 enterprise SCA에서 오래된 강자. 라이선스 컴플라이언스(법무팀 친화) 쪽에서는 Mend가 강하다. 개발자 UX와 fix automation은 Snyk가 강하다.

언제 쓰나: developer experience와 자동 fix PR을 중시하는 mid-size~enterprise. 무료 tier로 작은 팀 시작에도 좋다.

5장 · Aikido Security — 유럽 출신 신예, AppSec + Cloud 통합

Aikido는 2022년 벨기에에서 시작한 보안 스타트업으로, 2024년 Series A(17M EUR), 2025-2026년에 빠르게 성장. 포지션은 "Snyk + Wiz를 하나로, 더 싸게".

커버리지 (하나의 SaaS에서):

SAST + SCA + Container + IaC (Snyk 영역)
Cloud Posture (CSPM, AWS/GCP/Azure)
Secret 스캔
사용 도구 통합 (Trivy·Semgrep·OSV 등 OSS 엔진을 후드 아래에서 쓴다)
AI Auto-Fix PR — 발견된 취약점에 대해 자동으로 PR을 만들어 보낸다 (2025년 차별화 기능)

강점:

빠르게 셋업 — GitHub 연결 → 클라우드 connect → 10분이면 첫 결과.
가격이 명시적이고 싸다 — Snyk/Wiz 대비 4060% 수준의 가격 포지션.
OSS 엔진 위에 UX/통합 — 후드 아래는 Trivy/Semgrep 같은 OSS, 위에는 통합 UI/노이즈 감소/AI 자동 fix.
유럽 GDPR 친화 — EU 호스팅 옵션이 처음부터 명시.

약점:

runtime / CIEM / DSPM이 약하다 — Wiz 만큼 cloud-deep 하진 않다.
enterprise feature gap — 큰 조직의 거버넌스/RBAC 요구는 아직 채워지는 중.
신생 회사 리스크 — 인수/회사 변화 가능성은 늘 있다.

언제 쓰나: small~mid-size 팀, "Snyk 가격이 부담", "Wiz까진 과한데 cloud도 보고 싶음" — 이 교집합. 2026년에 빠르게 점유율을 가져가는 중이다.

6장 · Wiz — CNAPP 카테고리 리더

Wiz는 2020년 이스라엘에서 시작, agentless cloud scanning으로 빠르게 시장을 가져갔다. 2024년 valuation 12B+, 2025년 Google이 32B에 인수 발표(2026년 클로징 완료). CNAPP(Cloud Native Application Protection Platform) 카테고리의 사실상 표준.

핵심 컨셉: snapshot 기반 agentless. 클라우드 계정의 EBS/Disk 스냅샷을 클로닝해서 사이드 채널로 스캔. 에이전트 배포가 없어서 도입 마찰이 거의 없다 — IAM role 하나 주면 끝.

커버리지:

CSPM (cloud misconfig)
CWPP (workload — VM, container, serverless)
CIEM (identity — IAM 권한 그래프)
DSPM (data — S3/RDS 안의 PII 분류)
Vulnerability (image + OS)
Container/K8s
Wiz Code (2024 출시, SAST 영역)
NHI (Non-Human Identity) (2025-2026 강화 영역) — 서비스 계정, API 키, OIDC 페더레이션을 자산처럼 추적

강점:

Security Graph — 모든 자산/권한/취약점을 그래프 DB에 넣고 쿼리. "외부 인터넷에서 도달 가능 + critical CVE + admin IAM 권한"같은 multi-hop 쿼리.
Toxic combination — 단일 CVE가 아니라 "이 조합이 위험" 우선순위화. 이게 Wiz가 시장을 가져간 이유.
agentless 도입의 압도적 마찰 감소 — POC 1주, production 1개월.

약점:

가격 — enterprise 가격. 작은 회사가 쓸 만한 도구가 아니다.
runtime detection이 약하다 — agentless라서. 그래서 Wiz Runtime Sensor(에이전트)를 별도로 깐다(2024년 출시).
build/CI 단계 통합이 후순위 — Wiz는 cloud 쪽에서 시작했지 빌드 쪽이 강점이 아니다.
Google 인수 후 변화 — 2026년 현재 GCP 통합 가속 vs AWS/Azure 우선순위 우려가 동시에 있다.

언제 쓰나: 멀티 클라우드 enterprise. 포지셔닝의 핵심은 "우선순위화". 100개 critical CVE보다 "외부 노출 + critical + admin 권한" 3개를 보여주는 게 Wiz가 파는 값.

7장 · Orca Security — Agentless의 또 다른 선택지

Orca는 Wiz와 매우 비슷한 카테고리. 같은 SideScanning 컨셉을 먼저 상용화. 2021-2023년 Wiz와 정면 경쟁, 시장은 Wiz가 더 크게 가져갔지만 여전히 강력한 대안.

vs Wiz:

Orca가 먼저 시작했고 기술 깊이는 비슷.
Wiz는 sales motion과 attack-path 시각화에서 앞섰다.
Orca는 일부 enterprise에서 Wiz보다 가격이 유연하다고 알려져 있다.
둘 다 multi-cloud, 둘 다 CNAPP 풀스택.

언제 Orca를 고려하나: Wiz POC 대안, 가격 협상력, 또는 Wiz 인수 후 GCP 종속을 피하고 싶을 때.

8장 · Sysdig Secure / Falco — Runtime의 표준

Falco는 CNCF graduated 프로젝트, runtime 보안의 사실상 OSS 표준. Sysdig Secure는 Falco를 만든 회사의 상용 제품 — Falco를 production-ready로 감싼 SaaS.

컨셉: 커널 이벤트(syscall, eBPF)를 실시간으로 보고 룰에 매칭. "컨테이너 안에서 bash가 spawn됐다"같은 행동을 잡는다.

예시 룰 (Falco YAML).

- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point into a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
  output: >
    A shell was spawned in a container with an attached terminal
    (user=%user.name container=%container.name shell=%proc.name)
  priority: NOTICE

Falco 강점:

OSS, CNCF graduated — 거버넌스 안정.
eBPF + 커널 모듈 — 둘 다 지원, eBPF만 쓰면 모듈 빌드 부담이 없다.
K8s audit log 룰도 같이 — 클러스터 control-plane 이벤트도 같은 엔진에서.

Falco 약점:

튠이 필요하다 — out-of-box 룰셋은 noise가 많다. SRE가 룰을 조정해야 한다.
alert만, 응답은 별도 — Falcosidekick으로 알림은 보내지만 자동 격리는 별도 통합.
분석/시각화는 빈약 — log/메트릭 시스템에 넣어야 쓸 만하다.

Sysdig Secure(상용) 추가 값:

runtime forensics — 시점 캡처/리플레이.
룰 관리 UI + 추천 룰셋.
CNAPP 풀스택으로 확장 (image scan, cloud posture, IaC) — Wiz와 카테고리 경쟁.
compliance 리포트 (CIS, PCI, HIPAA).

언제 쓰나: runtime detection이 필수인 조직 (금융·헬스케어·정부). 또는 SOC가 컨테이너 클러스터의 실시간 이벤트를 봐야 할 때. OSS 스택이면 Falco 단독, 상용이면 Sysdig Secure.

9장 · Tetragon (Cilium / Isovalent) — eBPF Runtime의 도전자

Tetragon은 Cilium 만든 Isovalent(2024년 Cisco 인수)의 runtime 보안 도구. Falco의 eBPF-native 경쟁자. CNCF Sandbox(2024년 incubation 진행 중).

Falco vs Tetragon:

차원	Falco	Tetragon
모델	syscall 기반 룰 매칭	eBPF kernel filter + 정책 enforcement
응답	alert 위주	인라인 차단 가능 (kernel-level enforcement)
거버넌스	CNCF graduated	CNCF Sandbox
통합	독립	Cilium 생태계와 호환
학습 곡선	룰 YAML	TracingPolicy CRD (조금 더 깊은 eBPF 이해 필요)

Tetragon의 차별화: 단순 alert가 아니라 kernel-level enforcement — 특정 syscall이 일어나기 전에 차단할 수 있다. 예: 컨테이너 안에서 execve로 /bin/bash가 spawn되려 할 때 차단.

언제 Tetragon을 쓰나: 이미 Cilium 쓰는 클러스터, runtime enforcement(alert가 아니라 차단)가 필요한 곳, eBPF에 익숙한 팀. 2026년 채택은 Falco 대비 작지만 빠르게 늘고 있다.

10장 · JFrog Xray — Artifact 사이드

JFrog Xray는 JFrog Artifactory(아티팩트 저장소)의 보안 모듈. 저장된 모든 binary(컨테이너 이미지, jar, npm tarball 등)에 대해 CVE/라이선스를 영구적으로 추적.

차별점: 저장소 중심. 빌드/배포의 흐름이 아니라 "지금 우리 Artifactory에 있는 것들이 안전한가"에 답한다. 새 CVE가 공개되면 영향받는 모든 저장된 아티팩트가 retro-scan으로 표시.

언제 쓰나: 이미 JFrog Artifactory를 쓰는 조직. Trivy/Snyk와 겹치지만 "저장 시점"의 책임을 명확히 가져간다.

11장 · Sigstore (Cosign) + SLSA — 공급망의 골조

Sigstore는 OSS 공급망 서명 프로젝트(Linux Foundation). Cosign은 그 중 이미지 서명 도구.

# 키리스 서명 (OIDC 기반)
cosign sign --yes ghcr.io/myorg/myapp@sha256:abc...

# 검증
cosign verify --certificate-identity-regexp '.*@myorg.com$' \
  --certificate-oidc-issuer https://accounts.google.com \
  ghcr.io/myorg/myapp@sha256:abc...

핵심 컨셉:

키리스 서명 — OIDC로 신원 증명 → Fulcio가 단명 인증서 발급 → 서명 → Rekor(transparency log)에 기록. 키 보관 부담 없음.
재현 가능한 검증 — Rekor 로그가 공개 ledger처럼 동작.

SLSA(Supply-chain Levels for Software Artifacts): Google 주도, OpenSSF 호스팅. 빌드 시스템의 보증 수준을 1~4 레벨로 정의.

L1: 빌드가 스크립트로 정의됨.
L2: 빌드 서비스가 provenance를 생성.
L3: 빌드 환경이 격리되고 검증 가능.
L4: hermetic 빌드, 두 명의 reviewer.

2026년 현실: SLSA L3 도달하는 조직은 여전히 소수. 하지만 Cosign 서명 + GHA OIDC + Rekor 기록이 GitHub Actions 기반 팀의 표준이 되고 있다. 이게 SLSA L2 근방이다.

12장 · Wolfi / Chainguard — Distroless로 CVE를 없앤다

Chainguard는 2022년 시작, 2025년 Series D. 핵심 아이디어: 이미지에 들어가는 것을 줄이면 CVE도 줄어든다.

Wolfi — 보안 우선의 Linux distribution(Alpine 스타일이지만 glibc, "undistro").
Chainguard Images — Wolfi 기반의 최소 이미지(distroless). cgr.dev/chainguard/python, cgr.dev/chainguard/nginx 등.

예시: python:3.12 공식 이미지에 critical CVE가 12개 있다면, cgr.dev/chainguard/python:latest에는 0개에 가까운 게 흔하다(Chainguard가 daily rebuild + 빠른 패치).

강점: 공격 표면 자체를 줄인다. Trivy를 돌려서 CVE를 찾기보다, 처음부터 CVE가 없는 이미지로 시작한다.

약점:

enterprise 이미지는 유료(무료는 :latest 기본 라인업만).
디버깅이 불편 (distroless라 sh도 없다).
기존 이미지에서 마이그레이션 비용.

언제 쓰나: production 이미지 표준을 distroless로 잡고 싶을 때. 금융·정부·헬스케어처럼 CVE 제로에 가깝게 유지가 강제되는 곳.

13장 · 스캐너 vs 커버리지 매트릭스

도구의 자리를 한눈에 보는 표.

도구	Image	Code	OSS dep	IaC	Cloud posture	Runtime	NHI	DSPM	SBOM	OSS
Trivy	O	-	O	O	(partial)	-	-	-	O	yes
Grype + Syft	O	-	O	-	-	-	-	-	O	yes
Snyk	O	O	O	O	(Cloud add-on)	-	-	-	O	no
Aikido	O	O	O	O	O	-	(partial)	-	O	no
Wiz	O	O	O	O	O	(sensor)	O	O	-	no
Orca	O	O	O	O	O	-	O	O	-	no
Sysdig Secure	O	-	O	O	O	O	-	-	O	(Falco part)
Falco	-	-	-	-	-	O	-	-	-	yes
Tetragon	-	-	-	-	-	O	-	-	-	yes
JFrog Xray	O	-	O	-	-	-	-	-	O	no
Cosign	(sign)	-	-	-	-	-	-	-	(verify)	yes
Chainguard	(distro)	-	-	-	-	-	-	-	O	no

관찰: 하나의 도구가 모든 칸을 채우진 않는다. Wiz가 가장 가깝지만 빌드/CI 통합과 NHI가 100%는 아니다. OSS-only로 갈 때 빠지는 것: cloud posture, NHI, DSPM, 통합된 우선순위화.

14장 · CNAPP 카테고리 수렴 — CSPM + CWPP + CIEM + DSPM

2026년의 빅 픽처: CNAPP(Cloud Native Application Protection Platform). Gartner가 정의한 카테고리로, 다음을 통합:

CSPM (Cloud Security Posture Management) — 클라우드 misconfig.
CWPP (Cloud Workload Protection Platform) — VM/컨테이너/serverless 보호.
CIEM (Cloud Infrastructure Entitlement Management) — IAM 권한.
DSPM (Data Security Posture Management) — 데이터 위치·분류·접근.

2025-2026년에 Vulnerability Management까지 흡수. 그리고 NHI(Non-Human Identity) — 서비스 계정, API 키, OIDC 페더레이션을 사람 ID처럼 거버넌스 — 가 새 카테고리로 떠올랐다. Wiz가 이 영역에서 앞서있다.

왜 수렴하나: 보안팀이 7개 대시보드를 못 본다. 그리고 "도달 가능한 critical CVE + admin 권한 + 외부 노출"같은 toxic combination 우선순위화는 단일 graph 위에서만 가능하다. 도구가 분리되면 그 graph가 안 만들어진다.

반론: 거대 단일 플랫폼은 lock-in. 그래서 OSS 스택을 유지하면서 통합 UI만 사는 형태(Aikido 모델, 또는 자체 SOAR)도 늘고 있다.

15장 · Shift-Left vs Runtime — 끝나지 않는 논쟁

Shift-Left (빌드 시점에 잡자):

비용이 가장 싸다 — 개발자가 PR에서 고친다.
노이즈가 많다 — 모든 CVE가 실제 위험은 아니다.
도달 가능성·exploit 가능성 정보 부족.

Runtime (실제 도는 것만 보자):

신호가 진짜다 — 실제로 도는 컨테이너만.
그러나 늦다 — 이미 production.
agent 부담 + 성능 영향.

2026년 합의: 둘 다 해야 한다. 하지만 자원 배분이 다르다.

Shift-left는 "기본 위생". 모든 PR에서 critical은 막는다.
Runtime은 "도달 가능성 필터". critical 100개 중 실제로 production에서 로드되는 라이브러리 27개만 우선순위화.

이 두 신호를 묶어주는 게 CNAPP의 가장 큰 값 — eBPF runtime이 "이 패키지는 실제로 import됐다"를 알려주면, build-time CVE 리스트에서 그 27개만 critical로 표시한다. 나머지 73개는 critical이지만 우선순위 낮음. 이게 Wiz·Sysdig·Aikido가 2025-2026년에 다 같이 미는 방향.

16장 · AI-AppSec — Auto-Fix PR의 시대

2025-2026년의 새 카테고리: AI가 취약점을 찾고 PR로 패치까지 보낸다.

Aikido AI Auto-Fix — 발견된 CVE에 대해 의존성 업그레이드 PR을 자동 생성.
Snyk DeepCode AI — SAST 발견에 대해 코드 fix 제안.
GitHub Dependabot + Copilot Autofix (2024년 GA) — Dependabot이 의존성 PR, Copilot Autofix가 SAST 발견의 코드 패치.
Endor Labs — reachability analysis로 진짜 위험만, 그 위에 fix PR.

현실:

의존성 업그레이드는 자동화가 잘 된다 — 1-2 라인 변경.
코드 fix는 아직 누군가 review 한다 — SAST 발견은 컨텍스트가 많이 필요.
false positive 비율은 여전히 50% 근방 — 모든 자동 PR을 받지는 않는다.

가치: review 시간 단축. 50개 fix PR 중 30개는 즉시 머지, 20개는 사람이 본다.

17장 · 결정 프레임워크 — 우리 팀은 뭘 깔까

질문을 따라 답을 좁힌다.

Q1. 우리 팀 크기는?

5~20명 — OSS만으로 충분. Trivy + Falco + Cosign + Dependabot. 연 0달러.
20~100명 — Aikido 또는 Snyk + Trivy. 1개 SaaS + 1개 OSS. 연 1~5만 달러.
100명+ / enterprise — Wiz 또는 Orca + Sysdig + Snyk/Aikido. CNAPP + runtime + dev. 연 10만 달러+.

Q2. 어떤 카테고리가 우리에게 가장 큰 위험인가?

빌드/공급망 — Trivy + Cosign + Chainguard.
클라우드 misconfig — Wiz/Orca/Aikido CSPM.
runtime 침입 — Sysdig Secure 또는 Falco + SIEM.
권한 폭증(IAM *) — Wiz/Orca CIEM.

Q3. OSS-only로 어디까지 가나?

가능: Image scan, IaC, SBOM, 서명, runtime alert(Falco), 일부 CSPM(Prowler).
어렵다: graph 기반 우선순위화, NHI 거버넌스, DSPM, 통합 대시보드.
OSS만으로 SOC2/ISO 27001 통과 가능. 단 운영 부담은 사람으로 채운다.

Q4. 마케팅에 속지 않는 법:

"CNAPP" 라벨이 붙은 도구가 모두 같은 기능을 하지 않는다 — 매트릭스를 직접 그려라.
POC에서 자기 환경의 진짜 CVE 100개를 도구 3개에 던지고 노이즈/정확도를 비교한다.
가격은 개발자 수 / 자산 수 / 워크로드 수 등 단위마다 다르다 — 비교 시 정규화.
"AI 자동 fix"는 마케팅 자료의 demo와 우리 코드베이스의 실제 PR 머지율을 비교한다.

에필로그 — "스캔 결과를 누가 보는가"가 답이다

이 글의 한 문장 요약: 도구가 아니라 운영이 보안을 만든다.

2026년의 컨테이너 보안 도구는 차고 넘친다. Trivy 무료로 5분이면 셋업, Aikido 10분이면 cloud까지 연결, Wiz 1개월이면 enterprise 전체가 보인다. 문제는 그 결과를 매주 누가 보고, 무엇을 결정하는가 다. 도구를 깔아도 alert가 Slack 채널에 쌓이고 아무도 안 본다면 보안은 0이다.

좋은 컨테이너 보안 프로그램의 7가지:

단일 도구로 시작 — Trivy CI 게이트, critical만 막기.
runtime 한 줄 — Falco 또는 Tetragon, 채널 하나로 alert.
서명 + provenance — Cosign + Rekor, GHA OIDC 무료.
base image 표준 — Chainguard 또는 distroless. 새 이미지는 표준 외 거부.
분기당 한 번 후행 review — 도구가 놓친 게 뭔지 사람이 본다.
우선순위화 룰 — "도달 가능 + 외부 노출 + admin 권한" 같은 toxic combo만.
자동 PR + 사람 review — Dependabot/Aikido fix PR, 사람이 머지.

이 7개가 도구 무엇을 고르냐보다 중요하다. Wiz를 깔고도 이 7개가 없으면 잡지 못한다. Trivy 하나로도 이 7개가 있으면 95% 잡는다.

12개 항목 체크리스트

CI에 image scan이 붙어 있나 (critical 게이트)?
base image 표준이 있나 (distroless/Wolfi)?
IaC 스캔이 PR 단계에 있나?
SBOM이 빌드 산출물로 저장되나?
이미지 서명(Cosign)이 production에 강제되나?
runtime detection 도구가 클러스터에 있나 (Falco/Sysdig/Tetragon)?
cloud posture가 매일 스캔되나 (Prowler/Wiz/Aikido)?
외부 도달 가능 자산 인벤토리가 있나?
critical CVE alert를 매주 누가 보나?
IAM * 권한이 자동 검출되나?
시크릿 스캔이 git 푸시 단계에 있나?
SLSA L2 근방의 provenance가 있나 (GHA OIDC + Cosign + Rekor)?

안티패턴 10가지

Trivy 결과를 아무도 안 본다 — 스캔만 돈다.
모든 critical을 차단 — 노이즈에 묻혀 진짜 위험을 못 본다.
runtime 없이 빌드 스캔만 — 도달 가능성 정보가 없다.
CNAPP 도구 3개 동시 도입 — POC 진흙탕에 1년 빠진다.
SBOM은 생성하는데 검증 안 함 — 의식.
Cosign 서명은 하는데 검증 정책 없음 — 시그니처가 아무것도 막지 않는다.
base image를 매번 자유롭게 골라 씀 — distroless 표준 부재.
alert만 보고 우선순위화 없음 — 100개 critical에 마비.
shift-left에 모든 자원, runtime 0 — 빌드 통과한 후의 일을 못 본다.
상용 도구 깔면 OSS 다 버린다 — Trivy를 CI에서 빼는 순간 신호가 줄어든다.

다음 글 예고

다음 글 후보: Wiz Security Graph 깊게 파기 — toxic combination 우선순위화의 원리, Sigstore + GitHub Actions OIDC로 SLSA L2 만들기 실전, Falco vs Tetragon — 룰 작성과 운영의 실제 차이.

"도구가 보안을 만들지 않는다. 누가 매주 그 결과를 보고 무엇을 고치는가가 보안을 만든다."

— 컨테이너 & 클라우드네이티브 보안 2026, 끝.