L’AI ha ucciso la security through obscurity: perché il codice chiuso non basta più

In questo articolo scoprirai:

• Chi ha ucciso la security through obscurity
• La tesi di Ratner: l’AI toglie il collo di bottiglia, non aggiunge un attacco
• Quanto vale il codice chiuso: i numeri veri della supply chain
• Cosa cambia davvero per una PMI italiana con stack misto
• Modelli a pesi aperti: l’altro piano del discorso, con rischi diversi
• Le tre abitudini da rivedere: dipendenze, segreti, componenti pubblici

Chi ha ucciso la security through obscurity

Il 20 agosto 2026 Gal Ratner ha pubblicato The End of Open Source, un saggio che ribalta un’intuizione radicata: tenere il codice chiuso non è più una difesa. La tesi è secca, i servizi di intelligence non sono mai stati limitati da quanto codice riuscivano a rubare, ma da quanto ne riuscivano a leggere. L’AI cancella quel limite. Per chi tratta ancora la security through obscurity come una difesa, il punto non è scegliere una licenza: è accorgersi che il modello di minaccia è cambiato sotto i piedi, e che gran parte delle PMI italiane lo sta affrontando con abitudini scritte per un mondo diverso.

La tesi di Ratner: l’AI toglie il collo di bottiglia, non aggiunge un attacco

L’argomento di Ratner non è che l’AI abbia inventato una nuova classe di attacchi. È che ha rimosso la risorsa scarsa che rendeva l’esposizione tollerabile: l’attenzione umana qualificata. Leggere un repository alla ricerca di una falla richiedeva un analista esperto, giorni di lavoro e una ragione per cominciare. Era un costo che selezionava i bersagli.

Security through obscurity: l’attenzione umana era il vero limite

La frase che riassume il pezzo è anche la più scomoda per una piccola impresa: «You were never too small to hack. You were too boring to read, and that was a temporary condition.» Non eri protetto perché eri irrilevante, eri protetto perché nessuno aveva tempo di guardarti. Quel tempo adesso costa quasi zero.

Sul codice chiuso Ratner è altrettanto tagliente: «Closed source does not remove your exposure. It removes your ability to see it.» La logica regge: il binario proprietario contiene le stesse dipendenze, gli stessi errori di configurazione, gli stessi segreti dimenticati. Semplicemente, nessuno all’esterno può segnalarteli, e chi ti attacca ha strumenti di analisi che non richiedono il sorgente.

Big Sleep: la prova che la lettura automatica del codice funziona davvero

Questa parte della tesi ha una prova empirica solida. L’agente Big Sleep di Google ha individuato CVE-2025-6965, una falla critica in SQLite che, per ammissione della stessa Google, «era conosciuta solo ai malintenzionati ed era a rischio di essere sfruttata». Secondo Google è la prima volta documentata in cui un agente AI blocca preventivamente uno sfruttamento in corso. Vale però in entrambe le direzioni: la stessa capacità che difende, attacca.

Quanto vale il codice chiuso: i numeri veri della supply chain

Qui conviene lasciare la filosofia e guardare i conti. Il Software Supply Chain Report 2026 di Sonatype ha identificato 454.600 nuovi pacchetti malevoli nel corso del 2025, portando il totale storico bloccato a oltre 1,233 milioni. Oltre il 99% della malware open source si è concentrata su npm.

Malware open source: la scala industriale del 2025

Il dato che spiega meglio il cambio di scala è un altro: la campagna IndonesianFoods era progettata per auto-replicarsi ogni sette secondi e ha generato da sola 169.538 pacchetti. Sonatype documenta anche Shai-Hulud, il primo worm npm auto-replicante. Non è più vandalismo: è produzione industriale, e in buona parte sponsorizzata da stati.

Una precisazione di onestà: Ratner cita 1,8 milioni di pacchetti cumulativi entro il Q2 2026, mentre il report di Sonatype che lui stesso richiama si ferma a 1,233 milioni. La differenza non cambia la sostanza dell’argomento, ma il numero corretto è quello della fonte primaria.

Codice chiuso contro codice aperto: SolarWinds e il caso XZ Utils

Sul confronto aperto/chiuso, la cronaca è meno consolatoria di quanto si creda. SolarWinds, 3CX e NotPetya sono passati da software proprietario: nessun occhio esterno poteva accorgersene. La backdoor in XZ Utils, invece, è stata scoperta in fretta proprio perché il codice era leggibile, da un ingegnere che notò un ritardo di mezzo secondo. Il codice chiuso non ha impedito le compromissioni peggiori; ha solo allungato il tempo per accorgersene.

Cosa cambia davvero per una PMI italiana con stack misto

Le imprese italiane non devono scegliere fra aperto e chiuso: hanno già entrambi. Un gestionale proprietario, un CRM SaaS, un sito su CMS open source, qualche libreria in un’app interna. Il threat model non si applica a una categoria, si applica all’inventario.

Il problema è che quell’inventario spesso non esiste. Il Rapporto Cyber Index PMI di ACN, Confindustria, Generali e Politecnico di Milano, 1.000 imprese intervistate, assegna alle PMI italiane un punteggio medio di 52 su 100, sotto la soglia di sufficienza fissata a 60. Solo il 15% adotta un approccio strutturato alla sicurezza digitale.

