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

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

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

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개 다른 문제가 한 단어에 묶여 있다.

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

핵심: **하나의 도구가 모든 단계를 잡지 않는다.** 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 대비 ~40~60% 수준의 가격 포지션.

- **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 커버리지 매트릭스

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

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

| 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가지:

1. **단일 도구로 시작** — Trivy CI 게이트, critical만 막기.

2. **runtime 한 줄** — Falco 또는 Tetragon, 채널 하나로 alert.

3. **서명 + provenance** — Cosign + Rekor, GHA OIDC 무료.

4. **base image 표준** — Chainguard 또는 distroless. 새 이미지는 표준 외 거부.

5. **분기당 한 번 후행 review** — 도구가 놓친 게 뭔지 사람이 본다.

6. **우선순위화 룰** — "도달 가능 + 외부 노출 + admin 권한" 같은 toxic combo만.

7. **자동 PR + 사람 review** — Dependabot/Aikido fix PR, 사람이 머지.

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

12개 항목 체크리스트

1. CI에 image scan이 붙어 있나 (critical 게이트)?

2. base image 표준이 있나 (distroless/Wolfi)?

3. IaC 스캔이 PR 단계에 있나?

4. SBOM이 빌드 산출물로 저장되나?

5. 이미지 서명(Cosign)이 production에 강제되나?

6. runtime detection 도구가 클러스터에 있나 (Falco/Sysdig/Tetragon)?

7. cloud posture가 매일 스캔되나 (Prowler/Wiz/Aikido)?

8. 외부 도달 가능 자산 인벤토리가 있나?

9. critical CVE alert를 매주 누가 보나?

10. IAM `*` 권한이 자동 검출되나?

11. 시크릿 스캔이 git 푸시 단계에 있나?

12. SLSA L2 근방의 provenance가 있나 (GHA OIDC + Cosign + Rekor)?

안티패턴 10가지

1. **Trivy 결과를 아무도 안 본다** — 스캔만 돈다.

2. **모든 critical을 차단** — 노이즈에 묻혀 진짜 위험을 못 본다.

3. **runtime 없이 빌드 스캔만** — 도달 가능성 정보가 없다.

4. **CNAPP 도구 3개 동시 도입** — POC 진흙탕에 1년 빠진다.

5. **SBOM은 생성하는데 검증 안 함** — 의식.

6. **Cosign 서명은 하는데 검증 정책 없음** — 시그니처가 아무것도 막지 않는다.

7. **base image를 매번 자유롭게 골라 씀** — distroless 표준 부재.

8. **alert만 보고 우선순위화 없음** — 100개 critical에 마비.

9. **shift-left에 모든 자원, runtime 0** — 빌드 통과한 후의 일을 못 본다.

10. **상용 도구 깔면 OSS 다 버린다** — Trivy를 CI에서 빼는 순간 신호가 줄어든다.

다음 글 예고

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

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

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

참고 / References

- [Trivy — Aqua Security](https://trivy.dev/)

- [Trivy GitHub — aquasecurity/trivy](https://github.com/aquasecurity/trivy)

- [Trivy Documentation](https://aquasecurity.github.io/trivy/)

- [Grype — Anchore](https://github.com/anchore/grype)

- [Syft — SBOM generator](https://github.com/anchore/syft)

- [Snyk — Developer Security Platform](https://snyk.io/)

- [Snyk Open Source](https://snyk.io/product/open-source-security-management/)

- [Snyk Container](https://snyk.io/product/container-vulnerability-management/)

- [Aikido Security](https://www.aikido.dev/)

- [Aikido AI AutoFix announcement](https://www.aikido.dev/blog)

- [Wiz — Cloud Security Platform](https://www.wiz.io/)

- [Wiz Security Graph](https://www.wiz.io/platform/security-graph)

- [Google to acquire Wiz — 2024 announcement](https://blog.google/inside-google/company-announcements/google-announces-agreement-acquire-wiz/)

- [Orca Security](https://orca.security/)

- [Sysdig Secure](https://sysdig.com/products/secure/)

- [Falco — CNCF graduated](https://falco.org/)

- [Falco GitHub — falcosecurity/falco](https://github.com/falcosecurity/falco)

- [Tetragon — Isovalent/Cilium](https://tetragon.io/)

- [Tetragon GitHub — cilium/tetragon](https://github.com/cilium/tetragon)

- [JFrog Xray](https://jfrog.com/xray/)

- [Mend — formerly WhiteSource](https://www.mend.io/)

- [Sigstore](https://www.sigstore.dev/)

- [Cosign GitHub — sigstore/cosign](https://github.com/sigstore/cosign)

- [Rekor — transparency log](https://docs.sigstore.dev/logging/overview/)

- [SLSA — Supply-chain Levels for Software Artifacts](https://slsa.dev/)

- [Chainguard — secure base images](https://www.chainguard.dev/)

- [Wolfi — undistro Linux](https://github.com/wolfi-dev)

- [Prowler — OSS CSPM](https://github.com/prowler-cloud/prowler)

- [OSV.dev — Open Source Vulnerabilities](https://osv.dev/)

- [OpenSSF — Open Source Security Foundation](https://openssf.org/)

- [Gartner — CNAPP definition](https://www.gartner.com/en/information-technology/glossary/cloud-native-application-protection-platform-cnapp)

- [GitHub Copilot Autofix](https://github.blog/2024-03-20-found-means-fixed-introducing-code-scanning-autofix-powered-by-github-copilot-and-github-advanced-security/)

- [Endor Labs — reachability analysis](https://www.endorlabs.com/)

- [CNCF Landscape — Security & Compliance](https://landscape.cncf.io/category=security-compliance)