Cosa è successo

Meta ha confermato che un gruppo esterno è riuscito ad accedere ad alcuni suoi repository GitHub usando le credenziali rubate di un dipendente. L'azienda ha iniziato a notificare le persone coinvolte tra il 13 e il 14 ottobre 2026 (le fonti indicano date leggermente diverse) e ha detto di aver rilevato l'intrusione alcune settimane prima della comunicazione pubblica.

Secondo la ricostruzione fornita da Meta e riportata da più testate, il materiale sottratto è composto per circa il 99% da codice sorgente di alcuni prodotti e per circa l'1% da dati personali di circa 1.500 persone, per lo più dipendenti statunitensi. Meta ammette che quei dati personali non avrebbero dovuto trovarsi nei repository, perché la policy interna lo vieta. L'azienda aggiunge che una parte consistente di quanto sembra dato personale è in realtà sintetico o anonimizzato, usato per i test.

Ci sono poi alcuni elementi che non sono noti, e conviene dirlo chiaramente: non è stato chiarito come siano state rubate le credenziali, quanti repository siano coinvolti, quali categorie precise di dati personali siano state esposte né chi sia l'autore. Meta sostiene che non si tratti di una vulnerabilità in un prodotto e che i sistemi interni non siano stati violati; secondo le indagini preliminari condotte con GitHub, inoltre, gli aggressori non avrebbero preso di mira specificamente Meta. È una valutazione provvisoria, da trattare con cautela.

La risposta dichiarata comprende il blocco dell'accesso, il coinvolgimento di GitHub e delle forze dell'ordine, la rotazione dei segreti (credenziali e chiavi) presenti nei repository compromessi, nuovi controlli di scansione proattiva per individuare dati utente caricati per errore e la notifica alle autorità di regolamentazione. Alle persone coinvolte vengono offerti servizi di monitoraggio del credito e del dark web.

Perché questo caso è istruttivo

Il dettaglio più interessante non è il furto in sé, ma la sua anatomia. Non c'è uno zero-day, non c'è un exploit sofisticato di cui si abbia notizia: c'è un'identità legittima compromessa e una piattaforma di sviluppo che, in quel momento, conteneva più di quanto dovesse. Sono tre problemi distinti che si sommano:

  1. Un'identità sola è bastata. Se le credenziali di un singolo dipendente consentono di leggere più repository, il perimetro di fiducia è troppo ampio. Il problema non è tanto "l'account è stato rubato" (succede), ma "quanto poteva fare, da dove, e per quanto tempo prima che qualcuno se ne accorgesse".
  2. I repository come deposito involontario di dati. Dati personali nel codice, file di test copiati da ambienti reali, dump "temporanei", segreti nei file di configurazione: è un'abitudine diffusa anche in organizzazioni molto mature. Meta lo ammette apertamente, ed è proprio per questo che vale la pena imparare dal caso.
  3. Il codice sorgente come asset. Il 99% del bottino è codice. Per un attaccante il sorgente serve a cercare vulnerabilità in modo mirato, a individuare segreti dimenticati e a preparare attacchi alla supply chain. Anche quando "nessun sistema interno è stato violato", il danno si manifesta più avanti.

Cosa significa per le aziende italiane

Pochi in Italia hanno la scala di Meta, ma quasi tutte le aziende che sviluppano software, anche internamente (gestionali, portali, integrazioni per clienti), usano GitHub, GitLab o Bitbucket e hanno la stessa debolezza strutturale: i repository sono trattati come strumenti di lavoro, non come sistemi che custodiscono dati e segreti. Nella mia esperienza di consulenza, tre situazioni ricorrono con frequenza:

  • sviluppatori esterni o fornitori con accesso ai repository dell'azienda, spesso con account personali non gestiti da single sign-on;
  • token di accesso personali di lunga durata, creati per "far funzionare un'integrazione" e mai revocati;
  • database di test popolati con estrazioni reali di clienti o dipendenti, perché "i dati finti non rendono bene".

Quest'ultimo punto ha un risvolto di privacy che viene sottovalutato. Se un repository contiene dati personali reali e viene compromesso, si configura una violazione dei dati personali a tutti gli effetti. Ai sensi dell'art. 33 del GDPR il titolare deve valutare la notifica al Garante entro 72 ore da quando ne è venuto a conoscenza, a meno che sia improbabile che la violazione comporti un rischio per i diritti e le libertà delle persone, e, se il rischio è elevato, comunicarla agli interessati (art. 34). Il fatto che i dati fossero lì "per errore" non attenua l'obbligo: pesa semmai sul principio di minimizzazione e sulla protezione dei dati fin dalla progettazione (art. 25).

Sul versante NIS2, per i soggetti essenziali e importanti rientrano tra le misure minime la sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi, la gestione degli accessi e l'uso dell'autenticazione a più fattori. Un controllo serio su chi accede ai repository e su come vengono custoditi i segreti è esattamente il tipo di evidenza che un'autorità o un auditor si aspetta di vedere. Con la scadenza del 31 ottobre per alcuni adempimenti ACN alle porte, è un buon momento per verificare che la gestione degli accessi allo sviluppo software non sia rimasta fuori dal perimetro dell'analisi del rischio.

Cosa fare subito

  • Inventario degli accessi ai repository: elencare utenti, collaboratori esterni, app e token con accesso; rimuovere gli account dormienti e quelli non collegati al single sign-on aziendale.
  • MFA resistente al phishing (chiavi FIDO2/passkey) per tutti gli account con accesso al codice, in particolare amministratori e sviluppatori con permessi di scrittura.
  • Token a scadenza breve e con permessi minimi: sostituire i token personali di lunga durata con credenziali a scadenza ravvicinata e limitate a repository specifici.
  • Secret scanning e push protection attivi su tutta l'organizzazione, comprese le repository storiche: la scansione deve coprire anche la cronologia dei commit, non solo l'ultima versione.
  • Cercare dati personali reali nei repository: campioni di database, CSV, log e dump di test. Sostituirli con dati sintetici o effettivamente anonimizzati e ripulire la cronologia dove necessario.
  • Abilitare e conservare gli audit log della piattaforma di sviluppo, con alert su clonazioni massive, accessi da località insolite e creazione di nuovi token.
  • Piano di rotazione dei segreti: sapere in anticipo chi ruota cosa, in quanto tempo, se un repository venisse compromesso. Meta ha ruotato i segreti trovati; senza una procedura già pronta, in molte aziende servirebbero giorni.
  • Procedura di notifica pronta: verificare chi decide, entro quali tempi, se un repository con dati personali viene esposto (Garante entro 72 ore, valutazione sugli interessati, eventuale notifica allo CSIRT Italia per i soggetti NIS2).

In sintesi

Il caso Meta non dice che GitHub sia insicuro e non dimostra una falla nuova. Mostra, con una chiarezza rara perché ammessa dal diretto interessato, che il confine tra "ambiente di sviluppo" e "ambiente con dati reali" è spesso più sottile di quanto si pensi, e che una sola credenziale compromessa basta a trasformare quella sottigliezza in un incidente notificabile. Restano da chiarire il vettore iniziale e l'autore: aggiorneremo l'analisi se emergeranno elementi verificati.