C’è poi una scadenza concreta, non un’ipotesi. Il Cyber Resilience Act impone gli obblighi di segnalazione dall’11 settembre 2026, con applicazione piena dall’11 dicembre 2027. Il regolamento chiede ai produttori di gestire le vulnerabilità lungo l’intero ciclo di vita del prodotto e lungo la catena del valore, cioè anche sui componenti di terzi che hai integrato senza guardarli. Chi sviluppa o rivende software in Europa ha settimane, non anni.

La lettura corretta non è apocalittica: è che l’oscurità non compare in nessuno di questi obblighi come misura di sicurezza. Non lo era prima; adesso non è nemmeno un alibi. Su come conciliare adempimenti e adozione dell’AI abbiamo scritto una guida dedicata a sicurezza, GDPR e AI e una mappa completa di cosa prevede l’AI Act e chi deve adeguarsi.

Modelli a pesi aperti: l’altro piano del discorso, con rischi diversi

Quando in Italia si parla di «AI open source» spesso si intende un’altra cosa: modelli a pesi aperti installati in casa, per tenere i dati dentro il perimetro. È una scelta legittima e a volte la migliore, ma sposta le responsabilità invece di eliminarle, ed è anche il motivo per cui il dibattito politico sui modelli aperti non si è mai chiuso davvero.

OWASP AI Exchange distingue tre modelli di fornitura, hosted, self-hosted e addestrati internamente, e avverte che «le responsabilità variano significativamente». Tradotto: chi scarica i pesi diventa responsabile di patch, guardrail e monitoraggio, senza la pipeline di aggiornamento centralizzata di un fornitore.

Quanto siano fragili quei guardrail è documentato. Uno strumento gratuito chiamato Heretic rimuove le protezioni da un modello a pesi aperti in meno di dieci minuti su un laptop standard: sono stati censiti oltre 3.500 modelli così modificati, con 13 milioni di download cumulativi. A questo si aggiungono i rischi di data poisoning e model poisoning della supply chain, insieme alla concentrazione su pochissimi fornitori di pesi analizzata dalla Cloud Security Alliance: i pesi possono essere alterati alla fonte, e nessuno li scansiona in continuo per conto tuo. È la ragione per cui il modello da solo non basta a rendere sicuro un agente.

Vale anche per il mandato: pesi «opachi» non proteggono più di un sorgente leggibile. Il capitolo più sottovalutato resta la prompt injection indiretta, istruzioni nascoste in un documento che il sistema recupera da solo, prima voce della OWASP Top 10 per le applicazioni LLM e già uscita dalla teoria con l’evasione dall’ambiente di test di un modello OpenAI su Hugging Face.

Le tre abitudini da rivedere: dipendenze, segreti, componenti pubblici

La revisione utile è corta e verificabile. Primo: la dependency review. Serve un elenco di cosa gira davvero, la SBOM, la distinta base del software, e una regola su chi approva l’ingresso di un pacchetto nuovo. Con agenti che risolvono dipendenze in autonomia, l’ultimo checkpoint umano sparisce se nessuno lo mette per iscritto.

Segreti hardcoded: il numero che smonta la security through obscurity

Secondo: la rotazione dei segreti, che è il punto dove i numeri fanno più male. GitGuardian ha rilevato 28,65 milioni di nuovi segreti hardcoded nei commit pubblici del 2025, +34% su base annua, e 1.275.105 credenziali legate a servizi AI (+81%). Ma il dato decisivo è un altro: il 64% delle credenziali valide nel 2022 risultava ancora attivo a gennaio 2026. Quattro anni di esposizione senza revoca. E i repository interni hanno una probabilità sei volte maggiore dei pubblici di contenere un segreto in chiaro, l’oscurità, di nuovo, che rilassa invece di proteggere.

Terzo: l’audit sui componenti pubblici, inclusi quelli che nessuno ha deliberato. Le configurazioni MCP analizzate da GitGuardian esponevano 24.008 segreti unici, di cui 2.117 ancora validi. È esattamente il territorio della shadow AI: strumenti utili adottati dal basso, fuori da ogni inventario.

Il momento naturale per fare questa revisione è l’onboarding di un agente AI in azienda, perché è l’unica occasione in cui qualcuno mappa davvero dati, permessi e integrazioni. È anche il motivo per cui, in questi progetti, il servizio conta più del modello.

Noi di Mimír affianchiamo le aziende proprio in questa fase: l’onboarding assistito serve a capire quali dati l’agente tocca, con quali permessi e attraverso quali componenti di terze parti. Se avete un’esigenza su AI e agenti e volete partire con il perimetro chiaro, potete scriverci per una consulenza.

Fonti:

• Gal Ratner — The End of Open Source (20 agosto 2026)
• Sonatype — Software Supply Chain Report 2026: open source malware
• Google — Big Sleep e CVE-2025-6965 in SQLite
• OWASP — Top 10 per le applicazioni LLM
• OWASP AI Exchange — AI Security Overview e modelli di fornitura
• CISA — Software Bill of Materials (SBOM)
• Commissione europea — Cyber Resilience Act
• Cloud Security Alliance — Open-Weight Concentration Risk
• AvePoint — Open-weight AI models e rimozione dei guardrail
• GitGuardian — State of Secrets Sprawl 2026