En sikkerhetsskanner som skulle beskytte containere, ble i stedet våpenet mot dem. Det er kortversjonen av det som nå regnes som et av de mest alvorlige forsyningskjede-angrepene i 2026: kompromitteringen av Trivy, en av verdens mest brukte containerskannere. Aqua Security, selskapet bak verktøyet, bekreftet at angripere fikk tilgang til utgivelseskanalen 19. mars og spredte skadevare gjennom offisielle versjoner. Fem måneder senere, i august 2026, la trusseletterretningsselskapet CloudSEK frem det fulle omfanget: over 2.500 organisasjoner og rundt 434.000 CI/CD-pipelines potensielt eksponert. For norske og nordiske IT-avdelinger som har bygd hele utviklingsløpet sitt rundt containerscanning, er saken en vekker om hvor sårbar programvarekjeden faktisk er.

Hva skjedde: Trivy-angrepet i korte trekk

Trivy er et gratis, åpen kildekode-verktøy fra Aqua Security som skanner containere, filsystemer og infrastrukturkode for kjente sårbarheter. Ifølge CNCFs årlige undersøkelse kjører 82 prosent av alle containerbrukere Kubernetes i produksjon, og skannere som Trivy sitter dypt integrert i tusenvis av CI/CD-pipeliner verden over. Nettopp den utbredelsen gjorde verktøyet til et attraktivt mål.

Ifølge Aqua Securitys egen sikkerhetsvarsel brukte en trusselaktør stjålne legitimasjonsopplysninger til å publisere en ondsinnet Trivy-versjon 0.69.4. Deretter ble 76 av 77 versjonstagger i GitHub Action-et trivy-action tvangsoverskrevet med skadevare, mens alle syv tagger i setup-trivy ble byttet ut med ondsinnede commits. Tre dager senere, 22. mars, dukket enda to infiserte Docker Hub-images opp: versjon 0.69.5 og 0.69.6.

Tidslinjen: fra 19. mars til CloudSEKs augustrapport

Angrepet startet ikke i august, men konsekvensene ble først kartlagt for fullt da nyheten traff Norden. Under følger de viktigste datoene, samlet fra Aqua Securitys varsel og Legit Securitys gjennomgang av hendelsen.

  • 19. mars 2026, ca. kl. 17:43 UTC: Angriperen publiserer Trivy v0.69.4 med skjult skadevare og tvangsoverskriver GitHub Action-taggene.
  • 20. mars 2026: Aqua Security oppdager avviket og starter opprydding.
  • 21. mars 2026: Aqua publiserer sikkerhetsvarselet GHSA-69fq-xp46-6×23 og lister trygge versjoner.
  • 22. mars 2026: Nye infiserte Docker Hub-images (v0.69.5, v0.69.6) dukker opp, denne gangen uten tilsvarende GitHub-utgivelser.
  • 2. juli 2026: FBI sender ut varselet FLASH-20260702-01 om kampanjen.
  • 11.–12. august 2026: CloudSEK publiserer et søkbart datasett bygget på rundt 434.000 filer fanget fra angriperens egen infrastruktur, og kartlegger eksponeringen til over 2.500 selskaper.

Det er verdt å merke seg tidsspennet. Fra det første inntrenget til den fulle kartleggingen gikk det nesten fem måneder. I mellomtiden rakk skadevaren å spre seg videre til minst to andre utviklerverktøy, noe vi kommer tilbake til under.

Hvem er TeamPCP?

Trusselaktøren bak angrepet kalles TeamPCP i bransjerapportene, og beskrives som en økonomisk motivert gruppe som spesialiserer seg på å angripe utviklerverktøy og CI/CD-kjeder fremfor å gå direkte etter sluttbrukere. Google sitt trusseletterretningsteam GTIG har fulgt gruppen under betegnelsen UNC6780 og har navngitt skadevaren de brukte i Trivy-angrepet SANDCLOCK.

Fremgangsmåten er ikke ny i seg selv, men utførelsen skiller seg fra typiske ransomware-grupper. I stedet for å kreve løsepenger direkte, bygde TeamPCP en lang kjede av tillitsbrudd: stjålet legitimasjon fra én hendelse ble gjenbrukt til å kompromittere en helt annen kodebase. Det er nettopp denne gjenbruken av tilgang som gjorde at angrepet spredte seg til flere prosjekter over flere uker, ikke bare ett enkelt verktøy i én enkelt hendelse.

