Sicurezza delle dipendenze e analisi della composizione del software

Le applicazioni moderne sono composte in gran parte da librerie e framework open source di terze parti. Una tipica applicazione Node.js può avere più di 1.000 dipendenze transitive; un progetto Java può includere centinaia di artifact Maven. Ogni dipendenza rappresenta una potenziale superficie di attacco. La vulnerabilità Log4Shell (CVE-2021-44228) nella libreria Log4j ha dimostrato che una singola dipendenza può rendere immediatamente sfruttabili milioni di applicazioni in tutto il mondo, nel giro di pochi giorni dalla divulgazione.

Gli strumenti di Software Composition Analysis (SCA) inventariano automaticamente tutti i componenti open source di un'applicazione, incluse le dipendenze transitive (le dipendenze delle vostre dipendenze), e li verificano continuamente rispetto ai database delle vulnerabilità alla ricerca di CVE note. La SCA produce un Software Bill of Materials (SBOM) che elenca ogni componente e ogni versione, consentendo di identificare rapidamente i sistemi interessati quando vengono divulgate nuove vulnerabilità.

Le dipendenze transitive sono librerie da cui dipendono le vostre dipendenze dirette e che non avete scelto esplicitamente. Potreste dipendere direttamente dal Package A, che dipende dal Package B (versione 1.2), che a sua volta dipende dal Package C (versione 3.0, una versione vulnerabile). Non siete consapevoli della presenza del Package C, ma la vostra applicazione lo esegue. Gli strumenti SCA analizzano l'intero albero delle dipendenze per portare alla luce queste vulnerabilità nascoste, che gli sviluppatori non possono individuare direttamente.

Un Software Bill of Materials (SBOM) è un inventario formale e leggibile dalle macchine di tutti i componenti di un prodotto software, simile all'elenco degli ingredienti di un alimento. I formati SBOM includono SPDX (Linux Foundation) e CycloneDX (OWASP). L'Executive Order 14028 degli Stati Uniti (2021) ha reso obbligatori gli SBOM per il software venduto al governo federale. Con un SBOM, i team di sicurezza possono chiedere immediatamente: «quali dei nostri prodotti contengono Log4j?» e ottenere una risposta in pochi minuti, anziché dopo giorni di ricerca manuale.

Il blocco delle dipendenze specifica le versioni esatte delle dipendenze invece di intervalli flessibili (^1.2.3 o *). I file lock (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) registrano la versione esatta risolta di ogni dipendenza al momento dell'installazione. Devono essere sottoposti a commit nel controllo del codice sorgente per garantire che ogni membro del team e ogni pipeline CI/CD utilizzi versioni identiche delle dipendenze, prevenendo gli attacchi alla supply chain che contaminano le versioni dei pacchetti tra un'installazione e l'altra.

Gli attacchi alla supply chain prendono di mira l'ecosistema delle dipendenze. Il typosquatting consiste nel pubblicare pacchetti dannosi con nomi simili a quelli di pacchetti popolari (ad esempio, lodahs invece di lodash), contando sul fatto che gli sviluppatori digitino erroneamente il nome. Gli attacchi di dependency confusion sfruttano l'ordine con cui i package manager cercano nei registry: un attaccante pubblica un pacchetto dannoso con lo stesso nome di un pacchetto privato interno, ma con un numero di versione più alto, inducendo il package manager a installare la versione pubblica dannosa.

Nel settore sono ampiamente utilizzati diversi strumenti SCA. Snyk offre la scansione delle dipendenze, intuitiva per gli sviluppatori, con pull request automatiche per le correzioni. OWASP Dependency-Check è uno strumento gratuito e ampiamente adottato per Java, .NET, Python e Ruby. GitHub Dependabot apre automaticamente pull request per aggiornare le dipendenze vulnerabili nei repository GitHub. JFrog Xray e Sonatype Nexus IQ integrano la SCA nei repository degli artifact, impedendo alle build vulnerabili di arrivare in produzione.

La SCA è più efficace quando viene integrata nella pipeline CI/CD come quality gate. A ogni pull request e a ogni build, la pipeline esegue lo strumento SCA e interrompe la build se nelle dipendenze vengono rilevate CVE di gravità critica o alta. Questo approccio di «shift left» individua le dipendenze vulnerabili prima che arrivino in produzione, non mesi dopo durante una revisione manuale della sicurezza o in seguito a una violazione. I team dovrebbero definire soglie chiare di gravità delle vulnerabilità, distinguendo quelle che bloccano la distribuzione da quelle che generano solo avvisi.

Prima di aggiungere una dipendenza, valutate il suo livello di sicurezza utilizzando diversi indicatori. Attività di manutenzione: il progetto viene mantenuto attivamente? Quando sono stati effettuati l'ultimo commit e l'ultima release? Storico delle vulnerabilità note: quante CVE ha avuto e con quale rapidità sono state corrette? Volume dei download: i pacchetti ampiamente utilizzati sono sottoposti a un controllo di sicurezza maggiore. Numero di dipendenze: i pacchetti con meno dipendenze introducono un rischio transitive minore. OpenSSF Scorecard fornisce una valutazione automatica delle pratiche di sicurezza dei progetti open source.

Quando la SCA identifica una dipendenza vulnerabile, sono possibili diverse strategie di remediation. Aggiornare a una versione corretta: è l'opzione preferibile quando disponibile. Il virtual patching tramite regole WAF può mitigare i percorsi di exploit noti mentre si prepara l'aggiornamento. Rimuovere la dipendenza se non è più necessaria. Accettare il rischio con una giustificazione documentata se la vulnerabilità non è sfruttabile nello specifico contesto di utilizzo (ad esempio, una vulnerabilità lato server in una libreria lato client). Non lasciate mai vulnerabilità critiche senza intervento né accettazione documentata.

Gli strumenti SCA hanno una doppia funzione: identificano le vulnerabilità di sicurezza e segnalano i problemi di conformità delle licenze nelle dipendenze open source. Tra le licenze problematiche più comuni vi sono GPL v2/v3 (copyleft: richiede che anche il vostro prodotto venga distribuito come open source se lo distribuite), AGPL (estende la GPL ai servizi di rete) e SSPL. L'utilizzo di una libreria con licenza GPL in un software commerciale proprietario senza una licenza commerciale può creare una grave responsabilità legale. Strumenti SCA come FOSSA, Black Duck e WhiteSource automatizzano la scansione delle licenze insieme al rilevamento delle vulnerabilità, garantendo la conformità agli obblighi relativi all'open source.

Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione avete imparato che: gli strumenti SCA analizzano l'intero albero delle dipendenze, incluse quelle transitive, alla ricerca di CVE note; gli SBOM forniscono un inventario leggibile dalle macchine, consentendo di reagire rapidamente alla divulgazione di nuove vulnerabilità; infine, integrare la SCA nella pipeline CI/CD come quality gate permette di individuare le dipendenze vulnerabili prima che arrivino in produzione. Nella prossima lezione esploreremo il DevSecOps e come spostare i controlli di sicurezza a sinistra nell'intera pipeline CI/CD.