CVE-afhjælpning: fra advisory til et rettet, leveret build

Processen for CVE-afhjælpning

CVE-afhjælpning fjerner en offentligt kendt sårbarhed fra software, du kører eller leverer. For din egen kode betyder det en patch. For open source-afhængigheder, hvor de fleste CVE'er i et typisk produkt kommer fra, betyder det at nå frem til en version, hvor sårbarheden er rettet. Trinene er de samme i begge tilfælde:

1. Find hvert produkt, build og release, der indeholder den ramte pakke og version.
2. Vurdér, om sårbarheden rammer dig, og hvor hårdt.
3. Prioritér i forhold til alt det andet, der er åbent.
4. Ret ved at opgradere, patche, udskifte eller, hvis der ikke findes en rettelse, afbøde.
5. Verificér, at den rettede version er det, det nye build faktisk indeholder.
6. Registrér, hvad der var ramt, hvad du besluttede, og hvornår rettelsen blev leveret.

Trin 1: find alle ramte builds

Det første spørgsmål efter en advisory er, hvor pakken er. At svare ud fra kildekoderepositories er langsomt, og det er ofte forkert: Versionen i en lockfile, den version, et build resolvede, og versionen i et udgivet container-image kan alle være forskellige. Transitive afhængigheder og pakker, et build downloader uden om pakkehåndteringen, vises slet ikke i manifester.

Det pålidelige svar kommer fra en SBOM af hver release, der løbende matches mod advisories. Hvis den SBOM er registreret under buildet, angiver den, hvad buildet faktisk brugte, så matchet fortæller dig, hvilke leverede builds der indeholder den sårbare version, ikke hvilke repositories der nævner den.

Trin 2: prioritér med alvorlighed og udnyttelse

Alvorlighed alene rangerer for mange sårbarheder som presserende. De fleste teams kombinerer tre signaler:

Signal	Hvad det fortæller dig	Offentliggjort af
CVSS	Hvor alvorlig sårbarheden er, hvis den udnyttes, på en skala fra 0 til 10	FIRST (standarden); NVD og leverandører offentliggør scorer
EPSS	Den anslåede sandsynlighed for udnyttelse inden for de næste 30 dage	FIRST
KEV	Om sårbarheden vides at blive udnyttet i praksis	CISA's Known Exploited Vulnerabilities-katalog

Tilføj derefter din egen kontekst: om den ramte pakke leveres til kunder eller kun kører i et testjob, og om den sårbare funktion overhovedet bruges. En kendt udnyttet sårbarhed i en pakke, der leveres, kommer øverst på listen. Prioritering af sårbarheder gør disse signaler til en metode.

Tidsfrister for afhjælpning

• CISA BOD 26-04. Siden 10. juni 2026 fastsætter amerikanske føderale myndigheder hver frist ud fra fire spørgsmål: Er aktivet offentligt eksponeret, er sårbarheden i KEV-kataloget, kan udnyttelse automatiseres, og giver den delvis eller total kontrol? Svarene spænder fra 3 dage, med forensisk triage i de værste tilfælde, til rettelse ved næste systemopgradering. Det erstattede BOD 22-01, som gav to uger for de fleste KEV-poster.
• EU's Cyber Resilience Act. Producenter skal håndtere og afhjælpe sårbarheder uden forsinkelse, herunder gennem sikkerhedsopdateringer (bilag I, del II). Siden 11. september 2026 udløser en aktivt udnyttet sårbarhed i et produkt også rapporteringsfrister: en tidlig varsling inden for 24 timer, en underretning inden for 72 timer og en endelig rapport inden for 14 dage efter, at en rettelse er tilgængelig.
• Din egen politik. De fleste sikkerhedsprogrammer sætter interne mål efter alvorlighed. Uanset hvad de er, kan du kun nå dem, hvis trin 1 går hurtigt.

Trin 3: vælg rettelsen

Mulighed	Hvornår du bruger den
Opgradér	Der findes en rettet version. Foretræk den mindste opgradering, der indeholder rettelsen, for at begrænse breaking changes.
Opgradér forælderpakken	Den sårbare pakke er transitiv. En nyere release af den direkte afhængighed trækker ofte rettelsen med ind.
Tilsidesæt	Forælderpakken har ikke udgivet en rettelse. Gennemtving den transitive version med npm overrides, Yarn resolutions eller pnpm.overrides, og test den.
Patch eller backport	Du kan ikke flytte til den rettede hovedversion endnu. Anvend upstream-rettelsen på den version, du bruger.
Udskift	Pakken vedligeholdes ikke, eller den bliver ved med at give CVE'er. Skift til et alternativ.
Afbød og dokumentér	Der findes endnu ingen rettelse, eller dit produkt er ikke ramt. Reducér eksponeringen, og registrér vurderingen, for eksempel som en VEX-erklæring.