Slik fungerte skadevaren SANDCLOCK

Det som gjør denne saken spesielt ubehagelig for sikkerhetsteam, er hvor grundig skadevaren var bygget. Ifølge Aqua Securitys tekniske gjennomgang gjorde SANDCLOCK følgende når den kjørte inne i en CI/CD-jobb:

  • Hentet ut hemmeligheter direkte fra minnet til GitHub Actions Runner, før de i det hele tatt ble skrevet til disk.
  • Skannet over 50 forskjellige filstier på jakt etter SSH-nøkler, API-tokens, skyautentisering og til og med krypto-lommebokdata.
  • Krypterte alt den fant med en hybrid av AES-256-CBC og RSA-4096, trolig for å hindre at forsvarere kunne lese innholdet selv om de fanget trafikken.
  • Sendte dataene videre til angriperens egen infrastruktur, eller lastet dem opp som utgivelsesfiler i offerets eget GitHub-repo som en reserveløsning dersom hovedkanalen ble blokkert.

Den siste teknikken, å gjemme stjålne data i offerets egen infrastruktur, er verdt å dvele ved. Den gjør det vanskeligere å oppdage eksfiltrering med vanlig nettverksovervåking, fordi trafikken aldri forlater GitHubs egne servere før angriperen henter den ut manuelt senere.

Skalaen: 2.500 selskaper og 434.000 CI/CD-pipelines

CloudSEKs analyse fra august 2026 er den mest konkrete kilden til skalaen på angrepet. Selskapet bygde et søkbart datasett fra rundt 434.000 filer de fant i angriperens egen infrastruktur, og brukte det til å spore hvilke organisasjoner som hadde blitt truffet. Konklusjonen: over 2.500 selskaper hadde med høy grad av sikkerhet eksponert hemmeligheter til TeamPCP.

Det som ble stjålet spenner bredt. SecurityWeeks dekning lister opp AWS-, GCP- og Azure-nøkler, Kubernetes-tokens, miljøvariabler, CI/CD-hemmeligheter, API-nøkler for språkmodeller, databasetilkoblinger og webhook-tokens. Kort sagt: nesten alt en angriper trenger for å bevege seg videre inn i et offers skymiljø.

Kjente ofre: fra AWS til Volkswagen

De fleste ofrene i denne typen saker forblir anonyme, men denne gangen har flere store navn blitt bekreftet med det forskerne kaller “høy grad av sikkerhet”. Blant selskapene som skal ha vært eksponert finner vi Amazon Web Services, Cisco Systems, Deloitte, X Corp (tidligere Twitter), Volkswagen AG, Salesforce, Samsung Electronics og ServiceNow.

At selskaper med egne, godt bemannede sikkerhetsavdelinger havnet på listen, sier noe viktig om angrepets natur. Dette handlet ikke om dårlig sikkerhetshygiene hos ofrene. Det handlet om at de stolte på et verktøy som i utgangspunktet skulle gjøre dem tryggere.

Fra Trivy til LiteLLM: kaskadeeffekten i forsyningskjeden

Trivy-kompromitteringen var bare første ledd. Ifølge Arctic Wolfs analyse brukte TeamPCP tilgangen de fikk gjennom Trivy til å bevege seg videre inn i byggesystemet til AI-gatewayen LiteLLM. Der lyktes de i å legge inn skadevare i to PyPI-pakker, versjon 1.82.7 og 1.82.8, ved hjelp av en ondsinnet .pth-fil som kjørte automatisk hver gang Python startet opp, uten at brukeren måtte kjøre noe skript selv.

Samme kampanje rammet også Checkmarx sitt infrastruktur-som-kode-verktøy KICS, i versjoner eldre enn 2.3.29. Cloud Security Alliance har beskrevet hele forløpet som et sammenhengende angrep over flere uker, der ett kompromittert verktøy ble brukt som brekkstang mot det neste. Det er dette mønsteret, ikke bare Trivy-hendelsen isolert, som gjør at sikkerhetsmiljøet omtaler saken som en av årets alvorligste.

CVE-2026-33634 forklart: CVSS 9,4 og hva det betyr

Hendelsen har fått sitt eget sårbarhetsnummer, CVE-2026-33634, klassifisert under CWE-506 (innebygd ondsinnet kode) med en CVSS 4.0-score på 9,4 av 10. Det plasserer den i den kritiske kategorien, på linje med sårbarheter som tillater fullstendig systemkompromittering uten at angriperen trenger fysisk tilgang.

