Reachability-analyse

Waarom het bestaat

Een SCA-scan matcht pakketversies met advisories. Hij weet dat een versie een fout bevat, maar niet of uw applicatie het deel met die fout gebruikt. Een bibliotheek met honderden functies en één kwetsbare parser wordt op dezelfde manier gerapporteerd, of u die parser nu aanroept of niet, en over een grote afhankelijkheidsboom levert dat een achterstand op die niemand kan wegwerken.

Hoe reachability-analyse werkt

1. De kwetsbare code vinden. De tool moet weten in welke functie een kwetsbaarheid zit. Advisories vermelden dat vaak niet, dus leveranciers onderhouden eigen gegevens.
2. Een call graph opbouwen. De tool brengt in kaart welke functies welke andere aanroepen, van uw code tot diep in de afhankelijkheden.
3. Een pad zoeken. Leidt een keten van aanroepen van uw code naar de kwetsbare functie, dan is de bevinding bereikbaar. Zo niet, dan wordt ze als onbereikbaar gemarkeerd en lager gerangschikt.

Niveaus van reachability

Niveau	Vraag die het beantwoordt	Afweging
Afhankelijkheid	Wordt het pakket überhaupt geïmporteerd?	Goedkoop, en verwijdert alleen ongebruikte afhankelijkheden
Functie	Kan een aanroeppad de kwetsbare functie bereiken?	Het gebruikelijke doel, en vereist een call graph en kwetsbaarheidsgegevens per functie
Runtime	Is deze code in productie geladen of uitgevoerd?	Bewijs uit echt verkeer, maar alleen voor wat draaide terwijl er werd gekeken

Echt misbruik vraagt meer dan een pad. De invoer moet de functie bereiken in een vorm die de fout activeert, en dat kunnen maar weinig tools bepalen.

Waar reachability-analyse tekortschiet

• Onbereikbaar betekent niet veilig. Het betekent dat de tool geen pad heeft gevonden. Reflection, dynamische imports en het laden van plug-ins kunnen paden creëren die statische analyse niet ziet.
• De taaldekking varieert. Statisch gecompileerde talen zijn makkelijker te traceren dan dynamische, en tools verschillen in welke ecosystemen analyse op functieniveau krijgen.
• Kwetsbaarheidsgegevens zijn onvolledig. Als niemand een advisory aan een functie heeft gekoppeld, heeft de tool niets om naar te zoeken.
• Het verandert mee met uw code. Een bevinding die vandaag onbereikbaar is, kan na de volgende release bereikbaar zijn, dus het antwoord moet opnieuw worden gecontroleerd.
• Het rangschikt alleen wat is geïdentificeerd. Een component dat de scanner nooit heeft gevonden, kan niet worden geanalyseerd. Zonder volledige inventaris sorteert reachability maar een deel van het plaatje.

Hoe u het veilig gebruikt

• Gebruik het om werk te ordenen, niet om het af te wijzen. Los bereikbare bevindingen eerst op en plan de rest in, in plaats van ze te sluiten.
• Laat het niet zwaarder wegen dan actief misbruik. Een bevinding in de KEV-catalogus van CISA of met een hoge EPSS-score verdient een menselijke beslissing, ook als ze als onbereikbaar is gemarkeerd.
• Wees voorzichtig met services die vanaf internet bereikbaar zijn. Een verkeerd antwoord kost het meest waar aanvallers u rechtstreeks kunnen bereiken.
• Leg de redenering vast. Als u besluit dat een bevinding niet van toepassing is, bewaart een VEX-verklaring die beslissing en vertelt ze uw klanten waarom.

Zie hoe u kwetsbaarheden prioriteert voor hoe reachability samengaat met ernst, misbruikgegevens en bedrijfscontext.

Welke tools bieden reachability-analyse?

Veel commerciële SCA-tools, waaronder Snyk, Endor Labs, Mend, Checkmarx, Semgrep en Aikido, en de diepgang verschilt per taal. govulncheck van Go is een gratis voorbeeld voor één ecosysteem. Zie de beste SCA-tools vergeleken voor wat elk daarvan dekt.

De rol van CRACI

CRACI biedt geen reachability-analyse. Het werkt aan de stap ervoor: weten wat er überhaupt in de build zit. Het is een GitHub Actions-runner die elk pakket vastlegt dat een job ophaalt, inclusief de verborgen afhankelijkheden die lockfile-scanners missen, en de SBOM's van wat is geleverd opnieuw blijft beoordelen zodra nieuwe kwetsbaarheden worden gepubliceerd. Is reachability uw hoogste prioriteit, gebruik dan naast CRACI een tool die daarvoor is gemaakt. Zie hoe CRACI samengaat met uw SCA-tools.

Reachability-analyse: veelgestelde vragen

Wat is reachability-analyse in SCA?

Ze controleert of uw code de kwetsbare functie in een afhankelijkheid daadwerkelijk kan aanroepen, zodat bevindingen zonder pad vanuit uw code lager kunnen worden gerangschikt.

Is reachability-analyse nauwkeurig?

Ze is nuttig, maar geen bewijs. Een bereikbare bevinding heeft een echt pad, terwijl een onbereikbare alleen betekent dat de tool er geen heeft gevonden. Reflection, dynamisch laden en hiaten in kwetsbaarheidsgegevens kunnen allemaal een pad verbergen.

Kunt u onbereikbare kwetsbaarheden negeren?

Negeer ze niet zomaar. Plan ze in na de bereikbare bevindingen, controleer ze opnieuw na codewijzigingen en besteed extra aandacht aan alles wat actief wordt misbruikt of in een service draait die vanaf internet bereikbaar is.

Wat is het verschil tussen reachability en exploitability?

Reachability vraagt of code de kwetsbare functie kan bereiken. Exploitability vraagt of een aanvaller dat pad kan gebruiken om schade aan te richten. Een fout kan bereikbaar zijn en in uw opzet toch niet misbruikt kunnen worden.

Vermindert reachability-analyse het aantal meldingen?

Ja, dat is het belangrijkste doel. Hoeveel precies hangt af van de taal, de tool en hoeveel van elke afhankelijkheid uw code gebruikt.