LabHub

블로그

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

2026-05-14 · 34 분 읽기 · #container-security#trivy#snyk#aikido#wiz#sysdig#cnapp#sigstore#sbom

한국어English日本語

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

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코드 시크릿, SASTSemgrep, GitleaksSnyk Code, Aikido
Dependency (OSS)라이브러리 CVETrivy, Grype, OSV-ScannerSnyk Open Source, Mend
Container Image이미지 레이어 CVETrivy, Grype, SyftSnyk Container, Aikido
IaC / K8s manifestmisconfigTrivy, Checkov, KyvernoSnyk IaC, Aikido
Artifact / Registry저장된 binary/SBOMOSV, Grype + HarborJFrog Xray, Aqua
Cloud Posture (CSPM)AWS/GCP/Azure 설정Prowler, ScoutSuiteWiz, Orca, Aikido
Workload (CWPP)클러스터 안 워크로드Falco, TetragonSysdig Secure, Wiz
Identity (CIEM)IAM 권한 분석(제한적)Wiz, Orca
Data (DSPM)데이터 위치/분류(제한적)Wiz, Orca, Cyera
Runtime detection실행 중 이상 행동Falco, TetragonSysdig 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는 매시간 업데이트.

스캔 가능 대상:

한 줄 사용법.

# 이미지 스캔
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

강점:

약점:

언제 쓰나: 거의 모든 팀의 첫 도구. 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와의 차이:

언제 Grype/Syft를 쓰나:

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

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

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

제품 라인:

강점:

약점/논쟁점:

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에서):

강점:

약점:

언제 쓰나: 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 하나 주면 끝.

커버리지:

강점:

약점:

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

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

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

vs Wiz:

언제 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 강점:

Falco 약점:

Sysdig Secure(상용) 추가 값:

언제 쓰나: 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:

차원FalcoTetragon
모델syscall 기반 룰 매칭eBPF kernel filter + 정책 enforcement
응답alert 위주인라인 차단 가능 (kernel-level enforcement)
거버넌스CNCF graduatedCNCF Sandbox
통합독립Cilium 생태계와 호환
학습 곡선룰 YAMLTracingPolicy 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...

핵심 컨셉:

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

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

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

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

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

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

약점:

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

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

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

도구ImageCodeOSS depIaCCloud postureRuntimeNHIDSPMSBOMOSS
TrivyO-OO(partial)---Oyes
Grype + SyftO-O-----Oyes
SnykOOOO(Cloud add-on)---Ono
AikidoOOOOO-(partial)-Ono
WizOOOOO(sensor)OO-no
OrcaOOOOO-OO-no
Sysdig SecureO-OOOO--O(Falco part)
Falco-----O---yes
Tetragon-----O---yes
JFrog XrayO-O-----Ono
Cosign(sign)-------(verify)yes
Chainguard(distro)-------Ono

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

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

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

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 (빌드 시점에 잡자):

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

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

이 두 신호를 묶어주는 게 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로 패치까지 보낸다.

현실:

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

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

질문을 따라 답을 좁힌다.

Q1. 우리 팀 크기는?

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

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

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

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

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

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

원문 보기: https://www.youngju.dev/blog/culture/2026-05-14-container-security-2026-trivy-snyk-aikido-wiz-sysdig-grype-comparison-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다