Prioritering af sårbarheder: sådan afgør du, hvad du retter først

Derfor virker alvorlighed alene ikke

Det sædvanlige er at sortere efter CVSS og arbejde sig ned fra critical. Det føles objektivt, og det slår fejl af tre grunde:

• CVSS måler alvorlighed, ikke risiko. Den beskriver, hvor slem en sårbarhed ville være, hvis den blev udnyttet. Den siger ikke, om nogen udnytter den, eller om den betyder noget i dit produkt.
• For meget af listen haster. Mange offentliggjorte CVE'er scorer high eller critical, så en kø sorteret efter CVSS sætter hundredvis af fund øverst og giver ingen måde at vælge mellem dem på.
• Listen er kun så god som fortegnelsen. En scanner, der læser en lockfile, rapporterer udviklingsafhængigheder, der aldrig bliver leveret, og overser pakker, buildet downloadede uden om pakkehåndteringen. Begge dele forvrider rangeringen, før den begynder.

Prioritering tilføjer de manglende spørgsmål: Bliver den udnyttet, hvor sandsynligt er det, at den bliver det, og hvad sker der med dig, hvis den gør?

Signalerne

Signal	Spørgsmål, det besvarer	Kilde
CVSS	Hvor alvorlig er den, hvis den bliver udnyttet? Score fra 0 til 10.	FIRST (standarden); NVD og leverandører offentliggør scores
EPSS	Hvor sandsynlig er udnyttelse inden for de næste 30 dage? En sandsynlighed fra 0 til 1.	FIRST, opdateres dagligt, gratis
CISA KEV	Bliver den allerede udnyttet i praksis?	CISA's Known Exploited Vulnerabilities-katalog
SSVC	Hvad skal du gøre ud fra udnyttelse, konsekvens og din mission: track, attend eller act?	Beslutningstræer fra CERT/CC og CISA
Din kontekst	Bliver den sårbare version leveret? Er den eksponeret? Hvor vigtigt er produktet? Findes der en rettelse?	Din fortegnelse, arkitektur og dine aktivregistre

De offentlige signaler beskriver sårbarheden. Kun din kontekst beskriver din risiko, og det er den del, de fleste teams får fra den mindst pålidelige kilde.

En praktisk metode til prioritering

De fleste programmer ender med en eller anden version af disse niveauer. Sæt tidsfristerne efter det, din politik og dine kunder kræver.

1. Ret nu: kendt udnyttet, i software, du leverer. Alt på KEV-listen, eller med andre tegn på udnyttelse, som findes i et udgivet build. Til sammenligning giver CISA's BOD 26-04 amerikanske føderale myndigheder helt ned til 3 dage for en KEV-post på et offentligt eksponeret system.
2. Ret som det næste: sandsynligvis udnyttet og alvorlig. En høj EPSS-score kombineret med high eller critical CVSS i en leveret og eksponeret komponent. Vælg en EPSS-tærskel, der giver en kø, dit team faktisk kan nå igennem.
3. Ret løbende: alt andet, der bliver leveret. Saml det i regelmæssige opgraderinger af afhængigheder i stedet for at håndtere hvert fund som en hændelse.
4. Dokumentér: ikke berørt. Den sårbare pakke er til stede, men den sårbare kode bliver ikke brugt, eller komponenten bliver ikke leveret. Registrér begrundelsen som en VEX-erklæring, så det samme fund ikke kommer tilbage til gennemgang, og så kunder, der spørger, kan se hvorfor.

Rangér derefter løbende igen. En sårbarhed, der lå på niveau tre, kan rykke op på niveau ét fra den ene dag til den anden, når den føjes til KEV, eller dens EPSS-score stiger brat.

De sårbarheder, du aldrig når at rangere

Enhver prioriteringsmetode rangerer de fund, den har foran sig. En sårbar pakke, scanneren aldrig så, giver intet fund, så den får aldrig en CVSS-score, en EPSS-score eller et KEV-match. Den er ikke rangeret lavt. Den er slet ikke rangeret, og den bliver leveret alligevel.

