Trellix, nome noto nel panorama della cybersecurity aziendale, si ritrova al centro di un paradosso imbarazzante: un attacco al codice sorgente di un’azienda che vende strumenti per prevenire attacchi. L’incidente, confermato da fonti come The Hacker News e SecurityWeek, ha visto un attore non identificato ottenere accesso a una porzione del repository interno. L’azienda ha dichiarato di aver avviato le indagini con esperti forensi e di aver coinvolto le forze dell’ordine, ma il danno — anche solo reputazionale — è già stato fatto.

Il paradosso del guardiano derubato

Trellix non è un attore minore: nata dalla fusione tra McAfee Enterprise e FireEye, si presenta come un pilastro della difesa informatica avanzata. Il fatto che proprio il suo codice sorgente sia stato compromesso non è solo un incidente tecnico, ma una ferita simbolica. L’azienda sostiene che il processo di rilascio e distribuzione del software non sia stato alterato, il che suggerirebbe un contenimento efficace. Ma la domanda che rimane è: chi ha accesso a quel codice, e cosa ne ha fatto?

Non ci sono segnalazioni di backdoor inserite, né di exploit diffusi. Tuttavia, l’accesso a codice proprietario può rivelare logiche interne, punti deboli, configurazioni hard-coded o persino vulnerabilità zero-day non ancora scoperte. Anche in assenza di un impatto immediato, il valore strategico di questo tipo di informazione per un attore ostile è inestimabile.

Il 42% che nessuno vuole vedere

Secondo il rapporto IBM Security X-Force Threat Intelligence Index 2025, il 42% delle violazioni di sicurezza coinvolge vulnerabilità nel software. Non si tratta di attacchi esterni generici, ma di falle nel codice che vengono sfruttate per ottenere accesso profondo ai sistemi. In questo contesto, un repository di codice sorgente diventa un obiettivo di prim’ordine: è l’anatomia digitale di un prodotto. Proteggerlo non è una scelta, è un obbligo.

Eppure, molte organizzazioni — comprese quelle del settore security — trattano i repository come semplici depositi tecnici, non come asset strategici. L’accesso spesso non è limitato con criteri zero trust, le modifiche non sono sempre tracciate in tempo reale, e i controlli di integrità sono saltuari. Il risultato? Un ambiente in cui un attaccante, una volta dentro, può navigare tra file e commit con relativa facilità.

Lezioni da non imparare (di nuovo)

L’incidente Trellix non è un’anomalia. È un’istantanea di un problema strutturale. Nel 2020, SolarWinds fu colpito in modo simile: un accesso al codice sorgente portò a una delle più gravi compromissioni della catena di approvvigionamento software della storia. Il risultato fu CVE-2020-10148, una backdoor inserita nel processo di build. Oggi, nonostante i moniti, la lezione sembra non essere stata assimilata a fondo.

La difesa efficace richiede più di semplici dichiarazioni di sicurezza. Richiede:

  • Modello zero trust applicato ai repository: nessun accesso predefinito, autenticazione continua, segmentazione rigorosa.
  • Audit continui del codice: strumenti di detection automatica per modifiche non autorizzate, integrazione con SIEM e SOAR.
  • Piani di risposta collaudati: non basta coinvolgere la polizia dopo il fatto. Serve un processo chiaro, testato, con ruoli definiti e comunicazione trasparente.

Trellix ha fatto la cosa giusta nel notificare l’evento e nel muoversi rapidamente. Ma la vera misura della risposta non sarà nei comunicati stampa, bensì nella capacità di dimostrare, con prove tecniche, che il codice rilasciato è identico a quello prodotto — e che nessuna mano estranea lo ha alterato.

Il settore della sicurezza deve smettere di considerare se stesso immune. Quando il guardiano ha un buco nella porta di servizio, nessuno è al sicuro.