Prioritering av sårbarheter: slik avgjør du hva du skal rette først

Hvorfor alvorlighetsgrad alene ikke fungerer

Standardvalget er å sortere etter CVSS og jobbe seg nedover fra kritisk. Det føles objektivt, og det svikter av tre grunner:

• CVSS måler alvorlighetsgrad, ikke risiko. Det beskriver hvor ille en sårbarhet ville vært hvis den ble utnyttet. Det sier ikke om noen utnytter den, eller om den betyr noe i produktet ditt.
• For mye av listen haster. Mange publiserte CVE-er får høy eller kritisk score, så en kø sortert etter CVSS legger hundrevis av funn øverst og gir ingen måte å velge mellom dem på.
• Listen er bare så god som oversikten. En skanner som leser en lockfile, rapporterer utviklingsavhengigheter som aldri leveres, og går glipp av pakker bygget lastet ned utenfor pakkebehandleren. Begge deler forvrenger rangeringen før den begynner.

Prioritering legger til spørsmålene som mangler: Blir den utnyttet, hvor sannsynlig er det at den blir det, og hva skjer med deg hvis den blir det.

Signalene

Signal	Spørsmålet det svarer på	Kilde
CVSS	Hvor alvorlig er den hvis den blir utnyttet? Score fra 0 til 10.	FIRST (standarden); NVD og leverandører publiserer scorer
EPSS	Hvor sannsynlig er utnyttelse de neste 30 dagene? En sannsynlighet fra 0 til 1.	FIRST, oppdateres daglig, gratis
CISA KEV	Blir den allerede utnyttet i praksis?	CISAs katalog Known Exploited Vulnerabilities
SSVC	Gitt utnyttelse, konsekvens og oppdraget ditt, hva bør du gjøre: track, attend eller act?	Beslutningstrær fra CERT/CC og CISA
Din kontekst	Leveres den sårbare versjonen? Er den eksponert? Hvor viktig er produktet? Finnes det en retting?	Din oversikt, arkitektur og dine aktivaregistre

De offentlige signalene beskriver sårbarheten. Bare din kontekst beskriver din risiko, og det er den delen de fleste team henter fra den minst pålitelige kilden.

En praktisk metode for prioritering

De fleste programmer ender opp med en variant av disse nivåene. Sett tidsfristene etter hva policyen din og kundene dine krever.

1. Rett nå: kjent utnyttet, i programvare du leverer. Alt på KEV-listen, eller med andre bevis på utnyttelse, som finnes i et utgitt bygg. Til sammenligning gir CISAs BOD 26-04 amerikanske føderale etater så lite som 3 dager for en KEV-oppføring på et offentlig eksponert system.
2. Rett deretter: sannsynlig utnyttet og alvorlig. En høy EPSS-score kombinert med høy eller kritisk CVSS, i en levert og eksponert komponent. Velg en EPSS-terskel som gir en kø teamet ditt faktisk klarer å tømme.
3. Rett rutinemessig: alt annet som leveres. Samle det i regelmessige avhengighetsoppgraderinger i stedet for å håndtere hvert funn som en hendelse.
4. Dokumenter: ikke berørt. Den sårbare pakken er til stede, men den sårbare koden brukes ikke, eller komponenten leveres ikke. Registrer begrunnelsen som en VEX-erklæring, slik at det samme funnet ikke kommer tilbake til vurdering, og slik at kunder som spør, kan se hvorfor.

Ranger deretter på nytt kontinuerlig. En sårbarhet som lå på nivå tre, kan flytte til nivå én over natten når den legges til i KEV eller EPSS-scoren hopper.

Sårbarhetene du aldri får rangert

Hver prioriteringsmetode rangerer funnene den har foran seg. En sårbar pakke skanneren aldri så, gir ikke noe funn, så den får aldri en CVSS-score, en EPSS-score eller en KEV-match. Den er ikke rangert lavt. Den er ikke rangert i det hele tatt, og den leveres likevel.

