Questo blog riporta i punti salienti del nostro webinar "ISupply Chain Software : i punti deboli sfruttati dagli hacker". Guarda il webinar completo qui.
I rischi legati alla catena Software sono aumentati notevolmente poiché le organizzazioni fanno sempre più affidamento su componenti open source, pacchetti esterni e pipeline di sviluppo automatizzate. Piccole lacune che un tempo sembravano innocue ora comportano conseguenze reali, soprattutto perché le dipendenze diventano sempre più profonde e difficili da verificare.
Un chiaro esempio di questo cambiamento è stato il recente worm npm Shai-Hulud e Shai-Hulud 2.0, che si è diffuso attraverso pacchetti compromessi e ha colpito migliaia di progetti a valle nel giro di poche ore. Incidenti come questo rendono chiara una cosa: le debolezze della catena di approvvigionamento non rimangono più circoscritte, ma si propagano a cascata attraverso interi ecosistemi.
Con il 70-90% dei software moderni composto da componenti open source, la maggior parte dei quali gli sviluppatori non vedono mai direttamente, piccoli problemi possono rapidamente diventare grandi rischi. Tuttavia, solo il 15% delle organizzazioni si sente sicuro di come gestisce tale rischio open source. Con il 70% degli attacchi AI dannosi che si prevede colpiranno le catene di approvvigionamento entro il 2025, identificare i punti deboli nella catena di approvvigionamento del software è ora essenziale.
Per i team di ingegneri e sicurezza, il vantaggio è semplice: sapere dove si trovano questi punti deboli significa meno sorprese, tempi di risposta più rapidi e una probabilità molto minore di finire nei titoli dei giornali dedicati alla catena di approvvigionamento.
Gli SBOM non sono più facoltativi
Per gestire i rischi legati alla catena di fornitura del software e rispondere alle vulnerabilità, le organizzazioni devono avere una visione chiara di ciò che è contenuto nel loro stack software. Alla base di questa visibilità c'è l'SBOM (Software Bill of Materials), che crea la trasparenza necessaria per comprendere i rischi legati ai componenti e agire rapidamente quando sorgono problemi.
Un SBOM è definito come un inventario dettagliato di tutti i componenti chiusi e open source, le licenze e le dipendenze utilizzati in un'applicazione. Questo inventario fornisce dati essenziali per la trasparenza, la conformità e la gestione dei rischi.
Ciò che oggi non è vulnerabile o dannoso può facilmente diventarlo domani. Poiché le vulnerabilità vengono scoperte continuamente, anche nelle versioni precedenti, è necessario un monitoraggio e un inventario costanti.
George PrichiciVicepresidente, Prodotti, OPSWAT
SBOM contro SCA
Una cosa importante è la distinzione tra SBOM e SCA (Software Analysis). L'SBOM è l'inventario, ovvero un elenco di componenti. L'SCA valuta se uno qualsiasi di questi componenti è vulnerabile, obsoleto o rischioso. Insieme, forniscono alle organizzazioni le informazioni necessarie per prendere decisioni informate, rispondere più rapidamente alle questioni di sicurezza e rafforzare la gestione complessiva dei rischi.
| Categoria | SBOM | SCA |
|---|---|---|
Scopo | Inventario dei componenti |
Identificare le vulnerabilità nei componenti
|
Copertura dei rischi | Conformità e visibilità | Rischi per la sicurezza, CVE, rischi di runtime |
Tempistica | Pre-implementazione / approvvigionamento | Continuo / compilazione e runtime |
I movimenti globali, in parte guidati da attacchi come SolarWinds, ora richiedono SBOM, con spinte normative provenienti da entità come CISA, NSA e NIST, nonché dall'UE e dai paesi alleati della NATO, rendendo la trasparenza SBOM non più facoltativa, ma un requisito fondamentale per qualsiasi fornitore di software.
I 7 punti deboli critici sfruttati dagli hacker
La rapidità dello sviluppo moderno, unita alla forte dipendenza da codice di terze parti e open source, ha introdotto gravi vulnerabilità. Gli autori delle minacce stanno sfruttando sette principali punti deboli:
1. Open source e rischio di dipendenza
Quando gli sviluppatori danno priorità alla velocità, spesso utilizzano grandi librerie open source senza una revisione completa del codice. Un singolo componente può introdurre ulteriori dipendenze transitive. Se si monitora solo il livello superiore, è possibile che non si riesca a individuare il codice dannoso iniettato in quelle dipendenze transitive nascoste.
Questo modello è qualcosa che continuiamo a vedere negli ecosistemi open source. Un pacchetto compromesso può propagarsi attraverso le catene di dipendenza e raggiungere milioni di download prima che qualcuno se ne accorga. Un recente attacco alla catena di fornitura npm che ha coinvolto un crypto-malware evidenzia esattamente come ciò avvenga nella pratica.
Le migliori pratiche:
- Esegui la scansione di tutti i pacchetti open source e delle loro catene di dipendenze complete per identificare vulnerabilità, componenti obsoleti o malware nascosti prima che raggiungano il tuo codice base.
- Monitorare continuamente le dipendenze nel tempo, poiché componenti sicuri possono diventare rischiosi con la comparsa di nuovi CVE o aggiornamenti dannosi.
- Utilizza registri affidabili e verifica l'integrità dei pacchetti per assicurarti che quelli scaricati non siano stati manomessi.
- Applica politiche che segnalano o bloccano le licenze rischiose, in modo che termini di licenza incompatibili o virali non si insinuino nelle tue build.
- Ritardare l'utilizzo dei pacchetti appena pubblicati fino a quando non sono stati controllati, riducendo la possibilità di introdurre versioni non revisionate o dannose nel proprio ambiente.
2. Rischio legato alle licenze
Le questioni relative alle licenze ora riguardano tanto l'ingegneria quanto l'ambito legale. Le licenze virali, come la GPL, possono obbligare a pubblicare l'applicazione risultante con la stessa licenza, causando potenzialmente alla vostra azienda la perdita della propria proprietà intellettuale (IP). È necessario un monitoraggio continuo perché i termini della licenza possono cambiare, anche per le versioni precedenti, precedentemente conformi.
Le migliori pratiche:
- Utilizza uno strumento automatico di rilevamento delle licenze per segnalare le licenze ad alto rischio o incompatibili nelle prime fasi dello sviluppo. Una spiegazione più approfondita dell'importanza di questo aspetto è disponibile qui: Il ruolo cruciale del rilevamento delle licenze nella sicurezza open source.
- Monitorare costantemente le modifiche alle licenze per individuare eventuali cambiamenti che potrebbero influire sulla conformità o sull'esposizione della proprietà intellettuale.
- Blocca o rivedi i componenti con licenze restrittive o virali prima che entrino nel codice base.
- Mantenere un inventario chiaro di tutte le licenze in uso per semplificare gli audit e le valutazioni dei rischi.
3. Lacune nei dati SBOM o SBOM mancanti
Sebbene le normative impongano la condivisione degli SBOM, un elenco di alto livello non è sufficiente. Per una mitigazione e una prevenzione efficaci sono necessari dati dettagliati, tra cui l'autore, i collaboratori, la frequenza di rilascio e lo stato di manutenzione.
Le migliori pratiche:
- Migliora i report SBOM eseguendo una nuova scansione dei componenti per arricchirli con dati aggiornati sulle licenze, lo stato delle vulnerabilità e altri metadati critici. Un esempio dettagliato di come farlo è descritto qui sotto nella sezione Convalida e arricchimento dei report SBOM di CycloneDX.
- Convalidare e arricchire gli SBOM utilizzando strumenti automatizzati per garantire che le informazioni siano complete, accurate e utilizzabili.
- Richiedere ai fornitori di fornire una SBOM completa, comprese le dipendenze transitive e tutti i metadati pertinenti.
- Aggiornare e monitorare costantemente gli inventari SBOM man mano che i componenti evolvono o emergono nuove vulnerabilità.
4. Fornitori terzi
Ogni fornitore di cui ti affidi diventa parte della tua catena di approvvigionamento. Se spediscono componenti obsoleti o compromessi, sei tu a ereditare tale rischio. Gli SBOM completi, comprese le dipendenze transitive, consentono di comprendere rapidamente la tua esposizione invece di dover rincorrere i fornitori durante un incidente. Un recente post su Gestione delle vulnerabilità delle dipendenze nellaSupply Chain Software esplora come i team possono rafforzare questa parte del processo.
5. Supply Chain AI
A causa della rapida diffusione dell'intelligenza artificiale, i team spesso aggirano le normali restrizioni, rendendo questo aspetto un importante vettore di attacco. Gli aggressori inseriscono codice dannoso nei modelli di machine learning, nei file PICO o nelle librerie open source. Il typosquatting è comune in ambienti come Pytorch, dove gli utenti potrebbero scaricare la libreria sbagliata, che può distribuire malware e portare all'esecuzione completa di codice remoto sul computer di un ingegnere.
6.Container
La scansione dei container deve evolversi oltre il semplice focus sulle vulnerabilità. La sicurezza moderna deve anche cercare malware, crypto miner e minacce ad azione rapida pubblicate in immagini di container disponibili pubblicamente. Una recente analisi del NVIDIA Container CVE-2024-0132 mostra quanto sia facile trascurare questi problemi.
7. Divulgazione di segreti e credenziali
Quando i team lavorano rapidamente, spesso inseriscono chiavi di accesso o credenziali nel codice sorgente per eseguire i test. Anche se successivamente sovrascritti, questi segreti rimangono spesso nella cronologia Git, dove sono facilmente individuabili dagli hacker tramite scansione. Smascherare le minacce nascoste: come rilevare i segreti nel codice mostra come avvengono queste esposizioni e cosa possono fare i team per prevenirle.
Il percorso verso unaSupply ChainSoftware Secure
Per contrastare queste minacce, la sicurezza deve adottare una mentalità "shift left", ovvero le stesse politiche applicate prima del rilascio dovrebbero essere applicate in una fase precedente del ciclo di sviluppo. L'obiettivo è integrare la sicurezza come un livello aggiuntivo alla pipeline CI/CD esistente. Questo approccio automatizzato garantisce l'applicazione delle politiche quando necessario, senza influire sulla produttività ingegneristica.
Una soluzione completa deve fornire:
- Scansione automatizzata della catena di approvvigionamento lungo tutta la pipeline
- Visibilità sul codice sorgente, sui container e sui file forniti dai fornitori
- Analisi che va oltre i CVE per rilevare malware, problemi di licenza e segreti esposti
Come OPSWAT colmare queste lacune
- Multiscanning rilevare il malware nelle prime fasi del processo
- Gate di sicurezza CI/CD integrati per GitHub, GitLab, TeamCity, Jenkins e altro ancora
- Generazione automatizzata di SBOM e mappatura delle vulnerabilità
- Firma degli artefatti e convalida dell'integrità
- Scansione dei segreti e applicazione delle norme di igiene delle credenziali
Parla con uno dei nostri esperti per trovare soluzioni su misura per il tuo stack oggi stesso.
