Indice dei contenuti
- Oltre il mito: “closed source = sicuro”
- SDK chiusi: il punto cieco più comune
- Plugin “certificati” ma non mantenuti
- Le dipendenze JavaScript dimenticate
- La supply chain nel software proprietario
- Il problema organizzativo, non solo tecnico
- Perché questo tema è più attuale che mai
Quando si parla di sicurezza delle dipendenze, il pensiero corre quasi automaticamente all’open source. Log4j, npm, PyPI, Maven: negli ultimi anni l’attenzione mediatica e tecnica si è concentrata soprattutto sulle librerie aperte, sui repository pubblici e sulle vulnerabilità ereditate da codice scritto da altri. Ma questa narrazione, per quanto fondata, è incompleta.
La supply chain software non è un problema esclusivo dell’open source. Anzi, in molti contesti aziendali il rischio maggiore arriva proprio da ciò che è percepito come “sicuro per definizione”: SDK proprietari, plugin certificati, componenti commerciali e dipendenze chiuse che nessuno controlla davvero.
Questo articolo nasce da qui: smontare un luogo comune e analizzare perché la sicurezza delle dipendenze riguarda tuttoil software, non solo quello open source. Lo faremo con esempi concreti, scenari reali e un taglio volutamente non banale, pensato per chi lavora davvero con sistemi complessi.
Oltre il mito: “closed source = sicuro”
In molte organizzazioni esiste ancora un assunto implicito: se un componente è proprietario, allora è anche più sicuro. Il ragionamento è semplice (e rassicurante): il codice non è pubblico, il vendor è responsabile, c’è un contratto, magari una certificazione. Problema risolto.
In realtà, questo approccio confonde controllo con fiducia. Il fatto che il codice non sia visibile non significa che sia stato scritto bene, mantenuto correttamente o aggiornato con tempestività. Al contrario, l’opacità rende più difficile individuare vulnerabilità, comprenderne l’impatto e valutare i rischi reali.
Nel mondo open source, almeno in teoria, chiunque può analizzare il codice, segnalare bug, proporre fix. Nel software chiuso, invece, tutto dipende da:
- tempi e priorità del fornitore
- trasparenza nella disclosure
- qualità del processo di sviluppo interno
- reale volontà di correggere problemi che non impattano direttamente il business
La sicurezza della supply chain diventa così un problema di asimmetria informativa: tu usi il componente, ma non sai davvero cosa succede al suo interno.
SDK chiusi: il punto cieco più comune
Esempio
Gli SDK proprietari. Sono ovunque: analytics, advertising, pagamenti, autenticazione, servizi cloud, IoT, mobile app. Spesso vengono integrati con poche righe di codice, seguendo una guida ufficiale e senza ulteriori domande.
Il problema è che un SDK:
- gira dentro la tua applicazione
- ha accesso agli stessi permessi
- comunica verso l’esterno
- può aggiornarsi dinamicamente
Se l’SDK contiene una vulnerabilità critica, questa diventa automaticamente parte del tuo perimetro di rischio.
In diversi incidenti reali, SDK chiusi hanno introdotto:
- remote code execution non documentate
- librerie obsolete al loro interno (openssl, curl, zlib)
- chiamate a endpoint non più mantenuti
- logica di update silenziosa, fuori dal controllo del team
Il paradosso è che spesso questi SDK non vengono nemmeno considerati “dipendenze” nei processi di sicurezza. Non finiscono negli SBOM, non vengono scannerizzati, non rientrano nelle policy di patch management. Sono una scatola nera fidata, fino al giorno dell’incidente.
Plugin “certificati” ma non mantenuti
Un altro punto critico è rappresentato dai plugin certificati. CMS, e-commerce, ERP, CRM, piattaforme di collaboration: quasi tutti espongono marketplace ufficiali con estensioni “verificate”, “approved”, “certified”.
Queste etichette trasmettono un messaggio chiaro: puoi fidarti. Ma la certificazione, nella maggior parte dei casi, è:
- una verifica iniziale
- un controllo funzionale
- raramente un audit di sicurezza continuo
Il risultato è che molti plugin:
- restano compatibili a livello tecnico
- ma non vengono più aggiornati dal punto di vista della sicurezza
- accumulano debito tecnico
- continuano a essere distribuiti perché “ufficiali”
In diversi casi di compromissione, l’entry point non è stato il core della piattaforma, ma un plugin certificato installato anni prima, mai più rivisto e dimenticato persino dagli amministratori.
Qui la sicurezza delle dipendenze fallisce non per mancanza di strumenti, ma per eccesso di fiducia istituzionalizzata.
Le dipendenze JavaScript dimenticate
Il mondo JavaScript merita un capitolo a parte. Frontend moderni, backend Node.js, tool di build, pipeline CI/CD: tutto ruota attorno a un ecosistema di dipendenze profonde e transitive.
Il problema non è solo la quantità, ma la persistenza. Molte dipendenze:
- vengono aggiunte per risolvere un problema specifico
- restano nel progetto anche quando non servono più
- non vengono aggiornate perché “funziona tutto”
Col tempo si crea una stratificazione di librerie:
- non più utilizzate direttamente
- ma ancora presenti nel bundle
- con vulnerabilità note
- spesso segnalate, ma ignorate
In ambienti enterprise è comune trovare progetti con:
- decine di dipendenze non referenziate
- versioni bloccate da anni
- pacchetti mantenuti da sviluppatori che non esistono più
Il rischio non è teorico: una dipendenza JavaScript dimenticata può diventare la porta d’ingresso per un attacco alla supply chain, soprattutto se viene compromesso il maintainer o l’account di pubblicazione.
La supply chain nel software proprietario
Quando si parla di software proprietario, si tende a immaginare un prodotto monolitico, sviluppato internamente dal vendor. In realtà, anche il software commerciale moderno è una catena di dipendenze.
Un prodotto chiuso può includere:
- librerie open source embedded
- componenti di terze parti licenziati
- SDK di altri vendor
- servizi cloud esterni
- moduli legacy mai riscritti
Il cliente finale vede un’unica interfaccia, ma sotto c’è una supply chain complessa, spesso invisibile. E quando emerge una vulnerabilità, il problema diventa duplice:
- dipendenza tecnica
- dipendenza contrattuale
Non puoi patchare da solo. Devi aspettare. E nel frattempo sei esposto.
Questo è uno dei motivi per cui la sicurezza delle dipendenze nel software proprietario è, paradossalmente, più difficile da gestire rispetto all’open source.
Il problema organizzativo, non solo tecnico
Un errore comune è trattare la sicurezza delle dipendenze come un tema puramente tecnico. In realtà è soprattutto un problema organizzativo e culturale.
Alcuni segnali tipici:
- nessuno è responsabile delle dipendenze
- non esiste un inventario aggiornato
- gli audit sono episodici
- le dipendenze “storiche” non si toccano
- il vendor viene dato per affidabile a priori
In questo contesto, anche il miglior tool di scanning serve a poco. La supply chain software richiede processi chiari:
- ownership delle dipendenze
- criteri di adozione e dismissione
- valutazione del rischio del fornitore
- monitoraggio continuo
Senza queste basi, la sicurezza resta reattiva e frammentata.
Perché questo tema è più attuale che mai
Negli ultimi anni gli attacchi alla supply chain sono aumentati perché sono efficienti. Compromettere una dipendenza significa colpire centinaia o migliaia di target con un solo sforzo.
E mentre l’attenzione si concentra sull’open source, molte organizzazioni restano vulnerabili proprio dove si sentono più tranquille: software commerciale, plugin ufficiali, SDK “affidabili”.
Il vero cambio di paradigma è questo:
la sicurezza delle dipendenze non è una questione di licenza, ma di visibilità, controllo e responsabilità.
Conclusione
Pensare che il rischio di supply chain riguardi solo l’open source è una semplificazione pericolosa. SDK chiusi, plugin certificati e dipendenze dimenticate dimostrano ogni giorno che il problema è trasversale.
La domanda giusta non è “è open source o proprietario?”
Ma:
- chi lo mantiene?
- come viene aggiornato?
- cosa succede se domani emerge una vulnerabilità?
Solo affrontando la sicurezza delle dipendenze in modo sistemico, e non ideologico, è possibile ridurre davvero il rischio. Tutto il resto è una falsa sensazione di controllo.
Domande frequenti
- La sicurezza delle dipendenze riguarda solo l’open source?
No, riguarda anche software proprietario, SDK chiusi e plugin certificati. - Perché gli SDK proprietari sono rischiosi?
Perché sono scatole nere con privilegi elevati e spesso fuori dai controlli di sicurezza. - I plugin certificati sono sempre sicuri?
No, la certificazione iniziale non garantisce manutenzione continua. - Cosa sono le dipendenze dimenticate?
Librerie non più usate direttamente ma ancora presenti nel progetto. - Il software proprietario ha una supply chain?
Sì, spesso include molte componenti di terze parti. - Perché è difficile gestire vulnerabilità nei prodotti chiusi?
Perché dipendi dai tempi e dalle scelte del vendor. - Gli SBOM includono anche componenti proprietari?
Dovrebbero, ma spesso non lo fanno in modo completo. - I tool automatici bastano?
No, senza processi e responsabilità chiare restano inefficaci. - Qual è l’errore più comune delle aziende?
Fidarsi del vendor senza verificare. - Qual è il primo passo concreto?
Mappare tutte le dipendenze, indipendentemente dalla licenza.
