// TOM'S HARDWARE ITALIA — MONDO
GitHub Threat Detector: 22 regole contro gli attacchi supply chain
Gli eventi che GitHub produce durante la normale attività dei repository possono diventare segnali per individuare un attacco alla supply chain prima che il codice compromesso raggiunga i sistemi tradizionali di protezione degli endpoint. Da questa idea nasce GitHub Threat Detector, un rilevatore open source che analizza il comportamento osservabile nelle pipeline di sviluppo. La prima versione comprende 22 regole considerate pronte per ambienti di produzione, altre 12 in fase beta e correlazioni capaci di combinare più anomalie.
Il progetto è stato presentato nei briefing di Black Hat USA 2026 da Yossi Weizman, ricercatore di Microsoft, e Mor Weinberger, affiliato alla società di sicurezza Echo. L'approccio riprende la logica di un EDR: invece di osservare processi e file su un computer, ricostruisce ciò che accade nel tempo all'interno dei repository, nelle automazioni e nelle operazioni eseguite dagli account.
Per ottenere questa telemetria, GitHub Threat Detector combina tre fonti. I webhook acquisiscono automaticamente gli eventi selezionati, le API forniscono ulteriori informazioni sull'attività e l'ispezione diretta della cronologia Git permette di verificare modifiche e sequenze di azioni. La documentazione ufficiale dei webhook GitHub elenca gli eventi e i payload disponibili, che costituiscono una parte del flusso analizzato dal sistema.
Le regole cercano comportamenti già osservati in campagne e compromissioni reali. Tra questi rientrano identità dei commit contraffatte, tag alterati, abuso dei workflow di GitHub Actions, sottrazione di token OIDC e tentativi di cancellare le tracce. Weizman e Weinberger hanno ricavato questi schemi dalla campagna Shai-Hulud, dagli attacchi che hanno coinvolto Trivy e da Megalodon, operazione che ha interessato migliaia di repository.
Anche l'audit log delle organizzazioni fornisce dati utilizzabili per ricostruire una sequenza sospetta. GitHub registra l'attore, l'azione eseguita, il repository coinvolto, la posizione e il momento dell'evento; queste informazioni possono essere consultate, esportate o interrogate tramite API, come descritto nella documentazione dell'audit log. Collegando più eventi, il rilevatore può distinguere un'operazione isolata da un comportamento articolato su più passaggi.
Il progetto tratta quindi log ed eventi già disponibili come una sorgente operativa per segnalare compromissioni della pipeline, anziché lasciarli confinati alle analisi successive a un incidente. Il catalogo iniziale offre 22 rilevamenti dichiarati production-ready, mentre 12 regole restano per ora in beta. Il perimetro descritto riguarda l'attività osservabile su GitHub e nella cronologia Git: l'efficacia delle correlazioni dipende dai segnali raccolti e dai comportamenti coperti dalle regole pubblicate.
Aggiungi Tom's Hardware alle tue fonti preferite su Google