Trivy v roce 2026: Kompletní průvodce skenováním zranitelností kontejnerů a IaC

Aktualizováno: 27. června 2026

Trivy je open-source bezpečnostní skener od Aqua Security, který v jednom binárním souboru detekuje CVE zranitelnosti, IaC misconfigurace, tajné klíče a generuje SBOM pro kontejnerové obrazy, souborové systémy, Git repozitáře a Kubernetes clustery. V roce 2026 jde o nejhvězdičkovanější open-source skener na GitHubu (přes 36 500 hvězd), který se stal de facto standardem pro skenování zranitelností v cloud-native ekosystému. Tento průvodce vychází z verze 0.70.0 vydané v dubnu 2026 a reflektuje poučení z incidentu v dodavatelském řetězci, který Trivy zasáhl v březnu 2026.

• Trivy 0.70+ skenuje kontejnerové obrazy, filesystémy, Git repozitáře, Kubernetes clustery, Terraform a CloudFormation pomocí jediného binárního souboru.
• Po incidentu v březnu 2026 (CVE-2026-33634) je nutné připnout GitHub Action na konkrétní commit SHA, nikoli na verzový tag.
• Trivy podporuje generování SBOM ve formátech CycloneDX 1.6 a SPDX 2.3 přímo z příkazové řádky.
• Pro air-gapped prostředí lze databázi zranitelností stáhnout offline pomocí trivy image --download-db-only a sdílet ji přes OCI registr.
• Integrace s GitHub Actions přes SARIF výstup umožňuje zobrazit nálezy přímo v záložce Security pull requestu.
• Distroless obrazy snižují počet detekovaných zranitelností až o 90 % oproti obrazům založeným na Debianu nebo Ubuntu.

Co je Trivy a proč ho používat v roce 2026

Trivy (čte se traj-vi) je univerzální bezpečnostní skener vyvíjený firmou Aqua Security na GitHubu pod licencí Apache 2.0. Na rozdíl od specializovaných nástrojů kombinuje pět různých typů kontrol v jednom binárním souboru bez závislostí: skenování CVE v OS balíčcích a v aplikačních knihovnách, detekci misconfigurací v infrastrukturním kódu, hledání tajných klíčů, kontrolu licenční shody a generování SBOM (Software Bill of Materials). V září 2025 do Trivy vstoupil i původně samostatný tfsec, takže všechna pravidla pro Terraform jsou dnes součástí trivy config.

Upřímně řečeno, ještě před dvěma lety jsem v CI měl tři různé skenery vedle sebe (Clair na obrazy, tfsec na Terraform, Gitleaks na tajné klíče) a každý měl jiný formát výstupu. Trivy mi v jednom průchodu dělá to samé a celá pipeline je o pět minut kratší.

Pro provozní týmy je hlavní výhodou rychlost a portabilita. Skener neběží jako démon, nevyžaduje server ani cloudovou registraci a celý vulnerability scan typického obrazu trvá pod 10 sekund po prvním stažení databáze. Trivy navíc udržuje vlastní databázi zranitelností (Aqua Trivy DB), která agreguje data z NVD, GitHub Security Advisories, Red Hat OVAL, Debian Security Tracker, Ubuntu CVE Tracker, Alpine SecDB a desítek dalších zdrojů. Databáze se rebuilduje každých 6 hodin a distribuuje jako OCI artefakt přes GitHub Container Registry, což usnadňuje mirroring v interních prostředích.

V roce 2026 nabízí Trivy několik funkcí, které ho odlišují od konkurence: filtrování zranitelností podle vztahu balíčků (--pkg-relationships) umožňuje skenovat pouze přímé závislosti, podpora pro --vex načítá VEX dokumenty pro potlačení známých falešných pozitiv a integrace s policy enginem Rego (OPA) dovoluje psát vlastní pravidla pro misconfigurace.

Instalace Trivy na Linux

Trivy je distribuován jako statický binární soubor pro Linux, macOS a Windows. Pro produkční použití doporučuji oficiální balíčky deb a rpm, protože automaticky řeší aktualizace přes systémový správce balíčků. Po incidentu v březnu 2026 byly podpisové klíče repozitáře rotovány, takže pokud máte Trivy nainstalovaný před dubnem 2026, musíte před spuštěním apt update nebo yum update znovu importovat nový GPG klíč.

