Prioritering av sårbarheter: så avgör du vad som ska åtgärdas först

Varför allvarlighetsgrad ensam inte fungerar

Standardvalet är att sortera efter CVSS och arbeta sig ner från kritiskt. Det känns objektivt, och det misslyckas av tre skäl:

• CVSS mäter allvarlighetsgrad, inte risk. Det beskriver hur illa en sårbarhet skulle vara om den utnyttjades. Det säger inte om någon utnyttjar den, eller om den spelar någon roll i din produkt.
• För mycket av listan är brådskande. Många publicerade CVE:er får höga eller kritiska poäng, så en kö som sorteras efter CVSS lägger hundratals fynd överst och ger inget sätt att välja mellan dem.
• Listan är bara så bra som inventeringen. En skanner som läser en lockfile rapporterar utvecklingsberoenden som aldrig levereras, och missar paket som bygget laddade ner utanför pakethanteraren. Båda förvränger rangordningen innan den ens har börjat.

Prioritering lägger till de frågor som saknas: utnyttjas den, hur troligt är det att den kommer att utnyttjas, och vad händer med dig om det sker.

Signalerna

Signal	Fråga den besvarar	Källa
CVSS	Hur allvarlig är den om den utnyttjas? Poängsätts från 0 till 10.	FIRST (standarden); NVD och leverantörer publicerar poäng
EPSS	Hur sannolikt är det att den utnyttjas de kommande 30 dagarna? En sannolikhet från 0 till 1.	FIRST, uppdateras dagligen, gratis
CISA KEV	Utnyttjas den redan i det vilda?	CISA:s katalog Known Exploited Vulnerabilities
SSVC	Vad ska du göra, givet utnyttjande, påverkan och ditt uppdrag: track, attend eller act?	Beslutsträd från CERT/CC och CISA
Ditt sammanhang	Levereras den sårbara versionen? Är den exponerad? Hur viktig är produkten? Finns det en åtgärd?	Din inventering, arkitektur och dina tillgångsregister

De publika signalerna beskriver sårbarheten. Bara ditt sammanhang beskriver din risk, och det är den del som de flesta team får från den minst tillförlitliga källan.

En praktisk metod för prioritering

De flesta program hamnar i någon variant av de här nivåerna. Sätt tidsgränserna efter vad din policy och dina kunder kräver.

1. Åtgärda nu: känt utnyttjad, i programvara du levererar. Allt på KEV-listan, eller med andra bevis på utnyttjande, som finns i ett släppt bygge. Som jämförelse ger CISA:s BOD 26-04 amerikanska federala myndigheter så lite som 3 dagar för en KEV-post på ett offentligt exponerat system.
2. Åtgärda härnäst: troligen utnyttjad och allvarlig. En hög EPSS-poäng i kombination med hög eller kritisk CVSS, i en levererad och exponerad komponent. Välj en EPSS-tröskel som ger en kö som ditt team faktiskt kan beta av.
3. Åtgärda rutinmässigt: allt annat som levereras. Samla det i regelbundna beroendeuppgraderingar i stället för att hantera varje fynd som en incident.
4. Dokumentera: inte berörd. Det sårbara paketet finns men den sårbara koden används inte, eller så levereras komponenten inte. Registrera resonemanget som ett VEX-uttalande, så att samma fynd inte kommer tillbaka för granskning och så att kunder som frågar kan se varför.

Rangordna sedan om löpande. En sårbarhet som låg på nivå tre kan flyttas till nivå ett över en natt när den läggs till i KEV eller dess EPSS-poäng skjuter i höjden.

Sårbarheterna du aldrig får chansen att rangordna

Varje prioriteringsmetod rangordnar de fynd den har framför sig. Ett sårbart paket som skannern aldrig såg ger inget fynd, så det får aldrig någon CVSS-poäng, EPSS-poäng eller KEV-träff. Det rangordnas inte lågt. Det rangordnas inte alls, och det levereras ändå.

