CVE-utbedring: fra advisory til et rettet, levert bygg

Prosessen for CVE-utbedring

CVE-utbedring fjerner en offentlig kjent sårbarhet fra programvare du kjører eller leverer. For din egen kode betyr det en patch. For avhengigheter med åpen kildekode, der de fleste CVE-er i et typisk produkt kommer fra, betyr det å komme til en versjon der sårbarheten er rettet. Stegene er uansett de samme:

1. Finn hvert produkt, bygg og hver utgivelse som inneholder den berørte pakken og versjonen.
2. Vurder om sårbarheten berører deg, og hvor alvorlig.
3. Prioriter mot alt annet som er åpent.
4. Rett ved å oppgradere, patche, erstatte eller, hvis det ikke finnes noen retting, redusere risikoen.
5. Verifiser at den rettede versjonen er det det nye bygget faktisk inneholder.
6. Registrer hva som var berørt, hva du bestemte, og når rettingen ble levert.

Steg 1: finn hvert berørte bygg

Det første spørsmålet etter en advisory er hvor pakken er. Å svare ut fra kildekoderepositorier er tregt, og det er ofte feil: Versjonen i en lockfile, versjonen et bygg løste og versjonen i et utgitt container-image kan alle være forskjellige. Transitive avhengigheter og pakker et bygg laster ned utenom pakkebehandleren, dukker ikke opp i manifester i det hele tatt.

Det pålitelige svaret kommer fra en SBOM for hver utgivelse, kontinuerlig matchet mot advisories. Hvis den SBOM-en er registrert under bygget, viser den hva bygget faktisk brukte, så matchen forteller deg hvilke leverte bygg som inneholder den sårbare versjonen, ikke hvilke repositorier som nevner den.

Steg 2: prioriter med alvorlighetsgrad og utnyttelse

Alvorlighetsgrad alene rangerer for mange sårbarheter som hastesaker. De fleste team kombinerer tre signaler:

Signal	Hva det forteller deg	Publisert av
CVSS	Hvor alvorlig sårbarheten er hvis den utnyttes, med score fra 0 til 10	FIRST (standarden); NVD og leverandører publiserer score
EPSS	Den anslåtte sannsynligheten for utnyttelse de neste 30 dagene	FIRST
KEV	Om sårbarheten er kjent for å bli utnyttet i praksis	CISAs Known Exploited Vulnerabilities-katalog

Legg deretter til din egen kontekst: om den berørte pakken leveres til kunder eller bare kjører i en testjobb, og om den sårbare funksjonen i det hele tatt brukes. En kjent utnyttet sårbarhet i en pakke som leveres, går øverst på listen. Prioritering av sårbarheter gjør disse signalene om til en metode.

Tidsfrister for utbedring

• CISA BOD 26-04. Siden 10. juni 2026 setter amerikanske føderale etater hver frist ut fra fire spørsmål: Er ressursen offentlig eksponert, er sårbarheten i KEV-katalogen, kan utnyttelse automatiseres, og gir den delvis eller full kontroll? Svarene spenner fra 3 dager, med forensisk triage i de verste tilfellene, til retting ved neste systemoppgradering. Direktivet erstattet BOD 22-01, som ga to uker for de fleste KEV-oppføringer.
• EUs Cyber Resilience Act. Produsenter må håndtere og utbedre sårbarheter uten opphold, blant annet gjennom sikkerhetsoppdateringer (vedlegg I del II). Siden 11. september 2026 utløser en aktivt utnyttet sårbarhet i et produkt også rapporteringsfrister: et tidlig varsel innen 24 timer, en melding innen 72 timer og en sluttrapport innen 14 dager etter at en retting er tilgjengelig.
• Din egen policy. De fleste sikkerhetsprogrammer setter interne mål etter alvorlighetsgrad. Uansett hva de er, kan du bare nå dem hvis steg 1 går raskt.

Steg 3: velg rettingen

Alternativ	Når du bør bruke det
Oppgrader	Det finnes en rettet versjon. Velg helst den minste oppgraderingen som inkluderer rettingen, for å begrense brytende endringer.
Oppgrader foreldrepakken	Den sårbare pakken er transitiv. En nyere utgivelse av den direkte avhengigheten henter ofte inn rettingen.
Overstyr	Foreldrepakken har ikke gitt ut en retting. Tving frem den transitive versjonen med npm overrides, Yarn resolutions eller pnpm.overrides, og test den.
Patch eller backport	Du kan ikke gå over til den rettede hovedversjonen ennå. Overfør oppstrømsrettingen til versjonen du bruker.
Erstatt	Pakken vedlikeholdes ikke eller gir stadig nye CVE-er. Gå over til et alternativ.
Reduser risikoen og dokumenter	Det finnes ingen retting ennå, eller produktet ditt er ikke berørt. Reduser eksponeringen og registrer vurderingen, for eksempel som en VEX-erklæring.

