Åtgärda CVE:er: från säkerhetsmeddelande till ett åtgärdat, levererat bygge

Processen för att åtgärda CVE:er

Att åtgärda en CVE innebär att ta bort en offentliggjord sårbarhet från programvara du kör eller levererar. För din egen kod betyder det en patch. För open source-beroenden, där de flesta CVE:er i en typisk produkt kommer ifrån, betyder det att komma till en version där sårbarheten är åtgärdad. Oavsett vilket är stegen desamma:

1. Hitta varje produkt, bygge och release som innehåller det berörda paketet och den berörda versionen.
2. Bedöm om sårbarheten påverkar dig, och hur allvarligt.
3. Prioritera mot allt annat som är öppet.
4. Åtgärda genom att uppgradera, patcha, ersätta eller, om det inte finns någon rättning, begränsa.
5. Verifiera att den åtgärdade versionen är den som det nya bygget faktiskt innehåller.
6. Dokumentera vad som berördes, vad du beslutade och när rättningen levererades.

Steg 1: hitta varje berört bygge

Den första frågan efter ett säkerhetsmeddelande är var paketet finns. Att besvara den utifrån källkodsrepon går långsamt och blir ofta fel: versionen i en lockfile, versionen som löstes i ett bygge och versionen i en släppt containeravbild kan alla skilja sig åt. Transitiva beroenden och paket som ett bygge laddar ned utanför pakethanteraren syns inte alls i manifest.

Det tillförlitliga svaret kommer från en SBOM för varje release, som matchas löpande mot säkerhetsmeddelanden. Om den SBOM:en registreras under bygget listar den vad bygget faktiskt använde, så matchningen visar vilka levererade byggen som innehåller den sårbara versionen, inte vilka repon som nämner den.

Steg 2: prioritera med allvarlighetsgrad och utnyttjande

Enbart allvarlighetsgrad rankar för många sårbarheter som brådskande. De flesta team kombinerar tre signaler:

Signal	Vad den säger	Publiceras av
CVSS	Hur allvarlig sårbarheten är om den utnyttjas, på en skala från 0 till 10	FIRST (standarden); NVD och leverantörer publicerar poäng
EPSS	Den uppskattade sannolikheten för utnyttjande under de kommande 30 dagarna	FIRST
KEV	Om sårbarheten är känd för att utnyttjas i verkligheten	CISA:s katalog Known Exploited Vulnerabilities

Lägg sedan till din egen kontext: om det berörda paketet levereras till kunder eller bara körs i ett testjobb, och om den sårbara funktionen används över huvud taget. En känt utnyttjad sårbarhet i ett paket som levereras hamnar överst på listan. Prioritering av sårbarheter gör dessa signaler till en metod.

Tidsfrister för åtgärder

• CISA BOD 26-04. Sedan den 10 juni 2026 sätter amerikanska federala myndigheter varje tidsfrist utifrån fyra frågor: är tillgången publikt exponerad, finns sårbarheten i KEV-katalogen, kan utnyttjandet automatiseras, och ger det partiell eller total kontroll. Svaren sträcker sig från 3 dagar, med forensisk triage i de värsta fallen, till åtgärd vid nästa systemuppgradering. Direktivet ersatte BOD 22-01, som gav två veckor för de flesta KEV-poster.
• EU:s Cyber Resilience Act. Tillverkare måste hantera och åtgärda sårbarheter utan dröjsmål, bland annat genom säkerhetsuppdateringar (bilaga I, del II). Sedan den 11 september 2026 startar en aktivt utnyttjad sårbarhet i en produkt också en rapporteringsfrist: en tidig varning inom 24 timmar, en anmälan inom 72 timmar och en slutrapport inom 14 dagar från att en rättning finns tillgänglig.
• Din egen policy. De flesta säkerhetsprogram sätter interna mål utifrån allvarlighetsgrad. Oavsett vilka de är kan du bara klara dem om steg 1 går snabbt.

Steg 3: välj åtgärd

Alternativ	När det ska användas
Uppgradera	Det finns en åtgärdad version. Välj helst den minsta uppgraderingen som innehåller rättningen, för att begränsa inkompatibla ändringar.
Uppgradera föräldrapaketet	Det sårbara paketet är transitivt. En nyare release av det direkta beroendet drar ofta in rättningen.
Tvinga version	Föräldrapaketet har inte släppt någon rättning. Tvinga den transitiva versionen med npm overrides, Yarn resolutions eller pnpm.overrides, och testa.
Patcha eller bakåtporta	Du kan inte gå över till den åtgärdade huvudversionen ännu. Tillämpa uppströmsrättningen på versionen du använder.
Ersätt	Paketet underhålls inte eller fortsätter att ge CVE:er. Gå över till ett alternativ.
Begränsa och dokumentera	Det finns ännu ingen rättning, eller så berörs inte din produkt. Minska exponeringen och dokumentera bedömningen, till exempel som ett VEX-uttalande.