Det här händer oftare än det låter, eftersom de flesta skannrar räknar ut vad som finns i din programvara utifrån filer: lockfilen, manifesten eller byggresultatet. Allt som bygget hämtar och som ingen lockfile listar är ett dolt beroende, och filbaserade verktyg missar det:

• Installationshookar. Kod som laddas ner av npm-skripten preinstall och postinstall, den väg som Shai-Hulud-masken använde.
• Byggskript. Till exempel byggskript i Rust som laddar ner kod under bygget.
• Basavbilder. Basavbilden i ett containerbygge och dess operativsystemslager.
• Cachar. Paket som återställs från en CI-cache i stället för att installeras från lockfilen.

Att skanna resultatet i efterhand täpper inte till luckan. En färdig binär, särskilt kompilerad kod som Rust, tvingar skannern att gissa vad som ingick. Och eftersom byggen inte är reproducerbara som standard är en ombyggnad av samma commit senare ingen garanti för samma beroenden.

En SBOM från bygget börjar från andra hållet. CRACI kör dina GitHub Actions-jobb och ser trafiken som kommer in i varje bygge, så det registrerar varje paket som jobbet faktiskt drog in, dolda beroenden inräknade. Varje SBOM har en fullständighetsstatus som anger när något inte kunde ses. I praktiken har CRACI hittat sårbara paket som Snyk och Aikido inte rapporterade, eftersom deras skanningar saknade komponenterna. Det är just de fynd som en prioriteringsmetod aldrig får chansen att rangordna.

Sammanhang: det som skannrar inte kan poängsätta åt dig

Levereras den sårbara versionen faktiskt?

Det här är frågan som tar bort mest brus. Ett testramverk i en lockfile, ett paket som är låst i en gren som aldrig släpps, ett containersteg som kastas bort: inget av det når kunderna. En SBOM registrerad under bygget besvarar frågan utifrån vad releasebygget faktiskt använde, snarare än utifrån vad repot deklarerar.

Vilka releaser innehåller den, och sedan när?

Ett fynd i en produkt som du levererar till kunder, där varje release sedan i våras är berörd, går före samma fynd i ett internt verktyg. Att känna till exponeringsperioden säger också vad du behöver redovisa.

Kan den sårbara koden nås?

Reachability-analys spårar om din kod kan anropa den sårbara funktionen i ett beroende. Flera SCA-verktyg erbjuder det, och det är effektivt för att flytta onåbara fynd längre ner på listan. Behandla det som en signal bland flera: det ser bara kodvägar som analysen kan följa, och en nåbar funktion är inte samma sak som en som går att utnyttja.

Är den exponerad, och finns det en åtgärd?

En tjänst som är nåbar från internet rankas högre än ett batchjobb på ett privat nätverk. En sårbarhet med en åtgärdad version är billigare att stänga än en som kräver en begränsande åtgärd. Båda ändrar ordningen, inte om den hanteras.

Riskbaserad sårbarhetshantering

Riskbaserad sårbarhetshantering är namnet på samma idé på programnivå: rangordna efter bevis på utnyttjande, sannolikhet, allvarlighetsgrad och affärssammanhang, mät hur snabbt de mest riskfyllda fynden stängs och acceptera att fynd med låg risk kan förbli öppna. Mätetalen ändras i takt med det. I stället för det totala antalet öppna sårbarheter spårar du hur många känt utnyttjade sårbarheter som är öppna i levererad programvara, och hur länge de förblir öppna.

Verktyg för prioritering av sårbarheter

Tre sorters verktyg står för det mesta av rangordningen i dag:

• Plattformar för sårbarhetshantering i infrastruktur som Tenable, Qualys och Rapid7 poängsätter värdar, slutpunkter och molntillgångar med egna riskbetyg, byggda på information om utnyttjande.
• SCA- och applikationssäkerhetsverktyg som Snyk, Endor Labs och Semgrep rangordnar fynd i beroenden, flera av dem med reachability-analys.
• Verktyg med öppen källkod som Grype, som rapporterar EPSS- och KEV-data med sina fynd, och Dependency-Track, som analyserar SBOM:er löpande.

