Trivy-guide: Skanna Containers efter CVE:er [2026]

Den 19 mars 2026 upptäckte Aqua Security att deras eget skanningsverktyg Trivy hade blivit vapen i en leveranskedjeattack. Enligt bolagets incidentrapport hade GitHub Actions-komponenterna trivy-action och setup-trivy manipulerats, och 76 av 77 versionstaggar i trivy-action tvingades om (force-pushades) till skadliga commits. En förfalskad binärutgåva, v0.69.4, cirkulerade också innan Aqua hann städa upp releaser från GitHub, Docker Hub, GHCR och ECR. Ironin är svår att missa: verktyget team använder för att lita på sina containerimages blev själv en attackyta. Det har vi också skrivit om i vår genomgång av TeamPCP-incidenterna, där just Trivy var ett av fem säkerhetsverktyg som komprometterades under loppet av tolv dagar.

Den här guiden lär dig använda Trivy på rätt sätt, inklusive hur du verifierar att binären själv går att lita på innan du bygger in den i en pipeline. Du får 14 konkreta steg: installation, binärverifiering, imageskanning, SBOM-generering i CycloneDX och SPDX, integration i GitHub Actions och GitLab CI, skydd av Kubernetes-kluster med trivy-operator, samt hantering av falska positiva och cachningsproblem. Målet är ett fungerande skyddsnät du kan koppla in från första commit till produktionsdrift, inte bara ett enstaka kommando du kör manuellt en gång i månaden.

Trivy sårbarhetsskanning har blivit standardvalet för många nordiska DevSecOps-team, delvis för att det är öppen källkod och delvis för att ett enda verktyg täcker images, filsystem, IaC-konfiguration och SBOM:er. Med NIS2 och Cyber Resilience Act som skärper kraven på spårbarhet i mjukvaruleveranskedjan räcker det inte längre att bara bygga och pusha en image. Du behöver kunna visa vad den innehåller, vilka kända sårbarheter som finns kvar och varför.

Guiden riktar sig till plattformsteam, DevOps-ingenjörer och säkerhetsansvariga som redan äger, eller håller på att bygga upp, en CI/CD-pipeline för containeriserade applikationer. Du behöver inte ha jobbat med sårbarhetsskanning tidigare för att följa stegen, men grundläggande erfarenhet av Docker, Git och antingen GitHub Actions eller GitLab CI gör resan betydligt smidigare. Har ni redan en etablerad pipeline utan skanningssteg är det här troligen den enskilt snabbaste förbättringen ni kan göra för att stänga en känd, ofta förbisedd risk.

Mars 2026-incidenten i detalj: vad som faktiskt hände

Innan du börjar bygga in Trivy i era pipelines är det värt att förstå exakt vad som gick fel i mars, eftersom hela guidens fokus på verifiering bygger på den händelsen. Enligt Aqua Securitys egen incidentrapport, publicerad på bolagets blogg, upptäcktes angreppet den 19 mars 2026 och pågick i ungefär tolv timmar innan det stoppades. Angriparna fick skrivåtkomst till repositorierna för trivy-action och setup-trivy, två komponenter som miljontals byggkörningar i GitHub Actions förlitar sig på för att hämta och köra Trivy automatiskt.

Det som gjorde incidenten allvarlig var inte bara att skadlig kod publicerades, utan hur den publicerades. Genom att force-pusha nya commits till redan existerande versionstaggar fick angriparna byggjobb som redan pekade mot en “säker”, tidigare granskad tagg att i praktiken hämta helt ny, oreviderad kod nästa gång jobbet kördes. Det är precis den typen av tyst substitution som gör pinning till en tagg som @v1 otillräckligt, eftersom taggen i sig kan flyttas utan att någon kod i ert eget repository ändras. En parallell, förfalskad binärutgåva av själva Trivy, märkt v0.69.4, cirkulerade också en kort period innan den upptäcktes och togs bort från GitHub Releases, Docker Hub, GHCR och Amazon ECR. Aqua Securitys efterföljande råd, som vi refererar genomgående i den här guiden, pekar ut v0.69.2 och v0.69.3 som de senaste binärversionerna som var opåverkade, samt v0.35.0 av trivy-action och v0.2.6 av setup-trivy som återskapade, säkra versioner.

Vad är Trivy och varför är verktyget centralt just nu

Trivy är en öppen källkods-skanner från Aqua Security som täcker fyra huvudsakliga användningsområden i ett och samma kommandoradsverktyg: sårbarhetsskanning av containerimages och paket, upptäckt av felkonfigurationer i IaC-filer som Terraform och Kubernetes-manifest, generering och konsumtion av mjukvarulistor (SBOM:er) i CycloneDX- och SPDX-format, samt granskning av hemliga nycklar som råkat hamna i kod eller images. Projektet är öppen källkod och ligger på GitHub under aquasecurity-organisationen, med fullständig dokumentation tillgänglig på trivy.dev. Den senaste utgåvan som synts i projektets release-historik är v0.71.2, daterad 19 juni 2026, med en huvudlinje v0.71.0 som släpptes redan 1 juni samma år. Det visar att projektet fortsatt att leverera uppdateringar aktivt även efter marskompromissen.