Vektorstrengen, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, forteller at angrepet kan utføres over nettverk, med lav kompleksitet, med lave privilegier og uten at et offer trenger å klikke på noe. Konsekvensen er full skade på konfidensialitet, integritet og tilgjengelighet. For et sikkerhetsverktøy som i utgangspunktet skal kjøre med tilgang til nesten hele byggemiljøet, er det vanskelig å tenke seg en verre kombinasjon.

Historisk kontekst: forsyningskjede-angrep gjennom ti år

Trivy-saken er ikke den første gangen tillit til et utviklerverktøy har blitt utnyttet. Tabellen under viser hvordan den sammenlignes med fem av de mest kjente forsyningskjede-angrepene det siste tiåret.

HendelseÅrAngrepsvektorOmfang
SolarWinds Orion2020Kompromittert byggesystem, signert oppdatering (SUNBURST)Tusenvis av organisasjoner, inkl. amerikanske myndigheter
event-stream (npm)2018Overtatt vedlikeholderrolle, målrettet mot Bitcoin-lommebøkerUkjent antall, men pakken hadde millioner av nedlastinger
Codecov2021Manipulert bash-opplastingsskript, hentet miljøvariabler fra CI/CDFlere hundre kunder berørt
ua-parser-js (npm)2021Kapret utgiverkonto, spredte kryptomining og passordtyveriMillioner av ukentlige nedlastinger eksponert
xz utils (liblzma)2024Bakdør lagt inn av tillitsfull bidragsyter over flere årFanget opp før masseutbredelse i Linux-distribusjoner
Trivy / TeamPCP2026Stjålet legitimasjon, tvangsoverskrevne versjonstagger og images2.500+ selskaper, ca. 434.000 CI/CD-pipelines

Det som skiller Trivy-saken fra SolarWinds og Codecov, er at målet denne gangen var selve sikkerhetsverktøyet. Ofrene installerte ikke en tilfeldig avhengighet, de installerte det de trodde skulle beskytte dem mot akkurat denne typen angrep.

Trivy mot konkurrentene: markedsposisjon i containersikkerhet

Trivy er langt fra det eneste verktøyet norske og nordiske utviklerteam bruker til å skanne containere. Tabellen under sammenligner Trivy med de mest brukte alternativene, og hvordan de vanligvis er posisjonert i markedet.

VerktøyLeverandør / modellTypisk brukRelevans etter Trivy-saken
TrivyAqua Security, åpen kildekodeContainer-, filsystem- og IaC-skanningDirekte rammet, krever oppgradering og opprullet tillit
GrypeAnchore, åpen kildekodeContainer- og SBOM-basert sårbarhetsskanningVanlig alternativ; ikke rammet av denne kampanjen
Docker ScoutDocker, native SaaS-tjenesteBildeanalyse og SBOM integrert i Docker-økosystemetTettere kontrollert utgivelseskjede gjennom Docker selv
SnykKommersiell, med gratis nivåSAST, avhengighetsanalyse og containersikkerhetOfte brukt som andre skanner ved siden av Trivy
ClairRed Hat / CoreOS, åpen kildekodeBildeskanning, ofte i registre som QuayMindre utsatt for GitHub Actions-vektoren spesifikt

Poenget her er ikke at Trivy er dårligere enn konkurrentene. Det er at popularitet i seg selv er en risikofaktor. Jo flere pipelines som stoler blindt på ett verktøy, jo mer attraktivt blir nettopp det verktøyet som mål for en gruppe som TeamPCP.

Hvorfor sikkerhetsverktøy er blitt et yndet mål

Containere og Kubernetes er ikke lenger eksperimentell teknologi. CNCFs undersøkelse viser at 98 prosent av virksomhetene som ble spurt nå har tatt i bruk cloud native-teknologi i en eller annen form, og at 77 prosent av Fortune 100-selskapene kjører Kubernetes i produksjon. Blant selskaper som satser på KI-arbeidslaster, bruker 66 prosent Kubernetes til å skalere inferens.

Den utbredelsen har gjort sikkerhetsverktøy til et rasjonelt mål for angripere. Et skadelig innslag i én populær CI/CD-komponent gir tilgang til langt flere miljøer enn et angrep mot et enkeltselskap noensinne kunne. Legit Security peker på at nettopp tilliten til sikkerhetsverktøy er problemet: team stoler på at et verktøy som heter “scanner” eller “security action” er trygt, og hopper derfor over de kontrollene de ellers ville brukt på ukjent kode.

