Vulnerable and Outdated Components: la guida OWASP A06

I componenti vulnerabili e obsoleti rappresentano un rischio critico, soprattutto per le moderne applicazioni web basate su un’architettura modulare e su componenti di terze parti. Il rischio è amplificato quando librerie, framework e moduli esterni non vengono aggiornati regolarmente o smettono di ricevere supporto da parte dei loro sviluppatori, esponendo così l’applicazione a vulnerabilità note.

Questo tipo di rischio, classificato come A06 – Componenti Vulnerabili e Obsoleti nella lista OWASP Top 10 per il 2021, è tra le principali minacce per la sicurezza delle applicazioni web. Casi come Equifax (2017) e Log4Shell (2021) hanno dimostrato che una singola dipendenza non aggiornata può compromettere intere infrastrutture aziendali.

In questo articolo approfondiamo cosa sono i componenti vulnerabili e obsoleti, gli esempi più importanti di attacchi causati da queste vulnerabilità, l’impatto sul business e le tecniche specifiche per mitigarne i rischi.

1. Cosa sono i componenti vulnerabili e obsoleti
2. Esempi famosi di attacchi causati da componenti vulnerabili
3. Tipologie di componenti a rischio
4. Impatto sul business
5. Come identificare i componenti vulnerabili
6. Best practice per la mitigazione

Cosa sono i componenti vulnerabili e obsoleti?

Differenza tra “vulnerabile” e “obsoleto”

I termini “vulnerabile” e “obsoleto” sono spesso usati insieme ma indicano due condizioni diverse:

• Un componente vulnerabile presenta una falla di sicurezza nota, identificata da un CVE pubblico
• Un componente obsoleto non riceve più supporto dal vendor: anche se oggi non ha vulnerabilità note, è solo questione di tempo prima che ne emergano

Tali componenti possono essere progettati con difetti che rendono possibile l’esecuzione di codice non autorizzato o l’accesso a dati sensibili. Diventano “obsoleti” quando il fornitore cessa di supportarli, interrompendo la distribuzione di patch e aggiornamenti di sicurezza.

Perché sono un rischio crescente per le aziende

Una moderna applicazione web aziendale dipende mediamente da centinaia di librerie di terze parti, spesso annidate (la libreria A usa la libreria B che usa la C). Questo fenomeno, chiamato transitive dependency, fa sì che gli sviluppatori spesso non sappiano nemmeno quali componenti sono effettivamente in uso nella propria applicazione.
Una libreria di crittografia non aggiornata potrebbe non garantire più l’integrità dei dati crittografati, mentre un modulo API deprecato può non essere conforme ai più recenti standard di sicurezza. Le vulnerabilità nei componenti spesso derivano da errori di programmazione, configurazioni sbagliate o utilizzo di protocolli e algoritmi deboli.

Esempi famosi di attacchi causati da componenti vulnerabili

La storia recente offre diversi esempi di attacchi informatici resi possibili dall’utilizzo di componenti vulnerabili.

Log4Shell (2021) — il caso più devastante della storia recente

Nel dicembre 2021 è stata scoperta CVE-2021-44228, una vulnerabilità critica in Apache Log4j, una libreria Java per la gestione dei log utilizzata praticamente in ogni applicazione Java aziendale. Lo score CVSS della vulnerabilità è 10.0/10.0 — il massimo possibile.

L’attacco, ribattezzato Log4Shell, permetteva di eseguire codice arbitrario sul server semplicemente inserendo una stringa malevola in un campo che venisse loggato (es. user-agent, header HTTP, payload JSON). Ha colpito decine di migliaia di aziende a livello globale, dal Pentagono ad Apple, da Twitter a Steam. Molte organizzazioni hanno scoperto di usare Log4j solo dopo lo scoppio della crisi, perché era una transitive dependency di altre librerie.

Log4Shell è il caso scolastico dei rischi A06: una singola libreria di logging — apparentemente innocua — ha messo in ginocchio l’intera industria IT mondiale.

Equifax (2017) — Apache Struts

Nel 2017 Equifax, una delle principali agenzie di credito statunitensi, subì un data breach di importanti dimensioni. Gli attaccanti sfruttarono CVE-2017-5638, una vulnerabilità nel framework Apache Struts utilizzato dall’applicazione web di Equifax. Nonostante fosse disponibile una patch di sicurezza da diversi mesi, non era stata applicata, consentendo agli attaccanti di accedere ai dati sensibili di 147 milioni di utenti. Il breach costò all’azienda oltre 700 milioni di dollari in cause legali e sanzioni.

WannaCry (2017) — SMBv1 Windows

L’attacco ransomware WannaCry ha colpito centinaia di migliaia di computer in tutto il mondo sfruttando EternalBlue (CVE-2017-0144), una vulnerabilità nel protocollo SMBv1 di Microsoft Windows. Anche in questo caso, Microsoft aveva già rilasciato una patch mesi prima, ma molti sistemi non erano stati aggiornati. WannaCry si diffuse rapidamente paralizzando ospedali, ministeri e aziende manifatturiere, inclusa una parte del sistema sanitario britannico NHS.

Heartbleed (2014) — OpenSSL

Heartbleed (CVE-2014-0160) è una vulnerabilità nel protocollo OpenSSL che ha permesso di leggere dati sensibili direttamente dalla memoria dei server, compromettendo le comunicazioni crittografate di milioni di utenti. Resta uno dei primi grandi casi di “componente fondamentale rotto” che ha fatto capire al mondo quanto fosse fragile l’infrastruttura open source su cui si regge il web.

Tipologie di componenti vulnerabili e obsoleti

I componenti vulnerabili e obsoleti possono essere classificati in tre categorie principali.