Arkitekturen bakom Trivy är enklare än den kan verka från utsidan. Verktyget laddar ner en lokal kopia av sin sårbarhetsdatabas, som byggs från flera uppströmskällor som distributionernas egna säkerhetsflöden och NVD, och matchar sedan paketen i det du skannar mot den databasen offline. Det gör att själva analysen går snabbt när databasen väl finns lokalt cachad, och att ni inte behöver skicka känslig information om er kodbas eller era images till en extern tjänst för att få ett resultat.

Det som gör Trivy relevant för en svensk och nordisk publik just nu är kombinationen av två saker. För det första används verktyget redan brett i CI/CD-pipelines hos DevSecOps-team i regionen, eftersom det är gratis, snabbt att komma igång med och stödjer de vanligaste registren och orkestreringsplattformarna. För det andra visade händelsen i mars 2026 att det inte räcker att bara installera ett skanningsverktyg. Du måste också kunna verifiera att verktyget självt inte har manipulerats, särskilt när det körs med skrivbehörighet i en byggpipeline. Den lärdomen gäller inte bara Trivy utan hela kategorin av säkerhetsverktyg som får långtgående åtkomst i CI/CD. Läs mer om det bredare sammanhanget i vår översikt av säkerhet online.

Trivy jämfört med Grype och Docker Scout

Innan du investerar tid i att bygga ut en hel pipeline kring ett verktyg är det värt att förstå var det passar bäst. Tre alternativ dominerar diskussionen om öppen källkods- och Docker-native skanning: Trivy, Grype och Docker Scout. De löser delvis samma problem men med olika fokus, och valet påverkar hur mycket extra tooling du behöver lägga till senare.

Verktyg	Huvudstyrka	Passar bäst för	Praktisk skillnad
Trivy	Bred täckning: sårbarheter, felkonfiguration och SBOM i samma verktyg	Team som vill ha ett verktyg för images, filsystem, IaC och SBOM samtidigt	Standardvalet när du vill slippa flera separata skannrar i pipelinen
Grype	Fokuserad sårbarhetsmatchning mot images och SBOM:er	Team som redan har egen tooling och vill ha en smalare, DIY-vänlig skanner	Gör en sak (sårbarhetsmatchning) men gör den utan extra funktioner runt omkring
Docker Scout	Inbyggd integration i Dockers eget ekosystem	Team vars bygg- och driftflöde redan är centrerat kring Docker Desktop och Docker Hub	Kommersiellt SaaS-alternativ med tätast koppling till Docker-verktygen

Ett sätt att sammanfatta valet: Trivy är det mångsidiga öppen källkods-alternativet, Grype är den smalare DIY-skannern, och Docker Scout är det Docker-integrerade kommersiella spåret. Resten av den här guiden fokuserar på Trivy eftersom det är verktyget flest team i regionen redan har eller överväger, men grundprinciperna för verifiering, filtrering och CI/CD-integration går att återanvända oavsett vilket verktyg du landar i.

Det finns inget som hindrar er från att köra flera skannrar parallellt under en övergångsperiod, till exempel för att jämföra träffbild innan ni bestämmer er för ett primärt verktyg. I praktiken landar de flesta team ändå i ett huvudverktyg för de dagliga CI/CD-grindarna, av det enkla skälet att för många parallella rapporter med olika format och olika severity-bedömningar snabbt blir svårare att agera på än ett enda, väl underhållet verktyg. Välj hellre ett verktyg ni faktiskt hinner underhålla och verifiera ordentligt, än tre verktyg som alla halvhalvt bevakas.

Förkunskaper och verktyg du behöver

Guiden förutsätter att du redan bygger containerimages regelbundet och har grundläggande vana vid terminalen. Du behöver inte vara expert på sårbarhetshantering, men det hjälper om du känner till skillnaden mellan en imagetagg och en digest, eftersom flera kommandon nedan refererar till bådadera.

Trivy v0.69.3 eller senare (installeras i steg 1, se avsnittet om säkra versioner)
Docker Engine eller Podman för att bygga images lokalt
Ett GitHub- eller GitLab-konto om du vill följa CI/CD-delen
kubectl konfigurerat mot ett test-Kubernetes-kluster om du vill följa operatordelen
cosign installerat om du vill verifiera binärens Sigstore-signatur (valfritt men rekommenderat)
Grundläggande förståelse för YAML, eftersom både GitHub Actions och GitLab CI konfigureras i det formatet