Instalace na Debianu nebo Ubuntu vypadá takto:

# Import aktuálního GPG klíče (rotováno po incidentu)
sudo apt-get install -y wget gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key \
  | sudo gpg --dearmor -o /usr/share/keyrings/trivy.gpg

# Přidání repozitáře s explicitním klíčem
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] \
  https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" \
  | sudo tee /etc/apt/sources.list.d/trivy.list

sudo apt-get update
sudo apt-get install -y trivy

# Ověření verze (měla by být 0.70.0 nebo novější)
trivy --version

Pro Red Hat, AlmaLinux nebo Rocky Linux je proces analogický s dnf. V Kubernetes prostředí lze Trivy nasadit jako trivy-operator, který kontinuálně skenuje běžící workloady a publikuje výsledky jako CRD objekty VulnerabilityReport. Pro jednorázové skeny v CI/CD ale stačí stažení samostatného binárního souboru:

# Bezpečnější varianta: připnout konkrétní verzi a SHA-256
TRIVY_VERSION="0.70.0"
TRIVY_SHA256="3f4a8b...e91d"  # ověřit z release notes

curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz"
echo "${TRIVY_SHA256}  trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz" | sha256sum -c -
tar -xzf "trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz"
sudo install -m 0755 trivy /usr/local/bin/trivy

Jak skenovat kontejnerové obrazy pomocí Trivy

Základní příkaz pro skenování obrazu je trivy image <název:tag>. Při prvním spuštění si Trivy stáhne aktuální databázi zranitelností (zhruba 60 MB) a uloží ji do ~/.cache/trivy. Následující skeny už databázi pouze aktualizují inkrementálně, takže ten první sken je vždycky pomalejší.

# Základní sken obrazu z Docker Hubu
trivy image nginx:1.27.3

# Sken pouze kritických a vysokých CVE
trivy image --severity CRITICAL,HIGH nginx:1.27.3

# Ignorovat zranitelnosti bez dostupné opravy
trivy image --ignore-unfixed --severity CRITICAL,HIGH nginx:1.27.3

# Selhat build, pokud existuje alespoň jedna kritická CVE
trivy image --exit-code 1 --severity CRITICAL nginx:1.27.3

# JSON výstup pro další zpracování
trivy image --format json --output report.json nginx:1.27.3

# Sken konkrétního digestu (doporučeno pro produkci)
trivy image nginx@sha256:c628bf32e5...

Pro CI/CD pipeline je klíčový přepínač --exit-code v kombinaci se --severity. Doporučuji nasadit dva oddělené skeny: první s --exit-code 0 a formátem SARIF pro reportování všech nálezů do dashboardu a druhý s --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed, který skutečně rozbije build pouze na opravitelné kritické chyby. Bez příznaku --ignore-unfixed vás budou denně blokovat CVE, které ještě nemají patch a vy s nimi stejně nic neuděláte.

Pro detailní pohled na to, proč konkrétní balíček vykazuje zranitelnost, použijte --list-all-pkgs a v JSON výstupu se podívejte na pole PkgPath a DependsOn. To je nezbytné u Java aplikací, kde shaded JAR může obsahovat zranitelný transitivní log4j i přes to, že váš pom.xml ho explicitně neuvádí.

Skenování IaC misconfigurací (Terraform, Kubernetes, Helm)

Příkaz trivy config spouští skenování infrastrukturního kódu na předem definovaná pravidla. Po sloučení s tfsec v roce 2025 pokrývá Trivy přes 800 kontrol pro Terraform, CloudFormation, Kubernetes manifesty, Helm charty, Dockerfile, Ansible playbooky a ARM šablony. Pravidla jsou napsaná v jazyce Rego a lze je rozšířit o vlastní firemní policy.

# Sken aktuálního adresáře (auto-detekce typu souborů)
trivy config .

# Sken Terraform modulu s konkrétními severity
trivy config --severity HIGH,CRITICAL ./infrastructure/

# Sken Kubernetes manifestů a Helm chartů
trivy config --misconfig-scanners=kubernetes,helm ./k8s/

# Vlastní policy v Rego
trivy config --policy ./custom-policies/ --namespaces user ./terraform/

