Reachability-analyse

Hvorfor den finnes

En SCA-skanning matcher pakkeversjoner mot advisories. Den vet at en versjon inneholder en feil, men ikke om applikasjonen din bruker delen med feilen. Et bibliotek med hundrevis av funksjoner og én sårbar parser rapporteres på samme måte enten du kaller den parseren eller ikke, og i et stort avhengighetstre blir det til en backlog ingen klarer å bli ferdig med.

Slik fungerer reachability-analyse

1. Finner den sårbare koden. Verktøyet må vite hvilken funksjon en sårbarhet ligger i. Advisories sier ofte ikke det, så leverandørene vedlikeholder egne data.
2. Bygger en kallgraf. Den kartlegger hvilke funksjoner som kaller hvilke, fra koden din og ned gjennom avhengighetene.
3. Leter etter en sti. Hvis en kjede av kall fører fra koden din til den sårbare funksjonen, er funnet nåbart. Hvis ikke, merkes det som ikke nåbart og rangeres lavere.

Nivåer av reachability

Nivå	Spørsmålet det svarer på	Avveining
Avhengighet	Er pakken i det hele tatt importert?	Billig, og fjerner bare ubrukte avhengigheter
Funksjon	Kan en kallsti nå den sårbare funksjonen?	Det vanlige målet, og krever en kallgraf og sårbarhetsdata per funksjon
Kjøretid	Ble denne koden lastet eller kjørt i produksjon?	Dokumentasjon fra ekte trafikk, men bare for det som kjørte mens den så på

En reell utnyttelse krever mer enn en sti. Inputen må nå funksjonen i en form som utløser feilen, og det er det få verktøy som kan avgjøre.

Hvor reachability-analyse kommer til kort

• Ikke nåbart betyr ikke trygt. Det betyr at verktøyet ikke fant noen sti. Refleksjon, dynamiske importer og lasting av plugins kan skape stier som statisk analyse ikke ser.
• Språkdekningen varierer. Statisk kompilerte språk er lettere å spore enn dynamiske, og verktøyene er ulike når det gjelder hvilke økosystemer som får analyse på funksjonsnivå.
• Sårbarhetsdataene er ufullstendige. Hvis ingen har koblet en advisory til en funksjon, har verktøyet ingenting å lete etter.
• Den endres med koden din. Et funn som ikke er nåbart i dag, kan være nåbart etter neste utgivelse, så svaret må sjekkes på nytt.
• Den rangerer bare det som er identifisert. En komponent skanneren aldri fant, kan ikke analyseres. Uten en fullstendig oversikt sorterer reachability bare en del av bildet.

Slik bruker du den trygt

• Bruk den til å ordne arbeidet, ikke til å avvise det. Rett nåbare funn først og planlegg resten i stedet for å lukke dem.
• Ikke la den overstyre aktiv utnyttelse. Et funn i KEV-katalogen til CISA eller med en høy EPSS-score fortjener en menneskelig beslutning selv om det er merket som ikke nåbart.
• Vær forsiktig med tjenester som er eksponert mot internett. Prisen for et feil svar er høyest der angripere kan nå deg direkte.
• Registrer begrunnelsen. Hvis du bestemmer at et funn ikke gjelder, bevarer en VEX-erklæring beslutningen og forteller kundene dine hvorfor.

Hvordan reachability henger sammen med alvorlighetsgrad, data om utnyttelse og forretningskontekst, finner du i slik prioriterer du sårbarheter.

Hvilke verktøy tilbyr reachability-analyse?

Det gjør mange kommersielle SCA-verktøy, blant dem Snyk, Endor Labs, Mend, Checkmarx, Semgrep og Aikido, og dybden varierer med språket. Gos govulncheck er et gratis eksempel for ett økosystem. Se de beste SCA-verktøyene sammenlignet for hva hvert av dem dekker.

Hvor CRACI passer inn

CRACI tilbyr ikke reachability-analyse. CRACI jobber med steget før: å vite hva som i det hele tatt er i bygget. Det er en GitHub Actions-runner som registrerer hver pakke hver jobb henter, inkludert de skjulte avhengighetene som lockfile-skannere går glipp av, og fortsetter å vurdere SBOM-ene for det som er levert, på nytt etter hvert som nye sårbarheter publiseres. Hvis reachability er din høyeste prioritet, bør du bruke et verktøy laget for det ved siden av CRACI. Se hvor CRACI passer inn ved siden av SCA-verktøyene dine.

Reachability-analyse: ofte stilte spørsmål

Hva er reachability-analyse i SCA?

Den sjekker om koden din faktisk kan kalle den sårbare funksjonen i en avhengighet, slik at funn uten en sti fra koden din kan rangeres lavere.

Er reachability-analyse nøyaktig?

Den er nyttig, men ikke et bevis. Et nåbart funn har en reell sti, mens et ikke-nåbart funn bare betyr at verktøyet ikke fant noen. Refleksjon, dynamisk lasting og hull i sårbarhetsdataene kan alle skjule en sti.

Kan du ignorere sårbarheter som ikke er nåbare?

Ikke ignorer dem helt. Planlegg dem etter nåbare funn, sjekk på nytt etter kodeendringer, og gi ekstra oppmerksomhet til alt som utnyttes aktivt eller kjører i en tjeneste som er eksponert mot internett.

Hva er forskjellen på reachability og utnyttbarhet?

Reachability spør om kode kan nå den sårbare funksjonen. Utnyttbarhet spør om en angriper kan bruke den stien til å gjøre skade. En feil kan være nåbar og likevel ikke kunne utnyttes i ditt oppsett.

Reduserer reachability-analyse antallet varsler?

Ja, det er hovedformålet. Hvor mye avhenger av språket, verktøyet og hvor mye av hver avhengighet koden din bruker.