Verktyg	Version i denna guide	Status
Trivy (binär)	v0.69.2 / v0.69.3	Bekräftat säkra efter marskompromissen 2026
trivy-action (GitHub)	v0.35.0	Säker version efter incidenten
setup-trivy (GitHub)	v0.2.6	Återskapad säker version, commit 3fb12ec
Trivy senaste release	v0.71.2	19 juni 2026
cosign	v3.0.x eller senare	Används för att verifiera Trivy-binären

Steg 1–2: Installera Trivy och verifiera binären

Det enklaste sättet att installera Trivy på macOS och Linux är via Homebrew, som är den officiellt dokumenterade metoden för båda plattformarna.

# macOS och Linux via Homebrew
brew install trivy

# Debian/Ubuntu via Aquas APT-repo
sudo apt-get install wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/trivy.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] \
https://aquasecurity.github.io/trivy-repo/deb generic main" \
  | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

# Kontrollera installerad version
trivy --version

Givet marskompromissen 2026 bör du inte stanna vid att installera senaste “latest”-tagg utan att tänka efter. Ladda i stället ner en specifik, bekräftat säker version och verifiera dess Sigstore-signatur med cosign innan du litar på binären i en produktionspipeline. Samma princip beskriver vi mer utförligt i vår guide till att signera containerimages med cosign, men här är kommandona anpassade för att verifiera själva Trivy-binären.

# Ladda ner binär och Sigstore-bunt för en bekräftat säker version
curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v0.69.2/trivy_0.69.2_Linux-64bit.tar.gz"
curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v0.69.2/trivy_0.69.2_Linux-64bit.tar.gz.sigstore.json"

# Verifiera signaturen mot Trivys officiella GitHub-identitet
cosign verify-blob \
  --certificate-identity-regexp 'https://github\.com/aquasecurity/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  --bundle trivy_0.69.2_Linux-64bit.tar.gz.sigstore.json \
  trivy_0.69.2_Linux-64bit.tar.gz
# Förväntat svar: "Verified OK"

Om verifieringen misslyckas, avbryt installationen och undersök varför innan du går vidare. Ett brutet verifieringssteg är inte något du ska ignorera eller kringgå med en flagga, det är precis det steget som var tänkt att fånga nästa version av mars 2026-incidenten.

Steg 3–4: Skanna din första containerimage

Med Trivy installerat och verifierat är det dags att köra din första skanning. Grundkommandot är trivy image följt av namnet på imagen du vill granska. Utan flaggor listar Trivy alla kända sårbarheter oavsett allvarlighetsgrad, vilket ofta blir en lång och svårnavigerad lista.

# Enkel skanning, alla allvarlighetsgrader
trivy image nginx:1.25

# Filtrera till bara det som faktiskt spelar roll i praktiken:
# höga och kritiska sårbarheter, exklusive sådana som saknar patch
trivy image \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  nginx:1.25

Flaggan --ignore-unfixed är ett av de viktigaste verktygen för att hålla rapporterna hanterbara. Den döljer sårbarheter som ännu inte har någon tillgänglig patch, vilket i annat fall ofta dränker de faktiskt åtgärdbara fynden i brus. Kombinerat med --exit-code 1 kan du få Trivy att avsluta med felkod när något matchande hittas, vilket är precis det beteende du vill ha i en CI/CD-gate.

Ett typiskt tabellutdata från kommandot ovan ser ut ungefär så här:

nginx:1.25 (debian 12.5)
==========================
Total: 3 (HIGH: 2, CRITICAL: 1)

┌────────────┬────────────────┬──────────┬────────┬───────────────┬───────────────┐
│  Library   │ Vulnerability  │ Severity │ Status │ Installed Ver │  Fixed Ver    │
├────────────┼────────────────┼──────────┼────────┼───────────────┼───────────────┤
│ libssl3    │ CVE-2026-XXXXX │ CRITICAL │ fixed  │ 3.0.13-1      │ 3.0.15-1      │
│ zlib1g     │ CVE-2026-YYYYY │ HIGH     │ fixed  │ 1.3-1         │ 1.3.1-1       │
│ libc-bin   │ CVE-2026-ZZZZZ │ HIGH     │ fixed  │ 2.36-9        │ 2.36-11       │
└────────────┴────────────────┴──────────┴────────┴───────────────┴───────────────┘

Lägg märke till kolumnen “Status”. Den skiljer mellan sårbarheter som redan har en fixad version (fixed) och sådana som saknar patch (affected/will_not_fix), vilket är precis det --ignore-unfixed filtrerar bort. För maskinläsbar bearbetning, byt ut tabellformatet mot JSON eller SARIF med flaggan --format, till exempel --format json --output resultat.json.

