Violation de données dans la chaîne d’approvisionnement GitHub de Checkmarx en 2026

La page de synthèse de Checkmarx consacrée à l’incident, mise à jour le 6 juillet, indique que l’enquête menée avec l’appui de Mandiant et les travaux de renforcement de la sécurité étaient achevés, et que l’incident était entièrement maîtrisé. La chronologie officielle relie directement l’accès initial, les artefacts malveillants, l’exfiltration du 30 mars, la publication du 25 avril et les mesures prises par la suite, en les présentant comme des éléments d’un même incident.

Dans un article indépendant publié le 28 avril, BleepingComputer a rapporté que Checkmarx avait confirmé que les données publiées appartenaient à l’entreprise et provenaient d’un dépôt GitHub privé. Le média indiquait avoir constaté la présence d’un ensemble de données de 96 GB, sans en avoir examiné le contenu.

Selon Checkmarx, l’incident trouve son origine dans l’attaque de la chaîne d’approvisionnement de Trivy attribuée à TeamPCP. Le 19 mars, des composants Trivy malveillants ont collecté des identifiants auprès d’utilisateurs en aval, puis les attaquants ont utilisé ces identifiants pour accéder à l’environnement GitHub de Checkmarx. L’entreprise a détecté un accès non autorisé le 23 mars, mais des identifiants compromis ou conservés en cache ont permis des activités ultérieures.

L’accès à GitHub a permis aux attaquants d’interagir avec les dépôts et de publier du code malveillant par certains canaux de distribution externes. Checkmarx a révoqué les autorisations de publication, renouvelé les identifiants, bloqué les accès sortants vers l’infrastructure des attaquants et verrouillé les dépôts concernés. L’entreprise a informé les forces de l’ordre et les autorités compétentes, et a fait appel à Mandiant pour l’assister dans l’analyse forensique.

La catégorie de données confirmée est celle des données exfiltrées des dépôts GitHub de Checkmarx. L’entreprise n’a pas rendu public d’inventaire détaillé répartissant ces contenus entre code source, configuration, documentation, identifiants ou autres fichiers. L’exfiltration du 30 mars et la publication du 25 avril sont confirmées, mais la dernière mise à jour officielle n’a précisé ni la taille de l’ensemble de données ni les catégories de fichiers qu’il contenait.

Checkmarx a indiqué que ses dépôts GitHub sont distincts de l’environnement de production des clients et que les données clients n’y sont pas stockées dans le cadre de ses pratiques habituelles. L’examen achevé par Mandiant a confirmé que les acteurs malveillants n’avaient pas accédé à Checkmarx One SaaS et que l’environnement de production AWS n’avait pas été touché. Le code source des clients, les résultats d’analyse et les données SaaS ne figurent donc pas parmi les catégories de données de cette fiche.

La synthèse officielle indique que des actions GitHub Actions malveillantes et des extensions VS Code malveillantes sur Open VSX ont été publiées pendant la vague de mars. Une deuxième vague, le 22 avril, a touché des versions identifiées des images Docker de Checkmarx KICS, de Checkmarx AST GitHub Action et des extensions AST Results et Developer Assist sur VS Code et Open VSX. Les versions reconnues comme sûres et déjà publiées n’ont pas été écrasées, et le risque était limité à des fenêtres de publication définies.

Le 9 mai, un compte de service externe a publié une version modifiée du plugin Checkmarx Jenkins AST sur Jenkins Marketplace; l’entreprise a fourni des versions saines et leurs empreintes de hachage. Ces répercussions sur la chaîne d’approvisionnement signifient que des jetons, des clés, des fichiers de configuration ou d’autres secrets ont pu être volés dans des environnements de développement tiers ayant exécuté les artefacts concernés. Checkmarx n’a pas publié de total vérifié des téléchargements ou des environnements en aval effectivement compromis.

Les conclusions finales de Mandiant ont limité l’activité des acteurs malveillants à l’environnement GitHub de Checkmarx, à un nombre restreint de postes de travail infectés et à une reconnaissance initiale portant sur les identifiants AWS de Checkmarx. L’environnement de production AWS n’a pas été touché, aucun accès à Checkmarx One SaaS n’a eu lieu et le code malveillant a été supprimé de l’environnement GitHub. La dernière activité observée au sein de Checkmarx remonte au 22 avril.

Le produit CxSAST installé sur site et son programme d’installation n’ont pas été compromis; le risque concernait des composants distribués par des canaux externes. Les organisations ayant exécuté un artefact concerné pendant sa fenêtre de publication devaient néanmoins examiner leurs propres environnements, rechercher des indicateurs de compromission et renouveler les secrets en cas de suspicion de compromission. Cette fiche confirme la violation de données de l’entreprise Checkmarx, mais n’affirme pas que tous ses clients ont automatiquement subi une violation de données.

La date de l’incident repose sur la première activité technique vérifiable à partir de sources publiques. Les données dont le vol est vérifié sont des données de dépôts GitHub. Les artefacts de développement malveillants sont présentés comme les répercussions en aval, sur la chaîne d’approvisionnement, de ce même accès initial.

L’organisation n’a pas publié de total vérifiable de personnes concernées ou d’enregistrements. L’absence de chiffres publiés ne signifie pas que l’incident n’a eu aucun impact, mais que les sources publiques ne fournissent pas de total fiable. L’attribution à LAPSUS$ et la taille de 96 GB de l’ensemble de données figurent dans des articles indépendants, mais Checkmarx ne les a pas retenues pour établir une catégorie de données définitive ou un nombre total de personnes; elles sont donc exclues des champs numériques. Les données de production des clients et Checkmarx One SaaS restent en dehors du périmètre confirmé.