Typické nálezy v Kubernetes manifestech zahrnují absenci securityContext.runAsNonRoot, neomezené resource limits, použití hostNetwork: true nebo image taženého s tagem latest. Pro produkční prostředí kombinuji Trivy s admission controllerem jako Kyverno nebo Gatekeeper, který blokuje deployment manifestů selhávajících na stejných pravidlech. Více o runtime ochraně Kubernetes clusteru najdete v průvodci runtime bezpečností Linuxu s eBPF, Falco a Tetragonem.

Generování SBOM ve formátu CycloneDX a SPDX

SBOM (Software Bill of Materials) je strojově čitelný seznam všech komponent obrazu nebo aplikace. Od září 2025 vyžaduje americká vyhláška NIST SP 800-218 SBOM pro veškerý software dodávaný federální vládě, a podobné požadavky postupně zavádí EU Cyber Resilience Act. Trivy generuje SBOM ve dvou hlavních formátech:

# CycloneDX 1.6 (preferováno OWASP)
trivy image --format cyclonedx --output sbom.cdx.json myapp:1.2.3

# SPDX 2.3 (preferováno Linux Foundation)
trivy image --format spdx-json --output sbom.spdx.json myapp:1.2.3

# Sken SBOM (užitečné pro audit historických buildů)
trivy sbom sbom.cdx.json

# Atestace SBOM podepsaná pomocí Cosign
cosign attest --predicate sbom.cdx.json \
  --type cyclonedx myregistry.example.com/myapp:1.2.3

Hlavní výhodou generovaného SBOM je oddělení skenovací fáze od fáze hodnocení. Build pipeline jednou vygeneruje SBOM a uloží ho jako artefakt, security tým pak může opakovaně spouštět trivy sbom proti tomuto souboru s aktualizovanou databází zranitelností, aniž by musel celý obraz znovu pullovat a rozbalovat. Tento postup zkracuje denní audit historických buildů z hodin na minuty.

Detekce tajných klíčů v repozitáři

Trivy obsahuje předdefinovanou sadu přibližně 100 regex vzorů pro detekci tajných klíčů (AWS access keys, GitHub tokeny, Slack webhooky, soukromé SSH klíče, JWT tokeny i hesla v .env souborech). Skenování se spouští příkazem trivy fs --scanners secret:

# Sken pracovního adresáře na tajné klíče
trivy fs --scanners secret --severity HIGH,CRITICAL .

# Kombinace s vulnerability skenováním v jednom průchodu
trivy fs --scanners vuln,secret,misconfig .

# Vlastní pravidla v souboru trivy-secret.yaml
trivy fs --scanners secret --secret-config trivy-secret.yaml .

Pro efektivní pre-commit hook doporučuji nasadit Trivy přes pre-commit framework s ignore filem .trivyignore pro známá falešná pozitiva (např. testovací fixture s placeholderovým API klíčem). Detekce tajných klíčů v Trivy je vědomě méně agresivní než dedikované nástroje jako Gitleaks nebo TruffleHog — má vyšší přesnost za cenu nižšího recallu, což se pro CI/CD bránu osvědčuje lépe.

Integrace Trivy do GitHub Actions a GitLab CI

Oficiální GitHub Action aquasecurity/trivy-action je nejpoužívanější integrace, ale po incidentu v březnu 2026 vyžaduje opatrnost. Vždy připínejte action na konkrétní commit SHA, nikoli na verzový tag. Útočníci v březnu přesměrovali tagy v0.28.0 až v0.29.2 na škodlivé commity a všechny pipeline používající @master nebo plovoucí tagy stáhly trojanizovanou verzi.

# .github/workflows/trivy.yml
name: Trivy Container Scan
on:
  pull_request:
    branches: [main]

jobs:
  trivy-scan:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      security-events: write  # nutné pro upload SARIF
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Trivy vulnerability scan
        # Připnuto na commit SHA, NIKOLI na @master nebo @v0.28
        uses: aquasecurity/trivy-action@18f2510ee396bbf400402947b394f2dd8c87dbb0 # v0.29.0
        with:
          image-ref: 'myapp:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          ignore-unfixed: true
          exit-code: '1'

      - name: Upload SARIF to GitHub Security
        if: always()
        uses: github/codeql-action/upload-sarif@4e828ff8d448a8a6e532957b1811f387a63867e8 # v3.29.4
        with:
          sarif_file: 'trivy-results.sarif'