Steg 5: Skanna filsystem och IaC-konfiguration

Sårbarheter i containerimages är bara halva bilden. Trivy kan också granska ett filsystem direkt, till exempel din källkodskatalog innan den ens har byggts till en image, samt IaC-filer som Terraform-moduler och Kubernetes-manifest för felkonfigurationer.

# Skanna en lokal katalog (källkod, beroenden, Dockerfiles)
trivy fs --severity HIGH,CRITICAL ./mitt-projekt

# Skanna IaC-konfiguration efter felkonfigurationer
trivy config --severity HIGH,CRITICAL ./infrastruktur

trivy fs är särskilt användbart tidigt i utvecklingsflödet, till exempel som en lokal pre-commit-kontroll, eftersom det låter dig fånga sårbara beroenden innan de ens hamnar i en byggd image. trivy config kompletterar detta genom att leta efter vanliga misstag i infrastrukturdefinitioner, som containrar som körs som root, saknade resursgränser eller öppna säkerhetsgrupper, utan att du behöver bygga eller köra något alls.

En vanlig missuppfattning är att trivy config bara handlar om Kubernetes-manifest. I praktiken täcker skannern flera IaC-format samtidigt, inklusive Terraform, CloudFormation, Dockerfiles och Helm-charts, och känner igen filtypen automatiskt utifrån innehåll och filändelse. Det gör det möjligt att peka verktyget mot ett helt infrastrukturrepository och få en samlad rapport, i stället för att behöva köra separata verktyg för varje IaC-ramverk teamet råkar använda. För team som redan standardiserat kring Terraform är detta ofta det snabbaste sättet att få en baslinje av vad som behöver åtgärdas innan nästa granskning.

Steg 6–7: Generera en SBOM i CycloneDX och SPDX

En mjukvarulista, SBOM, är en maskinläsbar inventering av allt en image eller ett projekt innehåller: paket, bibliotek, versioner och licenser. Trivy stödjer båda de dominerande formaten, CycloneDX och SPDX, och kan generera dem från images, filsystem, repositorier och VM-avbilder. Det är precis den här typen av spårbarhet EU:s regelverk kring leveranskedjesäkerhet efterfrågar, ett ämne vi går igenom mer i detalj i vår guide till SBOM och leveranskedjesäkerhet.

# CycloneDX-format (JSON), från en image
trivy image --format cyclonedx --output sbom.cdx.json alpine:3.16

# CycloneDX från ett lokalt filsystem
trivy fs --format cyclonedx --output sbom.cdx.json ./mitt-projekt

# SPDX tag-value
trivy image --format spdx --output sbom.spdx alpine:3.16

# SPDX i JSON-format
trivy image --format spdx-json --output sbom.spdx.json alpine:3.16

Vilket format du väljer beror ofta på vilka verktyg som ska konsumera SBOM:en i nästa led. CycloneDX, som underhålls av OWASP-projektet CycloneDX, har starkt stöd i säkerhetsverktyg och används flitigt tillsammans med signering och attestering. SPDX, standardiserat via Linux Foundation-projektet SPDX, har i stället lång historik inom licensefterlevnad och är det format flera myndighetskrav explicit hänvisar till. Många team genererar helt enkelt båda och lagrar dem tillsammans med imagen i registret.

Ett utdrag ur en CycloneDX-fil ger en känsla för hur strukturerad datan blir jämfört med en fritextrapport. Varje komponent listas med namn, version, typ och en unik identifierare (purl), vilket gör filen läsbar för både människor och verktyg nedströms.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.15",
      "purl": "pkg:deb/debian/[email protected]?arch=amd64"
    },
    {
      "type": "library",
      "name": "zlib1g",
      "version": "1.3.1-1",
      "purl": "pkg:deb/debian/[email protected]?arch=amd64"
    }
  ]
}

Steg 8: Skanna en befintlig SBOM för sårbarheter

Trivy kan även gå åt andra hållet: ta en redan genererad SBOM-fil som indata och matcha innehållet mot sin sårbarhetsdatabas, utan att behöva komma åt själva imagen eller källkoden igen.

# Läs in en SPDX-fil och sårbarhetsskanna innehållet
trivy sbom sbom.spdx.json --severity HIGH,CRITICAL

Det här mönstret är särskilt värdefullt när en leverantör skickar dig en SBOM för en komponent du inte själv har byggt. Du kan då köra en oberoende sårbarhetskontroll mot leverantörens egen inventering, utan att behöva lita blint på deras påstående om att komponenten är säker.

Steg 9–10: Automatisera skanning i GitHub Actions och GitLab CI

