Analisi di raggiungibilità

Perché esiste

Una scansione SCA confronta le versioni dei pacchetti con gli advisory. Sa che una versione contiene un difetto, ma non se la Sua applicazione usa la parte difettosa. Una libreria con centinaia di funzioni e un parser vulnerabile viene segnalata allo stesso modo che Lei chiami o meno quel parser, e su un ampio albero delle dipendenze tutto questo si somma in un backlog che nessuno può smaltire.

Come funziona l'analisi di raggiungibilità

1. Trovare il codice vulnerabile. Lo strumento deve sapere in quale funzione si trova una vulnerabilità. Spesso gli advisory non lo dicono, quindi i vendor mantengono dati propri.
2. Costruire un call graph. Mappa quali funzioni chiamano quali altre, dal Suo codice giù attraverso le dipendenze.
3. Cercare un percorso. Se una catena di chiamate porta dal Suo codice alla funzione vulnerabile, il risultato è raggiungibile. In caso contrario, viene contrassegnato come non raggiungibile e classificato più in basso.

Livelli di raggiungibilità

Livello	A quale domanda risponde	Compromesso
Dipendenza	Il pacchetto viene almeno importato?	Economico, ed elimina solo le dipendenze inutilizzate
Funzione	Un percorso di chiamate può raggiungere la funzione vulnerabile?	L'obiettivo più comune, e richiede un call graph e dati sulle vulnerabilità per funzione
Runtime	Questo codice è stato caricato o eseguito in produzione?	Evidenze dal traffico reale, ma solo per ciò che è stato eseguito durante l'osservazione

Un exploit reale richiede più di un percorso. L'input deve raggiungere la funzione in una forma che faccia scattare il difetto, e pochi strumenti sono in grado di stabilirlo.

Dove l'analisi di raggiungibilità non basta

• Non raggiungibile non significa sicuro. Significa che lo strumento non ha trovato un percorso. Reflection, import dinamici e caricamento di plugin possono creare percorsi che l'analisi statica non vede.
• La copertura dei linguaggi varia. I linguaggi a compilazione statica sono più facili da tracciare di quelli dinamici, e gli strumenti differiscono sugli ecosistemi che ricevono l'analisi a livello di funzione.
• I dati sulle vulnerabilità sono incompleti. Se nessuno ha associato un advisory a una funzione, lo strumento non ha nulla da cercare.
• Cambia con il Suo codice. Un risultato oggi non raggiungibile può diventarlo dopo la prossima release, quindi la risposta va ricontrollata.
• Classifica solo ciò che è stato identificato. Un componente che lo scanner non ha mai trovato non può essere analizzato. Senza un inventario completo, la raggiungibilità ordina solo una parte del quadro.

Come usarla in sicurezza

• La usi per ordinare il lavoro, non per scartarlo. Corregga prima i risultati raggiungibili e pianifichi gli altri, invece di chiuderli.
• Non le lasci prevalere sullo sfruttamento attivo. Un risultato presente nel catalogo KEV di CISA o con un punteggio EPSS elevato merita la decisione di una persona, anche se è contrassegnato come non raggiungibile.
• Faccia attenzione ai servizi esposti su internet. Il costo di una risposta sbagliata è massimo dove gli attaccanti possono raggiungerLa direttamente.
• Registri il ragionamento. Se decide che un risultato non si applica, una dichiarazione VEX conserva la decisione e ne spiega il motivo ai Suoi clienti.

Per capire come la raggiungibilità si combina con gravità, dati sugli exploit e contesto di business, veda come dare priorità alle vulnerabilità.

Quali strumenti offrono l'analisi di raggiungibilità?

Molti strumenti SCA commerciali la offrono, tra cui Snyk, Endor Labs, Mend, Checkmarx, Semgrep e Aikido, con una profondità che varia in base al linguaggio. govulncheck di Go è un esempio gratuito per un singolo ecosistema. Veda il confronto tra i migliori strumenti SCA per sapere che cosa copre ciascuno.

Dove si colloca CRACI

CRACI non offre l'analisi di raggiungibilità. Lavora sul passaggio che la precede: sapere che cosa c'è nella build. È un runner GitHub Actions che registra ogni pacchetto scaricato da ciascun job, comprese le dipendenze nascoste che gli scanner di lockfile non vedono, e continua a rivalutare le SBOM di ciò che è stato distribuito man mano che vengono pubblicate nuove vulnerabilità. Se la raggiungibilità è la Sua priorità principale, usi uno strumento creato per questo accanto a CRACI. Veda dove si colloca CRACI accanto ai Suoi strumenti SCA.

Analisi di raggiungibilità: domande frequenti

Che cos'è l'analisi di raggiungibilità nella SCA?

Verifica se il Suo codice può effettivamente chiamare la funzione vulnerabile di una dipendenza, così i risultati senza un percorso dal Suo codice possono essere classificati più in basso.

L'analisi di raggiungibilità è accurata?

È utile, ma non è una prova. Un risultato raggiungibile ha un percorso reale, mentre uno non raggiungibile significa solo che lo strumento non ne ha trovati. Reflection, caricamento dinamico e lacune nei dati sulle vulnerabilità possono nascondere un percorso.

Si possono ignorare le vulnerabilità non raggiungibili?

Non le ignori del tutto. Le pianifichi dopo i risultati raggiungibili, le ricontrolli dopo le modifiche al codice e presti particolare attenzione a tutto ciò che viene sfruttato attivamente o viene eseguito in un servizio esposto su internet.

Qual è la differenza tra raggiungibilità e sfruttabilità?

La raggiungibilità chiede se il codice può arrivare alla funzione vulnerabile. La sfruttabilità chiede se un attaccante può usare quel percorso per causare danni. Un difetto può essere raggiungibile e tuttavia non sfruttabile nella Sua configurazione.

L'analisi di raggiungibilità riduce gli avvisi?

Sì, è il suo scopo principale. Di quanto dipende dal linguaggio, dallo strumento e da quanta parte di ogni dipendenza usa il Suo codice.