Pro GitLab CI je oficiálním řešením Container-Scanning.gitlab-ci.yml šablona, která Trivy spouští v rámci built-in security dashboardu. Při samostatném použití mimo template stačí Docker-in-Docker runner a několik řádek YAML. Hlubší pohled na zabezpečení samotných pipeline workflow najdete v průvodci zabezpečením GitHub Actions a CI/CD pipeline proti útokům na dodavatelský řetězec.

Offline režim a air-gapped prostředí

V regulovaných prostředích (banky, vládní instituce, kritická infrastruktura) je zakázáno tahat data z veřejného internetu do produkčních CI runnerů. Trivy je pro tento scénář dobře připravený. Databázi lze stáhnout na jednom stroji s přístupem k internetu, exportovat ji a distribuovat do air-gapped sítě přes interní OCI registr.

# Krok 1: Stažení DB na bastion hostu s přístupem k internetu
trivy image --download-db-only
trivy image --download-java-db-only

# Krok 2: Export DB jako OCI artefakt do interního registru
oras push registry.internal.corp/trivy-db:2 \
  ~/.cache/trivy/db/trivy.db:application/vnd.aquasec.trivy.db.layer.v1.tar+gzip

# Krok 3: Konfigurace klienta v air-gapped prostředí
export TRIVY_DB_REPOSITORY="registry.internal.corp/trivy-db"
export TRIVY_JAVA_DB_REPOSITORY="registry.internal.corp/trivy-java-db"

# Sken bez přístupu k veřejnému internetu
trivy image --skip-db-update myregistry.internal.corp/myapp:1.0.0

Pro plně offline provoz lze také použít --offline-scan, který zakáže veškeré externí volání včetně dotazu na Maven Central pro Java JAR scanning. V tomto režimu Trivy nedokáže rozpoznat shaded JAR knihovny, takže pro Java aplikace doporučuji nahrát i Trivy Java DB do interního registru.

Incident dodavatelského řetězce z března 2026

Mezi 19. a 23. březnem 2026 byl Trivy zasažen sofistikovaným útokem na dodavatelský řetězec evidovaným jako CVE-2026-33634 (CVSS 9.4). Útočník známý jako TeamPCP kompromitoval přístupové údaje jednoho z maintainerů a publikoval škodlivé verze 0.69.4, 0.69.5 a 0.69.6 na Docker Hub a na GitHub Releases. Současně byly přepsány tagy v repozitářích aquasecurity/trivy-action a aquasecurity/setup-trivy, takže každá pipeline používající plovoucí tagy stáhla trojanizovanou verzi.

Škodlivá funkce v binárce Trivy exfiltrovala obsah proměnných prostředí, ~/.aws/credentials, ~/.kube/config, ~/.ssh/id_* a Docker konfigurace na C2 server schovaný za CDN. Z části získaných NPM tokenů útočníci publikovali kompromitované verze 28 populárních NPM balíčků, které následně rozšířily self-propagující worm CanisterWorm. Detaily incidentu shrnuje oficiální analýza Docker Inc..

Praktické důsledky pro vaši pipeline:

• Připínejte vše na commit SHA. Tagy jsou v Gitu mutable a útočník s přístupem k repozitáři je může přepsat. SHA-1 commitu přepsat nelze.
• Ověřujte instalační skripty hashem. Stáhnout SHA256SUMS z release stránky, ověřit jeho podpis pomocí Sigstore cosign verify-blob a teprve pak spustit binárku.
• Izolujte CI tajné klíče. GitHub OIDC tokeny s krátkou platností místo dlouhožijících PAT, AWS IAM Roles for Service Accounts (IRSA) místo statických access keys, GitHub Actions permissions: bloky omezené na minimum.
• Monitorujte odchozí traffic z runnerů. Egress firewall pravidlo, které dovolí pouze whitelistované destinace (Docker Hub, váš registr, GitHub API), by celý exfiltrační kanál útoku zablokovalo.

Pokud používáte vlastní firewall pro omezení egress trafficu CI runnerů, projděte si kompletního průvodce konfigurací nftables pro moderní linuxový firewall.