Reaksjoner fra sikkerhetsmiljøet

Flere store aktører i sikkerhetsbransjen har publisert egne vurderinger av saken, og de er samstemte om alvoret. Cloud Security Alliance omtaler hele forløpet som en sammenhengende kampanje over flere dager, der tillit til ett verktøy ble utnyttet til å angripe det neste. Microsoft har publisert egen veiledning for hvordan bedrifter kan oppdage og etterforske spor etter kompromitteringen i egne CI/CD-miljøer, og understreker at angrepet utnyttet nettopp den tilliten organisasjoner normalt gir til sikkerhetsverktøy.

SANS Internet Storm Center har brukt saken som et undervisningseksempel i det de kaller kaskaderende svikt i forsyningskjeden, og viser til at Google sitt GTIG-team kunne knytte SANDCLOCK-skadevaren til tyveri av kildekode hos minst én stor teknologiaktør. Reflectiz har på sin side pekt på det de kaller et synlighetsproblem: mange organisasjoner vet rett og slett ikke hvilke versjoner av hvilke verktøy som faktisk kjører i deres egne bygge-pipelines, noe som gjorde det vanskelig å fastslå eksponering raskt selv etter at Aqua Security varslet om hendelsen.

Aqua Securitys offisielle respons

Aqua Security handlet raskt etter at avviket ble oppdaget. Selskapet rullet tilbake Trivy til de sist kjente trygge versjonene, 0.69.2 og 0.69.3, og publiserte et fullstendig sikkerhetsvarsel med oversikt over berørte komponenter. I varselet oppgir Aqua at årsaken var gjenbruk av stjålet legitimasjon fra en tidligere, ikke fullstendig utbedret hendelse, en detalj som understreker hvor kostbart det er å la selv mindre sikkerhetshull stå åpne over tid.

Anbefalingene fra Aqua er konkrete: oppgrader umiddelbart til trygge versjoner, roter alle hemmeligheter som kan ha vært eksponert, gjennomgå logger fra GitHub Actions i tidsrommet 19.–20. mars, og søk etter repositorier med navnemønsteret tpcp-docs, som kan indikere vellykket datauttrekk. Selskapet oppfordrer også alle brukere til å pinne GitHub Actions til fullstendige commit-SHA-er fremfor bevegelige versjonstagger.

Dette bør norske og nordiske virksomheter gjøre nå

For IT- og sikkerhetsteam i Norge og Norden handler dette om mer enn å oppdatere én pakke. Under er de konkrete grepene sikkerhetsforskere anbefaler, oversatt til en sjekkliste.

  • Oppgrader til Trivy v0.69.2/0.69.3 eller nyere, trivy-action v0.35.0+ og setup-trivy v0.2.6.
  • Roter alle hemmeligheter som kan ha passert gjennom en pipeline mellom 19. og 24. mars 2026.
  • Gjennomgå CI/CD-logger for uventede nettverkskall til ukjente domener i samme periode.
  • Søk gjennom organisasjonens GitHub-kontoer etter uautoriserte tpcp-docs-repositorier.
  • Kartlegg om LiteLLM 1.82.7/1.82.8 eller Checkmarx KICS eldre enn 2.3.29 er i bruk noe sted i kjeden.
  • Pinn alle GitHub Actions til commit-SHA fremfor tagg eller “latest”.

Det siste punktet er enklere å implementere enn mange tror. Under er et eksempel på forskjellen mellom en sårbar og en trygg referanse i en GitHub Actions-workflow.

# Sårbart: bruker en bevegelig tagg som kan overskrives
- uses: aquasecurity/[email protected]

# Trygt: pinnet til en spesifikk commit-SHA
- uses: aquasecurity/trivy-action@1f0aa582c8c8f5f7639610d6d38baddfea4fdcee # v0.35.0

Markedseffekt: FinOps, budsjetter og NIS2/DORA-krav

Saken kommer på et tidspunkt der markedet for forsyningskjedesikkerhet allerede vokser. Analyser anslår at markedet for programvare-forsyningskjedesikkerhet var verdt rundt 2,16 milliarder dollar i 2026 og vil vokse videre mot midten av 2030-tallet. Gartner har i tillegg formalisert kategorien i egne markedsrapporter, noe som signaliserer at styreledere nå forventer et eget budsjettpunkt for nettopp denne typen risiko, ikke bare generell applikasjonssikkerhet.