Det meste af dette trin kan automatiseres, fra valget af version til oprettelsen af pull requesten. Automatiseret afhjælpning af sårbarheder gennemgår, hvad du skal automatisere, og hvad du skal overlade til et menneske.

Trin 4: en merget rettelse er ikke en leveret rettelse

Pull requesten er merget, så CVE'en er lukket. Ikke nødvendigvis. Rettelsen er i repositoriet, men et build gendanner en forældet cache, et base-image har stadig den gamle pakke, eller en release-branch fik aldrig ændringen med. Sagen står som rettet, mens produktet stadig leverer den sårbare version.

Slut cirklen fra den anden ende: Tjek SBOM'en for det næste build, og bekræft, at den sårbare version er væk. Når den SBOM registrerer, hvad buildet faktisk hentede, inklusive pakker gendannet fra caches, besvarer tjekket det spørgsmål, kunden, revisoren og myndigheden reelt stiller.

Sådan understøtter CRACI CVE-afhjælpning

• Find. CRACI registrerer de pakker, hvert GitHub Actions-job hentede, inklusive transitive afhængigheder og pakker gendannet fra caches, og genvurderer løbende overvågede SBOM'er. Organisationsoversigter samler fund på tværs af builds og repositories, så du ser, hvilke builds en ny CVE rammer.
• Tildel. Sikkerhedsteams triagerer hvert fund og sender det til det team, der ejer rettelsen. CRACI understøtter VEX til at registrere, hvordan en sårbarhed påvirker dit produkt.
• Verificér. Hvert nyt build får sin egen SBOM med en fuldstændighedsstatus, så du kan bekræfte, at den rettede version er det, buildet brugte.
• Rapportér. For aktivt udnyttede sårbarheder under CRA indsender CRACI underretningerne til myndighederne på producentens vegne.

Se sårbarhedssporing for den fulde funktionalitet.

CVE-afhjælpning: ofte stillede spørgsmål

Hvad er CVE-afhjælpning?

CVE-afhjælpning er at fjerne en offentligt kendt sårbarhed, identificeret ved sit CVE-ID, fra den software, du kører eller leverer. For en afhængighed betyder det som regel at opgradere til en version, hvor sårbarheden er rettet. For din egen kode betyder det at patche den.

Hvordan prioriterer jeg, hvilke CVE'er der skal rettes først?

Kombinér alvorlighed med tegn på udnyttelse. CVSS beskriver, hvor slem en sårbarhed er, EPSS anslår, hvor sandsynligt det er, at den bliver udnyttet inden for de næste 30 dage, og CISA's Known Exploited Vulnerabilities-katalog angiver dem, der allerede bliver udnyttet. En kendt udnyttet sårbarhed i en pakke, du leverer, kommer øverst.

Hvor hurtigt skal CVE'er afhjælpes?

Det afhænger af, hvem der spørger. CISA's Binding Operational Directive 26-04 giver amerikanske føderale myndigheder mellem 3 dage og næste systemopgradering, afhængigt af om sårbarheden er i KEV-kataloget, om aktivet er offentligt eksponeret, om udnyttelse kan automatiseres, og hvor meget kontrol den giver en angriber. EU's Cyber Resilience Act kræver, at producenter afhjælper sårbarheder uden forsinkelse, og siden 11. september 2026 udløser en aktivt udnyttet sårbarhed i et produkt en rapporteringsfrist på 24 timer.

Hvad hvis der endnu ikke findes en rettet version?

Afbød og dokumentér. Deaktivér den ramte funktion, blokér angrebsvejen, eller udskift komponenten, hvis du kan, og registrér din vurdering, for eksempel som en VEX-erklæring. Hold derefter øje med den rettede release, og afhjælp, når den lander.

Hvordan retter jeg en CVE i en transitiv afhængighed?

Prøv først at opgradere den direkte afhængighed, der trækker den ind, da en nyere release ofte får rettelsen med. Hvis der endnu ikke findes en, lader de fleste pakkehåndteringer dig gennemtvinge versionen af en transitiv pakke: overrides i npm, resolutions i Yarn, pnpm.overrides i pnpm. Test resultatet, for forælderpakken er ikke bygget mod den version.