Trivy vs Grype vs Snyk: kdy zvolit co

Třemi nejčastěji srovnávanými skenery na trhu jsou Trivy, Grype od Anchore a komerční Snyk. Každý cílí na trochu jiné publikum a v praxi se často kombinují — žádný skener nemá 100% pokrytí všech CVE databází.

Vlastnost	Trivy	Grype	Snyk
Licence	Apache 2.0 (open-source)	Apache 2.0 (open-source)	Komerční (omezený free tier)
Databáze zranitelností	Offline OCI artefakt	Offline (Grype DB)	Cloudová SnykVulnDB
Skórování rizika	CVSS + EPSS	CVSS + EPSS + CISA KEV	Kontextové dle reachability
IaC skenování	Ano (Terraform, K8s, Helm, ARM)	Ne	Omezeně
Detekce tajných klíčů	Ano	Ne	Ne
SBOM formáty	CycloneDX, SPDX	Přes Syft	Omezeně
IDE integrace	Ne	Ne	VS Code, IntelliJ
Air-gapped provoz	Ano	Ano	Ne (vyžaduje cloud)
Cena při škálování	Zdarma	Zdarma	Placené per repo

V mé praxi se osvědčila kombinace Trivy + Grype spouštěná paralelně v CI. Pokud obě nahlásí stejné CVE, je dost pravděpodobně reálné. Pokud nahlásí jen jedno, jde buď o falešné pozitivum, nebo o mezeru v databázi druhého (přesně to nás jednou potkalo u CVE v transitivní knihovně Go, kterou Trivy znal a Grype tehdy ne). Grype navíc přidává hodnocení podle CISA Known Exploited Vulnerabilities katalogu, což pomáhá prioritizovat patche podle skutečně zneužívaných zranitelností v divočině.

Snyk dává smysl tam, kde si organizace cení automatizovaných remediation PR a kontextového hodnocení reachability — Snyk umí detekovat, zda zranitelnou funkci v knihovně skutečně volá váš kód. Za to si ale účtuje a vyžaduje odesílání metadat do cloudu, což diskvalifikuje air-gapped prostředí.

Často kladené dotazy

Jak rychlý je Trivy ve srovnání s ostatními skenery?

Trivy 0.70 zvládne sken typického 200MB obrazu pod 8 sekund po stažení databáze. Grype je v čistém vulnerability skenování o 10–20 % rychlejší, ale Trivy nabízí více funkcí v jednom průchodu. Snyk je obvykle 2–4× pomalejší kvůli síťovým voláním na cloudovou databázi.

Je Trivy zdarma i pro komerční použití?

Ano. Trivy je distribuován pod licencí Apache 2.0, která dovoluje neomezené komerční použití, modifikaci i redistribuci. Aqua Security navíc nabízí placenou edici Aqua Trivy Premium s komerční podporou a rozšířenou databází, ale CLI nástroj zůstává plně open-source.

Jak často Trivy aktualizuje databázi zranitelností?

Hlavní databáze se rebuilduje každých 6 hodin a klient ji při výchozím nastavení stahuje 1× za 24 hodin (řízeno přepínačem --db-update-interval). Java DB pro shaded JAR scanning se aktualizuje denně. Pro produkční CI doporučuji explicitně připnout verzi DB pomocí proměnné TRIVY_DB_REPOSITORY na konkrétní digest.

Detekuje Trivy zero-day zranitelnosti?

Ne. Trivy jako každý SCA skener pracuje pouze se známými CVE z veřejných databází. Pro detekci neznámých zranitelností potřebujete dynamickou analýzu (DAST), fuzz testing nebo runtime ochranu typu eBPF-based detekce anomálního chování procesů.

Mohu Trivy použít pro skenování AWS, Azure nebo GCP účtů?

Ano, od verze 0.40 obsahuje Trivy příkaz trivy aws, který skenuje konfiguraci AWS účtu na misconfigurace (např. veřejné S3 buckety, IAM policy s wildcardem). Pro Azure a GCP existuje samostatný projekt Cloud Custodian nebo specializovaný Prowler. Pokrytí AWS v Trivy je v roce 2026 srovnatelné s ScoutSuite a Steampipe.