For finansforetak i Norden er dette ikke bare en teknisk detalj. EUs forordning om digital operasjonell motstandsdyktighet, DORA, har vært i kraft for finanssektoren siden januar 2025 og stiller krav om at foretak fører oppdaterte registre over alle IKT-tredjepartsleverandører og vurderer konsentrasjonsrisiko i leverandørkjeden. NIS2-direktivet stiller tilsvarende krav til risikostyring av leverandørkjeden for et bredere sett av virksomheter, inkludert flere norske selskaper som leverer kritisk infrastruktur. En hendelse som Trivy-saken er nøyaktig den typen konsentrasjonsrisiko begge regelverkene ber virksomheter kartlegge.

Praktisk betyr det at mange norske sikkerhetsteam nå må dokumentere ikke bare hvilke skyleverandører de bruker, men også hvilke åpen kildekode-skannere og GitHub Actions som kjører inne i egne pipelines, og hvordan de verifiserer integriteten til disse før de kjøres i produksjon.

Fem spådommer for containersikkerhet fremover

  • Obligatorisk SHA-pinning blir standard: Flere organisasjoner vil kreve commit-SHA-pinning av alle GitHub Actions som en fast del av sikkerhetspolicyen, ikke lenger en anbefaling.
  • Flere skannere i parallell: Team vil i økende grad kjøre to uavhengige skannere samtidig, slik at et kompromittert verktøy ikke er eneste sikkerhetslag.
  • Kortere revisjonssykluser for leverandørkjeden: DORA- og NIS2-pålagte gjennomganger av IKT-tredjeparter vil begynne å inkludere navngitte åpen kildekode-avhengigheter, ikke bare kommersielle leverandører.
  • Signering blir en forutsetning, ikke et tillegg: Rammeverk som SLSA og Sigstore vil se raskere adopsjon som svar på nettopp denne typen tvangsoverskrevne tagger.
  • Flere kaskaderende funn: Gitt hvor lang tid det tok å avdekke det fulle omfanget av Trivy-saken, er det sannsynlig at ytterligere berørte prosjekter fra samme kampanje identifiseres i månedene fremover.

Ofte stilte spørsmål

Hva er Trivy?
Trivy er et gratis, åpen kildekode-verktøy fra Aqua Security som skanner containerbilder, filsystemer og infrastrukturkode for kjente sårbarheter og feilkonfigurasjoner.

Hvilke Trivy-versjoner var berørt?
Trivy-versjonene 0.69.4, 0.69.5 og 0.69.6, samt GitHub Action-ene trivy-action før versjon 0.35.0 og setup-trivy før versjon 0.2.6.

Er min organisasjon rammet hvis vi bruker Trivy?
Bare hvis dere kjørte en av de berørte versjonene mellom 19. og 24. mars 2026, eller brukte de kompromitterte GitHub Actions-taggene i samme periode. Sjekk byggeloggene for perioden for å være sikker.

Hva er SANDCLOCK?
SANDCLOCK er navnet Google sitt trusseletterretningsteam GTIG har gitt skadevaren TeamPCP brukte til å hente ut hemmeligheter fra kompromitterte CI/CD-miljøer.

Henger LiteLLM-bruddet sammen med Trivy-saken?
Ja. Ifølge analyser fra Arctic Wolf og CloudSEK brukte TeamPCP tilgangen fra Trivy-kompromitteringen til å infisere to versjoner av AI-gatewayen LiteLLM på PyPI.

Hva bør jeg gjøre først hvis vi har brukt en berørt versjon?
Oppgrader umiddelbart til en trygg versjon, roter alle hemmeligheter som kan ha vært eksponert i den aktuelle pipelinen, og gjennomgå logger for uventet utgående nettverkstrafikk.

Gjelder DORA og NIS2 for oss hvis vi ikke er en bank?
DORA gjelder primært finanssektoren, mens NIS2 dekker et bredere sett av sektorer, inkludert flere typer kritisk infrastruktur og digitale tjenester i Norge og resten av EU/EØS.

Finnes det et CVE-nummer for saken?
Ja, hendelsen er registrert som CVE-2026-33634, med en CVSS 3.1-score på 9,4 og klassifisert som CWE-506, innebygd ondsinnet kode.

Relatert dekning