Changer ses secrets après un incident ne suffit pas sans inventaire complet
Ce qu’il faut retenir
Révoquer un secret sans savoir combien de copies circulent revient à changer la serrure en laissant un double dehors.
La rotation des secrets n’est efficace que si elle est exhaustive. Cela suppose un inventaire préalable : quels secrets existent, où sont-ils stockés, quels services les consomment.
Sans cet inventaire, la réponse à incident est borgne — on croit avoir corrigé, on n’a que partiellement contenu.
Illustrations
Cas 1 : CanisterWorm — Aqua Security (2026)
Ce qui s’est passé : Après la compromission CanisterWorm, Aqua Security a révoqué ses jetons GitHub. Les attaquants ont continué à opérer. Aqua a révoqué une deuxième fois. Des clés actives avaient été oubliées à chaque rotation — des jetons qui circulaient dans des environnements non recensés.
Pourquoi c’est arrivé : Aucun inventaire centralisé des secrets en circulation. La rotation a ciblé les jetons connus, pas tous les jetons existants.
Conséquences : La fenêtre de compromission s’est étendue inutilement. L’attaquant a maintenu son accès malgré deux tentatives de remédiation.
Articles liés
- TeamPCP deploys worm via npm Trivy compromise — angle : cas concret de rotation incomplète pendant un incident actif