Send en foreløpig uttalelse innen timer, et bekreftet svar så snart du kan bevise det, og en oppfølging hver gang noe endrer seg. Si hva du vet, hva du fortsatt sjekker og når du kommer med en oppdatering. Bygg hvert «ikke berørt» på det byggene dine faktisk installerte i angrepsvinduet, ikke på dagens lockfile.
Dette innlegget handler om hva du skal si, når og med hvilket grunnlag. For selve undersøkelsen, hvordan du finner ut om en sårbar komponent finnes i produktene dine og siden når, se er vi berørt av en CVE?.
Hvorfor kundene spør deg, ikke pakkeregisteret
Uken etter et mye omtalt angrep, fortalte en liten programvareleverandør oss, sendte kundene ham tekstmeldinger: Er tingene deres trygge? Er tingene mine trygge? Kundene hans håndterer sensitive data, teamet hans har ingen sikkerhetsspesialist, og spørsmålet trengte et svar samme dag.
Kundene spør ikke om en pakke ble kompromittert. Det har registeret og forskerne allerede sagt. De spør om det du har levert dem inneholder den, fordi produktet ditt er deres eksponering. De har egne kunder, revisorer eller myndigheter som stiller dem det samme spørsmålet. I regulerte leverandørkjeder som halvledere, industriutstyr og helse er spørsmålet kontraktsfestet, ikke nysgjerrighet.
De spør også igjen hvis svaret ditt ikke kan etterprøves. «Vi er ikke berørt» uten noe bak er et løfte; «vi sjekket hvert utgivelsesbygg fra 24. til 31. mars, og ingen av dem installerte de berørte versjonene» er en uttalelse de kan stole på.
Fire nylige angrep og spørsmålet hvert av dem reiste
Det riktige svaret avhenger av hvordan angrepet fungerte, så en mal alene er ikke nok. For hvert av disse avgjør ett faktum hva «berørt» betyr for en leverandør.
Bakdøren i xz Utils (CVE-2024-3094), offentliggjort 29. mars 2024. Andres Freund fant en bakdør i xz-versjonene 5.6.0 og 5.6.1. Utgivelses-tarballene inneholdt kode som ikke fantes i Git-repositoriet, og den sprøytet inn bakdøren under bygget. NVD og Red Hat gir den begge 10.0 etter CVSS 3.1. Den nådde for det meste rullerende distribusjoner og testdistribusjoner: Debian testing, unstable og experimental, Fedora Rawhide og 41, openSUSE Tumbleweed og Kali, mens stabile utgivelser ikke var berørt. Spørsmålet det reiste: Inneholder noe image eller noen enhet vi har levert, xz 5.6.0 eller 5.6.1, og hvilket base-image brukte hvert bygg?
Ormen Shai-Hulud på npm, i bølger siden september 2025. Infiserte pakker kjører et skript ved installasjon som stjeler npm-, GitHub- og skylegitimasjon og bruker den til å publisere infiserte versjoner av flere pakker. Spørsmålet det reiste: Installerte noen CI-jobb en infisert versjon, og ble publiseringstokenene våre eksponert, noe som ville gjøre oss til en spreder? Vår Shai-Hulud-oppføring lister hver bølge og hvordan du sjekker.
LiteLLM på PyPI, 24. mars 2026. Versjonene 1.82.7 og 1.82.8 ble lastet opp direkte til PyPI med kode som stjeler legitimasjon og som aldri fantes i prosjektets GitHub-repositorium. I 1.82.8 kjørte en .pth-fil nyttelasten hver gang en Python-tolk startet, ikke bare når LiteLLM ble importert; den samlet inn miljøvariabler, SSH-nøkler, skylegitimasjon og Kubernetes-hemmeligheter. HiddenLayer knytter angrepet til TeamPCP, som også rammet verktøy fra Trivy og Checkmarx samme måned. LiteLLMs egen advisory gir to forklaringer på den første tilgangen: den sporer kompromitteringen til Trivy-avhengigheten i arbeidsflyten for sikkerhetsskanning i CI-en, og skriver at PyPI-kontoen til en vedlikeholder kan ha blitt kompromittert. Selv eksponeringsvinduet spriker innad i den samme advisoryen, rundt 40 minutter ett sted og 10:39 til 16:00 UTC et annet. Spørsmålet det reiste: Inneholdt et bygg eller en levert container disse versjonene, og hvilke hemmeligheter fantes i det miljøet?
axios på npm, 31. mars 2026. En angriper overtok en vedlikeholders npm-konto og publiserte axios 1.14.1 og 0.30.4, som la til en avhengighet, [email protected], der installasjonsskriptet plantet en trojaner for fjerntilgang på macOS, Windows og Linux. Datadog anslår vinduet til 00:21 til 03:25 UTC; ifølge Snyk ble versjonene fjernet 03:29 UTC. Spørsmålet det reiste: Løste noe bygg opp disse versjonene i det vinduet? En lockfile som ble committet før vinduet, svarer «nei» for bygg som brukte den, og sier ingenting om bygg som kjørte npm install uten den.
| Angrep | Økosystem | Berørte versjoner | Vindu | Hva «berørt» betyr for en leverandør |
|---|---|---|---|---|
| xz Utils | Linux-distribusjoner | 5.6.0, 5.6.1 | Uker, frem til offentliggjøringen 29. mars 2024 | Du har levert den, i et image eller en enhet bygget på en berørt distribusjon |
| Shai-Hulud | npm | Hundrevis av pakker, per bølge | Timer til dager per bølge | Du har bygget med den, og tokenene dine kan ha spredt den; du kan også ha levert den |
| LiteLLM | PyPI | 1.82.7, 1.82.8 | 24. mars 2026, fra 10:39 UTC (kildene spriker om slutten) | Du har bygget med den eller levert den, og hemmeligheter i det miljøet kan være stjålet |
| axios | npm | 1.14.1, 0.30.4 | 31. mars 2026, omtrent 00:21 til 03:25 UTC | Du bygget med den i vinduet; trojaneren kjørte på byggemaskinen |
De samme spørsmålene dukker opp ved en kritisk sårbarhet som ikke er et leverandørkjedeangrep. Da PHP2Shell ble utnyttet i oktober 2026, spurte kundene til hvert produkt som leveres med PHP, hvilke av versjonene deres som inneholder en berørt PHP. Stegene nedenfor gjelder uendret.
Svaret har tre trinn
| Trinn | Når | Hva du sender |
|---|---|---|
| Foreløpig uttalelse | Innen timer etter nyheten | Hva du vet, hva du sjekker, når du kommer med en oppdatering |
| Bekreftet svar | Så snart du kan bevise det, vanligvis første dag | «Ikke berørt» for navngitte versjoner, eller «berørt» med hva man skal gjøre |
| Oppfølging | Når rettingen er levert, når du får vite noe nytt, når du lukker saken | Det samme varselet, revidert |
Den første timen: den foreløpige uttalelsen
En foreløpig uttalelse (holding statement) er den første offentlige uttalelsen du kommer med før fakta er på plass. Si noe som er sant, raskt. Stillhet fylles med antakelser, og en kunde som ikke hører noe fra deg, antar at du ikke har fått det med deg.
- Hvem og hvor. Én navngitt avsender, i kanalen kunden brukte, pluss sikkerhetssiden din. Én felles tekst slår svar skrevet på sparket: Den forblir konsekvent, og juristene gjennomgår den én gang.
- Hva den inneholder. At du kjenner til angrepet, at du sjekker produktene og byggesystemene dine, hva du vet så langt, når neste oppdatering kommer og hvem man kan kontakte.
- Hva den ikke må inneholde. «Vi er ikke berørt» før du har sjekket, spekulasjoner om angriperen eller skyldfordeling.
Mal 1: foreløpig uttalelse
Emne: [Navn på angrepet]: vår første uttalelse
Vi er kjent med den rapporterte kompromitteringen av [pakke eller prosjekt] ([berørte versjoner], publisert [dato]). Sikkerhetsteamet vårt går nå gjennom alle utgivelser av [produkt] og byggesystemene våre for å se etter de berørte versjonene. Så langt har vi [ikke funnet berørte versjoner i produktene vi har sjekket / ikke fullført gjennomgangen]. Vi sender en oppdatering innen [dato og klokkeslett, tidssone]. Har du spørsmål i mellomtiden, kan du kontakte [navn, adresse til sikkerhetskontakt]. Vi vil ikke spekulere i konsekvensene før gjennomgangen er fullført.For en tekstmelding eller chat holder det med to setninger:
Vi kjenner til kompromitteringen ved [navn på angrepet] og går nå gjennom alle utgivelser av [produkt] og byggene våre. Du får et bekreftet svar fra oss innen [klokkeslett].La juristene godkjenne alle tre malene før du trenger dem.
Første dag: bekreft, med dokumentasjon
To utfall er mulige, og hvert av dem krever sin egen dokumentasjon. For et «ikke berørt»-svar samler du inn:
- den berørte pakken og versjonene, fra advisoryen eller forskernes gjennomgang
- produktene dine og versjonene kundene faktisk kjører
- for hver av disse versjonene: bygget som produserte den, og registreringen av hva det bygget installerte, ikke den nåværende lockfilen
- hvert bygg som kjørte i angrepsvinduet, inkludert CI-jobber som aldri produserte en utgivelse
- for ormer som stjeler tokener: om det fantes CI-hemmeligheter i jobber som kunne ha kjørt den ondsinnede koden
Er vi berørt av en CVE? forklarer hvordan du fastslår hvert av disse punktene.
Hver uttalelse du kommer med, må være underbygget av noe du kan vise frem:
| Uttalelse | Hva du må kunne vise | Hva som ikke er nok |
|---|---|---|
| «Produkt X versjon Y inneholder ikke pakke Z» | SBOM-en registrert fra utgivelsesbygget for versjon Y | En skanning av det nåværende repositoriet |
| «Ingen av byggene våre installerte de kompromitterte versjonene» | Installasjonsregistreringer for hvert bygg i vinduet | En lockfile som enkelte jobber går utenom |
| «Utgivelsesprosessen vår ble ikke kompromittert» | Registreringer av nettverkstrafikk og bruk av hemmeligheter i vinduet | Fravær av varsler |
| «Kunder på versjon Y er trygge etter oppgradering» | Registreringen av det rettede bygget, og legitimasjonen du roterte | En oppføring i endringsloggen |
Mal 2: ikke berørt
Emne: [Navn på angrepet]: [produkt] er ikke berørt
Vi har fullført gjennomgangen etter kompromitteringen av [pakke] ([berørte versjoner]). Følgende versjoner av [produkt] er ikke berørt: [liste over produkter og versjoner som er sjekket]. Vi har sjekket alle utgivelsesbygg og CI-bygg som kjørte mellom [startdato] og [sluttdato]. Denne uttalelsen bygger på registreringen av komponentene hvert utgivelsesbygg installerte, ikke på en skanning av den nåværende kildekoden vår. Ingen av disse byggene installerte de berørte versjonene. Trenger du dokumentasjonen, kan vi sende SBOM-en for versjonene du kjører, eller en VEX-erklæring. Får vi vite noe som endrer denne vurderingen, gir vi deg beskjed. Kontakt: [navn, adresse til sikkerhetskontakt].Si «ikke berørt» for navngitte versjoner. Skriv aldri «100 % trygt». Hvis kunden deretter ber om hele SBOM-en, se hvordan du svarer på kunders SBOM-forespørsler.
Mal 3: berørt, med tiltak
Emne: [Navn på angrepet]: tiltak kreves for [produkt] versjon [x til y]
Gjennomgangen vår etter kompromitteringen av [pakke] viste at [produkt] versjon [x til y] er berørt. Det første berørte bygget ble produsert [dato]; versjon [z], utgitt [dato], inneholder ikke lenger [pakkeversjon].
Hva dette betyr: [risikoen i klartekst, for eksempel «en komponent som er installert i disse versjonene, kan sende legitimasjon fra systemet den kjører på, til en ekstern server»].
Hva du bør gjøre nå: Oppgrader til [produkt] [z]. Hvis du ikke kan oppgradere med en gang, [tiltak, for eksempel å blokkere utgående tilkoblinger til de oppførte vertene]. Hvis du har brukt [produkt] versjon [x til y] i [miljø], må du rotere [legitimasjon eller nøkler] som var tilgjengelige for det.
Hva vi har gjort: Vi har fjernet de berørte versjonene fra byggene våre, bygget [produkt] på nytt fra rene avhengigheter, rotert legitimasjonen byggesystemene våre bruker og [andre tiltak]. [Vi har varslet de relevante myndighetene der det kreves.]
Vi sender neste oppdatering innen [dato], eller tidligere hvis noe endrer seg. Kontakt: [navn, adresse til sikkerhetskontakt].Et «berørt»-varsel kan også være en juridisk plikt; se avsnittet om rapportering nedenfor.
Der VEX og CSAF passer inn. En «ikke berørt»- eller «rettet»-erklæring kan publiseres som VEX, så kundenes skannere slutter å flagge pakken. Større kunder kan i tillegg forvente en maskinlesbar advisory; CSAF er formatet de fleste av dem ber om.
Oppfølging: avslutt det skikkelig
Send en oppfølging når rettingen er levert, når undersøkelsen din finner noe nytt, og en siste melding når saken lukkes. Ha én advisory per hendelse, og revider den i stedet for å sende en ny hver gang (oppdater, ikke erstatt). Noter hva du fortalte hvem og når: Neste revisjon eller sikkerhetsspørreskjema fra en kunde kommer til å spørre.
Hva du sier når du ikke vet ennå
«Vi vet ikke ennå» bygger mer tillit enn et «ikke berørt» du må trekke tilbake. Formuleringer som er ærlige uten å skape unødig uro:
- «Vi har ikke funnet [pakke] i [produktene som er sjekket så langt]. Vi sjekker fortsatt [gjenstående produkter eller byggesystemer] og gir deg en oppdatering innen [klokkeslett].»
- «Versjonene du kjører, ble bygget før angrepsvinduet. Vi bekrefter nå at ingen senere bygg har erstattet dem.»
- «Vi sjekker om noen av byggesystemene våre kjørte de berørte versjonene. Det installerte produktet ditt er et eget spørsmål, og vi svarer på begge.»
Formuleringer du bør unngå:
- «Ingen konsekvenser overhodet»
- «Fullstendig sikkert»
- «Ikke berørt av noe leverandørkjedeangrep»
- «Skanneren vår fant ingenting»
Når angrepet blir en rapporteringsplikt
Hvis du selger produkter med digitale elementer i EU, har rapporteringspliktene i Cyber Resilience Act gjeldt siden 11. september 2026, dagen da ENISA lanserte den felles rapporteringsplattformen (Single Reporting Platform). En aktivt utnyttet sårbarhet i produktet ditt, eller en alvorlig hendelse som påvirker sikkerheten til det, utløser et tidlig varsel innen 24 timer etter at du ble kjent med den, en melding innen 72 timer og en sluttrapport, sendt inn via plattformen til den koordinerende CSIRT-en din og ENISA. CRA-veiledningen går gjennom stegene.
Om en kompromittert avhengighet du har levert, eller en kompromittering av din egen byggeprosess, oppfyller disse definisjonene, er en vurdering for deg og juristene dine, ikke for dette innlegget. Forordningen definerer begrepene:
- En «aktivt utnyttet sårbarhet» er «en sårbarhet der det finnes pålitelige bevis for at en ondsinnet aktør har utnyttet den i et system uten tillatelse fra systemeieren» (artikkel 3 nr. 42).
- En hendelse er alvorlig når «den påvirker eller kan påvirke negativt evnen et produkt med digitale elementer har til å beskytte tilgjengeligheten, autentisiteten, integriteten eller konfidensialiteten til sensitive eller viktige data eller funksjoner», eller når «den har ført til eller kan føre til at ondsinnet kode innføres eller kjøres» i produktet eller i en brukers systemer (artikkel 14 nr. 5).
Artikkel 14(8) legger til en plikt overfor brukerne: å informere de berørte brukerne, og der det er hensiktsmessig alle brukere, om sårbarheten eller hendelsen og om eventuelle tiltak de kan iverksette, «der det er hensiktsmessig, i et strukturert, maskinlesbart format som lett kan behandles automatisk». Mal 3 kan være en del av å oppfylle den plikten.
Andre regelverk gjelder også. Etter NIS2 melder vesentlige og viktige enheter betydelige hendelser til sin CSIRT eller kompetente myndighet, og mange kundekontrakter har egne varslingsklausuler med egne frister.
Vær klar før neste gang
- En registrering av hva hvert utgivelsesbygg installerte, tatt vare på i hele produktets støtteperiode (SBOM-er fra byggetidspunktet).
- En liste over hvilke kunder som kjører hvilke versjoner.
- De tre malene ovenfor, godkjent av juristene.
- En navngitt avsender og en kanal for hver type kunde.
- En sikkerhetsside og en
security.txt-fil der oppdateringene havner (koordinert sårbarhetsavsløring). - Egress-kontroll i CI, så en kompromittert pakke ikke kan sende hemmeligheter til en vert bygget ikke trenger (egress-policy for GitHub Actions).
For hendelser som kommer i hundrevis i stedet for én om gangen, se slik skalerer du et PSIRT.
Slik passer CRACI inn
Dokumentasjonstabellen ovenfor etterspør én ting gang på gang: en registrering av hva hvert utgivelsesbygg installerte. Det er det CRACI tar vare på. CRACI kjører GitHub Actions-byggene dine på egne runnere og registrerer hver pakke hver jobb faktisk hentet inn, inkludert pakker hentet av installasjonsskript og pakker gjenopprettet fra cacher. SBOM-en til hvert tidligere bygg tas vare på, så «installerte noe bygg axios 1.14.1 i vinduet?» besvares ut fra byggehistorikken, med perioden du var berørt, så langt tilbake som oppbevaringstiden din rekker.
Kjente ondsinnede utgivelser som har en publisert CVE, som bakdøren i xz, flagges som enhver annen sårbarhet, og en policy gate kan blokkere bygg som inneholder dem. CRACI oppdager ikke en ny ondsinnet pakke ut fra atferd eller omdømme.
CRACIs egress-policy blokkerer tilkoblinger til verter et bygg ikke trenger, noe som begrenser hva et ondsinnet installasjonsskript kan sende ut, selv ved et angrep ingen har sett før. Når en kunde ber om dokumentasjonen, kan du eksportere SBOM-en for versjonene de kjører, som CycloneDX eller SPDX, og sende den. CRACI støtter VEX.
Svar på «var vi berørt?» ut fra byggehistorikken din, eller les mer om hvordan leverandørkjedeangrep fungerer.
Når CRACI ikke er svaret
- Du trenger hjelp med selve kommunikasjonen. PR og juridisk rådgivning er en annen jobb.
- Den berørte programvaren ble ikke bygget på CRACI. CRACI registrerer GitHub Actions-bygg som kjører på runnerne sine; andre CI-systemer står på veikartet.
- Spørsmålet gjelder en leverandørs produkt du ikke har bygget. Leverandør-SBOM-er kan legges til i CRACI, men svaret blir aldri bedre enn leverandørens SBOM.
- Du må fange en helt ny ondsinnet pakke før det finnes noen advisory. CRACI flagger kjente ondsinnede utgivelser når en advisory med en CVE er publisert; det oppdager ikke skadevare ut fra atferd eller omdømme (håndtering av zero-day-sårbarheter).
Ofte stilte spørsmål
Hva sier jeg til kundene når et leverandørkjedeangrep er i nyhetene?
Send en foreløpig uttalelse innen timer: Du kjenner til angrepet, du sjekker produktene og byggene dine, hva du vet så langt og når du kommer med en oppdatering. Følg opp med et bekreftet svar for navngitte produktversjoner så snart du kan underbygge det med byggeregistreringer, og en oppfølging når noe endrer seg.
Hva bør en foreløpig uttalelse si?
Hva som skjedde, i én setning, at du sjekker produktene og byggesystemene dine, hva du har funnet så langt, tidspunktet for neste oppdatering og en kontakt. Den må ikke si «ikke berørt» før du har sjekket, spekulere om angriperen eller legge skylden på noen.
Hvordan sier jeg «vi er ikke berørt» uten å love for mye?
Nevn produktene og versjonene du har sjekket, datoperioden for byggene du har sjekket og dokumentasjonen du brukte, for eksempel registreringen av komponentene hvert utgivelsesbygg installerte. Si «ikke berørt» for de versjonene, tilby SBOM-en eller en VEX-erklæring, og lov å oppdatere hvis noe endrer seg. Unngå «100 % trygt» eller «fullstendig sikkert».
Hva bør et «vi var berørt»-varsel til kundene inneholde?
Hvilke produkter og versjoner som er berørt, siden når og frem til hvilken rettet versjon, risikoen i klartekst, hva kunden bør gjøre nå (oppgradere, rotere legitimasjon, blokkere verter), hva du allerede har gjort, når neste oppdatering kommer og hvem man kan kontakte.
Hvilken dokumentasjon bør ligge bak en «ikke berørt»-uttalelse?
For hver versjon kundene kjører: registreringen av hva bygget som produserte den, installerte, ikke dagens lockfile. Legg til registreringene av hvert bygg som kjørte i angrepsvinduet og, ved angrep som stjeler legitimasjon, om det fantes hemmeligheter i jobber som kunne ha kjørt den ondsinnede koden.
Må jeg rapportere et leverandørkjedeangrep etter Cyber Resilience Act?
Kanskje. Siden 11. september 2026 må produsenter av produkter med digitale elementer som selges i EU, rapportere aktivt utnyttede sårbarheter og alvorlige hendelser som påvirker produktsikkerheten: et tidlig varsel innen 24 timer, en melding innen 72 timer og en sluttrapport. Om et bestemt angrep faller inn under dette, er en vurdering for deg og juristene dine.
Hvor raskt bør vi svare kundene?
Innen timer med en foreløpig uttalelse, selv om alt den sier, er at du sjekker og når du kommer med en oppdatering. Det bekreftede svaret følger så snart du kan bevise det. Et raskt og ærlig «vi sjekker» gjør mer for tilliten enn et sent «ikke berørt».