Verktyg för sårbarhetshantering i jämförelse går igenom dem ett i taget.

Så stöder CRACI prioritering

CRACI börjar där rangordningen oftast går fel: inventeringen. Det kör dina GitHub Actions-jobb och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, paket som återställs från cachar och dolda beroenden som ingen lockfile listar.

• Fynd för det som levererats. Bevakade SBOM:er omvärderas löpande, och vyer för hela organisationen sammanställer fynd över byggen och repon. Varje paket visar sina säkerhetsmeddelanden med allvarlighetsgrad och de paket som drar in det.
• Exponeringsperiod. Bygghistoriken visar vilka tidigare byggen som innehöll ett sårbart beroende, direkt eller transitivt, så att du vet vilka releaser som berördes och hur länge.
• Triage och vidarebefordran. Säkerhetsteamen triagerar fynden och skickar vart och ett till teamet som äger åtgärden. CRACI har stöd för VEX för att registrera att en sårbarhet inte påverkar din produkt.
• Spärrar. Policyspärrar kan blockera ett bygge på grund av fynd, inklusive ett bygge som innehåller en specifik CVE.

CRACI erbjuder inte reachability-analys. Om det är den signal du behöver mest, välj något av SCA-verktygen som erbjuder det. Se sårbarhetsspårning för hela funktionen.

Prioritering av sårbarheter: vanliga frågor

Vad är prioritering av sårbarheter?

Prioritering av sårbarheter innebär att avgöra vilka kända sårbarheter som ska åtgärdas först, vilka som kan vänta och vilka som inte påverkar dig alls. Den rangordnar fynd efter hur sannolikt det är att de utnyttjas och hur stor skada det skulle göra i din miljö, inte bara efter allvarlighetsgrad.

Hur prioriterar man sårbarheter?

Börja med en korrekt inventering, så att du rangordnar sårbarheter i programvara som faktiskt levereras. Lägg allt på CISA:s lista Known Exploited Vulnerabilities först, och rangordna sedan resten efter sannolikhet för utnyttjande (EPSS) och allvarlighetsgrad (CVSS), justerat för ditt sammanhang: exponering, produktens betydelse och om det finns en åtgärd. Registrera de som inte påverkar dig som VEX-uttalanden.

Räcker CVSS för att prioritera sårbarheter?

Nej. CVSS mäter hur allvarlig en sårbarhet är, inte hur sannolikt det är att den utnyttjas eller hur mycket den spelar roll för dig. Rangordning enbart efter CVSS markerar en stor del av backloggen som hög eller kritisk, och de flesta av de sårbarheterna utnyttjas aldrig.

Vad är riskbaserad sårbarhetshantering?

Riskbaserad sårbarhetshantering rangordnar och åtgärdar sårbarheter efter den risk de utgör för din organisation, genom att kombinera bevis på utnyttjande, sannolikhet, allvarlighetsgrad och affärssammanhang, i stället för att gå igenom dem efter CVSS-poäng eller ålder.

Vad är skillnaden mellan EPSS och KEV?

EPSS är en prognos: den uppskattade sannolikheten att en CVE utnyttjas de kommande 30 dagarna. KEV är en registrering: CISA:s katalog över sårbarheter med bevis på utnyttjande i det vilda. En KEV-post är ett faktum; en EPSS-poäng är en sannolikhet. Använd KEV först och EPSS för att rangordna allt annat.

Ersätter reachability-analys prioritering?

Nej, det är ytterligare en signal. Reachability kontrollerar om din kod kan anropa den sårbara funktionen i ett beroende. Det tar bort fynd som inte kan utlösas, men säger ingenting om hur sannolikt utnyttjande är, och det täcker bara kod som analysen kan följa.