Cos'è l'analisi della composizione del software (SCA)?

Gli strumenti SCA operano scansionando il codice sorgente del software, raccogliendolo in un database, confrontandolo con database di vulnerabilità noti, verificando la presenza di aggiornamenti o problemi di licenza e quindi producendo un report. 

Sebbene l'analisi della composizione del software possa analizzare tutti i tipi di elementi software, compresi i componenti proprietari e le immagini dei contenitori, è più comunemente utilizzata per analizzare le librerie open source. I componenti open source sono inclusi in qualche misura in quasi tutte le basi di codice moderne e, poiché le vulnerabilità nel loro codice sono di dominio pubblico, è particolarmente importante mantenere il software open source aggiornato e trasparente.

Gli strumenti SCA gestiscono i rischi di vulnerabilità di sicurezza derivanti da componenti software di origine sconosciuta, problemi di compatibilità tra diverse licenze open source e documentazione o supporto incompleti o insufficienti per le librerie open source.  

L'analisi della composizione del software fa parte della pipeline  DevOps cloud-native che integra il processo di sviluppo del software con le operazioni IT. SCA supporta inoltre il livello di sicurezza di un'organizzazione come parte della pipeline DevSecOps, che integra sicurezza con sviluppo e operazioni. Gli strumenti SCA possono essere distribuiti in un ambiente di sviluppo integrato (IDE), fornendo analisi del codice in tempo reale durante il processo di sviluppo.

La SCA si differenzia da altre forme di scansione delle vulnerabilità come il test statico di sicurezza applicativa (SAST), il test dinamico di sicurezza delle applicazioni (DAST) e la scansione delle dipendenze.

I team IT spesso utilizzano strumenti SCA per generare una scheda dei materiali software (SBOM). Il SBOM elenca tutti i componenti, le librerie e i moduli di un prodotto software in un formato leggibile da macchina per la conformità e la sicurezza della supply chain. Gli SBOM possono anche informare ulteriormente le politiche di scansione SCA.

Secondo i dati di un sondaggio della International Data Corporation, il 93 percento delle aziende con almeno 100 dipendenti utilizzava software open source nel 2024, il che evidenzia la diffusa necessità di soluzioni SCA.¹

SCA lavora raccogliendo codice sorgente, confrontandolo con database di vulnerabilità, analizzando il codice per eventuali problemi di conformità, eliminando falsi positivi e creando un report per i team di cybersecurity e sviluppo. 

Gli strumenti SCA scansionano e analizzano attivamente il codice durante lo sviluppo come parte della pipeline di integrazione continua e consegna continua (CI/CD) lungo tutto il ciclo di vita dello sviluppo, concentrandosi principalmente su componenti open-source e dipendenze di terze parti.

Per farlo, gli strumenti SCA elencano innanzitutto gli elementi base di tutto il software nell'ambiente IT, inclusi i loro componenti, framework, librerie, immagini container, moduli e dipendenze. Le due forme principali di scansione SCA sono: 

• Scansione statica, o manifest scanning, che legge file di configurazione e metadati per trovare gli elementi esplicitamente descritti lì.

• Scansione dinamica o del runtime, che identifica le librerie mentre vengono eseguite in tempo reale scansionando il codice binario. 

Entrambi i tipi di scansione presentano benefici e svantaggi. Una scansione statica potrebbe includere vulnerabilità di componenti di terze parti nel codice sorgente che non vengono effettivamente implementati nel tempo di esecuzione, creando falsi positivi. Una scansione dinamica, d'altra parte, potrebbe non essere mai completamente completa, poiché tutti gli elementi del codice non vengono eseguiti nel tempo di esecuzione. Molte organizzazioni utilizzano una combinazione di entrambi.

Una volta che uno strumento SCA ha terminato di raccogliere codice, crea una scheda di materiali software (SBOM) e confronta i componenti dello SBOM con database che descrivono vulnerabilità comuni e rischi di sicurezza software moderni.

I team di sicurezza confrontano il SBOM sia con database proprietari di vulnerabilità note sia con quelli pubblici come il National Vulnerability Database (NVD) o la lista Common Vulnerabilities and Exposures (CVE). Una volta segnalate le potenziali vulnerabilità, lo strumento SCA assegnerà a ciascuna un punteggio di minaccia (spesso utilizzando il Common Vulnerability Scoring System, o CVSS) che consente al team di cybersecurity di dare priorità alla correzione.

Alcuni strumenti di sicurezza automatizzano la gestione delle vulnerabilità applicando la patch o l'aggiornamento appropriato come parte della pipeline CI/CD. I team di sicurezza in genere monitorano questo processo per garantire che le modifiche applicate non influiscano sulle dipendenze o sulle funzionalità esistenti.

Gli strumenti SCA verificano inoltre la SBOM rispetto alle politiche aziendali e alle leggi sulle licenze software per garantire la conformità.

L'Open Source Initiative elenca oltre 100 licenze open source approvate, alcune delle quali consentono la creazione di prodotti proprietari a partire da codice open source. Non tutti sono compatibili, il che significa che le organizzazioni sono responsabili di garantire che i loro prodotti siano conformi.

Le soluzioni SCA possono verificare che tutto il software open source abbia l'attribuzione richiesta, o che gli elementi soggetti a "copyleft", che ne vieta l'uso in software proprietario protetto da copyright, non siano inclusi nello sviluppo di quel software. 

L'analisi della composizione del software può anche rilevare le dipendenze tra i componenti del progetto, una fonte importante di potenziali vulnerabilità.

