Scansione SCA

Che cosa succede in una scansione SCA

1. Lettura del target. Lo scanner legge manifest e lockfile come package-lock.json, poetry.lock o Cargo.lock, oppure decomprime un'immagine container.
2. Creazione dell'elenco dei componenti. Traduce ciò che ha trovato in nomi e versioni, di solito incluse le dipendenze transitive.
3. Confronto con i dati. Ogni componente viene cercato in fonti come GitHub Advisory Database, OSV e NVD, e la sua licenza viene confrontata con la Sua policy.
4. Report. I risultati vengono ordinati per gravità, di solito con una versione corretta. In CI, una policy può far fallire il job.

Per la pratica più ampia di cui fa parte, veda che cos'è la software composition analysis.

Dove eseguire le scansioni SCA

Una scansione in un solo punto lascia delle lacune. Ogni fase risponde a una domanda diversa, quindi la maggior parte dei team ne esegue più di una.

Dove	A che cosa risponde	Che cosa non vede
Macchina dello sviluppatore o IDE	Questo pacchetto si può aggiungere in sicurezza?	Tutto ciò su cui lo sviluppatore non la esegue
Pull request	Questa modifica aggiunge un rischio noto?	Nuovi advisory per codice che non è cambiato
Build CI	Che cosa contiene la release?	Tutto ciò che lo scanner non riesce a vedere nella build
Registry di container	Che cosa c'è in questa immagine?	Codice compilato e strumenti di build che non lasciano traccia
Dopo il rilascio	Ciò che abbiamo distribuito è colpito da qualcosa di nuovo?	Nulla, se il registro di ciò che è stato distribuito è completo

L'ultima riga è quella che la maggior parte dei programmi trascura. Un nuovo advisory riguarda una versione distribuita mesi fa, e nessuna pull request farà partire una scansione per individuarla.

Come leggere i risultati di una scansione SCA

La prima scansione di un progetto reale restituisce spesso centinaia di risultati. Li affronti in questo ordine:

1. Inizi da ciò che viene sfruttato. Un risultato presente nel catalogo KEV di CISA ha la precedenza su un punteggio CVSS più alto senza sfruttamento noto. Veda come dare priorità alle vulnerabilità.
2. Verifichi che sia pertinente. Le dipendenze usate solo in sviluppo non vengono distribuite. Alcuni strumenti aggiungono l'analisi di raggiungibilità per verificare se il codice vulnerabile può essere chiamato.
3. Corregga al livello giusto. Per un risultato transitivo, la correzione di solito va fatta nel pacchetto che lo introduce, come mostra un grafo delle dipendenze.
4. Registri ciò che non correggerà. Un risultato che ha deciso di accettare deve indicarne il motivo, altrimenti la persona successiva ripeterà il lavoro. VEX è il modo standard per registrarlo.

Perché una scansione pulita non significa software pulito

• Vede ciò che è dichiarato. Uno scanner legge i file che ha davanti, quindi un repository che non include un lockfile gli offre poco su cui lavorare, e il codice scaricato da un hook di installazione non compare mai.
• Vede ciò verso cui lo ha puntato. L'immagine base, gli strumenti di build e le GitHub Actions della Sua pipeline sono separati dal manifest della Sua applicazione.
• Conosce solo ciò che è pubblicato. Un nuovo pacchetto malevolo non ha ancora un advisory.
• L'elenco non è la build. Le build risolvono le versioni quando vengono eseguite, quindi ciò che la scansione ha letto e ciò che la release contiene possono differire.

Questi sono limiti della scansione in sé, commerciale o open source. CRACI ha trovato pacchetti vulnerabili che Snyk e Aikido non avevano segnalato, perché quei componenti non erano mai stati in ciò che avevano scansionato.

Scanner gratuiti e commerciali

Le opzioni gratuite coprono bene le basi. Gli avvisi di Dependabot sono inclusi in GitHub, OWASP Dependency-Check e Trivy sono open source e Grype si abbina al generatore di SBOM Syft. Gli strumenti commerciali aggiungono policy, prioritizzazione, raggiungibilità e workflow tra molti team. Il confronto tra i migliori strumenti SCA ne copre 13, e questa guida mostra perché i risultati dei generatori gratuiti divergono tra loro.

Scansione SCA e registrazione in fase di build

CRACI non è uno scanner e Lei non deve rinunciare al Suo. È un runner GitHub Actions che registra ogni pacchetto scaricato da ciascun job, a ogni profondità dell'albero e compresi i pacchetti ripristinati dalle cache CI, poi continua a rivalutare le SBOM di ciò che è stato distribuito man mano che vengono pubblicate nuove vulnerabilità. Il Suo scanner copre le pull request e le macchine degli sviluppatori. CRACI copre la build e tutto ciò che viene dopo. Veda dove si colloca CRACI accanto ai Suoi strumenti SCA.

Scansione SCA: domande frequenti

Che cos'è una scansione SCA?

Una scansione SCA legge i manifest, i lockfile o l'immagine container di un progetto, individua i componenti open source che usa e li confronta con i dati su vulnerabilità e licenze.

SCA è la stessa cosa della scansione delle dipendenze?

Quasi. La scansione delle dipendenze di solito indica il controllo delle dipendenze alla ricerca di vulnerabilità note. SCA è il termine più ampio e comprende anche licenze, pacchetti obsoleti e la produzione di un inventario come una SBOM.

Quando vanno eseguite le scansioni SCA?

Sulle pull request, per impedire l'ingresso di nuovi rischi; nella build CI, per descrivere la release; e di continuo dopo il rilascio, perché i nuovi advisory riguardano software già distribuito.

Quanto dura una scansione SCA?

Di solito da pochi secondi a qualche minuto, perché legge metadati invece di analizzare tutto il Suo codice. Per questo è pratico eseguirla su ogni pull request.

Perché gli scanner SCA riportano risultati diversi?

Ognuno ha regole proprie su che cosa leggere, come denominare i componenti e quali dati sulle vulnerabilità usare. Lo stesso commit può produrre elenchi di componenti e risultati diversi.

La scansione SCA trova il malware?

Il confronto con gli advisory trova le release malevole solo quando esiste un advisory. Gli strumenti che analizzano il comportamento dei pacchetti possono individuarne alcune prima. Un nuovo pacchetto malevolo non ha alcun advisory il giorno in cui compare.