// 2 ZERO-DAY · 5 CVE · 5 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Il poster DFIR di Wiz CIRT mappa i log audit VCS su MITRE ATT&CK, ma rivela gap critici: il 88% dei clienti usa SaaS con retention di 7 giorni e visibilità

Il 27 agosto 2026 il team di ricerca Wiz CIRT ha diffuso un poster DFIR dedicato alle piattaforme di version control SaaS, mappando eventi audit specifici sul framework MITRE ATT&CK per GitHub, GitLab, Bitbucket e Azure DevOps. Il documento nasce da un dato operativo: il 88% dei clienti Wiz utilizza VCS in cloud, ma le stesse azioni offensive — dal cloning massivo al branch hijacking — generano log con nomi diversi su ogni piattaforma e spesso scompaiono dopo pochi giorni. La frammentazione non è un problema di traduzione: è un gap di visibilità che trasforma incident response in risposta a tentoni.

Punti chiave
  • Il poster Wiz CIRT traduce tattiche MITRE ATT&CK in query specifiche per quattro piattaforme VCS, evidenziando che la stessa operazione — esempio, mass repository cloning — si chiama git.clone su GitHub, repository_git_operation su GitLab e RepositoryCloneEvent su Bitbucket Data Center.
  • GitHub conserva di default i log di lettura e scrittura Git per sette giorni; oltre questo arco, gli eventi di accesso ai repository diventano irrecuperabili senza configurazione proattiva.
  • GitLab, in configurazione standard, non scrive le operazioni Git nel database: richiede lo streaming degli audit event, disponibile al tier Ultimate, per avere traccia analoga.
  • Solo GitHub tra le quattro piattaforme hosted permette di attivare il logging delle richieste API, e richiede configurazione esplicita: questa assenza amplifica i blind spot su chiamate programmatiche non rintracciabili altrove.

La taxonomia come campo minato: quando lo stesso attacco ha quattro nomi

Il nucleo del lavoro di Wiz CIRT è una matrice di traduzione sistematica. Per ogni tattica MITRE ATT&CK identificata nel vettore VCS, il poster indica il nome dell'evento audit corrispondente su ciascuna piattaforma. La scelta di pubblicare questa mappatura non è accademica: durante incident response reali, i team devono costruire query su log il cui significato cambia da un SaaS all'altro.

Il caso più eloquente è il mass repository cloning. Su GitHub l'evento si chiama git.clone; su GitLab diventa repository_git_operation; su Bitbucket Data Center si trasforma in RepositoryCloneEvent. La differenza non è terminologica: è strutturale, perché ogni piattaforma organizza i propri audit log con campi, filtri e retention diversi. Bitbucket Cloud e Bitbucket Data Center, specifica la fonte, hanno meccanismi di audit logging "fondamentalmente diversi" — un'ulteriore complicazione per team che gestiscono istanze ibride.

GitHub e GitLab mantengono schemi audit log coerenti tra le versioni SaaS e self-hosted, ma questo vantaggio si annulla parzialmente se la raccolta dati non è abilitata in tempo. La matrice del poster funziona da cheat sheet per detection engineering: traduce tecniche offensive in query concrete, riducendo il tempo di sviluppo delle regole di rilevamento.

Sette giorni e poi il buio: i limiti di retention che forzano la credential rotation

La retention emerge come punto di frizione critico. GitHub memorizza gli eventi di lettura e scrittura Git per sette giorni di default. Passata questa finestra, l'accesso storico ai repository non è più ricostruibile tramite i log nativi della piattaforma. Un caso documentato dal Wiz CIRT illustra la conseguenza operativa: durante un'indagine, "because historical Git clone events were not fully available due to standard retention limits, the scope of the exfiltrated repositories could not be determined". L'impossibilità di quantificare cosa è stato clonato ha costretto l'organizzazione a una rotazione credenziali su scala intera, senza poter stabilire se l'azione fosse necessaria o superflua.

GitLab presenta un profilo diverso ma compatibile: in configurazione standard, le operazioni Git non vengono salvate nel database. Lo streaming completo degli audit event richiede il tier Ultimate, secondo la documentazione ufficiale. Questo significa che organizzazioni con piani inferiori operano con visibilità parziale per definizione, indipendentemente dalla competenza del team SOC.