Gli strumenti SCA possono rilevare sia dipendenze dirette, cioè dove i componenti software sono usati direttamente l'uno dall'altro a livello di codice, sia dipendenze transitive. Una dipendenza transitiva si verifica quando un software diventa indirettamente dipendente da un componente software da cui dipende una delle sue dipendenze dirette. Ad esempio: il componente A dipende dal componente B, che a sua volta dipende dal componente C. In questo scenario, per proprietà transitiva il componente A dipende dal componente C.

Gli strumenti SCA devono determinare quali dipendenze introducono vulnerabilità e quali no, per ridurre il numero di falsi avvisi. Lo fanno valutando la supply chain del software e determinando se una vulnerabilità nel codice è "raggiungibile", ovvero se verrà chiamata in un ambiente di runtime data la configurazione attuale della rete. 

I risultati dell'analisi della composizione software vengono poi compilati in un report e spesso presentati in una dashboard, dati non elaborati come un file JSON, un nuovo SBOM o una combinazione di tutti e tre.

Negli ultimi anni gli sviluppatori hanno fatto progressi nella riduzione dei falsi positivi in questi report.

• L'analisi dei metodi vulnerabili traccia i percorsi di chiamata dei componenti software per garantire che le vulnerabilità rilevate siano raggiungibili.

• Il machine learning e l'intelligenza artificiale hanno contribuito all'identificazione dei falsi positivi. Con il giusto training, i modelli possono identificare con precisione se una vulnerabilità è raggiungibile o meno. Elaborazione del linguaggio naturale viene utilizzata anche per analizzare i messaggi di commit del controllo di versione provenienti da repository come GitHub, al fine di rilevare potenziali problemi non identificabili nel codice. 

Alcuni strumenti SCA includono funzionalità di monitoraggio continuo e correzione automatica, che integrano ulteriormente la pratica nel workflow di sviluppo DevSecOps. La correzione automatica viene comunemente effettuata avviando pull request che notificano agli sviluppatori di risolvere problemi di licenza o applicare nuove patch di sicurezza.

I vantaggi della SCA includono una maggiore fiducia nella compliance e nella cybersecurity di un'organizzazione, nonché una maggiore automazione dei workflow IT.

Aiutando a garantire che tutti i componenti open-source dell'ecosistema IT siano utilizzati in conformità con i requisiti di licenza e conformità, la SCA può aiutare le organizzazioni a ridurre i rischi legali.

Identificare vulnerabilità di rete create dall'imprevedibilità dei componenti software open source è una parte cruciale della gestione del rischio IT. Rendendo la supply chain del software open source più trasparente, le organizzazioni possono godere dei benefici della personalizzazione e dei costi più bassi, pur mantenendo la certezza di aver ridotto i rischi di sicurezza connessi.

Automatizzando gran parte del monitoraggio delle vulnerabilità, delle dipendenze e della conformità, le soluzioni SCA consentono ai team IT di svolgere altre attività. Questa ampia automazione aiuta anche a rafforzare le pratiche DevOps di un'organizzazione.

Alcune delle sfide poste dall'analisi della composizione software includono la mancanza di completezza nel tracciare le vulnerabilità, la limitazione dei falsi positivi e la gestione dell'ambito dell'analisi.

L'analisi della composizione del software è diversa da DAST e SAST, due metodi di test aggiuntivi utilizzati per identificare le vulnerabilità di sicurezza nelle applicazioni moderne. 

Mentre la SCA fornisce ai team IT una mappa completa dei componenti software, delle dipendenze e delle vulnerabilità, DAST e SAST si concentrano e rivelano i singoli difetti di tali componenti e delle più ampie applicazioni software che costituiscono.

La differenza tra DAST e SAST è simile alla differenza tra scansione statica e dinamica nella SCA. Il test dinamico di sicurezza delle applicazioni (DAST) valuta le applicazioni nei loro ambienti di produzione, imitando utenti malintenzionati e attacchi informatici per aiutare a identificare i problemi di sicurezza. I test statici di sicurezza delle applicazioni (SAST) approfondiscono il codice sorgente di un'app, cercando le vulnerabilità nel codice così come è scritto.  

Mentre la SCA si concentra sull'enumerazione e l'analisi dei componenti in un dato software, DAST e SAST si concentrano specificamente sul test di vulnerabilità di sicurezza di quel software, sia in tempo reale nel caso del primo sia nel codice sorgente nel caso del secondo. Entrambi sono spesso utilizzati insieme alla SCA, ma possono anche essere praticati indipendentemente. 

SCA differisce dalla mappatura delle dipendenze, il processo di identificazione, comprensione e visualizzazione delle relazioni tra applicazioni, sistemi e processi all'interno delle operazioni IT di un'organizzazione.

Gli strumenti SCA forniscono una panoramica delle dipendenze dei componenti e identificano potenziali vulnerabilità che potrebbero derivare da esse, ma la mappatura delle dipendenze si riferisce a una categoria più ampia di pratiche di observability che identificano le dipendenze in tutto l'ambiente IT.

La mappatura delle dipendenze può concentrarsi sulle dipendenze all'interno e tra le applicazioni, ma può anche estendersi a un ambito più ampio, individuando dipendenze nell'infrastruttura di rete o in interi sistemi reali, come una smart grid elettrica. La mappatura delle dipendenze è spesso parte integrante delle pratiche SCA, ma può essere eseguita anche in modo autonomo, indipendentemente dalle soluzioni SCA.