Send en første udtalelse (holding statement) inden for få timer, et bekræftet svar, så snart du kan bevise det, og en opfølgning, når noget ændrer sig. Sig, hvad du ved, hvad du stadig tjekker, og hvornår du opdaterer. Byg hvert "ikke berørt" på det, dine builds faktisk installerede i angrebsvinduet, ikke på dagens lockfile.
Dette indlæg handler om, hvad du skal sige, hvornår, og med hvad som belæg. For selve undersøgelsen, altså hvordan du finder ud af, om en sårbar komponent er i dine produkter, og siden hvornår, så se er vi berørt af en CVE?.
Hvorfor kunderne spørger dig og ikke pakkeregistret
Ugen efter et meget omtalt angreb, fortalte en lille softwareleverandør os, sendte hans kunder ham sms'er: Er jeres ting sikre? Er mine ting sikre? Hans kunder håndterer følsomme data, hans team har ingen sikkerhedsspecialist, og spørgsmålet krævede et svar samme dag.
Kunderne spørger ikke, om en pakke blev kompromitteret. Det har registret og forskerne allerede sagt. De spørger, om det, du har leveret til dem, indeholder den, fordi dit produkt er deres eksponering. De har selv kunder, auditorer eller myndigheder, der stiller dem det samme spørgsmål. I regulerede forsyningskæder som halvledere, industrielt udstyr og sundhed er spørgsmålet kontraktligt, ikke nysgerrighed.
De spørger også igen, hvis dit svar ikke kan efterprøves. "Vi er ikke berørt" uden noget bag er et løfte; "vi har tjekket hvert release-build fra 24. til 31. marts, og intet af dem installerede de berørte versioner" er en udtalelse, de kan regne med.
Fire nylige angreb og det spørgsmål, hvert af dem rejste
Det rigtige svar afhænger af, hvordan angrebet virkede, så en skabelon alene er ikke nok. For hvert af disse afgør én kendsgerning, hvad "berørt" betyder for en leverandør.
Bagdøren i xz Utils (CVE-2024-3094), offentliggjort 29. marts 2024. Andres Freund fandt en bagdør i xz version 5.6.0 og 5.6.1. Release-tarballene indeholdt kode, der ikke var i Git-repositoriet, og den indsatte bagdøren under buildet. NVD og Red Hat giver den begge 10.0 under CVSS 3.1. Den nåede primært rolling- og testdistributioner: Debian testing, unstable og experimental, Fedora Rawhide og 41, openSUSE Tumbleweed og Kali, mens stabile udgivelser ikke var berørt. Spørgsmålet, det rejste: Indeholder et image eller en enhed, vi har leveret, xz 5.6.0 eller 5.6.1, og hvilket base-image brugte hvert build?
npm-ormen Shai-Hulud, i bølger siden september 2025. Inficerede pakker kører et script ved installation, der stjæler npm-, GitHub- og cloud-legitimationsoplysninger og bruger dem til at udgive inficerede versioner af flere pakker. Spørgsmålet, det rejste: Installerede et CI-job en inficeret version, og blev vores publiceringstokens eksponeret, så vi selv blev en spreder? Vores Shai-Hulud-side lister hver bølge, og hvordan du tjekker.
LiteLLM på PyPI, 24. marts 2026. Version 1.82.7 og 1.82.8 blev uploadet direkte til PyPI med kode, der stjal legitimationsoplysninger, og som aldrig var i projektets GitHub-repository. I 1.82.8 kørte en .pth-fil payloadet, hver gang en Python-fortolker startede, ikke kun når LiteLLM blev importeret; den indsamlede miljøvariabler, SSH-nøgler, cloud-legitimationsoplysninger og Kubernetes-secrets. HiddenLayer kobler angrebet til TeamPCP, der også ramte værktøjer fra Trivy og Checkmarx samme måned. LiteLLM's egen advisory giver to forklaringer på den første adgang: den sporer kompromitteringen til Trivy-afhængigheden i sit workflow til sikkerhedsscanning i CI og skriver, at en maintainers PyPI-konto kan være blevet kompromitteret. Selv eksponeringsvinduet er forskelligt i samme advisory: omkring 40 minutter ét sted og 10:39 til 16:00 UTC et andet. Spørgsmålet, det rejste: Indeholdt et build eller en leveret container de versioner, og hvilke secrets var til stede i det miljø?
axios på npm, 31. marts 2026. En angriber overtog en maintainers npm-konto og udgav axios 1.14.1 og 0.30.4, som tilføjede en afhængighed, [email protected], hvis installationsscript lagde en trojaner til fjernadgang til macOS, Windows og Linux. Datadog angiver vinduet til 00:21 til 03:25 UTC; ifølge Snyk blev versionerne fjernet kl. 03:29 UTC. Spørgsmålet, det rejste: Resolvede et build de versioner i det vindue? En lockfile, der var committet før vinduet, svarer "nej" for de builds, der brugte den, og siger intet om builds, der kørte npm install uden den.
| Angreb | Økosystem | Berørte versioner | Vindue | Hvad "berørt" betyder for en leverandør |
|---|---|---|---|---|
| xz Utils | Linux-distributioner | 5.6.0, 5.6.1 | Uger, indtil offentliggørelsen 29. marts 2024 | Du leverede den, i et image eller en enhed bygget på en berørt distribution |
| Shai-Hulud | npm | Hundredvis af pakker pr. bølge | Timer til dage pr. bølge | Du byggede med den, og dine tokens kan have spredt den; du kan også have leveret den |
| LiteLLM | PyPI | 1.82.7, 1.82.8 | 24. marts 2026, fra 10:39 UTC (kilderne er uenige om slutningen) | Du byggede med den eller leverede den, og secrets i det miljø kan være stjålet |
| axios | npm | 1.14.1, 0.30.4 | 31. marts 2026, omkring 00:21 til 03:25 UTC | Du byggede med den i vinduet; trojaneren kørte på build-maskinen |
De samme spørgsmål dukker op ved en kritisk sårbarhed, der ikke er et forsyningskædeangreb. Da PHP2Shell blev udnyttet i oktober 2026, spurgte kunderne til hvert produkt, der leveres med PHP, hvilke af deres versioner der har en berørt PHP. Trinene nedenfor gælder uændret.
Svaret har tre faser
| Fase | Hvornår | Hvad du sender |
|---|---|---|
| Første udtalelse | Inden for få timer efter nyheden | Hvad du ved, hvad du tjekker, hvornår du opdaterer |
| Bekræftet svar | Så snart du kan bevise det, som regel på dag ét | "Ikke berørt" for navngivne versioner, eller "berørt" med, hvad man skal gøre |
| Opfølgning | Når rettelsen leveres, når du lærer noget nyt, når du lukker sagen | Den samme meddelelse, revideret |
Den første time: den første udtalelse
En første udtalelse er den første offentlige udtalelse, du kommer med, før kendsgerningerne er på plads. Sig noget sandt, hurtigt. Tavshed bliver fyldt ud med antagelser, og en kunde, der intet hører fra dig, går ud fra, at du ikke har opdaget det.
- Hvem og hvor. Én navngiven afsender, i den kanal kunden brugte, plus din sikkerhedsside. Én fælles tekst slår improviserede svar: Den forbliver konsistent, og juridisk gennemgår den én gang.
- Hvad den indeholder. At du kender til angrebet, at du tjekker dine produkter og build-systemer, hvad du ved indtil nu, hvornår næste opdatering kommer, og hvem man kan kontakte.
- Hvad den ikke må indeholde. "Vi er ikke berørt", før du har tjekket, spekulationer om angriberen eller skyldfordeling.
Skabelon 1: første udtalelse
Emne: [navn på angrebet]: vores første udtalelse
Vi er bekendt med den rapporterede kompromittering af [pakke eller projekt] ([berørte versioner], udgivet [dato]). Vores sikkerhedsteam gennemgår hver release af [produkt] og vores build-systemer for de berørte versioner. Indtil videre har vi [ikke fundet berørte versioner i de produkter, der er tjekket / endnu ikke afsluttet gennemgangen]. Vi sender en opdatering senest [dato og klokkeslæt, tidszone]. Har I spørgsmål i mellemtiden, er I velkomne til at kontakte [navn, sikkerhedskontaktadresse]. Vi vil ikke spekulere i konsekvenserne, før gennemgangen er afsluttet.Til en sms eller chat er to sætninger nok:
Vi kender til kompromitteringen i forbindelse med [navn på angrebet] og er i gang med at tjekke hver release af [produkt] og vores builds. I får et bekræftet svar fra os senest [klokkeslæt].Få jurister til at godkende alle tre skabeloner, før du får brug for dem.
Dag ét: bekræft, med dokumentation
To udfald er mulige, og hvert kræver sin egen dokumentation. Til et "ikke berørt"-svar skal du indsamle:
- den berørte pakke og versioner, fra advisoryen eller forskernes gennemgang
- dine produkter og de versioner, kunderne faktisk kører
- for hver af de versioner det build, der producerede den, og registreringen af, hvad det build installerede, ikke den nuværende lockfile
- hvert build, der kørte i angrebsvinduet, også CI-jobs, der aldrig producerede en release
- for orme, der stjæler tokens: om der var CI-secrets til stede i jobs, der kunne have kørt den ondsindede kode
Er vi berørt af en CVE? forklarer, hvordan du fastlægger hver af disse.
Hver udtalelse, du kommer med, skal være underbygget af noget, du kan vise:
| Udtalelse | Hvad du skal kunne vise | Hvad der ikke er nok |
|---|---|---|
| "Produkt X version Y indeholder ikke pakke Z" | Den SBOM, der er registreret fra release-buildet af version Y | En scanning af det nuværende repository |
| "Ingen af vores builds installerede de kompromitterede versioner" | Installationsregistreringer for hvert build i vinduet | En lockfile, som nogle jobs går udenom |
| "Vores release-pipeline blev ikke kompromitteret" | Registreringer af netværk og brug af secrets i vinduet | Fraværet af alarmer |
| "Kunder på version Y er sikre efter opgradering" | Registreringen af det rettede build og de legitimationsoplysninger, du har roteret | En post i changeloggen |
Skabelon 2: ikke berørt
Emne: [navn på angrebet]: [produkt] er ikke berørt
Vi har afsluttet vores gennemgang i forbindelse med kompromitteringen af [pakke] ([berørte versioner]). Følgende versioner af [produkt] er ikke berørt: [liste over gennemgåede produkter og versioner]. Vi har gennemgået hvert release-build og CI-build, der kørte mellem [startdato] og [slutdato]. Denne udtalelse bygger på registreringen af de komponenter, som hvert release-build installerede, ikke på en scanning af vores nuværende kildekode. Ingen af disse builds installerede de berørte versioner. Hvis I har brug for dokumentationen, kan vi sende SBOM'en for de versioner, I kører, eller en VEX-erklæring. Hvis vi får kendskab til noget, der ændrer denne vurdering, giver vi jer besked. Kontakt: [navn, sikkerhedskontaktadresse].Sig "ikke berørt" for navngivne versioner. Skriv aldrig "100 % sikker". Hvis kunden derefter beder om den fulde SBOM, så se at besvare kunders SBOM-forespørgsler.
Skabelon 3: berørt, med afhjælpning
Emne: [navn på angrebet]: handling påkrævet for [produkt] version [x til y]
Vores gennemgang i forbindelse med kompromitteringen af [pakke] har vist, at [produkt] version [x til y] er berørt. Det første berørte build blev produceret den [dato]; version [z], udgivet [dato], indeholder ikke længere [pakkeversion].
Hvad det betyder: [risikoen i almindeligt sprog, for eksempel "en komponent, der er installeret i disse versioner, kan sende legitimationsoplysninger fra det system, den kører på, til en ekstern server"].
Hvad I skal gøre nu: Opgradér til [produkt] [z]. Hvis I ikke kan opgradere med det samme, [afhjælpning, for eksempel blokér udgående forbindelser til de nævnte hosts]. Hvis I har brugt [produkt] version [x til y] i [miljø], så rotér de [legitimationsoplysninger eller nøgler], der var tilgængelige for det.
Hvad vi har gjort: Vi har fjernet de berørte versioner fra vores builds, genbygget [produkt] fra rene afhængigheder, roteret de legitimationsoplysninger, vores build-systemer bruger, og [andre tiltag]. [Vi har underrettet de relevante myndigheder, hvor det kræves.]
Vi sender næste opdatering senest [dato], eller før, hvis noget ændrer sig. Kontakt: [navn, sikkerhedskontaktadresse].En "berørt"-meddelelse kan også være en juridisk pligt; se afsnittet om rapportering nedenfor.
Hvor VEX og CSAF passer ind. En "ikke berørt"- eller "rettet"-udtalelse kan offentliggøres som VEX, så kundernes scannere holder op med at markere pakken. Større kunder forventer måske også en maskinlæsbar advisory; CSAF er det format, de fleste af dem beder om.
Opfølgning: luk den ordentligt
Send en opfølgning, når rettelsen leveres, når din undersøgelse finder noget nyt, og en afsluttende besked, når sagen lukkes. Hold én advisory pr. hændelse, og revidér den i stedet for at sende en ny hver gang (opdatér, erstat ikke). Registrér, hvad du fortalte hvem og hvornår: Den næste audit eller kundens sikkerhedsspørgeskema vil spørge om det.
Hvad du skal sige, når du ikke ved det endnu
"Det ved vi ikke endnu" skaber mere tillid end et "ikke berørt", du må trække tilbage. Formuleringer, der er ærlige uden at skabe unødig uro:
- "Vi har ikke fundet [pakke] i [produkter, der er tjekket indtil nu]. Vi tjekker stadig [resterende produkter eller build-systemer] og opdaterer jer senest [klokkeslæt]."
- "De versioner, I kører, blev bygget før angrebsvinduet. Vi bekræfter nu, at intet senere build har erstattet dem."
- "Vi tjekker, om nogen af vores build-systemer har kørt de berørte versioner. Jeres installerede produkt er et separat spørgsmål, og vi besvarer begge."
Formuleringer, du bør undgå:
- "Overhovedet ingen påvirkning"
- "Fuldstændig sikker"
- "Ikke berørt af noget forsyningskædeangreb"
- "Vores scanner fandt intet"
Når angrebet bliver en rapporteringspligt
Hvis du sælger produkter med digitale elementer i EU, har Cyber Resilience Act anvendt sine rapporteringsforpligtelser siden 11. september 2026, den dag ENISA lancerede den fælles rapporteringsplatform. En aktivt udnyttet sårbarhed i dit produkt eller en alvorlig hændelse, der påvirker dets sikkerhed, udløser en tidlig advarsel inden for 24 timer efter, at du er blevet opmærksom på den, en underretning inden for 72 timer og en endelig rapport, indsendt via platformen til din koordinerende CSIRT og ENISA. CRA-guiden gennemgår trinene.
Om en kompromitteret afhængighed, du har leveret, eller en kompromittering af din egen build-pipeline opfylder de definitioner, er en vurdering for dig og dine jurister, ikke for dette indlæg. Forordningen definerer begreberne:
- En "aktivt udnyttet sårbarhed" er "en sårbarhed, for hvilken der er pålidelig dokumentation for, at en ondsindet aktør har udnyttet den i et system uden tilladelse fra systemejeren" (artikel 3, nr. 42).
- En hændelse er alvorlig, hvis "den har eller kan have en negativ indvirkning på et produkt med digitale elementers evne til at beskytte tilgængeligheden, autenticiteten, integriteten eller fortroligheden af følsomme eller vigtige data eller funktioner", eller hvis "den har ført til eller kan føre til indførelse eller udførelse af ondsindet kode" i produktet eller i en brugers systemer (artikel 14, stk. 5).
Artikel 14(8) tilføjer en pligt over for brugerne: at underrette de berørte brugere og, hvor det er relevant, alle brugere om sårbarheden eller hændelsen og om eventuelle afhjælpende foranstaltninger, de kan træffe, "hvor det er relevant, i et struktureret, maskinlæsbart format, der let kan behandles automatisk". Skabelon 3 kan være en del af at opfylde den pligt.
Andre regelsæt gælder også. Under NIS2 underretter væsentlige og vigtige enheder deres CSIRT eller kompetente myndighed om væsentlige hændelser, og mange kundekontrakter har deres egne underretningsklausuler med egne frister.
Vær klar før det næste
- En registrering af, hvad hvert release-build installerede, gemt i produktets supportperiode (SBOM'er fra build-tidspunktet).
- En liste over, hvilke kunder der kører hvilke versioner.
- De tre skabeloner ovenfor, godkendt af juridisk afdeling.
- En navngiven afsender og en kanal for hver type kunde.
- En sikkerhedsside og en
security.txt-fil, hvor opdateringerne lægges (koordineret offentliggørelse af sårbarheder). - Egress-kontrol i CI, så en kompromitteret pakke ikke kan sende secrets til en host, buildet ikke har brug for (egress-politik for GitHub Actions).
Ved hændelser, der kommer i hundredvis i stedet for én ad gangen, så se at skalere et PSIRT.
Hvor CRACI passer ind
Dokumentationstabellen ovenfor beder igen og igen om én ting: en registrering af, hvad hvert release-build installerede. Det er det, CRACI gemmer. CRACI kører dine GitHub Actions-builds på sine egne runners og registrerer hver pakke, hvert job faktisk trak ind, også pakker hentet af installationsscripts og pakker gendannet fra caches. Hvert tidligere builds SBOM gemmes, så "installerede et build axios 1.14.1 i vinduet?" besvares ud fra build-historikken, med den periode, du var berørt, så langt tilbage som din opbevaringsperiode rækker.
Kendte ondsindede releases, der har en offentliggjort CVE, som bagdøren i xz, markeres som enhver anden sårbarhed, og en policy gate kan blokere builds, der indeholder dem. CRACI opdager ikke en ny ondsindet pakke ud fra dens adfærd eller omdømme.
CRACI's egress-politik blokerer forbindelser til hosts, et build ikke har brug for, hvilket begrænser, hvad et ondsindet installationsscript kan sende ud, selv ved et angreb, ingen har set før. Når en kunde beder om dokumentationen, kan du eksportere SBOM'en for de versioner, kunden kører, som CycloneDX eller SPDX og sende den. CRACI understøtter VEX.
Besvar "var vi berørt?" ud fra din build-historik, eller læs mere om, hvordan forsyningskædeangreb virker.
Når CRACI ikke er svaret
- Du har brug for hjælp til selve kommunikationen. PR og juridisk rådgivning er en anden opgave.
- Den berørte software blev ikke bygget på CRACI. CRACI registrerer GitHub Actions-builds, der kører på dets runners; andre CI-systemer er på roadmappen.
- Spørgsmålet handler om en leverandørs produkt, du ikke selv har bygget. Leverandør-SBOM'er kan tilføjes til CRACI, men svaret er kun så godt som leverandørens SBOM.
- Du skal fange en helt ny ondsindet pakke, før der findes en advisory. CRACI markerer kendte ondsindede releases, når en advisory med en CVE er offentliggjort; det opdager ikke malware ud fra adfærd eller omdømme (at reagere på zero-day-sårbarheder).
Ofte stillede spørgsmål
Hvad skal jeg sige til kunderne, når et forsyningskædeangreb er i nyhederne?
Send en første udtalelse inden for få timer: Du kender til angrebet, du tjekker dine produkter og builds, hvad du ved indtil nu, og hvornår du opdaterer. Følg op med et bekræftet svar for navngivne produktversioner, så snart du kan underbygge det med build-registreringer, og en opfølgning, når noget ændrer sig.
Hvad bør en første udtalelse sige?
Hvad der skete, i én sætning, at du tjekker dine produkter og build-systemer, hvad du har fundet indtil nu, tidspunktet for næste opdatering og en kontaktperson. Den må ikke sige "ikke berørt", før du har tjekket, spekulere om angriberen eller give nogen skylden.
Hvordan siger jeg "vi er ikke berørt" uden at love for meget?
Navngiv de produkter og versioner, du har tjekket, den periode af builds, du har tjekket, og den dokumentation, du har brugt, for eksempel registreringen af de komponenter, hvert release-build installerede. Sig "ikke berørt" for de versioner, tilbyd SBOM'en eller en VEX-erklæring, og lov at opdatere, hvis noget ændrer sig. Undgå "100 % sikker" eller "fuldstændig sikker".
Hvad skal en "vi var berørt"-meddelelse til kunderne indeholde?
Hvilke produkter og versioner der er berørt, siden hvornår og frem til hvilken rettet version, risikoen i almindeligt sprog, hvad kunden skal gøre nu (opgradere, rotere legitimationsoplysninger, blokere hosts), hvad du allerede har gjort, hvornår næste opdatering kommer, og hvem man kan kontakte.
Hvilken dokumentation bør ligge bag en "ikke berørt"-udtalelse?
For hver version, kunderne kører, registreringen af, hvad det build, der producerede den, installerede, ikke dagens lockfile. Tilføj registreringerne af hvert build, der kørte i angrebsvinduet, og ved angreb, der stjæler legitimationsoplysninger, om der var secrets til stede i jobs, der kunne have kørt den ondsindede kode.
Skal jeg rapportere et forsyningskædeangreb under Cyber Resilience Act?
Muligvis. Siden 11. september 2026 skal producenter af produkter med digitale elementer, der sælges i EU, rapportere aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker produktets sikkerhed: en tidlig advarsel inden for 24 timer, en underretning inden for 72 timer og en endelig rapport. Om et givet angreb er omfattet, er en vurdering for dig og dine jurister.
Hvor hurtigt bør vi svare kunderne?
Inden for få timer med en første udtalelse, også selvom den kun siger, at du tjekker, og hvornår du opdaterer. Det bekræftede svar følger, så snart du kan bevise det. Et hurtigt, ærligt "vi tjekker" gør mere for tilliden end et sent "ikke berørt".