Il dato quantitativo è segnalato con precisione: il 88% dei clienti Wiz utilizza VCS SaaS. Questa concentrazione su infrastrutture gestite rende i gap di visibilità un problema di massa, non di nicchia. L'assenza di log API su GitLab, Bitbucket e Azure DevOps — con la sola eccezione di GitHub, che richiede configurazione esplicita — completa il quadro di una superficie di attacco monitorata in modo discontinuo.

"Relying exclusively on the UI or API to fetch logs during an active incident leaves critical blind spots for detection and response capabilities."
— Wiz CIRT

Da JINX-0164 a TeamPCP: cosa accade quando i log mancano

Il poster non deriva da teoria astratta. Due campagne documentate da Wiz CIRT — JINX-0164 e TeamPCP — mostrano tecniche VCS che la matrice è progettata per rilevare. JINX-0164 ha impiegato impersonation commit, direct-to-main commits e branch hijacking su repository GitHub. TeamPCP, attivo nel settore delle criptovalute, ha combinato git.clone massivo, cancellazione di workflow logs e pull request con workflow malevoli sfruttando personal access token rubati. Tra il furto delle credenziali e l'inizio delle operazioni di discovery AWS sono trascorse circa 24 ore.

Entrambe le campagne condividono un tratto: le tecniche di post-compromise — cancellazione log, cloning massivo, manipolazione branch — sono rilevabili solo se gli eventi corrispondenti sono stati loggati e conservati. Quando la retention scade o lo streaming non è attivo, l'investigazione retrocede su inferenze e correlazioni indirette, con tempi di risposta che si allungano proporzionalmente. Il poster DFIR non corregge i gap di piattaforma: li documenta sistematicamente, fornendo ai team una checklist di readiness per identificare in anticipo cosa non sarà visibile dopo un incidente.

Cosa fare adesso

Il dossier Wiz CIRT non elenca raccomandazioni operative standardizzate, ma i fatti verificati indicano azioni prioritarie per team che gestiscono VCS SaaS.

Verificare la configurazione di logging API su GitHub. È l'unica piattaforma tra le quattro che supporta questa capability, ma richiede attivazione esplicita. Senza questa impostazione, le chiamate programmatiche restano fuori dalla visibilità operativa.

Valutare lo streaming degli audit event per GitLab. Il tier Ultimate è necessario per la copertura completa. Organizzazioni con piani inferiori operano con un buco strutturale su operazioni Git, non recuperabile retroattivamente.

Mappare la propria nomenclatura eventi su quella del poster. Il detection engineering deve tradurre le regole MITRE ATT&CK in query specifiche per piattaforma, non assumere equivalenze semantiche tra log con nomi simili.

Distinguere tra Bitbucket Cloud e Bitbucket Data Center nei playbook. I meccanismi di audit logging sono fondamentalmente diversi: un runbook valido per un'istanza non è trasferibile all'altra senza revisione.

Perché il problema non si risolve con più strumenti

La pubblicazione del poster DFIR mette a fuoco una tensione strutturale del cloud enterprise: la centralizzazione operativa su SaaS non coincide con centralizzazione della visibilità. Le piattaforme VCS sono infrastrutture critiche — ospitano codice, pipeline, segreti e configurazioni — ma i loro log audit sono progettati per conformità e troubleshooting, non per forensics ad alta fedeltà. La differenza è nella granularità, nella retention e nella coerenza cross-platform.

Il lavoro di Wiz CIRT non propone una tecnologia nuova: organizza ciò che esiste, evidenziando dove esiste meno di quanto i team di sicurezza presumano. Il rischio non è l'ignoranza dei log, ma la fiducia nella loro completezza. Quando un attaccante clona centinaia di repository e i log scadono prima che l'allarme suoni, l'indagine non è difficile: è impossibile. La credential rotation di massa diventa allora un atto di disperazione, non di precisione.

Domande frequenti

Il poster è uno strumento open source?
No. È prodotto dal Wiz CIRT, il team di ricerca e risposta agli incidenti di Wiz, come risorsa commerciale per clienti e professionisti della sicurezza.

Perché GitLab non salva le operazioni Git per default?
Secondo il dossier, la scelta architetturale è quella di non scriverle nel database in configurazione standard. Lo streaming al tier Ultimate è il percorso documentato per la raccolta completa.

Azure DevOps è meno sicuro delle altre piattaforme?
Il brief non permette confronti di sicurezza assoluta. I dati disponibili indicano che Azure DevOps non supporta il logging delle richieste API, a differenza di GitHub con configurazione esplicita; su altri aspetti della visibilità, il dossier non fornisce informazioni comparative.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. wiz.io
  2. docs.gitlab.com