Come già accennato in un post precedente, lo sviluppo di software moderno è praticamente impensabile senza l’utilizzo di componenti open-source. Ma negli ultimi anni i rischi associati sono diventati sempre più diversi, complessi e numerosi. Quando, in primo luogo, le vulnerabilità influiscono sull’infrastruttura e sul codice di un’azienda più velocemente di quanto vengano sanate; in secondo luogo, i dati sono inaffidabili e incompleti; e in terzo luogo, il malware potrebbe essere in agguato all’interno dei componenti più diffusi: non è sufficiente eseguire la scansione dei numeri di versione e inviare ticket di correzione al team IT. La gestione delle vulnerabilità deve essere estesa per coprire i criteri di download del software, i limiti per gli assistenti IA e l’intera pipeline di build del software.

Un pool attendibile di componenti open source

La parte principale della soluzione è impedire l’utilizzo di codice vulnerabile e dannoso. È necessario implementare le seguenti misure:

• Avere un archivio interno degli artefatti. L’unica fonte dei componenti per lo sviluppo interno deve essere un archivio unificato in cui i componenti sono ammessi solo dopo una serie di controlli.
• Esecuzione di uno screening rigoroso dei componenti. Questi includono i controlli di: versioni note del componente, versioni note vulnerabili e dannose, data di pubblicazione, cronologia attività e reputazione del pacchetto e dei relativi autori. È obbligatorio eseguire la scansione dell’intero contenuto del pacchetto, incluse le istruzioni per la compilazione, i test case e altri dati ausiliari. Per filtrare il registro durante l’importazione, utilizza scanner open source specializzati o una soluzione completa per la protezione dei carichi di lavoro nel cloud.
• Esecuzione del blocco delle dipendenze. I processi di compilazione, gli strumenti di intelligenza artificiale e gli sviluppatori non devono utilizzare modelli (ad esempio “più recenti”) per specificare le versioni. Le build del progetto devono essere basate su versioni verificate. Allo stesso tempo, le dipendenze aggiunte devono essere aggiornate periodicamente alle versioni verificate più recenti che mantengono la compatibilità e sono prive di vulnerabilità note. Questo riduce significativamente il rischio di attacchi alla supply chain dovuti alla compromissione di un pacchetto noto.

Miglioramento dei dati sulle vulnerabilità

Per identificare le vulnerabilità in modo più efficace e assegnare correttamente le priorità, un’organizzazione deve definire diversi processi IT e di sicurezza:

• Arricchimento dei dati sulle vulnerabilità. A seconda delle esigenze dell’organizzazione, questo è necessario per arricchire le informazioni combinando i dati di NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, oppure per acquistare un feed commerciale di intelligence sulla vulnerabilità in cui i dati sono già aggregati e arricchiti. In entrambi i casi, vale la pena monitorare ulteriormente i feed di intelligence sulle minacce per tenere traccia delle tendenze di sfruttamento nel mondo reale e ottenere informazioni dettagliate sul profilo degli autori degli attacchi che prendono di mira vulnerabilità specifiche. Kaspersky fornisce un feed di dati specializzati incentrato specificamente sui componenti open source.
• Analisi approfondita della composizione del software. Gli strumenti specializzati di analisi della composizione del software (SCA) consentono di spostarsi correttamente nella catena delle dipendenze nel codice open source per eseguire un inventario completo delle librerie utilizzate e individuare i componenti obsoleti o non supportati. I dati sui componenti integri sono inoltre utili per arricchire il registro degli artefatti.
• Identificazione dell’abandonware. Anche se un componente non è formalmente vulnerabile e non è stato ufficialmente dichiarato non supportato, il processo di scansione dovrebbe contrassegnare i componenti che non ricevono aggiornamenti da più di un anno. Questi garantiscono un’analisi separata e una potenziale sostituzione, proprio come i componenti EOL.

Protezione del codice e degli agenti di IA

Le attività dei sistemi IA utilizzati nella codifica devono essere racchiuse in un set completo di misure di sicurezza, dal filtraggio dei dati di input alla formazione degli utenti:

• Restrizioni sui suggerimenti per le dipendenze. Configurare l’ambiente di sviluppo per assicurarsi che gli agenti e gli assistenti IA possano fare riferimento solo a componenti e librerie del registro degli artefatti attendibili. Se questi non contengono gli strumenti giusti, il modello deve attivare una richiesta per includere la dipendenza nel registro, anziché estrarre qualcosa da PyPI che corrisponda semplicemente alla descrizione.
• Filtrare gli output del modello. Nonostante queste restrizioni, tutto ciò che viene generato dal modello deve anche essere verificato per garantire che il codice IA non contenga dipendenze obsolete, non supportate, vulnerabili o inventate. Questo controllo deve essere integrato direttamente nel processo di accettazione del codice o nella fase di preparazione della build. Non sostituisce il tradizionale processo di analisi statica: gli strumenti SAST devono ancora essere incorporati nella pipeline CI/CD.
• Formazione per sviluppatori. I team IT e sicurezza devono avere una profonda familiarità con le caratteristiche dei sistemi di IA, i relativi principi operativi e gli errori comuni. A tale scopo, i dipendenti devono completare un corso di formazione specialistica adattato al ruolo specifico.