Det meste av dette steget kan automatiseres, fra å velge versjon til å åpne pull requesten. Automatisert utbedring av sårbarheter dekker hva du bør automatisere, og hva du bør overlate til et menneske.

Steg 4: en merget retting er ikke en levert retting

Pull requesten ble merget, så CVE-en er lukket. Ikke nødvendigvis. Rettingen er i repositoriet, men et bygg gjenoppretter en utdatert cache, et base-image har fortsatt den gamle pakken, eller en utgivelsesgren fikk aldri med endringen. Saken står som rettet, mens produktet fortsatt leverer den sårbare versjonen.

Lukk sløyfen fra den andre enden: Sjekk SBOM-en for neste bygg og bekreft at den sårbare versjonen er borte. Når den SBOM-en registrerer hva bygget faktisk hentet, inkludert pakker gjenopprettet fra cacher, svarer sjekken på spørsmålet kunden, revisoren og tilsynsmyndigheten egentlig stiller.

Slik støtter CRACI CVE-utbedring

• Finn. CRACI registrerer pakkene hver GitHub Actions-jobb hentet, inkludert transitive avhengigheter og pakker gjenopprettet fra cacher, og vurderer overvåkede SBOM-er kontinuerlig på nytt. Organisasjonsvisninger samler funn på tvers av bygg og repositorier, så du ser hvilke bygg en ny CVE berører.
• Tildel. Sikkerhetsteam prioriterer hvert funn og sender det til teamet som eier rettingen. CRACI støtter VEX for å registrere hvordan en sårbarhet berører produktet ditt.
• Verifiser. Hvert nye bygg får sin egen SBOM med en fullstendighetsstatus, så du kan bekrefte at den rettede versjonen er det bygget brukte.
• Rapporter. For aktivt utnyttede sårbarheter under CRA sender CRACI inn varslene til myndighetene på vegne av produsenten.

Se sporing av sårbarheter for hele funksjonen.

CVE-utbedring: ofte stilte spørsmål

Hva er CVE-utbedring?

CVE-utbedring er å fjerne en offentlig kjent sårbarhet, identifisert med CVE-ID-en, fra programvaren du kjører eller leverer. For en avhengighet betyr det vanligvis å oppgradere til en versjon der sårbarheten er rettet. For din egen kode betyr det å patche den.

Hvordan prioriterer jeg hvilke CVE-er som skal rettes først?

Kombiner alvorlighetsgrad med tegn på utnyttelse. CVSS beskriver hvor ille en sårbarhet er, EPSS anslår hvor sannsynlig det er at den blir utnyttet de neste 30 dagene, og CISAs Known Exploited Vulnerabilities-katalog viser dem som allerede blir utnyttet. En kjent utnyttet sårbarhet i en pakke du leverer, går øverst.

Hvor raskt må CVE-er utbedres?

Det kommer an på hvem som spør. CISAs Binding Operational Directive 26-04 gir amerikanske føderale etater mellom 3 dager og neste systemoppgradering, avhengig av om sårbarheten er i KEV-katalogen, om ressursen er offentlig eksponert, om utnyttelse kan automatiseres, og hvor mye kontroll den gir en angriper. EUs Cyber Resilience Act ber produsenter utbedre sårbarheter uten opphold, og siden 11. september 2026 utløser en aktivt utnyttet sårbarhet i et produkt en rapporteringsfrist på 24 timer.

Hva om det ikke finnes noen rettet versjon ennå?

Reduser risikoen og dokumenter. Slå av den berørte funksjonen, blokker angrepsveien eller bytt komponenten hvis du kan, og registrer vurderingen, for eksempel som en VEX-erklæring. Følg deretter med på om det kommer en rettet utgivelse, og utbedre når den er ute.

Hvordan retter jeg en CVE i en transitiv avhengighet?

Prøv først å oppgradere den direkte avhengigheten som henter den inn, siden en nyere utgivelse ofte tar med rettingen. Hvis det ikke finnes noen ennå, lar de fleste pakkebehandlere deg tvinge frem versjonen av en transitiv pakke: overrides i npm, resolutions i Yarn, pnpm.overrides i pnpm. Test resultatet, for foreldrepakken ble ikke bygget mot den versjonen.