Manuell skanning fångar inte mycket i praktiken. Värdet kommer av att köra Trivy vid varje bygge, med ett resultat som antingen blockerar eller flaggar innan koden når produktion. I GitHub Actions används den officiella actionen aquasecurity/trivy-action. Efter marskompromissen 2026 är det viktigt att peka på en bekräftat säker version, v0.35.0, och helst pinna referensen till en commit-SHA snarare än en flyttbar tagg som @v1. Aqua Securitys egen incidentblogg beskriver stegen för sanering mer i detalj för team som behöver granska historiska körningar.

name: Container CI med Trivy

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout kod
        uses: actions/checkout@v4

      - name: Bygg Docker-image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: false
          tags: mitt-team/webbapp:${{ github.sha }}

      - name: Skanna image med Trivy
        uses: aquasecurity/[email protected]
        with:
          image-ref: 'mitt-team/webbapp:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy.sarif'
          ignore-unfixed: true
          vuln-type: 'os,library'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'

      - name: Ladda upp resultat till GitHub Code Scanning
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy.sarif

I GitLab CI kan du antingen använda GitLabs inbyggda mall för container scanning med Trivy som motor, eller köra Trivy explicit i ett eget jobb med Docker-in-Docker. Det senare ger dig full kontroll över flaggor och format.

stages:
  - scan

trivy_scan:
  stage: scan
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_DRIVER: overlay2
  script:
    - docker build -t mitt-team/webbapp:latest .
    - docker run --rm \
        -v /var/run/docker.sock:/var/run/docker.sock \
        -v $(pwd):/root \
        aquasec/trivy:0.69.2 image mitt-team/webbapp:latest \
        --severity HIGH,CRITICAL \
        --ignore-unfixed \
        --exit-code 1
  allow_failure: false

Oavsett vilken plattform du väljer, undvik att uppdatera sårbarhetsdatabasen i varje enskild byggkörning. Sätt i stället upp ett separat, schemalagt jobb som laddar ner databasen till en delad cache, och låt de vanliga byggjobben återanvända den med miljövariabeln TRIVY_SKIP_DB_UPDATE=true. Det minskar både byggtid och belastningen mot GHCR, vilket vi återkommer till i felsökningsavsnittet.

Steg 11–12: Skydda Kubernetes-kluster med trivy-operator

CI/CD-skanning fångar det som passerar pipelinen, men fångar inte images som redan körs i klustret eller som deployas utanför den vanliga vägen. Det är där trivy-operator kommer in. Operatorn kör periodiska skanningar av befintliga arbetsbelastningar, som standard var femte minut, mot namnrymder märkta trivy-scan=true.

# Märk en namnrymd för periodisk skanning
kubectl label namespace produktion trivy-scan=true

# Märk en namnrymd för att blockera osäkra images vid deploy
kubectl label namespace produktion trivy-operator-validation=true

Utöver de periodiska skanningarna innehåller operatorn en admission controller implementerad som en ValidatingWebhook. När ett nytt pod-objekt skapas i en namnrymd märkt trivy-operator-validation=true skickar Kubernetes en admission-förfrågan, operatorn kontrollerar imagen med Trivy, och kan blockera podden om den innehåller sårbarheter över din tröskel. Kombinationen ger dig både kontinuerlig övervakning av det som redan körs och ett grindsteg för allt nytt som deployas, vilket kompletterar den hårdare klusterkonfiguration vi går igenom i vår guide till att härda Kubernetes-kluster och de allmänna säkerhetsprinciper Kubernetes-projektet själv dokumenterar i sin egen säkerhetsöversikt.

Steg 13–14: Hantera falska positiva och cache/rate limiting

När Trivy väl är på plats överallt kommer nästa problem naturligt: brus. Inte alla sårbarheter som Trivy hittar är relevanta för din specifika användning, och vissa CVE:er kan du medvetet ha bedömt som acceptabel risk. För det finns filen .trivyignore, som placeras i skanningens rotkatalog och listar CVE-ID:n som ska hoppas över.

# .trivyignore
# Bekräftat ej exploaterbar i vår kontext, se ärende SEC-482
CVE-2026-11111

# Patch väntas från uppströms, accepterad risk till 2026-10-01
CVE-2026-22222

Kommentera alltid varför en CVE ignoreras, inklusive ett ärendenummer eller ett förfallodatum om möjligt. En tom .trivyignore-lista utan motivering blir snabbt en svart låda som ingen vågar röra, och som växer okontrollerat över tid. Gör det till en rutin att gå igenom filen vid varje kvartalsskifte, ta bort poster där patchen faktiskt har kommit, och flagga poster som passerat sitt uppföljningsdatum för ny bedömning i stället för automatisk förlängning.