Dette skjer oftere enn man skulle tro, fordi de fleste skannere finner ut hva som er i programvaren din, ut fra filer: lockfilen, manifestene eller byggets utdata. Alt bygget henter som ingen lockfile lister opp, er en skjult avhengighet, og filbaserte verktøy går glipp av det:

• Installasjonshooks. Kode lastet ned av npm-skriptene preinstall og postinstall, ruten Shai-Hulud-ormen brukte.
• Byggeskript. For eksempel Rust-byggeskript som laster ned kode under bygging.
• Base-images. Base-imaget til et containerbygg og operativsystemlagene i det.
• Cacher. Pakker gjenopprettet fra en CI-cache i stedet for installert fra lockfilen.

Å skanne utdataene etterpå tetter ikke hullet. En ferdig binærfil, særlig kompilert kode som Rust, lar skanneren gjette på hva som gikk inn i den. Og fordi bygg ikke er reproduserbare som standard, er det å bygge samme commit på nytt senere ingen garanti for de samme avhengighetene.

En SBOM fra bygget begynner i den andre enden. CRACI kjører GitHub Actions-jobbene dine og ser trafikken som kommer inn i hvert bygg, så det registrerer hver pakke jobben faktisk hentet inn, skjulte avhengigheter inkludert. Hver SBOM har en fullstendighetsstatus som sier når noe ikke kunne ses. I praksis har CRACI funnet sårbare pakker som Snyk og Aikido ikke rapporterte, fordi skanningene deres manglet komponentene. Det er nettopp de funnene en prioriteringsmetode aldri får sjansen til å rangere.

Kontekst: delen skannere ikke kan gi deg en score for

Leveres den sårbare versjonen faktisk?

Dette er spørsmålet som fjerner mest støy. Et testrammeverk i en lockfile, en pakke festet i en gren som aldri blir utgitt, et containerstadium som kastes: Ingen av dem når kundene. En SBOM registrert under bygget besvarer spørsmålet ut fra det utgivelsesbygget faktisk brukte, ikke ut fra det repositoriet deklarerer.

Hvilke utgivelser inneholder den, og siden når?

Et funn i et produkt du leverer til kunder, der alle utgivelser siden i fjor vår er berørt, rangeres over det samme funnet i et internt verktøy. Å kjenne eksponeringsperioden forteller deg også hva du må opplyse om.

Kan den sårbare koden nås?

Reachability-analyse sporer om koden din kan kalle den sårbare funksjonen i en avhengighet. Flere SCA-verktøy tilbyr det, og det er effektivt til å skyve funn som ikke kan nås, nedover listen. Behandle det som én input: Det ser bare kodestier analysen kan følge, og en funksjon som kan nås, er ikke det samme som en som kan utnyttes.

Er den eksponert, og finnes det en retting?

En tjeneste som er tilgjengelig fra internett, rangeres over en batchjobb på et privat nettverk. En sårbarhet med en rettet versjon er billigere å lukke enn en som krever et avbøtende tiltak. Begge endrer rekkefølgen, ikke om den blir håndtert.

Risikobasert sårbarhetshåndtering

Risikobasert sårbarhetshåndtering er navnet på samme idé på programnivå: ranger etter bevis på utnyttelse, sannsynlighet, alvorlighetsgrad og forretningskontekst, mål hvor raskt de mest risikofylte funnene lukkes, og godta at funn med lav risiko kan bli stående åpne. Nøkkeltallene endrer seg med det. I stedet for det totale antallet åpne sårbarheter følger du med på hvor mange kjent utnyttede sårbarheter som er åpne i levert programvare, og hvor lenge de står åpne.

Verktøy for prioritering av sårbarheter

Tre typer verktøy gjør det meste av rangeringen i dag:

• Plattformer for sårbarhetshåndtering i infrastruktur som Tenable, Qualys og Rapid7 gir verter, endepunkter og skyressurser score med egne risikovurderinger, bygget på etterretning om utnyttelse.
• SCA- og applikasjonssikkerhetsverktøy som Snyk, Endor Labs og Semgrep rangerer avhengighetsfunn, flere av dem med reachability-analyse.
• Verktøy med åpen kildekode som Grype, som rapporterer EPSS- og KEV-data sammen med funnene, og Dependency-Track, som analyserer SBOM-er kontinuerlig.