Librerie e framework obsoleti
Sono il tipo più comune. Un framework non aggiornato può contenere vulnerabilità che minano la sicurezza delle funzionalità applicative fondamentali. Per esempio, una vecchia versione di un framework JavaScript potrebbe non essere più compatibile con le nuove politiche di sicurezza dei browser, esponendo l’applicazione a rischi di Cross-Site Scripting (XSS) o code injection.

API deprecate e non supportate
Quando un’API viene deprecata, viene sostituita da una versione migliorata e più sicura. Tuttavia, molte applicazioni continuano a utilizzare la versione obsoleta, esponendo il sistema a potenziali falle di sicurezza. Queste API possono non essere conformi agli ultimi standard e presentare difetti sfruttabili dagli attaccanti.

CMS e applicazioni non aggiornati
CMS come WordPress, Drupal o Joomla che non vengono aggiornati regolarmente diventano un obiettivo per attacchi di tipo SQL injection, permettendo l’accesso a database sensibili. Vale lo stesso per i plugin e i temi installati: ogni plugin obsoleto è una porta d’ingresso potenziale.

Impatto sul business

L’uso di componenti vulnerabili può avere un impatto devastante sulla sicurezza dell’applicazione e dell’infrastruttura sottostante. Una violazione di dati può comportare l’esposizione di informazioni sensibili — credenziali di accesso, dati finanziari, informazioni personali degli utenti — con conseguenze su tre piani:

• Sanzioni regolatorie: per le aziende soggette al GDPR le sanzioni possono arrivare fino al 4% del fatturato annuo globale. La direttiva NIS2 amplia ulteriormente la responsabilità per i settori considerati critici.
• Costi diretti: incident response, indagini forensi, eventuali riscatti, downtime operativo. Il caso Equifax (700+ milioni di dollari) rappresenta un limite estremo ma non isolato.
• Danno reputazionale: clienti, partner e investitori valutano la sicurezza come elemento di trust. Un breach pubblico può richiedere anni per essere superato.

In alcuni casi le vulnerabilità nei componenti possono essere sfruttate per eseguire codice arbitrario: un attaccante carica un payload malevolo, ottiene privilegi di amministratore e prende il controllo completo dell’infrastruttura.

Come identificare i componenti vulnerabili

Inventario delle dipendenze (SBOM)
Il primo passo è mantenere un Software Bill of Materials (SBOM) completo: un inventario di ogni componente in uso, con versione, fonte e stato degli aggiornamenti. L’SBOM è diventato uno standard di settore e in molti settori regolamentati (sanitario, finanziario, pubblica amministrazione) è ormai richiesto formalmente.

Software Composition Analysis (SCA)
Gli strumenti di Software Composition Analysis scansionano automaticamente il codice e le dipendenze, identificando librerie con CVE noti. Vengono integrati nel CI/CD pipeline per bloccare il deploy di software contenente vulnerabilità note.

Strumenti consigliati
Esistono diversi strumenti, open source e commerciali, per la SCA:

1. OWASP Dependency-Check: tool open source di riferimento, gratuito, supporta Java, .NET, Python, Ruby, Node.js
2. OWASP Dependency-Track: piattaforma open source per gestione SBOM e monitoring continuo
3. GitHub Dependabot: gratuito su GitHub, scansiona automaticamente le dipendenze di repository pubblici e privati
4. Snyk: commerciale (con free tier), molto usato in ambito enterprise
5. Trivy: tool open source per scansione container e dipendenze (di Aqua Security)

Per applicazioni aziendali complesse, integrare uno di questi strumenti nel CI/CD è la pratica standard nel 2026.

Monitoraggio CVE e NVD
Esistono fonti come il database Common Vulnerabilities and Exposures (CVE) e il National Vulnerability Database (NVD) che raccolgono e pubblicano informazioni su vulnerabilità note. L’iscrizione a mailing list di sicurezza (es. US-CERT, OSV.dev) consente di ricevere aggiornamenti tempestivi sulle nuove vulnerabilità scoperte.

Per applicazioni web aziendali complesse, i test automatici non sono sufficienti. Il servizio di Web Vulnerability Assessment di Cyberment effettua audit completi che identificano vulnerabilità contestuali, transitive dependencies a rischio e configurazioni di sicurezza non standard.

Come mitigare il problema

Patch management strutturato
La gestione delle patch deve essere integrata nel ciclo di vita dello sviluppo software, con routine regolari per verificare la disponibilità di aggiornamenti e applicarli rapidamente. Il caso Equifax dimostra che avere la patch disponibile non basta: serve un processo per applicarla in tempi rapidi.

Audit periodici delle dipendenze
Pianifica audit periodici (mensili o trimestrali) per:

1. Verificare la presenza di nuovi CVE sulle dipendenze in uso
2. Identificare componenti che non ricevono più aggiornamenti
3. Valutare la sostituzione di librerie a rischio con alternative supportate

Minimizzare la superficie d’attacco
Limita l’uso delle dipendenze alle sole necessarie per il funzionamento dell’applicazione. Gli sviluppatori devono verificare attentamente ogni dipendenza per assicurarsi che sia effettivamente essenziale. Meno componenti significa meno superficie d’attacco.

Piano di emergenza per zero-day
Per vulnerabilità critiche scoperte improvvisamente (zero-day), è essenziale avere un piano di risposta documentato. Log4Shell ha mostrato che le organizzazioni con team di incident response strutturati hanno reagito in ore, mentre le altre hanno impiegato giorni o settimane.

Le tue applicazioni sono vulnerabili?

Identificare i componenti vulnerabili e obsoleti su applicazioni web aziendali richiede un audit strutturato. I nostri ethical hacker certificati effettuano analisi complete su librerie, framework e dipendenze in uso, identificando vulnerabilità sfruttabili e priorità di intervento.