Det andra vanliga problemet är hastighetsbegränsning när Trivy laddar ner sin sårbarhetsdatabas från GHCR. Om många CI-jobb kör parallellt och var och en försöker hämta databasen samtidigt riskerar ni att slå i GHCR:s gräns för anonyma anrop, vilket ger felet TOOMANYREQUESTS. Lösningen är att sätta upp en pull-through-cache eller registerspegel internt, dela en gemensam databascache mellan byggagenter, och schemalägga uppdateringar separat i stället för att låta varje enskilt jobb uppdatera på egen hand.

Bygg ett komplett skyddsnät: från commit till produktion

Satt ihop bildar de 14 stegen ovan ett sammanhängande flöde snarare än fristående kommandon. En utvecklare kör trivy fs lokalt eller i en pre-commit-hook för snabb feedback. Byggpipelinen kör trivy image med --exit-code 1 som en hård grind innan imagen pushas till registret, och genererar samtidigt en SBOM i CycloneDX som lagras tillsammans med imagen. I klustret övervakar trivy-operator kontinuerligt det som redan körs och blockerar nya deployer som inte klarar tröskeln. Kompletterat med molnkonfigurationsgranskning, till exempel med öppen källkods-verktyget Prowler som vi beskriver i vår guide till molnsäkerhet med Prowler, täcker du både applikationslagret och infrastrukturlagret med samma öppna källkods-filosofi.

Det viktigaste att ta med sig är att ingen enskild kontroll räcker ensam. En bra pipeline fångar sårbara beroenden tidigt hos utvecklaren, blockerar kritiska fynd vid bygge, dokumenterar innehållet via SBOM, och fortsätter övervaka efter deploy. Det är den kombinationen, inte ett enda kommando, som faktiskt minskar risken.

Tänk på ordningen som ett antal grindar snarare än en enda mur. Om ett grindsteg missas, till exempel för att en utvecklare pushar direkt utan att gå via pipelinen, ska nästa grindsteg ändå fånga problemet. Det är därför den löpande klusterskanningen i trivy-operator är minst lika viktig som CI/CD-grinden, trots att den kommer sist i flödet. Ett team som bara litar på byggpipelinen har inget skydd mot images som deployas manuellt, via ett äldre skript eller via ett nödläge där normala rutiner medvetet kringgås.

Så påverkar NIS2 och Cyber Resilience Act era skanningskrav

För organisationer i Sverige och övriga Norden som redan hanterar krav enligt NIS2 räcker det inte längre att bara kunna visa att en applikation fungerar. Ni behöver också kunna visa vad den innehåller och att kända sårbarheter hanteras systematiskt, inte ad hoc när någon råkar upptäcka ett problem. Cyber Resilience Act lägger till ytterligare krav specifikt riktade mot tillverkare av produkter med digitala element, där dokumenterad sårbarhetshantering och möjligheten att leverera en SBOM på begäran blir en del av kraven snarare än en frivillig extra insats.

Trivy löser inte regelefterlevnad åt er, men det ger de tekniska byggstenarna regelverken förutsätter finns på plats: en löpande, dokumenterad process för att identifiera sårbarheter, en maskinläsbar mjukvarulista per release, och ett spårbart beslut för varje sårbarhet som medvetet lämnas oåtgärdad via .trivyignore. Det sistnämnda är värt att ta på allvar. En revisor eller tillsynsmyndighet som frågar “varför kördes den här kända sårbarheten ändå i produktion” förväntar sig ett dokumenterat svar, inte en axelryckning. Bygg därför in vanan att varje undantag i skanningen ska ha en motivering och ett datum för omprövning redan från start, snarare än att lägga till det i efterhand när något går fel.

Fem vanliga fallgropar när du inför Trivy

Att lita blint på “latest”. Att peka mot senaste taggen av Trivy, trivy-action eller setup-trivy utan verifiering är precis det beteende som gjorde marskompromissen 2026 så spridd. Pinna alltid till en specifik, verifierad version.
Att köra utan --ignore-unfixed i CI. Utan flaggan dränks teamet i sårbarheter som ändå inte går att åtgärda ännu, vilket snabbt leder till att ingen längre läser rapporterna.
Att låta varje byggjobb uppdatera sårbarhetsdatabasen separat. Det slår i GHCR:s hastighetsgräns och gör pipelinen både långsammare och skörare.
Att ignorera CVE:er utan dokumentation. En .trivyignore-fil utan kommentarer om varför blir obegriplig redan efter några månader.
Att bara skanna vid bygge, aldrig efter deploy. Nya sårbarheter i redan körande images upptäcks bara om ni har en löpande kontroll, som trivy-operator, inte bara en engångskontroll vid push.

Felsökning: åtta vanliga problem och lösningar

De flesta problem som dyker upp efter att Trivy väl är i drift handlar antingen om nätverk och cachning, om hur resultat tolkas fel, eller om att policyn i klustret är för strikt eller för slapp jämfört med vad teamet faktiskt avsåg. Listan nedan täcker de åtta vanligaste situationerna support-team och plattformsägare stöter på, i ungefär den ordning de brukar dyka upp under en utrullning.