Verktøy for sårbarhetshåndtering sammenlignet går gjennom dem ett for ett.

Slik støtter CRACI prioritering

CRACI begynner der rangeringen oftest går galt: i oversikten. Det kjører GitHub Actions-jobbene dine og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra cacher og skjulte avhengigheter som ingen lockfile lister opp.

• Funn for det som ble levert. Overvåkede SBOM-er vurderes på nytt kontinuerlig, og organisasjonsvisninger samler funn på tvers av bygg og repositorier. Hver pakke viser sine advisories med alvorlighetsgrad og pakkene som trekker den inn.
• Eksponeringsperiode. Byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar avhengighet, direkte eller transitiv, så du vet hvilke utgivelser som ble berørt, og hvor lenge.
• Triage og videresending. Sikkerhetsteam triagerer funn og sender hvert av dem til teamet som eier rettingen. CRACI støtter VEX for å registrere at en sårbarhet ikke berører produktet ditt.
• Gates. Policy gates kan blokkere et bygg på grunn av funn, blant annet et bygg som inneholder en bestemt CVE.

CRACI tilbyr ikke reachability-analyse. Hvis det er signalet du trenger mest, velg et av SCA-verktøyene som tilbyr det. Se sårbarhetssporing for hele funksjonaliteten.

Prioritering av sårbarheter: ofte stilte spørsmål

Hva er prioritering av sårbarheter?

Prioritering av sårbarheter er å avgjøre hvilke kjente sårbarheter som skal rettes først, hvilke som kan vente, og hvilke som ikke berører deg i det hele tatt. Den rangerer funn etter hvor sannsynlig det er at de blir utnyttet, og hvor stor skade det ville gjort i miljøet ditt, ikke etter alvorlighetsgrad alene.

Hvordan prioriterer du sårbarheter?

Begynn med en nøyaktig oversikt, så du rangerer sårbarheter i programvare som faktisk leveres. Sett alt på CISAs liste Known Exploited Vulnerabilities først, og ranger resten etter sannsynlighet for utnyttelse (EPSS) og alvorlighetsgrad (CVSS), justert for konteksten din: eksponering, hvor viktig produktet er, og om det finnes en retting. Registrer dem som ikke berører deg, som VEX-erklæringer.

Er CVSS nok til å prioritere sårbarheter?

Nei. CVSS måler hvor alvorlig en sårbarhet er, ikke hvor sannsynlig det er at den blir utnyttet, eller hvor mye den betyr for deg. Rangering etter CVSS alene merker en stor del av backloggen som høy eller kritisk, og de fleste av disse sårbarhetene blir aldri utnyttet.

Hva er risikobasert sårbarhetshåndtering?

Risikobasert sårbarhetshåndtering rangerer og retter sårbarheter etter risikoen de utgjør for organisasjonen din, ved å kombinere bevis på utnyttelse, sannsynlighet, alvorlighetsgrad og forretningskontekst, i stedet for å jobbe seg gjennom dem etter CVSS-score eller alder.

Hva er forskjellen på EPSS og KEV?

EPSS er en prognose: den estimerte sannsynligheten for at en CVE blir utnyttet de neste 30 dagene. KEV er en oversikt: CISAs katalog over sårbarheter med bevis på utnyttelse i praksis. En KEV-oppføring er et faktum; en EPSS-score er en sannsynlighet. Bruk KEV først og EPSS til å rangere alt annet.

Erstatter reachability-analyse prioritering?

Nei, det er enda en input. Reachability sjekker om koden din kan kalle den sårbare funksjonen i en avhengighet. Det fjerner funn som ikke kan utløses, men sier ingenting om hvor sannsynlig utnyttelse er, og dekker bare kode analysen kan følge.