Proteggere il mondo dai cyber attacchi è il business di Trellix. Ma chi protegge Trellix? Il 2 maggio 2026, la società di cybersecurity — nata nel 2022 dalla fusione tra McAfee Enterprise e FireEye — ha confermato di aver subito una violazione del proprio repository interno di codice sorgente. Un episodio che, aldilà delle rassicurazioni aziendali, pone domande molto serie sull’impatto che la compromissione del codice sorgente di un vendor di sicurezza può avere sull’intero ecosistema dei suoi clienti.
Chi è Trellix e perché è rilevante
Trellix è un attore di primo piano nel mercato della cybersecurity enterprise: offre soluzioni XDR (Extended Detection and Response), endpoint security, email security e threat intelligence a migliaia di organizzazioni in tutto il mondo, incluse agenzie governative, infrastrutture critiche e grandi istituzioni finanziarie. La sua genealogia è illustre: McAfee Enterprise — storico nome dell’antivirus — e FireEye — l’azienda che per prima attribuì pubblicamente gli attacchi informatici alle APT cinesi e scoprì attacchi come quello a Sony Pictures nel 2014 — si sono fuse per creare questo colosso da 1,2 miliardi di dollari, sotto la guida del fondo Symphony Technology Group.
Avere il codice sorgente di una società come Trellix nelle mani di un attore ostile non è come ottenere il codice di un’app mobile: è potenzialmente avere la mappa delle vulnerabilità di decine di prodotti di sicurezza distribuiti in ambienti altamente sensibili.
L’incidente: cosa sappiamo
Trellix ha dichiarato di aver “recentemente identificato” la compromissione del proprio repository di codice sorgente e di aver avviato immediatamente la risposta all’incidente, coinvolgendo forensic expert esterni. La comunicazione ufficiale è avvenuta il 2 maggio 2026, con la notifica alle forze dell’ordine competenti.
Secondo le informazioni diffuse, l’attaccante ha avuto accesso a “una porzione” del codice sorgente relativo allo sviluppo di prodotti. Trellix ha precisato che:
- Non vi sono evidenze che il codice sorgente sia stato sfruttato per attacchi o che il processo di distribuzione sia stato compromesso
- Non sono stati coinvolti ambienti o dati dei clienti
- Il materiale sottratto riguarda esclusivamente codice in fase di sviluppo (product development code), non il software in produzione distribuito ai clienti
Tuttavia, dettagli cruciali rimangono sconosciuti: l’identità dell’attaccante, il vettore di accesso iniziale, la durata della permanenza nella rete e la quantità precisa di codice esfiltrato. L’indagine forense è ancora in corso.
Il paradosso del vendor di sicurezza hackerato
Non è la prima volta che aziende di cybersecurity si trovano nel mirino. Il caso più emblematico rimane quello di SolarWinds nel 2020, quando il gruppo russo Cozy Bear (APT29) compromise la supply chain del software Orion infettando oltre 18.000 organizzazioni nel mondo. In quel caso, il vettore fu proprio il processo di build e distribuzione del software. Nel 2021, Kaseya fu compromessa via zero-day nella sua piattaforma VSA, usata per distribuire ransomware REvil a centinaia di MSP e migliaia di loro clienti finali. FireEye stessa — prima che diventasse parte di Trellix — fu violata da APT29 nel dicembre 2020, con il furto degli strumenti di red team proprietari.
Il pattern è chiaro: i vendor di sicurezza sono target ad altissimo valore perché offrono un doppio vantaggio strategico agli attaccanti:
- Intelligence sulle difese: capire come funzionano i prodotti di sicurezza permette di sviluppare tecniche di evasion specifiche
- Accesso privilegiato: i software di sicurezza operano con privilegi elevati sui sistemi dei clienti, rappresentando un vettore di distribuzione ideale per malware se compromessi
Le implicazioni concrete per i clienti
Anche accettando la narrazione ottimistica di Trellix — nessuna prova di sfruttamento, nessun cliente coinvolto — la compromissione del codice sorgente di un vendor di sicurezza apre scenari preoccupanti che i difensori devono considerare.
In primo luogo, il codice sorgente è una roadmap per trovare vulnerabilità: un attore sufficientemente motivato e capace può analizzare il codice rubato per identificare falle zero-day nei prodotti Trellix, da sfruttare successivamente per compromettere i clienti. In secondo luogo, conoscere i meccanismi interni di un prodotto EDR o XDR permette di sviluppare tecniche di evasion personalizzate, rendendo potenzialmente inefficaci le protezioni Trellix contro attori che abbiano studiato il codice. Terzo punto: non sappiamo ancora se la catena di sviluppo sia stata effettivamente compromessa o meno — le assicurazioni di Trellix si basano su un’indagine non ancora conclusa.
Consigli per i difensori e clienti Trellix
In attesa che l’indagine si concluda e che Trellix divulghi ulteriori dettagli tecnici, le organizzazioni che utilizzano prodotti Trellix dovrebbero adottare alcune misure precauzionali:
- Monitorare attivamente i canali ufficiali di Trellix per aggiornamenti sull’incidente e applicare tempestivamente qualsiasi patch rilasciata
- Aumentare il livello di logging e monitoraggio delle attività dei processi Trellix sui sistemi critici
- Verificare l’integrità degli agenti installati attraverso hash crittografici rispetto alle versioni certificate dal vendor
- Considerare una revisione dei permessi e dei livelli di accesso concessi ai prodotti Trellix nelle reti più sensibili
- Attivare meccanismi di anomaly detection aggiuntivi, non basati esclusivamente su Trellix, per i sistemi ad alto rischio
- Mantenere aggiornati i piani di incident response specifici per scenari di compromissione del vendor
Il caso Trellix è un promemoria particolare: nella cybersecurity moderna, nessuno è immune. Le aziende che si occupano di proteggere i sistemi altrui sono spesso i bersagli più appetibili — e la loro compromissione può avere effetti a cascata su un ecosistema enorme di clienti ignari. La trasparenza rapida e completa da parte del vendor sarà il vero banco di prova nelle prossime settimane.