Det mesta i det här steget går att automatisera, från att välja version till att öppna pull requesten. Automatiserad åtgärd av sårbarheter tar upp vad du ska automatisera och vad du ska låta en människa sköta.

Steg 4: en sammanslagen rättning är inte en levererad rättning

Pull requesten slogs samman, så CVE:n är stängd. Inte nödvändigtvis. Rättningen finns i repot, men ett bygge återställer en inaktuell cache, en basavbild innehåller fortfarande det gamla paketet eller en releasegren fick aldrig ändringen. I ärendet står det åtgärdat medan produkten fortfarande levereras med den sårbara versionen.

Följ upp från andra hållet: kontrollera SBOM:en för nästa bygge och bekräfta att den sårbara versionen är borta. När den SBOM:en registrerar vad bygget faktiskt hämtade, inklusive paket som återställs från cachar, besvarar kontrollen den fråga som kunden, revisorn och tillsynsmyndigheten egentligen ställer.

Så stöder CRACI åtgärd av CVE:er

• Hitta. CRACI registrerar paketen som varje GitHub Actions-jobb hämtade, inklusive transitiva beroenden och paket som återställs från cachar, och omvärderar bevakade SBOM:er löpande. Organisationsvyer samlar fynd över byggen och repon, så att du ser vilka byggen en ny CVE påverkar.
• Tilldela. Säkerhetsteam triagerar varje fynd och skickar det till teamet som äger åtgärden. CRACI har stöd för VEX för att dokumentera hur en sårbarhet påverkar din produkt.
• Verifiera. Varje nytt bygge får en egen SBOM med en fullständighetsstatus, så att du kan bekräfta att den åtgärdade versionen är den som bygget använde.
• Rapportera. För aktivt utnyttjade sårbarheter enligt CRA skickar CRACI in anmälningarna till myndigheterna för tillverkarens räkning.

Se sårbarhetsuppföljning för hela funktionen.

Åtgärda CVE:er: vanliga frågor

Vad innebär det att åtgärda en CVE?

Att åtgärda en CVE innebär att ta bort en offentliggjord sårbarhet, identifierad med sitt CVE-id, från programvaran du kör eller levererar. För ett beroende innebär det oftast att uppgradera till en version där sårbarheten är åtgärdad. För din egen kod innebär det att patcha den.

Hur prioriterar jag vilka CVE:er jag ska åtgärda först?

Kombinera allvarlighetsgrad med belägg för utnyttjande. CVSS beskriver hur allvarlig en sårbarhet är, EPSS uppskattar hur sannolikt det är att den utnyttjas under de kommande 30 dagarna, och CISA:s katalog Known Exploited Vulnerabilities listar dem som redan utnyttjas. En känt utnyttjad sårbarhet i ett paket du levererar hamnar överst.

Hur snabbt måste CVE:er åtgärdas?

Det beror på vem som frågar. CISA:s Binding Operational Directive 26-04 ger amerikanska federala myndigheter mellan 3 dagar och nästa systemuppgradering, beroende på om sårbarheten finns i KEV-katalogen, om tillgången är publikt exponerad, om utnyttjandet kan automatiseras och hur mycket kontroll det ger en angripare. EU:s Cyber Resilience Act kräver att tillverkare åtgärdar sårbarheter utan dröjsmål, och sedan den 11 september 2026 startar en aktivt utnyttjad sårbarhet i en produkt en rapporteringsfrist på 24 timmar.

Vad gör jag om det ännu inte finns någon åtgärdad version?

Begränsa och dokumentera. Stäng av den berörda funktionen, blockera angreppsvägen eller byt ut komponenten om du kan, och dokumentera din bedömning, till exempel som ett VEX-uttalande. Håll sedan utkik efter den åtgärdade releasen och åtgärda när den kommer.

Hur åtgärdar jag en CVE i ett transitivt beroende?

Försök först uppgradera det direkta beroendet som drar in det, eftersom en nyare release ofta innehåller rättningen. Om det inte finns någon ännu låter de flesta pakethanterare dig tvinga versionen av ett transitivt paket: overrides i npm, resolutions i Yarn, pnpm.overrides i pnpm. Testa resultatet, eftersom föräldrapaketet inte byggdes mot den versionen.