Reachability-analys

Varför den finns

En SCA-skanning matchar paketversioner mot säkerhetsmeddelanden. Den vet att en version innehåller en brist, men inte om din applikation använder delen med bristen. Ett bibliotek med hundratals funktioner och en sårbar parser rapporteras på samma sätt oavsett om du anropar parsern eller inte, och i ett stort beroendeträd blir det en backlogg som ingen hinner beta av.

Så fungerar reachability-analys

1. Hitta den sårbara koden. Verktyget måste veta vilken funktion en sårbarhet finns i. Säkerhetsmeddelanden anger det ofta inte, så leverantörerna underhåller egna data.
2. Bygg en anropsgraf. Den kartlägger vilka funktioner som anropar vilka, från din kod ner genom beroendena.
3. Leta efter en väg. Om en kedja av anrop leder från din kod till den sårbara funktionen är fyndet nåbart. Annars markeras det som onåbart och rangordnas lägre.

Nivåer av reachability

Nivå	Frågan den besvarar	Avvägning
Beroende	Importeras paketet över huvud taget?	Billigt, och tar bara bort oanvända beroenden
Funktion	Kan en anropsväg nå den sårbara funktionen?	Det vanliga målet, och kräver en anropsgraf och sårbarhetsdata per funktion
Körning	Laddades eller kördes den här koden i produktion?	Belägg från verklig trafik, men bara för det som kördes under observationen

En verklig exploatering kräver mer än en väg. Indata måste nå funktionen i en form som utlöser bristen, vilket få verktyg kan avgöra.

Där reachability-analys brister

• Onåbart betyder inte säkert. Det betyder att verktyget inte hittade någon väg. Reflektion, dynamiska importer och laddning av plugins kan skapa vägar som statisk analys inte ser.
• Språktäckningen varierar. Statiskt kompilerade språk är lättare att spåra än dynamiska, och verktyg skiljer sig åt i vilka ekosystem som får analys på funktionsnivå.
• Sårbarhetsdata är ofullständiga. Om ingen har kopplat ett säkerhetsmeddelande till en funktion har verktyget inget att leta efter.
• Den ändras med din kod. Dagens onåbara fynd kan vara nåbart efter nästa release, så svaret behöver kontrolleras igen.
• Den rangordnar bara det som identifierats. En komponent som skannern aldrig hittade kan inte analyseras. Utan en komplett förteckning sorterar reachability bara en del av bilden.

Så använder du den säkert

• Använd den för att ordna arbetet, inte för att avfärda det. Åtgärda nåbara fynd först och schemalägg resten i stället för att stänga dem.
• Låt den inte gå före aktiv exploatering. Ett fynd i CISA:s KEV-katalog eller med en hög EPSS-poäng förtjänar ett mänskligt beslut även om det är markerat som onåbart.
• Var försiktig med tjänster som är exponerade mot internet. Ett felaktigt svar kostar mest där angripare kan nå dig direkt.
• Registrera resonemanget. Om du beslutar att ett fynd inte gäller bevarar ett VEX-uttalande beslutet och talar om för dina kunder varför.

För hur reachability samspelar med allvarlighetsgrad, exploateringsdata och affärskontext, se så prioriterar du sårbarheter.

Vilka verktyg erbjuder reachability-analys?

Många kommersiella SCA-verktyg gör det, bland dem Snyk, Endor Labs, Mend, Checkmarx, Semgrep och Aikido, och djupet varierar mellan språk. Go:s govulncheck är ett gratis exempel för ett ekosystem. Se de bästa SCA-verktygen i jämförelse för vad vart och ett täcker.

Var CRACI passar in

CRACI erbjuder inte reachability-analys. CRACI arbetar med steget före: att veta vad som över huvud taget finns i bygget. CRACI är en GitHub Actions-runner som registrerar varje paket som varje jobb hämtar, inklusive de dolda beroenden som lockfile-skannrar missar, och fortsätter att omvärdera SBOM:erna för det som levererats när nya sårbarheter publiceras. Om reachability är din högsta prioritet, använd ett verktyg som är byggt för det bredvid CRACI. Se var CRACI passar in bredvid dina SCA-verktyg.

Reachability-analys: vanliga frågor

Vad är reachability-analys i SCA?

Den kontrollerar om din kod faktiskt kan anropa den sårbara funktionen i ett beroende, så att fynd utan någon väg från din kod kan rangordnas lägre.

Är reachability-analys träffsäker?

Den är användbar men inget bevis. Ett nåbart fynd har en verklig väg, medan ett onåbart bara betyder att verktyget inte hittade någon. Reflektion, dynamisk laddning och luckor i sårbarhetsdata kan alla dölja en väg.

Kan du ignorera onåbara sårbarheter?

Ignorera dem inte helt. Schemalägg dem efter de nåbara fynden, kontrollera igen efter kodändringar och var extra uppmärksam på allt som utnyttjas aktivt eller körs i en tjänst som är exponerad mot internet.

Vad är skillnaden mellan reachability och exploaterbarhet?

Reachability frågar om kod kan nå den sårbara funktionen. Exploaterbarhet frågar om en angripare kan använda den vägen för att göra skada. En brist kan vara nåbar och ändå inte gå att exploatera i din miljö.

Minskar reachability-analys antalet varningar?

Ja, det är dess huvudsyfte. Hur mycket beror på språket, verktyget och hur stor del av varje beroende din kod använder.