A03:2025 Software Supply Chain Failures: la nuova voce che scala la classifica

Nel sondaggio della community che ha contribuito alla OWASP Top 10:2025, esattamente il 50% dei rispondenti ha votato questa categoria come rischio numero uno. È il segnale di un cambiamento profondo: il codice che scrivi tu è ormai solo una piccola parte di ciò che finisce in produzione, il resto arriva da librerie, strumenti di build e pipeline di cui ti fidi senza rivederli ogni volta.

1. Da «componenti vulnerabili» a «tutta la catena»

Questa voce non nasce dal nulla: è un'espansione di A06:2021 «Vulnerable and Outdated Components», ma con un ambito molto più ampio. OWASP la definisce ora come compromissioni nel processo di costruzione, distribuzione o aggiornamento del software, non solo librerie con una CVE nota, ma anche il modo in cui vengono compilate, firmate e consegnate.

Fonte: OWASP Top 10:2025: A03: espansione di A06:2021-Vulnerable and Outdated Components; votata al primo posto dal 50% dei rispondenti al sondaggio community.

2. Tre modi in cui la catena si rompe: con nomi reali

OWASP cita scenari concreti, non ipotetici:

• Un fornitore fidato viene compromesso, e il malware arriva insieme al normale aggiornamento, il caso

SolarWinds (2019): un aggiornamento compromesso ha colpito circa 18.000 organizzazioni.

• Il comportamento malevolo si attiva solo in condizioni specifiche: il furto Bybit del 2025, 1,5 miliardi di dollari, causato da un software di wallet compromesso che agiva solo quando il wallet bersaglio veniva effettivamente usato.
• Un worm si autopropaga attraverso i pacchetti stessi: «Shai-Hulud» (2025), il primo worm npm auto-propagante: pacchetti popolari compromessi con script post-installazione che rubavano token npm e li usavano per infettare automaticamente altri pacchetti accessibili, raggiungendo oltre 500 versioni compromesse.

Un dettaglio che OWASP sottolinea: i componenti girano di norma con gli stessi privilegi dell'applicazione stessa. Un difetto in una libreria di terze parti, per errore o per backdoor intenzionale, ha lo stesso impatto di un difetto nel tuo codice.

Fonte: OWASP Top 10:2025: A03: scenari #1-3 (SolarWinds, furto Bybit 2025, worm npm Shai-Hulud); i componenti girano con gli stessi privilegi dell'applicazione.

3. SBOM: sapere davvero cosa gira nel tuo software

Il primo strumento che OWASP raccomanda è la Software Bill of Materials (SBOM): un elenco centralizzato e gestito di tutti i componenti che usi, comprese le dipendenze transitive (quelle che non hai scelto tu direttamente, ma arrivano incluse in ciò che hai scelto).

// una dipendenza diretta porta con se' un'intera rete di dipendenze transitive: il-tuo-progetto -> libreria-A (scelta da te) -> libreria-B (dipendenza di A, mai vista direttamente) -> libreria-C (dipendenza di B...)

Senza una SBOM aggiornata, semplicemente non sai cosa gira davvero nel tuo sistema, e non puoi reagire in fretta quando una di quelle librerie, magari tre livelli sotto quella che hai scelto tu, viene dichiarata vulnerabile.

Fonte: OWASP Top 10:2025: A03, «How to prevent»: generare e gestire centralmente la SBOM, tracciando anche le dipendenze transitive; strumenti citati: OWASP Dependency-Track, OWASP CycloneDX.

4. Firma dei pacchetti: verificare, non solo scaricare

La raccomandazione ufficiale è netta: ottenere componenti solo da fonti ufficiali su collegamenti sicuri, e preferire pacchetti firmati: la firma riduce la probabilità di includere un componente modificato o malevolo senza saperlo. Scegli esplicitamente quale versione usare, e aggiorna solo quando c'è un motivo reale, non in automatico e alla cieca.

Nella vita reale: è la differenza tra comprare farmaci da una farmacia autorizzata con il sigillo di garanzia intatto, e comprarli da un banchetto per strada perché costano meno. Il sigillo (la firma) non garantisce che il farmaco sia efficace, ma ti dice che nessuno lo ha manomesso lungo il tragitto.

Fonte: OWASP Top 10:2025: A03, «How to prevent»: ottenere componenti solo da fonti fidate su link sicuri, preferendo pacchetti firmati.

5. CI/CD: la pipeline dev'essere sicura almeno quanto ciò che costruisce

Un punto che OWASP elenca esplicitamente tra le condizioni di vulnerabilità: la pipeline CI/CD ha una sicurezza più debole dei sistemi che costruisce e distribuisce. Le raccomandazioni concrete includono: separazione dei compiti (nessuna persona da sola dovrebbe poter scrivere codice e promuoverlo fino in produzione senza supervisione), build firmate, segreti isolati per ambiente, log a prova di manomissione.

Un'ultima raccomandazione pratica: evitare di distribuire aggiornamenti a tutti i sistemi contemporaneamente: con staged rollout o canary deployment, se un fornitore fidato viene compromesso, l'esposizione resta limitata a una piccola parte dell'infrastruttura invece che a tutta.

Fonte: OWASP Top 10:2025: A03, «How to prevent»: separazione dei compiti nella pipeline, build firmate, segreti isolati; distribuire aggiornamenti con staged rollout o canary deployment.

In sintesi

Il filo conduttore di questa voce è uno solo: la fiducia che dai a una dipendenza non dovrebbe mai essere automatica né definitiva. Sapere cosa gira, da dove viene, e come arriva fino a te è, ormai, parte del lavoro di scrivere software sicuro, non un compito a parte.