Reachability-analyse

Derfor findes den

En SCA-scanning matcher pakkeversioner mod advisories. Den ved, at en version indeholder en fejl, men ikke om din applikation bruger den del, fejlen sidder i. Et bibliotek med hundredvis af funktioner og én sårbar parser rapporteres på samme måde, uanset om du kalder parseren eller ej, og i et stort afhængighedstræ løber det op i en backlog, ingen kan blive færdig med.

Sådan virker reachability-analyse

1. Find den sårbare kode. Værktøjet skal vide, hvilken funktion en sårbarhed sidder i. Advisories siger det ofte ikke, så leverandører vedligeholder deres egne data.
2. Byg en kaldgraf. Den kortlægger, hvilke funktioner der kalder hvilke, fra din kode og ned gennem afhængighederne.
3. Se efter en sti. Hvis en kæde af kald fører fra din kode til den sårbare funktion, er fundet reachable. Hvis ikke, markeres det som unreachable og rangeres lavere.

Niveauer af reachability

Niveau	Spørgsmål, det besvarer	Afvejning
Afhængighed	Importeres pakken overhovedet?	Billigt og fjerner kun ubrugte afhængigheder
Funktion	Kan en kaldsti nå den sårbare funktion?	Det almindelige mål, kræver en kaldgraf og sårbarhedsdata pr. funktion
Kørsel	Blev denne kode indlæst eller kørt i produktion?	Dokumentation fra rigtig trafik, men kun for det, der kørte, mens den overvågede

Et reelt exploit kræver mere end en sti. Inputtet skal nå funktionen i en form, der udløser fejlen, og det er der få værktøjer, der kan se.

Hvor reachability-analyse kommer til kort

• Unreachable betyder ikke sikker. Det betyder, at værktøjet ikke fandt nogen sti. Reflection, dynamiske imports og indlæsning af plugins kan skabe stier, som statisk analyse ikke ser.
• Sprogdækningen varierer. Statisk kompilerede sprog er lettere at spore end dynamiske, og værktøjer er forskellige med hensyn til, hvilke økosystemer der får analyse på funktionsniveau.
• Sårbarhedsdata er ufuldstændige. Hvis ingen har koblet en advisory til en funktion, har værktøjet intet at lede efter.
• Den ændrer sig med din kode. Dagens unreachable fund kan være reachable efter næste release, så svaret skal tjekkes igen.
• Den rangerer kun det, der blev identificeret. En komponent, scanneren aldrig fandt, kan ikke analyseres. Uden en komplet fortegnelse sorterer reachability kun en del af billedet.

Sådan bruger du den sikkert

• Brug den til at ordne arbejdet, ikke til at afvise det. Ret reachable fund først, og planlæg resten i stedet for at lukke dem.
• Lad den ikke trumfe aktiv udnyttelse. Et fund i CISA's KEV-katalog eller med en høj EPSS-score fortjener en menneskelig beslutning, også selvom det er markeret som unreachable.
• Vær forsigtig med internetvendte services. Prisen for et forkert svar er størst dér, hvor angribere kan nå dig direkte.
• Registrér begrundelsen. Hvis du beslutter, at et fund ikke gælder, bevarer en VEX-erklæring beslutningen og fortæller dine kunder hvorfor.

Se, hvordan reachability hænger sammen med alvorlighed, exploit-data og forretningskontekst, i sådan prioriterer du sårbarheder.

Hvilke værktøjer tilbyder reachability-analyse?

Det gør mange kommercielle SCA-værktøjer, herunder Snyk, Endor Labs, Mend, Checkmarx, Semgrep og Aikido, og dybden varierer fra sprog til sprog. Go's govulncheck er et gratis eksempel for ét økosystem. Se de bedste SCA-værktøjer sammenlignet for, hvad hvert dækker.

Hvor CRACI passer ind

CRACI tilbyder ikke reachability-analyse. Det arbejder på trinnet før: at vide, hvad der overhovedet er i buildet. Det er en GitHub Actions-runner, der registrerer hver pakke, hvert job henter, inklusive de skjulte afhængigheder, som lockfile-scannere overser, og bliver ved med at genvurdere SBOM'erne for det leverede, efterhånden som nye sårbarheder offentliggøres. Hvis reachability er din højeste prioritet, så brug et værktøj bygget til det ved siden af CRACI. Se hvor CRACI passer ind ved siden af dine SCA-værktøjer.

Reachability-analyse: ofte stillede spørgsmål

Hvad er reachability-analyse i SCA?

Den tjekker, om din kode faktisk kan kalde den sårbare funktion i en afhængighed, så fund uden en sti fra din kode kan rangeres lavere.

Er reachability-analyse præcis?

Den er nyttig, men ikke et bevis. Et reachable fund har en reel sti, mens et unreachable fund kun betyder, at værktøjet ikke fandt nogen. Reflection, dynamisk indlæsning og huller i sårbarhedsdata kan alle skjule en sti.

Kan du ignorere unreachable sårbarheder?

Ignorér dem ikke helt. Planlæg dem efter de reachable fund, tjek dem igen efter kodeændringer, og giv ekstra opmærksomhed til alt, der aktivt udnyttes eller kører i en internetvendt service.

Hvad er forskellen på reachability og exploitability?

Reachability spørger, om kode kan nå den sårbare funktion. Exploitability spørger, om en angriber kan bruge den sti til at gøre skade. En fejl kan være reachable og alligevel ikke kunne udnyttes i din opsætning.

Reducerer reachability-analyse antallet af alarmer?

Ja, det er dens vigtigste formål. Hvor meget afhænger af sproget, værktøjet og hvor meget af hver afhængighed din kode bruger.