Via Indipendenza
La catena che nessuno ha disegnato ma tutti stanno usando
Il 12 giugno Washington ha spento Anthropic per l'Europa. Nessun preavviso, nessun negoziato, nessuna alternativa immediata per chi aveva costruito processi su quei modelli. Ne abbiamo parlato nella #015. Ma quella notizia ha prodotto un effetto collaterale meno visibile: ha costretto molte aziende a fare per la prima volta una domanda che avrebbero dovuto fare anni prima. Quante delle nostre infrastrutture critiche dipendono da un decisore esterno che non conosciamo?
La risposta, quasi sempre, è "più di quelle che pensavamo". Non perché qualcuno abbia fatto scelte imprudenti. Ma perché le dipendenze tecnologiche si accumulano in modo silenzioso, invisibile, strato per strato. Il CRM sceglie come database di default qualcosa che poi non si riesce a cambiare. Il gestionale usa per le email un provider che a sua volta usa AWS. Il sito web gira su un CDN che dipende da Cloudflare. L'autenticazione passa da Google. La firma digitale da un servizio che ha il suo provider DNS. Nessuno ha mai disegnato quella catena. Eppure, se un anello si spezza — per un guasto, per una sanzione, per una decisione commerciale, per un decreto governativo straniero — tutto si ferma.
Questo numero è dedicato a capire come funzionano le interdipendenze tecnologiche, perché sono strutturalmente invisibili, e cosa si può fare per misurare e ridurre l'esposizione — senza dover buttare via tutto e ricominciare da zero. Non è una questione tecnica. È una questione di consapevolezza strategica. E come tutte le questioni strategiche, parte da un esercizio banale: mappare ciò che già esiste.
Buon settembre. In cinque minuti.
🔒 Architettura e rischioLog4j, CrowdStrike, Anthropic: tre incidenti diversi, un'unica lezione sulla dipendenza invisibile
Tre eventi degli ultimi anni raccontano la stessa storia da angolazioni diverse. Vale la pena metterli in fila — non per fare storia, ma per capire il meccanismo che accomuna tutti e tre, e che si ripete ogni volta.
Log4j (dicembre 2021). Una vulnerabilità critica in una libreria Java open source per la gestione dei log — uno strumento di supporto, non il software principale di nessuno — ha esposto simultaneamente centinaia di migliaia di applicazioni in tutto il mondo. Il problema non era che le aziende avessero scelto male: era che la maggioranza non sapeva nemmeno di usare Log4j. Era una dipendenza transitiva — usata da un framework, che era usato da un'applicazione, che era usata dall'azienda. Nessuno aveva mai disegnato quella catena. La vulnerabilità critica nella libreria Log4j era presente come dipendenza in decine di migliaia di applicazioni Java, spesso senza che gli sviluppatori ne fossero consapevoli.
CrowdStrike (luglio 2024). Un aggiornamento difettoso del software di sicurezza Falcon Sensor ha causato il crash di circa 8,5 milioni di sistemi Windows in tutto il mondo, con interruzioni globali dei servizi critici. La particolarità di questo incidente è che non era un attacco: era un aggiornamento automatico di un software di cybersecurity — uno strumento installato precisamente per proteggere i sistemi, che aveva accesso privilegiato ai kernel dei computer di tutto il mondo. Il crash non è stato innescato da un codice malevolo distribuito da cybercriminali, bensì da una piattaforma antivirus che sfrutta un accesso in profondità ai sistemi endpoint per rilevare malware e attività sospette. Chi aveva aggiornamenti automatici attivi non ha avuto nessuna possibilità di intervenire prima del danno.
Anthropic (giugno 2026). L'abbiamo raccontato nella #015. Un decreto governativo americano. Un'azienda che spegne il servizio globalmente per rispettarlo. Migliaia di aziende europee che scoprono in un giorno di aver costruito processi critici su un'infrastruttura soggetta a una giurisdizione che non possono controllare.
Il filo che li collega è uno: la dipendenza non era visibile finché non si è spezzata. E in tutti e tre i casi, il problema non era la tecnologia in sé — era l'assenza di una mappa delle dipendenze che permettesse di capire in anticipo l'esposizione al rischio.
Le tre categorie di dipendenza tecnica da mappare — in ordine di visibilità decrescente:
1. Dipendenze di primo livello — i fornitori con cui avete un contratto diretto: il provider cloud, il gestore del dominio, il fornitore dell'ERP. Di solito questi li conoscete. Il rischio è concentrazione: quanti processi critici passano da uno solo di loro?
2. Dipendenze di secondo livello — i fornitori dei vostri fornitori. Il vostro gestionale SaaS gira su AWS o Azure? Il vostro provider email usa Cloudflare? Se il fornitore di primo livello ha un problema con il suo fornitore, voi lo sentite — senza avere nessun contratto con chi ha causato il problema.
3. Dipendenze transitive — le librerie e i componenti software che i vostri strumenti usano internamente senza che voi lo sappiate. Questo è il territorio di Log4j: una dipendenza nascosta in profondità nello stack software, invisibile finché non diventa un problema. Per mapparle serve una Software Bill of Materials (SBOM) — un documento che elenca tutti i componenti del software che usate. Ne abbiamo parlato nella #013.
Fonti: Cybersecurity360, Il Sole 24 Ore, Digitalic, Wikipedia — 2024/2026
🌍 Geopolitica digitaleIl 37% delle grandi aziende italiane sta rimpatriando i workload critici dal cloud. Non è nostalgia — è calcolo
Un dato presentato dagli Osservatori Digital Innovation del Politecnico di Milano all'evento LENS 2026 descrive un cambiamento silenzioso ma significativo: il 37% delle grandi aziende italiane sta valutando o ha già avviato percorsi di repatriation, ovvero il ritorno di determinati workload critici dal cloud pubblico verso infrastrutture on premise o cloud sovrani. Questa scelta è dettata dalla necessità di recuperare il controllo diretto sul dato, mitigare i rischi di vendor lock-in e rispondere a requisiti di compliance sempre più stringenti.
Non è un ritorno al passato. È una risposta razionale a una domanda che le grandi aziende hanno iniziato a porsi concretamente: se il mio fornitore cloud principale diventasse improvvisamente inaccessibile — per un decreto, per un guasto, per una sanzione, per una revisione commerciale — in quanto tempo riuscirei a ripristinare le operazioni critiche? Per chi non ha una risposta precisa a questa domanda, il cloud è diventato una scommessa strategica nascosta, non solo una scelta infrastrutturale.
La domanda può sembrare estrema, ma è sempre meno teorica: cosa accadrebbe se l'accesso a servizi cloud, piattaforme collaborative, sistemi di autenticazione o infrastrutture digitali gestite fuori dall'Europa diventasse improvvisamente più complesso, limitato o meno prevedibile? Non serve immaginare uno scenario di blocco totale — basta osservare quanto il funzionamento quotidiano delle aziende dipenda da servizi governati da normative e interessi che non sempre coincidono con quelli europei.
Le quattro domande di sovranità digitale da fare alla propria infrastruttura:
1. Dove risiedono i dati? In quale paese fisicamente, e sotto quale giurisdizione legale? Un data center "europeo" di un'azienda americana è soggetto al CLOUD Act americano: i dati possono essere richiesti da Washington senza che l'azienda europea ne venga informata.
2. Chi gestisce le infrastrutture? Chi controlla l'accesso fisico ai server, alle reti, ai sistemi di autenticazione? Se è un soggetto extraeuropeo, esistono garanzie contrattuali specifiche per i casi di conflitto normativo?
3. Qual è il piano B operativo? Se il fornitore principale diventasse irraggiungibile per 72 ore, quali processi si fermerebbero? Quanti di questi processi hanno un'alternativa già pronta o almeno documentata?
4. I dati sono portabili? In quanto tempo e con quale costo riuscireste a migrare i dati critici su un fornitore alternativo? Se la risposta è "mesi" o "non lo so", la portabilità non esiste nella pratica.
Fonti: Osservatori Digital Innovation Politecnico di Milano LENS 2026, HyperGrid, ZeroUnoWeb — 2026
☁️ Architettura del datoTerraform, Redis, HashiCorp: quando il fornitore cambia le regole del gioco dopo che avete già costruito su di lui
C'è una categoria di lock-in più sottile di quella che deriva da un contratto pluriennale o da dati in formati proprietari: il lock-in da adozione. Accade quando uno strumento diventa così integrato nei processi e nelle competenze di un'organizzazione da rendere il cambiamento costoso non per vincoli tecnici, ma per inerzia organizzativa. È in quel momento che il fornitore ha tutto il potere di ridisegnare le condizioni unilateralmente.
Da HashiCorp che, una volta acquisita da IBM, ha spostato Terraform sulla Business Source License, a Redis, con la revisione del proprio modello di licenza. Molte aziende avevano adottato questi strumenti non solo per motivi tecnici, ma perché li percepivano come parte dell'ecosistema comune. Ed è proprio questa invisibilità a rendere pericoloso il lock-in: quando una tecnologia è ovunque, ma non compare più nelle discussioni strategiche, il rischio è già entrato nel sistema.
Terraform — lo strumento più diffuso al mondo per il provisioning di infrastruttura cloud — è stato usato per anni da decine di migliaia di aziende nella convinzione che fosse open source. Quando HashiCorp ha cambiato la licenza, molte organizzazioni hanno scoperto di aver costruito interi processi di deployment su qualcosa che ora richiedeva un pagamento per l'uso commerciale. Il fork open source (OpenTofu) è arrivato in pochi mesi, ma quelle organizzazioni hanno dovuto affrontare una migrazione non pianificata, non a budget e non a scelta.
I cinque segnali che uno strumento è diventato un lock-in invisibile:
1. Nessuno in azienda sa esattamente cosa fa quello strumento — sanno solo che "senza di lui non funziona niente".
2. I dati prodotti dallo strumento non sono esportabili in formato standard senza il supporto del vendor.
3. Nessun'altra azienda del settore usa un'alternativa — tutti usano quello stesso strumento, il che crea l'illusione che non esistano alternative.
4. Gli aggiornamenti vengono applicati automaticamente senza un processo di test e approvazione — come nel caso CrowdStrike.
5. Il costo di migrazione stimato supera il budget annuale IT — il che significa che qualsiasi cambiamento è praticamente impossibile, e il vendor lo sa.
Fonte: Tom's Hardware — maggio 2026
🔧 Strategia operativaArchitettura per la resilienza: non serve ricostruire tutto. Serve sapere cosa spezzarsi per primo
Ridurre le dipendenze non significa eliminarle. Significa sceglierle consapevolmente, diversificarle dove il rischio è alto, e avere una risposta già pronta per quelle che non si possono eliminare. L'obiettivo non è l'autosufficienza — è la resilienza: la capacità di continuare a operare, anche in modo degradato, quando qualcosa si spezza.
Il principio architetturale che guida questo ragionamento si chiama "no single point of failure": nessun componente critico dovrebbe essere l'unico punto attraverso cui passa un processo aziendale essenziale. Se l'autenticazione di tutti i dipendenti passa da un unico provider di identity, quel provider è un SPOF. Se tutti i backup sono su un unico cloud, quel cloud è un SPOF. Se la connettività Internet passa da un unico ISP, quell'ISP è un SPOF. Una politica di "no single point of failure" significa che nessun fornitore deve diventare insostituibile.
Ma la resilienza non è solo tecnica. Le architetture digitali moderne si fondano su infrastrutture comuni, librerie open source, pipeline CI/CD, piattaforme SaaS e cloud globali che diventano single point of failure condivisi. Un incidente in un fornitore SaaS, in una piattaforma cloud o nella supply chain software può fermare produzione, pagamenti e servizi essenziali in poche ore, indipendentemente dal livello di sicurezza interna. La sicurezza interna è necessaria ma non sufficiente: la vulnerabilità può arrivare dall'esterno, attraverso un fornitore che a sua volta dipende da qualcun altro.
| Livello | Domanda da porsi | Risposta pratica |
|---|---|---|
| DNS | Se il vostro provider DNS va giù, il vostro sito e le email smettono di funzionare? | DNS secondario su provider diverso, TTL bassi |
| Identità | Se Google o Microsoft non sono raggiungibili, i dipendenti riescono ad autenticarsi? | Credenziali locali di emergenza, procedure offline documentate |
| Backup | Se il vostro cloud provider principale va offline, dove sono i backup? | Regola 3-2-1: backup offline su infrastruttura separata e diversa |
| Software | Se il vostro SaaS principale non è raggiungibile, avete una procedura di fallback? | Procedure manuali documentate per i processi critici, dati esportati periodicamente |
| Aggiornamenti | Gli aggiornamenti automatici possono fermare i sistemi critici senza preavviso? | Staging environment, finestre di manutenzione controllate, rollback pianificato |
Fonti: Digitalic, Eurocominnovazione, S-mart.biz — 2025/2026
🔬 Dal laboratorioIl problema delle dipendenze transitive: il codice che usate contiene codice che non sapete di usare
Un'applicazione moderna — che sia un gestionale, un e-commerce, un portale clienti — non è mai il codice scritto dal team che l'ha sviluppata. È quel codice più centinaia di librerie di terze parti, ciascuna delle quali a sua volta include altre librerie. Un'app Node.js di medie dimensioni ha tipicamente tra le 500 e le 1.500 dipendenze nel file node_modules. La maggior parte di queste dipendenze non le ha scelte nessuno — sono arrivate automaticamente come conseguenza di scelte che qualcun altro ha fatto.
Questo non è un problema teorico. L'incidente XZ Utils (2024) ha mostrato uno scenario ancora più sofisticato: un attore malevolo ha trascorso due anni a guadagnarsi la fiducia della comunità open source di un progetto critico per inserire una backdoor in una libreria di compressione ampiamente utilizzata nei sistemi Linux. La backdoor sarebbe entrata in produzione su milioni di sistemi attraverso aggiornamenti automatici — è stata scoperta per caso, giorni prima del rilascio stabile, da un ricercatore che aveva notato delle anomalie di performance. Una coincidenza fortunata, non un sistema di difesa.
La risposta tecnica si chiama Software Bill of Materials (SBOM) — un documento che elenca tutti i componenti del software in uso, incluse le dipendenze transitive, con versioni e licenze. Il Cyber Resilience Act europeo renderà la SBOM obbligatoria per molte categorie di prodotti software entro il 2027. Ma la ragione per adottarla non è la compliance: è sapere esattamente cosa c'è dentro il software che si usa, prima che qualcun altro lo scopra al posto vostro.
Fonte: Cybersecurity360, Bytebase — 2026
🎯 Strumento della settimanadraw.io + un pomeriggio — Come fare la mappa delle dipendenze della propria infrastruttura in 4 ore
Cos'è: draw.io (ora anche disponibile come app.diagrams.net) è uno strumento open source e gratuito per creare diagrammi — architetture software, mappe di rete, flussi di processo. Non richiede installazione: funziona nel browser. I file vengono salvati in locale o su Google Drive, senza account obbligatorio. Non è un software di monitoraggio automatico: è uno strumento per rendere esplicita la conoscenza che già esiste, ma non è mai stata messa su carta.
Come usarlo per mappare le dipendenze: l'esercizio più utile che un'organizzazione può fare è disegnare la propria "mappa delle dipendenze critiche" — uno schema che risponde a queste domande: quali sono i servizi digitali senza cui l'azienda non riesce a operare? Chi li fornisce? Dove girano? Cosa usano a loro volta? Quante ore di downtime tollerabile ha ciascuno di essi prima che l'impatto diventi significativo?
Non serve farlo in un giorno né coprire tutto. Un pomeriggio dedicato con il responsabile IT e uno o due responsabili di processo produce quasi sempre una mappa sufficiente per identificare i due o tre punti di esposizione maggiore — e per fare le domande giuste ai fornitori nelle prossime settimane.
→ app.diagrams.net — gratuito, open source, senza account. I file si salvano in formato XML, apribili su qualsiasi istanza futura.
Punto di partenza consigliato: iniziate dai processi critici, non dall'infrastruttura. Scrivete: "per fare X, usiamo Y, che usa Z, che gira su W, gestito da V". Poi disegnate. La mappa emergerà da sola.
Per chi vuole andare più in profondità: Dependency-Track (presentato nella #013) automatizza la mappatura delle dipendenze del software — non dell'intera infrastruttura, ma di ogni componente applicativo — e genera alert quando viene scoperta una vulnerabilità in uno dei componenti mappati.
Via Indipendenza
La newsletter settimanale per chi guida un'azienda e vuole capire la tecnologia, non subirla. Via Indipendenza utilizza strumenti di intelligenza artificiale generativa, ma la selezione delle fonti e il controllo dei testi generati è fatto dal nostro team di esperti del settore (avviso ai sensi delle disposizioni dell'A.I. ACT, il Regolamento UE/2024/1689).
Un progetto promosso da airpim srl