Skicka ett första uttalande inom några timmar, ett bekräftat svar så snart du kan bevisa det och en uppföljning när något förändras. Säg vad du vet, vad du fortfarande kontrollerar och när du uppdaterar. Grunda varje ”inte berörd” på vad dina byggen faktiskt installerade under attackfönstret, inte på dagens lockfil.
Det här inlägget handlar om vad du ska säga, när och med vilket underlag. För själva utredningen, hur du tar reda på om en sårbar komponent finns i dina produkter och sedan när, se är vi drabbade av en CVE?.
Varför kunderna frågar dig och inte paketregistret
Veckan efter en attack som rapporterades brett, berättade en liten programvaruleverantör för oss, skickade kunderna sms till honom: är era grejer säkra? Är mina grejer säkra? Hans kunder hanterar känsliga uppgifter, hans team har ingen säkerhetsspecialist och frågan behövde ett svar samma dag.
Kunderna frågar inte om ett paket har komprometterats. Det har registret och forskarna redan sagt. De frågar om det du har levererat till dem innehåller det, eftersom din produkt är deras exponering. De har egna kunder, revisorer eller tillsynsmyndigheter som ställer samma fråga till dem. I reglerade leveranskedjor som halvledare, industriutrustning och hälsa är frågan avtalsmässig, inte nyfikenhet.
De frågar också igen om ditt svar inte går att kontrollera. ”Vi är inte berörda” utan något bakom är ett löfte; ”vi kontrollerade varje releasebygge från 24 till 31 mars och inget installerade de berörda versionerna” är ett uttalande de kan lita på.
Fyra aktuella attacker och frågan som var och en väckte
Rätt svar beror på hur attacken fungerade, så en mall räcker inte ensam. För var och en av dessa avgör ett enda faktum vad ”berörd” betyder för en leverantör.
Bakdörren i xz Utils (CVE-2024-3094), offentliggjord 29 mars 2024. Andres Freund hittade en bakdörr i xz version 5.6.0 och 5.6.1. Releasearkiven innehöll kod som inte fanns i Git-repot, och den injicerade bakdörren under bygget. NVD och Red Hat ger den båda 10.0 enligt CVSS 3.1. Den nådde främst rullande distributioner och testdistributioner: Debian testing, unstable och experimental, Fedora Rawhide och 41, openSUSE Tumbleweed och Kali, medan stabila releaser inte berördes. Frågan den väckte: innehåller någon avbild eller enhet som vi har levererat xz 5.6.0 eller 5.6.1, och vilken basavbild använde varje bygge?
Masken Shai-Hulud på npm, i vågor sedan september 2025. Infekterade paket kör ett skript vid installationen som stjäl inloggningsuppgifter till npm, GitHub och molntjänster och använder dem för att publicera infekterade versioner av fler paket. Frågan den väckte: installerade något CI-jobb en infekterad version, och exponerades våra publiceringstokens, vilket skulle göra oss till en spridare? Vår post om Shai-Hulud listar varje våg och hur du kontrollerar.
LiteLLM på PyPI, 24 mars 2026. Version 1.82.7 och 1.82.8 laddades upp direkt till PyPI med kod som stjäl inloggningsuppgifter och som aldrig fanns i projektets GitHub-repo. I 1.82.8 körde en .pth-fil nyttolasten varje gång en Python-tolk startade, inte bara när LiteLLM importerades; den samlade in miljövariabler, SSH-nycklar, inloggningsuppgifter till molntjänster och Kubernetes-hemligheter. HiddenLayer kopplar attacken till TeamPCP, som också angrep verktyg från Trivy och Checkmarx samma månad. LiteLLM:s eget säkerhetsmeddelande ger två förklaringar till den första åtkomsten: det spårar intrånget till Trivy-beroendet i sitt arbetsflöde för säkerhetsskanning i CI och skriver att en maintainers PyPI-konto kan ha komprometterats. Till och med exponeringsfönstret skiljer sig inom samma säkerhetsmeddelande, omkring 40 minuter på ett ställe och 10:39 till 16:00 UTC på ett annat. Frågan den väckte: innehöll ett bygge eller en levererad container de versionerna, och vilka hemligheter fanns i den miljön?
axios på npm, 31 mars 2026. En angripare tog över en maintainers npm-konto och publicerade axios 1.14.1 och 0.30.4, som lade till ett beroende, [email protected], vars installationsskript släppte en trojan för fjärråtkomst för macOS, Windows och Linux. Datadog anger fönstret till 00:21 till 03:25 UTC; enligt Snyk togs versionerna bort 03:29 UTC. Frågan den väckte: löste något bygge upp de versionerna under det fönstret? En lockfil som checkats in före fönstret svarar ”nej” för byggen som använde den, och säger ingenting om byggen som körde npm install utan den.
| Attack | Ekosystem | Berörda versioner | Fönster | Vad ”berörd” betyder för en leverantör |
|---|---|---|---|---|
| xz Utils | Linux-distributioner | 5.6.0, 5.6.1 | Veckor, fram till offentliggörandet 29 mars 2024 | Du levererade den, i en avbild eller enhet byggd på en berörd distribution |
| Shai-Hulud | npm | Hundratals paket, per våg | Timmar till dagar per våg | Du byggde med den, och dina tokens kan ha spridit den; du kan också ha levererat den |
| LiteLLM | PyPI | 1.82.7, 1.82.8 | 24 mars 2026, från 10:39 UTC (källorna skiljer sig om slutet) | Du byggde med den eller levererade den, och hemligheter i den miljön kan ha stulits |
| axios | npm | 1.14.1, 0.30.4 | 31 mars 2026, ungefär 00:21 till 03:25 UTC | Du byggde med den under fönstret; trojanen kördes på byggmaskinen |
Samma frågor dyker upp för en kritisk sårbarhet som inte är en attack mot leveranskedjan. När PHP2Shell utnyttjades i oktober 2026 frågade kunderna till varje produkt som levereras med PHP vilka av deras versioner som innehåller en berörd PHP. Stegen nedan gäller oförändrade.
Svaret har tre steg
| Steg | När | Vad du skickar |
|---|---|---|
| Första uttalande | Inom några timmar efter nyheten | Vad du vet, vad du kontrollerar, när du uppdaterar |
| Bekräftat svar | Så snart du kan bevisa det, oftast första dagen | ”Inte berörd” för namngivna versioner, eller ”berörd” med vad som ska göras |
| Uppföljning | När rättningen levereras, när du får veta något nytt, när du stänger ärendet | Samma meddelande, reviderat |
Den första timmen: det första uttalandet
Ett första uttalande (holding statement) är det första offentliga uttalande du gör innan fakta finns på plats. Säg något som är sant, snabbt. Tystnad fylls med antaganden, och en kund som inte hör något från dig antar att du inte har märkt något.
- Vem och var. En namngiven avsändare, i den kanal som kunden använde, plus din säkerhetssida. En gemensam text slår svar skrivna i stunden: den förblir konsekvent, och juristerna granskar den en gång.
- Vad det innehåller. Att du känner till attacken, att du kontrollerar dina produkter och byggsystem, vad du vet hittills, när nästa uppdatering kommer och vem man kan kontakta.
- Vad det inte får innehålla. ”Vi är inte berörda” innan du har kontrollerat, spekulationer om angriparen eller skuldbeläggning.
Mall 1: första uttalande
Ämne: [Attackens namn]: vårt första uttalande
Vi känner till den rapporterade komprometteringen av [paket eller projekt] ([berörda versioner], publicerade [datum]). Vårt säkerhetsteam kontrollerar varje release av [produkt] och våra byggsystem med avseende på de berörda versionerna. Hittills har vi [inte hittat några berörda versioner i de produkter som kontrollerats / ännu inte slutfört kontrollen]. Vi skickar en uppdatering senast [datum och tid, tidszon]. Om du har frågor under tiden, kontakta [namn, adress till säkerhetskontakt]. Vi spekulerar inte om konsekvenserna innan kontrollen är klar.För ett sms eller en chatt räcker två meningar:
Vi känner till komprometteringen i [attackens namn] och kontrollerar nu varje release av [produkt] och våra byggen. Du får ett bekräftat svar från oss senast [tid].Låt juristerna godkänna alla tre mallarna innan du behöver dem.
Första dagen: bekräfta, med belägg
Två utfall är möjliga, och vart och ett behöver sina egna belägg. För svaret ”inte berörd”, samla in:
- det berörda paketet och versionerna, från säkerhetsmeddelandet eller forskarnas genomgång
- dina produkter och de versioner som kunderna faktiskt kör
- för var och en av de versionerna, bygget som producerade den och registreringen av vad bygget installerade, inte den aktuella lockfilen
- varje bygge som kördes under attackfönstret, inklusive CI-jobb som aldrig producerade någon release
- för maskar som stjäl tokens, om några CI-hemligheter fanns i jobb som kan ha kört den skadliga koden
Är vi drabbade av en CVE? förklarar hur du fastställer vart och ett av dessa.
Varje uttalande du gör måste stödjas av något du kan visa upp:
| Uttalande | Vad du måste kunna visa | Vad som inte räcker |
|---|---|---|
| ”Produkt X version Y innehåller inte paket Z” | SBOM:en som registrerades från releasebygget av version Y | En skanning av det aktuella repot |
| ”Inget av våra byggen installerade de komprometterade versionerna” | Installationsregistreringar för varje bygge under fönstret | En lockfil som vissa jobb kringgår |
| ”Vårt releaseflöde komprometterades inte” | Registreringar av nätverkstrafik och användning av hemligheter under fönstret | Att inga larm har utlösts |
| ”Kunder på version Y är säkra efter uppgradering” | Registreringen av det åtgärdade bygget och de inloggningsuppgifter du har bytt | En post i ändringsloggen |
Mall 2: inte berörd
Ämne: [Attackens namn]: [produkt] berörs inte
Vi har slutfört vår kontroll av komprometteringen av [paket] ([berörda versioner]). Följande versioner av [produkt] berörs inte: [lista över kontrollerade produkter och versioner]. Vi har kontrollerat varje releasebygge och CI-bygge som kördes mellan [startdatum] och [slutdatum]. Detta uttalande bygger på registreringen av de komponenter som varje releasebygge installerade, inte på en skanning av vår nuvarande källkod. Inget av dessa byggen installerade de berörda versionerna. Om du behöver beläggen kan vi skicka SBOM:en för de versioner du kör, eller ett VEX-uttalande. Om vi får veta något som ändrar denna bedömning meddelar vi dig. Kontakt: [namn, adress till säkerhetskontakt].Säg ”inte berörd” för namngivna versioner. Skriv aldrig ”100 % säkert”. Om kunden sedan ber om hela SBOM:en, se besvara kunders SBOM-förfrågningar.
Mall 3: berörd, med mitigering
Ämne: [Attackens namn]: åtgärd krävs för [produkt] version [x till y]
Vår kontroll av komprometteringen av [paket] visade att [produkt] version [x till y] berörs. Det första berörda bygget producerades [datum]; version [z], som släpptes [datum], innehåller inte längre [paketversion].
Vad detta innebär: [risken i klartext, till exempel ”en komponent som installerats i dessa versioner kan skicka inloggningsuppgifter från det system den körs på till en extern server”].
Vad du bör göra nu: uppgradera till [produkt] [z]. Om du inte kan uppgradera direkt, [mitigering, till exempel blockera utgående anslutningar till de listade värdarna]. Om du har använt [produkt] version [x till y] i [miljö], byt de [inloggningsuppgifter eller nycklar] som var tillgängliga för den.
Vad vi har gjort: vi har tagit bort de berörda versionerna från våra byggen, byggt om [produkt] från rena beroenden, bytt de inloggningsuppgifter som våra byggsystem använder och [övriga åtgärder]. [Vi har underrättat berörda myndigheter där det krävs.]
Vi skickar nästa uppdatering senast [datum], eller tidigare om något förändras. Kontakt: [namn, adress till säkerhetskontakt].Ett meddelande om ”berörd” kan också vara en rättslig skyldighet; se avsnittet om rapportering nedan.
Var VEX och CSAF passar in. Ett uttalande om ”inte berörd” eller ”åtgärdad” kan publiceras som VEX, så att kundernas skannrar slutar flagga paketet. Större kunder kan dessutom vänta sig ett maskinläsbart säkerhetsmeddelande; CSAF är det format som de flesta av dem efterfrågar.
Uppföljning: avsluta ordentligt
Skicka en uppföljning när rättningen levereras, när din utredning hittar något nytt och ett sista meddelande när ärendet stängs. Ha ett säkerhetsmeddelande per incident och revidera det i stället för att skicka ett nytt varje gång (uppdatera, ersätt inte). Registrera vad du sa till vem och när: nästa revision eller kunds säkerhetsenkät kommer att fråga.
Vad du säger när du inte vet ännu
”Vi vet inte ännu” bygger mer förtroende än ett ”inte berörd” som du måste ta tillbaka. Formuleringar som är ärliga utan att oroa någon:
- ”Vi har inte hittat [paket] i [de produkter som kontrollerats hittills]. Vi kontrollerar fortfarande [återstående produkter eller byggsystem] och uppdaterar dig senast [tid].”
- ”De versioner du kör byggdes före attackfönstret. Vi bekräftar att inget senare bygge har ersatt dem.”
- ”Vi kontrollerar om något av våra byggsystem körde de berörda versionerna. Din installerade produkt är en separat fråga, och vi besvarar båda.”
Formuleringar att undvika:
- ”Ingen påverkan över huvud taget”
- ”Helt säkert”
- ”Opåverkade av alla attacker mot leveranskedjan”
- ”Vår skanner hittade ingenting”
När attacken blir en rapporteringsskyldighet
Om du säljer produkter med digitala element i EU har Cyber Resilience Act tillämpat sina rapporteringsskyldigheter sedan den 11 september 2026, samma dag som ENISA lanserade den gemensamma rapporteringsplattformen. En aktivt utnyttjad sårbarhet i din produkt, eller en allvarlig incident som påverkar dess säkerhet, utlöser en tidig varning inom 24 timmar från att du fått kännedom om den, en anmälan inom 72 timmar och en slutrapport, som lämnas in via plattformen till din samordnande CSIRT och ENISA. CRA-guiden går igenom stegen.
Om ett komprometterat beroende som du har levererat, eller en kompromettering av ditt eget byggflöde, uppfyller de definitionerna är en bedömning för dig och dina jurister, inte för det här inlägget. Förordningen definierar begreppen:
- En ”aktivt utnyttjad sårbarhet” är ”en sårbarhet för vilken det finns tillförlitliga belägg för att en illasinnad aktör har utnyttjat den i ett system utan tillstånd från systemets ägare” (artikel 3 punkt 42).
- En incident är allvarlig om ”den negativt påverkar eller kan påverka förmågan hos en produkt med digitala element att skydda tillgängligheten, autenticiteten, integriteten eller konfidentialiteten hos känsliga eller viktiga data eller funktioner”, eller om ”den har lett eller kan leda till att skadlig kod införs eller körs” i produkten eller i en användares system (artikel 14(5)).
Artikel 14(8) lägger till en skyldighet gentemot användarna: informera de berörda användarna, och i förekommande fall alla användare, om sårbarheten eller incidenten och om eventuella mitigeringar de kan tillämpa, ”i förekommande fall i ett strukturerat, maskinläsbart format som lätt kan behandlas automatiskt”. Mall 3 kan vara en del av att uppfylla den skyldigheten.
Andra regelverk gäller också. Enligt NIS2 anmäler väsentliga och viktiga entiteter betydande incidenter till sin CSIRT eller behöriga myndighet, och många kundavtal har egna klausuler om anmälan med egna tidsfrister.
Var redo före nästa gång
- En registrering av vad varje releasebygge installerade, sparad under produktens supportperiod (SBOM:er från byggtiden).
- En lista över vilka kunder som kör vilka versioner.
- De tre mallarna ovan, godkända av juristerna.
- En namngiven avsändare och en kanal för varje typ av kund.
- En säkerhetssida och en
security.txt-fil där uppdateringarna publiceras (samordnat offentliggörande av sårbarheter). - Kontroll av utgående trafik i CI, så att ett komprometterat paket inte kan skicka hemligheter till en värd som bygget inte behöver (egress-policy för GitHub Actions).
För incidenter som kommer i hundratal snarare än en i taget, se skala upp ett PSIRT.
Så passar CRACI in
Tabellen över belägg ovan efterfrågar hela tiden en sak: en registrering av vad varje releasebygge installerade. Det är vad CRACI sparar. CRACI kör dina GitHub Actions-byggen på sina egna runners och registrerar varje paket som varje jobb faktiskt drog in, inklusive paket som hämtas av installationsskript och paket som återställs från cachar. Varje tidigare bygges SBOM sparas, så ”installerade något bygge axios 1.14.1 under fönstret?” besvaras utifrån bygghistoriken, med perioden du var drabbad, så långt tillbaka som din lagring räcker.
Kända skadliga releaser som har en publicerad CVE, till exempel bakdörren i xz, flaggas som vilken annan sårbarhet som helst, och en policykontroll kan blockera byggen som innehåller dem. CRACI upptäcker inte ett nytt skadligt paket utifrån dess beteende eller rykte.
CRACI:s egress-policy blockerar anslutningar till värdar som ett bygge inte behöver, vilket begränsar vad ett skadligt installationsskript kan skicka ut, även vid en attack som ingen har sett tidigare. När en kund ber om beläggen kan du exportera SBOM:en för de versioner kunden kör som CycloneDX eller SPDX och skicka den. CRACI har stöd för VEX.
Besvara ”var vi drabbade?” utifrån din bygghistorik, eller läs mer om hur attacker mot leveranskedjan fungerar.
När CRACI inte är svaret
- Du behöver hjälp med själva kommunikationen. PR och juridisk rådgivning är ett annat jobb.
- Den berörda programvaran byggdes inte på CRACI. CRACI registrerar GitHub Actions-byggen som körs på dess runners; andra CI-system finns på färdplanen.
- Frågan gäller en leverantörs produkt som du inte har byggt. Leverantörers SBOM:er kan läggas till i CRACI, men svaret blir aldrig bättre än leverantörens SBOM.
- Du behöver fånga ett helt nytt skadligt paket innan något säkerhetsmeddelande finns. CRACI flaggar kända skadliga releaser när ett säkerhetsmeddelande med en CVE har publicerats; det upptäcker inte skadlig kod utifrån beteende eller rykte (hantera zero-day-sårbarheter).
Vanliga frågor
Vad säger jag till kunderna när en attack mot leveranskedjan syns i nyheterna?
Skicka ett första uttalande inom några timmar: att du känner till attacken, att du kontrollerar dina produkter och byggen, vad du vet hittills och när du uppdaterar. Följ upp med ett bekräftat svar för namngivna produktversioner så snart du kan stödja det med byggregistreringar, och en uppföljning när något förändras.
Vad bör ett första uttalande innehålla?
Vad som hände i en mening, att du kontrollerar dina produkter och byggsystem, vad du har hittat hittills, tiden för nästa uppdatering och en kontakt. Det får inte säga ”inte berörd” innan du har kontrollerat, spekulera om angriparen eller skuldbelägga någon.
Hur säger jag ”vi är inte berörda” utan att lova för mycket?
Ange vilka produkter och versioner du har kontrollerat, datumintervallet för de byggen du har kontrollerat och de belägg du har använt, till exempel registreringen av de komponenter som varje releasebygge installerade. Säg ”inte berörd” för de versionerna, erbjud SBOM:en eller ett VEX-uttalande och lova att uppdatera om något förändras. Undvik ”100 % säkert” eller ”helt säkert”.
Vad bör ett meddelande till kunderna om att ”vi var berörda” innehålla?
Vilka produkter och versioner som berörs, sedan när och fram till vilken åtgärdad version, risken i klartext, vad kunden bör göra nu (uppgradera, byta inloggningsuppgifter, blockera värdar), vad du redan har gjort, när nästa uppdatering kommer och vem man kan kontakta.
Vilka belägg bör stödja ett uttalande om ”inte berörd”?
För varje version som kunderna kör, registreringen av vad bygget som producerade den installerade, inte dagens lockfil. Lägg till registreringarna för varje bygge som kördes under attackfönstret och, vid attacker som stjäl inloggningsuppgifter, om hemligheter fanns i jobb som kan ha kört den skadliga koden.
Måste jag rapportera en attack mot leveranskedjan enligt Cyber Resilience Act?
Möjligen. Sedan den 11 september 2026 måste tillverkare av produkter med digitala element som säljs i EU rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar produktens säkerhet: en tidig varning inom 24 timmar, en anmälan inom 72 timmar och en slutrapport. Om en viss attack omfattas är en bedömning för dig och dina jurister.
Hur snabbt bör vi svara kunderna?
Inom några timmar med ett första uttalande, även om det bara säger att du kontrollerar och när du uppdaterar. Det bekräftade svaret följer så snart du kan bevisa det. Ett snabbt och ärligt ”vi kontrollerar” gör mer för förtroendet än ett sent ”inte berörd”.