TOOMANYREQUESTS mot GHCR. Sätt upp en pull-through-cache eller registerspegel och uppdatera databasen i ett separat schemalagt jobb i stället för i varje körning.
Skanningen hänger sig eller ger cachefel. Trivys felsökningsdokumentation pekar på att en tidigare process kan ha lämnat filsystemcachen låst. Kontrollera om en Trivy-serverprocess fortfarande kör och håller ett lås på cachekatalogen, avsluta den, och rensa cachekatalogen om felet kvarstår.
Få eller inga träffar i en distroless-image. Distroless-images saknar den pakethanterardata Trivy normalt läser för OS-nivåns sårbarheter. Komplettera med SBOM-baserad skanning av byggartefakterna eller kör mot rootfs för att fånga applikationsbibliotek.
Fel arkitektur skannas i en multi-arch-image. Se till att byggagenten hämtar samma plattform som produktion faktiskt kör, till exempel genom att ange plattform explicit med docker buildx innan skanning.
SARIF-uppladdning till GitHub misslyckas. Kontrollera att jobbet har rätt behörigheter (security-events: write) och att SARIF-filen faktiskt skapades innan uppladdningssteget körs, gärna med if: always() så att felrapporten laddas upp även vid ett misslyckat skanningssteg.
Verifieringen av binären misslyckas med cosign. Dubbelkolla att du laddat ner rätt Sigstore-bunt för exakt den versionen du testar, och att --certificate-identity-regexp matchar Aquas faktiska GitHub-organisation. Ett fel här ska aldrig kringgås.
Admission-webhooken i trivy-operator blockerar allt, även godkända images. Kontrollera att namnrymden faktiskt är märkt korrekt och att tröskeln för allvarlighetsgrad inte är satt strängare än ni avsett, till exempel av misstag satt till LOW i stället för HIGH.
Skillnad mellan Trivys severity och leverantörens egen klassning. Trivy hämtar allvarlighetsgrad från flera källor, och faller tillbaka på CVSS-baserad mappning eller NVD när en leverantör saknar egen klassning. Det förklarar varför samma CVE ibland visas olika i olika verktyg.

Avancerade tips för erfarna säkerhetsteam

När grundflödet är på plats finns flera sätt att skärpa upprätthållandet ytterligare. Kombinera SBOM-generering med attestering via cosign, så att SBOM:en inte bara följer med imagen utan också går att kryptografiskt bevisa kommer från rätt byggpipeline. Använd --scanners vuln,secret,config tillsammans för att fånga läckta hemligheter och felkonfigurationer i samma körning som sårbarhetsskanningen, i stället för att köra tre separata verktyg.

För organisationer med striktare krav, överväg att köra Trivy i serverläge (trivy server) internt, så att klienter i pipelinen pratar mot en central instans med redan uppdaterad databas i stället för att var och en hämtar sin egen kopia. Det minskar både nätverkstrafik mot externa register och risken för att en enskild byggagent råkar köra mot en föråldrad eller manipulerad databas. Kombinera det gärna med organisationspolicyer som enbart tillåter godkända GitHub Actions, pinnade till commit-SHA, för att stänga precis den typ av lucka som utnyttjades i mars 2026. Den typen av byggnivåsäkerhet formaliseras i ramverket SLSA (Supply-chain Levels for Software Artifacts), som ger en stegvis skala för hur spårbar och manipuleringssäker en byggprocess faktiskt är, och som fungerar väl som gemensamt målspråk när säkerhetsteam och utvecklare ska enas om hur högt ribban ska läggas.

Ett annat effektivt grepp är att differentiera policyn per miljö i stället för att tillämpa samma tröskel överallt. En testmiljö kan tillåta MEDIUM-fynd utan att blockera, medan produktionsnamnrymden i klustret har en betydligt strängare gräns satt via trivy-operator. Det gör att utvecklare fortfarande kan iterera snabbt tidigt i flödet, samtidigt som det som faktiskt exponeras mot användare hålls till en högre standard.

Severity och CVSS: så tolkar du resultaten

Trivys egen dokumentation definierar hur allvarlighetsgrader tilldelas och hur verktyget faller tillbaka på CVSS-poäng när en källa saknar egen klassificering. Att förstå den här mappningen gör det lättare att sätta rätt tröskelvärden för --severity och för admission-policyn i Kubernetes.

CVSS-poäng	Severity i Trivy	Numeriskt värde
Saknas helt	UNKNOWN	0
0.1–3.9	LOW	1
4.0–6.9	MEDIUM	2
7.0–8.9	HIGH	3
9.0–10.0	CRITICAL	4

