En bref. Exportez le journal d'audit en JSON (et, si vous les avez, les événements Git et les archives de logs Actions), puis déposez le tout dans l'outil GitHub Forensics. L'analyse s'exécute dans votre navigateur, rien n'est envoyé. Lisez d'abord le verdict et ses notes de couverture, triez ensuite les constats par gravité, pivotez sur le jeton ou l'IP suspects, relisez la chronologie et déroulez la liste de remédiation. Comptez environ 30 minutes pour une première passe sur une organisation classique.

Voici le mode d'emploi concret de l'analyseur de ce site. Il suppose que vous avez déjà les fichiers ; sinon, commencez par exporter le journal d'audit GitHub.

Étape 1 : rassembler les exports

Le minimum, c'est le journal d'audit de l'organisation en JSON. Chaque source supplémentaire supprime un angle mort :

Vous ajoutez	Vous débloquez
L'affichage des adresses IP, activé avant l'export	Les détections de nouvelle IP et de nouveau pays par jeton et par acteur
Les événements Git (`include=all`, export de l'entreprise ou streaming)	La détection du clonage massif (rafales de `git.clone`)
Les archives de logs des exécutions suspectes	Les secrets encodés ou envoyés par une étape de workflow
Les alertes de secret scanning (JSON de l'API REST)	Les identifiants fuités et l'étape suivante côté cloud

Exportez aussi quelques semaines avant l'intrusion supposée. Les règles « nouveau pays » et « nouvelle IP » comparent chaque jeton à son propre historique, et il leur faut au moins 24 heures d'historique.

Étape 2 : déposer les fichiers

Déposez des fichiers isolés, des dossiers entiers ou des ZIP (jusqu'à trois niveaux d'imbrication) sur l'outil. Le format est reconnu d'après le contenu, pas d'après le nom du fichier. L'outil accepte les exports JSON / CSV de l'interface, les pages de l'API REST, les fichiers de streaming .json.log.gz, l'export des événements Git export-*.json.gz, les ZIP « Download log archive » d'Actions et le JSON des alertes de secret scanning.

Les fichiers sont lus par blocs de 4 Mo et le gzip est décompressé à la volée : des dumps de streaming de plusieurs gigaoctets passent donc sans tout charger en mémoire. Chaque fichier ignoré est listé avec son motif (« format non reconnu », « le fichier se termine au milieu d'un enregistrement », « enregistrements qui ne sont pas des événements d'audit »). Lisez cette liste : un export tronqué explique souvent un résultat trop calme.

Pour voir le rendu avant d'utiliser vos propres données, cliquez sur Essayer un exemple. Cela charge un incident fictif clairement signalé comme tel, analysé dans le cas fictif northwind-labs.

Étape 3 : lire le verdict et les notes de couverture

Le bandeau affiche l'un de trois verdicts. La politique est publiée dans le fichier de règles et sur la page de l'outil :

Compromis : au moins un constat critique (par exemple une étape de workflow qui encode des secrets), ou au moins deux règles distinctes de gravité élevée sur le même acteur, le même jeton ou la même IP.
Activité suspecte : au moins un constat de gravité élevée ou moyenne.
Aucun signe de compromission : rien au-dessus de faible.

Sous le bandeau, Pourquoi liste les constats qui ont déterminé le verdict, et la période couverte indique le premier et le dernier horodatage. Vérifiez qu'elle inclut bien la fenêtre qui vous intéresse.

Lisez ensuite les notes de couverture. Elles disent ce que le verdict n'a pas pu voir : pas d'adresses IP, pas d'événements Git, pas de métadonnées de jeton (hashed_token), pas d'événements d'exécution de workflow, ou un tableau tronqué. Un verdict sans signe de compromission accompagné de « Aucun événement Git » signifie que le clonage massif n'a pas été vérifié, pas qu'il n'a pas eu lieu.

Étape 4 : trier les constats

Les constats sont classés par gravité. Chacun affiche la règle, ses techniques ATT&CK, la première et la dernière occurrence, le nombre d'événements (et le nombre de valeurs distinctes pour les règles à seuil), les entités en cause et les lignes de preuve.

Triez une question à la fois :

L'acteur est-il attendu ? Un propriétaire qui modifie la protection de branche en journée, c'est normal. La même modification faite avec un jeton depuis un VPS à 3 h du matin ne l'est pas.
L'identifiant est-il l'habituel ? Comparez hashed_token, programmatic_access_type et user_agent avec les autres événements de l'acteur. Un curl/8.x là où le développeur utilise d'ordinaire git/2.x est un signal fort.
Cela recoupe-t-il d'autres constats ? Un token-new-ip isolé, c'est souvent un portable sur le Wi-Fi d'un hôtel. Le même jeton qui déclenche aussi git-clone-burst, c'est un incident.

Certaines règles sont bruyantes par nature. workflow-new-branch se déclenche à la première exécution de chaque branche de fonctionnalité, et actions-secret-created sur le travail de CI courant. C'est pour cela qu'elles sont classées faibles. Elles comptent quand elles impliquent un acteur déjà signalé par d'autres constats.

Étape 5 : pivoter sur les entités

L'onglet Entités liste les acteurs, les jetons (par empreinte), les adresses IP, les dépôts, les workflows, les runners et les applications. Cliquez sur Voir les événements sur n'importe lequel pour filtrer le tableau des événements.

Le pivot le plus utile est le jeton. Une fois qu'un hashed_token est jugé volé, chaque événement qui le porte est une activité de l'attaquant jusqu'à preuve du contraire, y compris ceux qui n'ont déclenché aucune règle. Pivotez ensuite sur l'IP de l'attaquant pour trouver d'autres identifiants utilisés depuis le même endroit. Le playbook du jeton fuité montre comment rapprocher une empreinte d'un vrai jeton.

L'onglet Événements permet la recherche en texte libre (action, acteur, IP, dépôt, n'importe quel champ), le filtrage par catégorie, un interrupteur Signalés uniquement et l'affichage en UTC ou en heure locale. Cliquez sur une ligne pour voir tous ses champs et les règles qui la citent.

Étape 6 : lire la chronologie, remédier, exporter

La Chronologie en mode « Constats uniquement » donne le récit de l'incident dans l'ordre. Les lignes agrégées (par exemple 38 clones) la gardent lisible. Désactivez le filtre pour voir les événements de contexte autour : changements de membres, mises à jour SAML, enregistrements de runners.

L'onglet Remédiation est une liste classée par urgence, dérivée des règles qui se sont déclenchées. Elle commence toujours par la préservation des preuves, puis couvre la révocation des jetons, le renouvellement des secrets Actions et des clés cloud, la suppression de la persistance et la restauration des protections. Les cases cochées ne sont conservées que sur la page.

Enfin, exportez :

Événements CSV : les événements qui correspondent à vos filtres actuels (filtrez d'abord, ou retirez les filtres pour tout exporter). Les cellules qui commencent par =, +, - ou @ sont échappées pour éviter l'injection de formules.
Constats CSV : une ligne par constat.
Rapport JSON : le résultat complet, pour votre dossier ou un autre outil.

Ce que l'outil ne fera pas à votre place

Les règles sont des heuristiques à seuils fixes : 10 dépôts distincts clonés en une heure environ depuis une même IP, et 24 heures d'historique pour les nouvelles IP et les nouveaux pays. Elles sont calibrées pour une organisation de taille moyenne, pas pour la vôtre. Le journal d'audit ne contient pas non plus le contenu des fichiers : un workflow modifié se déduit de ses exécutions, pas du diff. Lisez les limites du journal d'audit GitHub avant d'écrire « aucune preuve de compromission » dans un rapport.

Analyse du journal d'audit GitHub, pas à pas