Quando sviluppiamo un sito web o un'applicazione, raramente scriviamo ogni singola riga di codice da zero.
Utilizziamo librerie, framework, plugin, pacchetti e componenti realizzati da altri sviluppatori.
È una scelta normale e spesso indispensabile.
Un progetto PHP può utilizzare Composer per gestire le dipendenze. Un'applicazione JavaScript può affidarsi a npm. Un sito WordPress può includere decine di plugin, ognuno con il proprio codice e le proprie librerie.
Questi strumenti permettono di sviluppare più velocemente, ma introducono anche un aspetto da non sottovalutare: la sicurezza di un'applicazione dipende in parte dalla sicurezza dei componenti che utilizza.
È qui che entra in gioco il tema della software supply chain, la catena di fornitura del software.
Che cos'è la software supply chain?
La software supply chain comprende tutti gli elementi e i processi coinvolti nella realizzazione e distribuzione di un software.
Non riguarda soltanto il codice scritto direttamente dagli sviluppatori.
Può includere:
- Librerie open source.
- Framework.
- Plugin ed estensioni.
- Sistemi di compilazione.
- Repository di pacchetti.
- Strumenti CI/CD.
- Componenti di terze parti.
- Servizi utilizzati durante lo sviluppo e il rilascio.
Un problema di sicurezza in uno di questi elementi può avere conseguenze sui progetti che ne dipendono.
Non significa che utilizzare software open source sia pericoloso.
Significa piuttosto che bisogna conoscere i componenti utilizzati e gestirli con attenzione.
Come può diventare vulnerabile una dipendenza?
Esistono diversi scenari.
Una vulnerabilità scoperta in una libreria
Una libreria potrebbe contenere un errore che consente comportamenti imprevisti.
Il problema viene identificato, documentato e corretto attraverso un aggiornamento.
Se un'applicazione continua a utilizzare la versione vulnerabile, potrebbe rimanere esposta.
Un pacchetto compromesso
In altri casi, un attaccante può riuscire a compromettere un account di manutenzione, un sistema di pubblicazione o un componente della catena di distribuzione.
Il risultato potrebbe essere una versione malevola di un pacchetto apparentemente legittimo.
Un pacchetto creato per ingannare gli sviluppatori
Esistono tecniche come il typosquatting, nelle quali vengono pubblicati pacchetti con nomi molto simili a quelli di librerie conosciute.
Uno sviluppatore che commette un errore di digitazione potrebbe installare il componente sbagliato.
Un'altra tecnica è la dependency confusion, che sfrutta determinate configurazioni dei sistemi di risoluzione delle dipendenze per tentare di far installare pacchetti non attendibili.
Dipendenze dirette e transitive
Quando installiamo una libreria, spesso non installiamo soltanto quella.
Il componente scelto può dipendere da altri pacchetti, che a loro volta possono richiederne ulteriori.
Le dipendenze che aggiungiamo direttamente al progetto vengono chiamate dipendenze dirette.
Quelle installate perché richieste da altri componenti sono dette dipendenze transitive.
Immaginiamo un'applicazione che utilizza una libreria per generare documenti PDF.
La libreria potrebbe richiedere altri pacchetti per gestire immagini, font o operazioni di elaborazione.
Una vulnerabilità potrebbe trovarsi in uno di questi componenti secondari.
Ecco perché controllare soltanto le librerie dichiarate direttamente non è sempre sufficiente.
Perché le dipendenze obsolete sono un problema?
Una libreria non aggiornata non è automaticamente vulnerabile.
Tuttavia, con il passare del tempo possono emergere problemi di sicurezza che vengono corretti soltanto nelle versioni successive.
Continuare a utilizzare una release obsoleta può significare rinunciare a quelle correzioni.
Il problema diventa particolarmente delicato quando il componente non è più mantenuto.
In quel caso, potrebbe non essere disponibile alcuna patch ufficiale.
La soluzione può richiedere la sostituzione della libreria oppure l'adozione di misure compensative.
Come controllare le dipendenze PHP con Composer
Composer è uno degli strumenti più utilizzati per gestire pacchetti PHP.
Un progetto può dichiarare le proprie dipendenze nel file composer.json.
Il file composer.lock registra le versioni effettivamente risolte.
Per cercare vulnerabilità note nei pacchetti installati o bloccati nel progetto, Composer mette a disposizione il comando:
composer audit
Il controllo confronta le dipendenze con gli avvisi di sicurezza disponibili.
È un'operazione utile da eseguire periodicamente e prima dei rilasci.
Per esaminare le dipendenze presenti nel progetto puoi utilizzare:
composer show
Per individuare pacchetti per i quali esistono versioni più recenti:
composer outdated
Attenzione, però: una versione più recente non è necessariamente una correzione di sicurezza, così come un aggiornamento può introdurre modifiche incompatibili con il progetto.
È importante leggere le note di rilascio e verificare gli effetti delle modifiche.
Come controllare i pacchetti JavaScript con npm
Anche npm dispone di funzionalità per verificare le dipendenze.
Il comando:
npm audit
analizza le dipendenze rispetto agli avvisi di sicurezza disponibili.
Per ottenere un riepilogo in formato JSON:
npm audit --json
Un altro comando utile è:
npm outdated
che permette di individuare pacchetti non aggiornati.
È importante evitare aggiornamenti automatici indiscriminati in produzione.
Comandi che modificano le versioni delle dipendenze possono introdurre incompatibilità e richiedono test adeguati.
WordPress e sicurezza delle dipendenze 🔌
Nel mondo WordPress, la gestione delle dipendenze assume una forma particolare.
Temi e plugin sono componenti software che possono includere librerie proprie.
Un sito può essere aggiornato all'ultima versione di WordPress, ma utilizzare ancora un plugin vulnerabile.
Allo stesso modo, un plugin può incorporare una libreria obsoleta senza che questa sia immediatamente visibile nel pannello amministrativo.
Per ridurre i rischi è utile:
- Installare soltanto plugin realmente necessari.
- Preferire componenti mantenuti attivamente.
- Rimuovere temi e plugin inutilizzati.
- Verificare periodicamente gli aggiornamenti di sicurezza.
- Testare gli aggiornamenti più delicati in staging.
- Mantenere backup ripristinabili.
Un plugin disattivato ma ancora presente sul server può comunque rappresentare un rischio in determinate condizioni.
Quando un componente non serve più, generalmente è preferibile rimuoverlo anziché limitarsi a disattivarlo.
Che cos'è una SBOM?
La sigla SBOM significa Software Bill of Materials.
Possiamo immaginarla come una distinta dei componenti utilizzati per realizzare un'applicazione.
Una SBOM può contenere informazioni come:
- Nome dei componenti.
- Versioni.
- Relazioni tra dipendenze.
- Identificatori dei pacchetti.
- Altri metadati utili all'inventario.
L'obiettivo è sapere con maggiore precisione quali componenti fanno parte del software.
Se viene pubblicata una nuova vulnerabilità che interessa una determinata libreria, una SBOM aggiornata può aiutare a individuare più rapidamente i progetti potenzialmente coinvolti.
Tra i formati più conosciuti troviamo SPDX e CycloneDX.
Per approfondire puoi consultare il sito ufficiale di CycloneDX.
Vulnerabilità note e CVE
Quando viene scoperta una vulnerabilità, può essere assegnato un identificatore CVE.
Questo permette di fare riferimento al problema in modo univoco.
Tuttavia, non tutte le vulnerabilità ricevono immediatamente un CVE e non tutti gli avvisi riguardano necessariamente componenti utilizzati in modo vulnerabile dalla tua applicazione.
Per esempio, una libreria potrebbe essere affetta da un problema soltanto quando viene utilizzata una funzione specifica o una particolare configurazione.
È quindi importante distinguere tra:
Componente vulnerabile presente nel progetto: il pacchetto utilizzato corrisponde a una versione interessata da un avviso.
Vulnerabilità effettivamente sfruttabile: le condizioni necessarie all'attacco sono presenti nell'applicazione e il comportamento vulnerabile è raggiungibile.
La prima informazione è un segnale importante, ma non sempre dimostra automaticamente la seconda.
Come dare priorità agli aggiornamenti
Quando uno strumento di analisi segnala numerose vulnerabilità, può essere difficile decidere da dove iniziare.
Un approccio utile consiste nel considerare diversi elementi.
Gravità tecnica
Qual è il possibile impatto della vulnerabilità?
Può provocare un'interruzione del servizio, la divulgazione di dati o l'esecuzione di codice non autorizzato?
Esposizione del componente
La libreria è utilizzata in una funzionalità raggiungibile da Internet oppure soltanto in uno strumento interno?
Disponibilità di exploit
Esistono prove pubbliche di sfruttamento o indicazioni di attacchi già osservati?
Presenza di una correzione
È disponibile una versione sicura?
L'aggiornamento richiede modifiche importanti oppure può essere applicato rapidamente?
Importanza del sistema
Una vulnerabilità presente in un'applicazione pubblica che gestisce dati sensibili può richiedere maggiore urgenza rispetto allo stesso problema in un ambiente isolato.
Questi elementi aiutano a stabilire priorità più realistiche rispetto al semplice ordinamento per punteggio CVSS.
Come ridurre il rischio nella software supply chain
La gestione delle dipendenze dovrebbe diventare parte del normale processo di sviluppo.
Un buon punto di partenza consiste nel mantenere un inventario dei componenti utilizzati.
È poi utile adottare file di lock quando previsti dal gestore di pacchetti, così da rendere più prevedibili le installazioni.
Le dipendenze dovrebbero provenire da registri e repository attendibili.
Gli strumenti di scansione possono essere integrati nei controlli periodici e nelle pipeline CI/CD.
È inoltre opportuno limitare i privilegi dei sistemi di build e proteggere le credenziali utilizzate per pubblicare pacchetti o distribuire applicazioni.
Un ulteriore accorgimento consiste nel valutare attentamente nuove librerie prima di introdurle nel progetto.
Aggiungere una dipendenza per risolvere un problema molto semplice può aumentare inutilmente la complessità della manutenzione.
SCA: che cos'è la Software Composition Analysis?
La Software Composition Analysis, abbreviata SCA, è un insieme di tecniche e strumenti utilizzati per analizzare i componenti software di terze parti presenti in un progetto.
Questi strumenti possono aiutare a identificare:
- Dipendenze conosciute.
- Versioni dei pacchetti.
- Vulnerabilità pubblicamente documentate.
- Informazioni sulle licenze.
- Componenti che richiedono attenzione.
La SCA non sostituisce la revisione del codice e non garantisce che un'applicazione sia priva di vulnerabilità.
È però particolarmente utile per mantenere sotto controllo i rischi legati ai componenti esterni.
Gli aggiornamenti automatici sono sempre una buona idea?
Automatizzare parte della manutenzione può essere molto utile.
Strumenti come Dependabot e Renovate possono aiutare a individuare aggiornamenti disponibili e proporre modifiche alle dipendenze.
Tuttavia, l'automazione dovrebbe essere accompagnata da test.
Un aggiornamento potrebbe correggere una vulnerabilità ma introdurre un cambiamento incompatibile con il codice esistente.
Per questo motivo, è consigliabile utilizzare un processo che includa test automatici, revisione delle modifiche e possibilità di ripristino.
Soprattutto per applicazioni critiche, aggiornare non dovrebbe significare modificare direttamente la produzione senza verifiche.
Conclusione
La sicurezza del software non dipende soltanto dal codice che scriviamo personalmente.
Ogni libreria, plugin e componente esterno introduce una relazione di fiducia che deve essere gestita.
Questo non significa rinunciare alle dipendenze: significa utilizzarle in modo consapevole.
Inventario, aggiornamenti, analisi delle vulnerabilità e controllo della provenienza dei pacchetti sono elementi fondamentali per ridurre il rischio.
La regola più utile è sapere quali componenti utilizza la propria applicazione e disporre di un processo per intervenire quando emerge un problema.
Per approfondire puoi consultare le indicazioni di OWASP sulla sicurezza delle dipendenze e il progetto OpenSSF, dedicato al miglioramento della sicurezza del software open source.
Con MiHakero puoi affiancare ai controlli sulle dipendenze un'analisi della superficie esposta dei tuoi servizi pubblici e delle vulnerabilità note rilevabili dall'esterno. La verifica completa dei componenti interni richiede invece strumenti SCA e accesso all'inventario del software.
SEO Meta Title: Dipendenze software vulnerabili: rischi e soluzioni
SEO Meta Description: Scopri come individuare dipendenze vulnerabili in PHP, npm e WordPress, prevenire i rischi supply chain e gestire gli aggiornamenti.