När en källa varken anger severity eller CVSS-poäng faller Trivy tillbaka på NVD för att härleda en klassificering. Det är en av huvudanledningarna till att samma sårbarhet ibland visas med olika allvarlighetsgrad i olika skanningsverktyg, eftersom var och en väljer sin egen prioritetsordning bland datakällorna. Sätt därför tröskelvärdet för er organisation utifrån CVSS-intervallen snarare än att lita blint på en enskild källas egen etikett.

En praktisk utgångspunkt för de flesta team är att blockera bygget vid CRITICAL, kräva explicit godkännande vid HIGH, och enbart logga MEDIUM och LOW utan att stoppa något. Justera sedan tröskeln efter några gemensamma diskussioner om vad som faktiskt är rimligt i er miljö. En alltför sträng gräns satt utan förankring leder ofta till att utvecklare snabbt hittar sätt att kringgå kontrollen helt, vilket är sämre än en något mer generös gräns som faktiskt efterlevs.

Vanliga frågor

Är Trivy gratis att använda?

Ja, Trivy är öppen källkod och gratis att använda i sin helhet, inklusive alla skanningslägen som beskrivs i den här guiden. Aqua Security erbjuder separat kommersiella produkter byggda ovanpå Trivy, men själva CLI-verktyget kostar inget.

Vilken version av Trivy ska jag använda efter marskompromissen 2026?

Aqua Securitys incidentguidning pekar ut v0.69.2 och v0.69.3 som bekräftat säkra binärversioner, tillsammans med trivy-action v0.35.0 och setup-trivy v0.2.6. Om ni redan kört senare versioner, till exempel v0.71.2, bör ni ändå verifiera Sigstore-signaturen på den binär ni faktiskt använder innan ni litar på den i produktion.

Vad är skillnaden mellan trivy image och trivy fs?

trivy image skannar en byggd containerimage, antingen lokalt eller direkt från ett register. trivy fs skannar ett filsystem eller en katalog direkt, till exempel er källkodskatalog innan den byggs till en image, vilket gör den lämplig för tidig feedback i utvecklingsflödet.

Kan Trivy ersätta både Grype och Docker Scout?

För de flesta team, ja. Trivys bredare täckning av sårbarheter, felkonfiguration och SBOM i ett verktyg gör att ni sällan behöver lägga till Grype eller Docker Scout separat. Undantaget är om ert flöde redan är djupt integrerat med Docker Desktop och ni specifikt vill ha Docker Scouts kommersiella funktioner.

Hur ofta bör vi uppdatera Trivys sårbarhetsdatabas?

Uppdatera databasen i ett separat schemalagt jobb, snarare än vid varje enskild byggkörning, för att undvika hastighetsbegränsning mot GHCR. En daglig uppdatering är en rimlig utgångspunkt för de flesta team, med möjlighet att köra oftare för särskilt känsliga produktionslinjer.

Fungerar trivy-operator med alla Kubernetes-distributioner?

Operatorn bygger på standardfunktioner i Kubernetes, som ValidatingWebhook-konfiguration och namnrymdsetiketter, vilket gör den kompatibel med de flesta konformanta distributioner. Kontrollera ändå alltid release-anteckningarna för den specifika operatorversionen mot er Kubernetes-version innan driftsättning i produktion.

Vad gör jag om Trivy hittar en kritisk sårbarhet utan tillgänglig patch?

Bedöm faktisk exploaterbarhet i er kontext, dokumentera beslutet, och lägg vid behov till en tidsbegränsad post i .trivyignore med motivering och uppföljningsdatum. Undvik att permanent ignorera fyndet utan en plan för att åtgärda det när en patch väl släpps.

Kan Trivy skanna privata register som kräver inloggning?

Ja. Trivy återanvänder samma autentisering som er lokala Docker- eller Podman-konfiguration redan har mot registret, så om ni kan köra docker pull mot en privat image kan Trivy normalt skanna den utan extra inloggningssteg. I CI/CD-miljöer behöver byggagenten samma registeråtkomst som den redan har för att bygga och pusha images.

Behöver vi köra Trivy om vi redan använder en kommersiell skanningsprodukt?

Det beror på vad den kommersiella produkten faktiskt täcker. Flera kommersiella plattformar bygger själva ovanpå Trivys motor eller motsvarande öppen källkods-databaser, medan andra har egna, kompletterande datakällor. Om er nuvarande lösning redan ger er SBOM-generering, IaC-skanning och Kubernetes-övervakning i den omfattning den här guiden beskriver kan Trivy vara överflödigt. Om ni bara har punktlösningar för enskilda delar kan Trivy fylla luckorna utan extra licenskostnad.

Trivy-guide: Skanna Containers i 14 Steg, 75 Min [2026]