Rimozione sistematica dei componenti EOL

Se i sistemi di un’azienda utilizzano componenti open source obsoleti, è necessario adottare un approccio sistematico e coerente per affrontarne le vulnerabilità. Esistono tre metodi principali per eseguire questa operazione:

• Migrazione. Questo è il metodo più complesso e costoso dal punto di vista organizzativo, che implica la sostituzione totale di un componente seguita dall’adattamento, la riscrittura o la sostituzione delle applicazioni basate su di esso. Decidere in merito a una migrazione è particolarmente scoraggiante quando è necessaria una revisione radicale di tutto il codice interno. Questo problema riguarda spesso i componenti principali: è impossibile eseguire facilmente la migrazione da Node.js 14 o Python 2.
• Supporto a lungo termine (LTS). Esiste un mercato di servizi di supporto dedicato per i progetti legacy su larga scala. Talvolta ciò implica un fork del sistema legacy gestito da sviluppatori di terze parti; in altri casi, i team specializzati eseguono il backport delle patch che correggono vulnerabilità specifiche in versioni precedenti e non supportate. La transizione a LTS in genere richiede costi di supporto continui, ma in molti casi può essere comunque più conveniente rispetto a una migrazione completa.
• Controlli compensativi. In base ai risultati di un’analisi dettagliata, è possibile creare un set di misure di sicurezza avvolgenti per mitigare il rischio di sfruttamento per le vulnerabilità all’interno del prodotto precedente. Sia l’efficacia che la fattibilità economica di questo approccio dipendono dal ruolo del software all’interno dell’organizzazione.

Sicurezza, IT e azienda devono collaborare per scegliere uno di questi tre percorsi per ogni EOL documentata o componente abbandonato e rispecchiare la scelta effettuata nei registri delle risorse e nelle SBOM dell’azienda.

Gestione delle vulnerabilità open source basata sul rischio

Tutte le misure sopra elencate riducono il volume di componenti e software vulnerabili che entrano nell’organizzazione e semplificano il rilevamento e la correzione dei difetti. Nonostante questo, è impossibile eliminare ogni singolo difetto: il numero di applicazioni e di componenti sta semplicemente crescendo troppo velocemente.

Pertanto, rimane essenziale assegnare la priorità alle vulnerabilità in base ai rischi reali. Il modello di valutazione dei rischi deve essere espanso per tenere conto delle caratteristiche dell’open source, rispondendo alle seguenti domande:

• Il ramo di codice vulnerabile viene effettivamente eseguito nell’ambiente dell’organizzazione? È necessario eseguire un’analisi della raggiungibilità per le vulnerabilità rilevate. Molti frammenti di codice difettosi non vengono mai effettivamente eseguiti nell’ambito dell’implementazione specifica dell’organizzazione, rendendo impossibile lo sfruttamento della vulnerabilità. Alcune soluzioni SCA possono eseguire questa analisi. Questo stesso processo consente di valutare uno scenario alternativo: cosa succede se le procedure o i componenti vulnerabili vengono rimossi completamente dal progetto? A volte, questo metodo di riparazione si rivela sorprendentemente indolore.
• Il difetto viene sfruttato negli attacchi nel mondo reale? È disponibile un PoC? Le risposte a queste domande fanno parte di framework standard di assegnazione delle priorità come EPSS, ma il tracciamento deve essere condotto attraverso un set molto più ampio di fonti di intelligence.
• Sono state segnalate attività dei criminali informatici in questo registro delle dipendenze o in componenti correlati e simili? Si tratta di fattori aggiuntivi per l’assegnazione delle priorità.

La considerazione di questi fattori consente al team di allocare le risorse in modo efficace e correggere prima i difetti più pericolosi.

Trasparenza is the new black

La barra di sicurezza per il software open source è destinata a continuare a crescere. Le aziende che sviluppano applicazioni, anche per uso interno, dovranno far fronte a pressioni normative che richiedono una sicurezza informatica documentata e verificabile all’interno dei propri sistemi. Secondo le stime degli esperti Sonatype, il 90% delle aziende a livello globale rientra già in uno o più requisiti per fornire evidenza dell’affidabilità del software utilizzato; pertanto, gli esperti considerano la trasparenza “la valuta della sicurezza della filiera del software”.

Controllando l’utilizzo di componenti e applicazioni open source, arricchendo l’intelligence sulle minacce e monitorando rigorosamente i sistemi di sviluppo basati sull’intelligenza artificiale, le organizzazioni possono introdurre le innovazioni tanto agognate dall’azienda, il tutto superando il limite stabilito dalle autorità di regolamentazione e dai clienti.