Che cos'è la software composition analysis (SCA)?

Come funziona la SCA

1. Identificare i componenti. Lo strumento legge ciò verso cui viene puntato: manifest e lockfile in un repository, pacchetti installati oppure il contenuto di un'immagine container o di un binario. Il risultato è un inventario di componenti e versioni, spesso esportato come SBOM.
2. Confrontarli con i rischi noti. Ogni componente viene cercato in database di vulnerabilità come GitHub Advisory Database, OSV e NVD, e la sua licenza dichiarata viene confrontata con la Sua policy.
3. Dare priorità. I risultati vengono ordinati per gravità, e alcuni strumenti aggiungono l'analisi di raggiungibilità per verificare se il Suo codice può effettivamente chiamare la funzione vulnerabile.
4. Correggere. Molti strumenti suggeriscono una versione corretta o aprono una pull request, come fanno Dependabot e Renovate. Per una dipendenza transitiva vulnerabile, la correzione di solito va fatta nel pacchetto che la introduce, come mostra un grafo delle dipendenze.

Che cosa trova la SCA

• Vulnerabilità note nelle versioni che Lei usa, con gli advisory che le descrivono.
• Rischio di licenza, come una licenza copyleft in un prodotto proprietario.
• Pacchetti obsoleti e non mantenuti che non riceveranno correzioni di sicurezza.
• Pacchetti malevoli, negli strumenti che analizzano anche il comportamento dei pacchetti invece di limitarsi a confrontarli con gli advisory.

SCA vs SAST

La SCA e lo static application security testing (SAST) vengono spesso venduti insieme, ma esaminano codice diverso e rispondono a domande diverse.

	SCA	SAST
Che cosa analizza	I componenti open source e di terze parti da cui Lei dipende	Il codice scritto dal Suo team
Che cosa trova	Vulnerabilità note, problemi di licenza, pacchetti obsoleti	Difetti nel Suo codice, come injection o gestione non sicura dell'input
Che cosa legge	Manifest, lockfile, pacchetti installati, immagini o binari	Codice sorgente
Che cosa genera un nuovo risultato	Una modifica alle dipendenze, o un nuovo advisory per una versione già distribuita	Una modifica al Suo codice
Output tipico	Componenti vulnerabili con le versioni corrette, e una SBOM	Punti del codice con il difetto e una correzione suggerita

Servono entrambi. Una codebase senza risultati SAST può comunque distribuire una dipendenza vulnerabile, e un albero delle dipendenze pulito non dice nulla sul Suo codice. Veda SAST vs SCA per il confronto completo. Una differenza incide sul modo in cui eseguirli: un risultato SAST compare quando il Suo codice cambia, mentre un risultato SCA può comparire su una release distribuita mesi fa, il giorno in cui viene pubblicato un nuovo advisory.

Dove si ferma la SCA

Ogni risultato SCA dipende dal primo passaggio: identificare i componenti. Un componente che lo strumento non ha mai identificato non può essere confrontato, prioritizzato o corretto, e non compare nemmeno come lacuna. I punti ciechi più comuni:

• Ciò che i file non dicono. La maggior parte degli strumenti SCA legge manifest e lockfile. Un lockfile mancante o non aggiornato, i pacchetti ripristinati dalle cache CI, gli strumenti di build, i download e gli script di installazione non arrivano mai nell'inventario. Veda perché un lockfile non è un registro di ciò che è stato distribuito.
• Gli strumenti non concordano. Due scanner puntati sullo stesso commit restituiscono elenchi di componenti diversi, perché ciascuno ha regole proprie su che cosa leggere e come denominarlo. Veda che cosa non vedono i generatori di SBOM open source.
• Binari. Il software distribuito come binario precompilato dichiara poco o nulla di ciò che un lettore di manifest può vedere.
• Solo vulnerabilità note. Il confronto trova ciò che è stato pubblicato. Un nuovo pacchetto malevolo o un difetto non divulgato non ha ancora un advisory.
• Un'istantanea. Una scansione in una pull request descrive quel momento. I nuovi advisory per versioni già in produzione richiedono qualcosa che continui a controllare ciò che è stato distribuito.

Non è un difetto di un singolo prodotto. È il modo in cui funziona la scansione, 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.

Registri la build, mantenga la Sua SCA

CRACI colma la lacuna di identificazione dal lato della build. È 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, in una SBOM che dichiara la propria completezza. Continua a rivalutare le SBOM di ciò che è stato distribuito man mano che vengono pubblicate nuove vulnerabilità, e la cronologia delle build mostra quali build passate contenevano un pacchetto vulnerabile.

CRACI non esegue SAST né analisi di raggiungibilità, per scelta progettuale. I team lo eseguono accanto a uno strumento SCA o SAST che copre le pull request e il loro codice. Veda gli strumenti SCA a confronto, dove si colloca CRACI accanto ai Suoi strumenti SCA, oppure prenoti una demo per confrontare una SBOM registrata con la Sua scansione attuale.

Software composition analysis: domande frequenti

Che cos'è la SCA nella cyber security?

La software composition analysis (SCA) è la pratica di individuare i componenti open source e di terze parti nel Suo software e controllarli alla ricerca di vulnerabilità note, problemi di licenza e versioni obsolete. Copre il codice da cui Lei dipende, a differenza del codice che scrive.

Qual è la differenza tra SCA e SAST?

Il SAST analizza il codice scritto dal Suo team alla ricerca di difetti come i bug di injection. La SCA analizza i componenti da cui Lei dipende alla ricerca di vulnerabilità note e problemi di licenza. Rispondono a domande diverse, quindi la maggior parte dei programmi di sicurezza li esegue entrambi.

Che cosa significa scansione SCA?

Una scansione SCA legge i manifest, i lockfile, i pacchetti installati o un'immagine container di un progetto, individua quali componenti contiene e li confronta con i dati su vulnerabilità e licenze. Il risultato è un elenco di risultati, spesso con una SBOM dei componenti identificati.

Una SBOM è la stessa cosa della SCA?

No. Una SBOM è un inventario: l'elenco dei componenti in una release. La SCA è l'analisi: identificare i componenti e controllarne il rischio. Molti strumenti SCA producono una SBOM lungo il percorso, e una SBOM può alimentare il monitoraggio delle vulnerabilità dopo la release.

Quali sono i limiti della SCA?

Analizza solo i componenti che riesce a identificare, di solito da manifest e lockfile. I pacchetti ripristinati dalle cache CI, gli strumenti di build, i download e i binari senza metadati dei pacchetti possono sfuggire. Trova le vulnerabilità note, non quelle sconosciute, e una scansione è un'istantanea, a meno che lo strumento non continui a ricontrollare ciò che è stato distribuito.

Quali sono i migliori strumenti SCA?

Dipende da ciò che Le serve oltre alle basi: analisi di raggiungibilità, rilevamento dei pacchetti malevoli, policy sulle licenze o workflow per gli sviluppatori. Veda il nostro confronto tra 13 strumenti SCA per sapere che cosa copre ciascuno e dove si ferma.