Det sker oftere, end det lyder, fordi de fleste scannere udleder indholdet af din software fra filer: lockfilen, manifesterne eller buildets output. Alt, hvad buildet henter, og som ingen lockfile angiver, er en skjult afhængighed, og filbaserede værktøjer overser den:

• Install-hooks. Kode downloadet af npm-scripts som preinstall og postinstall, den vej Shai-Hulud-ormen brugte.
• Build-scripts. For eksempel Rust-build-scripts, der downloader kode under buildet.
• Base-images. Base-imaget i et container-build og dets styresystemlag.
• Caches. Pakker gendannet fra en CI-cache i stedet for installeret fra lockfilen.

At scanne outputtet bagefter lukker ikke hullet. En færdig binærfil, især kompileret kode som Rust, lader scanneren gætte på, hvad der gik ind i den. Og fordi builds som standard ikke er reproducerbare, er det ingen garanti for de samme afhængigheder at bygge det samme commit igen senere.

En SBOM fra buildet starter fra den anden ende. CRACI kører dine GitHub Actions-jobs og ser trafikken ind i hvert build, så det registrerer hver pakke, jobbet faktisk hentede, inklusive skjulte afhængigheder. Hver SBOM har en fuldstændighedsstatus, der siger, hvornår noget ikke kunne ses. I praksis har CRACI fundet sårbare pakker, som Snyk og Aikido ikke rapporterede, fordi komponenterne manglede i deres scanninger. Det er præcis de fund, en prioriteringsmetode aldrig får chancen for at rangere.

Kontekst: den del, scannere ikke kan score for dig

Bliver den sårbare version faktisk leveret?

Det er det spørgsmål, der fjerner mest støj. Et testframework i en lockfile, en pakke fastlåst i en branch, der aldrig bliver udgivet, et container-stage, der bliver smidt væk: Intet af det når kunderne. En SBOM registreret under buildet besvarer spørgsmålet ud fra det, release-buildet faktisk brugte, og ikke ud fra det, repositoriet deklarerer.

Hvilke releases indeholder den, og siden hvornår?

Et fund i et produkt, du leverer til kunder, hvor alle releases siden sidste forår er berørt, rangerer over det samme fund i et internt værktøj. At kende eksponeringsperioden fortæller dig også, hvad du skal oplyse.

Kan den sårbare kode nås?

Reachability-analyse sporer, om din kode kan kalde den sårbare funktion i en afhængighed. Flere SCA-værktøjer tilbyder det, og det er effektivt til at skubbe fund, der ikke kan nås, ned ad listen. Betragt det som ét input: Det ser kun de kodestier, analysen kan følge, og en funktion, der kan nås, er ikke det samme som en, der kan udnyttes.

Er den eksponeret, og findes der en rettelse?

En internetvendt tjeneste rangerer over et batchjob på et privat netværk. En sårbarhed med en rettet version er billigere at lukke end en, der kræver en afhjælpende foranstaltning. Begge dele ændrer rækkefølgen, ikke om den bliver håndteret.

Risikobaseret sårbarhedsstyring

Risikobaseret sårbarhedsstyring er navnet på programniveau for den samme idé: Rangér efter tegn på udnyttelse, sandsynlighed, alvorlighed og forretningskontekst, mål, hvor hurtigt de mest risikable fund bliver lukket, og acceptér, at fund med lav risiko kan forblive åbne. Målepunkterne ændrer sig med det. I stedet for det samlede antal åbne sårbarheder sporer du, hvor mange kendt udnyttede sårbarheder der er åbne i leveret software, og hvor længe de forbliver åbne.

Værktøjer til prioritering af sårbarheder

Tre slags værktøjer står for det meste af rangeringen i dag:

• Platforme til sårbarhedsstyring af infrastruktur som Tenable, Qualys og Rapid7 scorer hosts, endpoints og cloud-aktiver med deres egne risikovurderinger, bygget på efterretninger om udnyttelse.
• SCA- og applikationssikkerhedsværktøjer som Snyk, Endor Labs og Semgrep rangerer fund i afhængigheder, flere af dem med reachability-analyse.
• Open source-værktøjer som Grype, der rapporterer EPSS- og KEV-data sammen med sine fund, og Dependency-Track, der løbende analyserer SBOM'er.

Værktøjer til sårbarhedsstyring sammenlignet gennemgår dem ét for ét.

Sådan understøtter CRACI prioritering

CRACI starter der, hvor rangeringen oftest går galt: i fortegnelsen. Det kører dine GitHub Actions-jobs og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra caches og skjulte afhængigheder, som ingen lockfile angiver.

• Fund for det leverede. Overvågede SBOM'er genvurderes løbende, og organisationsoversigter samler fund på tværs af builds og repositories. Hver pakke viser sine advisories med alvorlighed og de pakker, der trækker den med.
• Eksponeringsperiode. Build-historikken viser, hvilke tidligere builds der indeholdt en sårbar afhængighed, direkte eller transitiv, så du ved, hvilke releases der var berørt, og hvor længe.
• Triage og videresendelse. Sikkerhedsteams triagerer fund og sender hvert enkelt til det team, der ejer rettelsen. CRACI understøtter VEX til at registrere, at en sårbarhed ikke berører dit produkt.
• Gates. Policy gates kan blokere et build på baggrund af fund, herunder et build, der indeholder en bestemt CVE.

CRACI tilbyder ikke reachability-analyse. Er det det signal, du har mest brug for, så vælg et af de SCA-værktøjer, der tilbyder det. Se sårbarhedssporing for den fulde funktionalitet.

Prioritering af sårbarheder: ofte stillede spørgsmål

Hvad er prioritering af sårbarheder?

Prioritering af sårbarheder er at beslutte, hvilke kendte sårbarheder der skal rettes først, hvilke der kan vente, og hvilke der slet ikke berører dig. Den rangerer fund efter, hvor sandsynligt det er, at de bliver udnyttet, og hvor stor skade det ville gøre i dit miljø, ikke kun efter alvorlighed.

Hvordan prioriterer du sårbarheder?

Start med en præcis fortegnelse, så du rangerer sårbarheder i software, der faktisk bliver leveret. Sæt alt på CISA's Known Exploited Vulnerabilities-liste først, og rangér derefter resten efter sandsynlighed for udnyttelse (EPSS) og alvorlighed (CVSS), justeret efter din kontekst: eksponering, produktets betydning, og om der findes en rettelse. Registrér dem, der ikke berører dig, som VEX-erklæringer.

Er CVSS nok til at prioritere sårbarheder?

Nej. CVSS måler, hvor alvorlig en sårbarhed er, ikke hvor sandsynligt det er, at den bliver udnyttet, eller hvor meget den betyder for dig. Rangering efter CVSS alene markerer en stor del af backloggen som high eller critical, og de fleste af de sårbarheder bliver aldrig udnyttet.

Hvad er risikobaseret sårbarhedsstyring?

Risikobaseret sårbarhedsstyring rangerer og retter sårbarheder efter den risiko, de udgør for din organisation, ved at kombinere tegn på udnyttelse, sandsynlighed, alvorlighed og forretningskontekst i stedet for at arbejde sig igennem dem efter CVSS-score eller alder.

Hvad er forskellen på EPSS og KEV?

EPSS er en prognose: den anslåede sandsynlighed for, at en CVE bliver udnyttet inden for de næste 30 dage. KEV er en registrering: CISA's katalog over sårbarheder med tegn på udnyttelse i praksis. En KEV-post er en kendsgerning; en EPSS-score er en sandsynlighed. Brug KEV først og EPSS til at rangere alt andet.

Erstatter reachability-analyse prioritering?

Nej, det er ét input mere. Reachability tjekker, om din kode kan kalde den sårbare funktion i en afhængighed. Det fjerner fund, der ikke kan udløses, men siger intet om, hvor sandsynlig udnyttelse er, og dækker kun kode, analysen kan følge.