Quand un plugin Jenkins devient une porte arrière, l'affaire Checkmark expose les identifiants et la sécurité de la chaîne d'approvisionnement

Publié 5 min de lectura 47 lecture

Pendant le week-end Checkmarx a confirmé qu'une version malveillante de son plugin Jenkins pour Application Security Testing (AST) a été publiée dans le marché Jenkins, en plus d'une chaîne d'incidents qui inclut déjà des fuites et des artefacts filetés dans GitHub, Docker et les vendeurs d'extension. L'entreprise connue sous le nom de TeamPCP a profité d'identifications obtenues dans une lacune précédente - liée à l'incident contre Trivy - pour insérer du code avec la capacité de voler des identifications dans divers outils de développement, y compris une version du plugin Checkmark téléchargé en dehors de son canal officiel. La note officielle de l'entreprise est disponible avec les détails initiaux et les recommandations dans sa publication publique: Mise à jour de sécurité de Checkmark.

Jenkins est un pilier dans de nombreux pipelines CI / CD et tout composant qui est intégré dans votre workflow a accès, dans une plus ou moins grande mesure, aux secrets, à la construction d'artefacts et aux références de déploiement. Un plugin rembourré peut non seulement exfiltré des jetons et des identifiants stockés dans l'environnement de construction, mais aussi agir comme vecteur pour les mouvements latéraux et la persistance dans l'infrastructure de développement. La version suspecte publiée a été identifiée comme étant 2026.5.09 et, selon Checkmarx, n'a pas suivi la procédure de libération normale (sans étiquette git ou version officielle), tandis que la société recommande de maintenir, dans la mesure du possible, la version sécurisée 2.0.13-829.vc72453fa _ 1c16 ou plus tôt jusqu'à ce que l'assainissement complet soit confirmé. Le plugin officiel dans le dépôt Jenkins peut être examiné ici: Checkmarx AST plugin.

Quand un plugin Jenkins devient une porte arrière, l'affaire Checkmark expose les identifiants et la sécurité de la chaîne d'approvisionnement
Image générée avec IA.

Au-delà de l'impact, cet incident met en évidence deux points critiques : la fragilité des références persistantes dans les dépôts et la nécessité de valider chaque artefact qui entre dans le pipeline. Lorsqu'un titre est filtré dans un lien de la chaîne d'approvisionnement, l'attaquant peut pivoter plusieurs vecteurs (repos, images, extensions) et maintenir l'accès pendant de longues périodes si les secrets ne sont pas tournés et révoqués. Le message laissé par les agresseurs - accusant le manque de rotation des secrets - est un rappel brut: rotations périodiques et gestion avec des politiques d'expiration sont de base, mais souvent négligé contrôle.

Si vous gérez Jenkins ou intégrez le plugin engagé, supposez que tout secret qui a traversé les travaux peut être compromis. Les mesures immédiates devraient comprendre l'identification et la quarantaine des cas qui ont installé la version 2026. 5.09, tournant tous les secrets et les lettres d'identité exposés, révoquant les jetons et les clés associés aux dépôts et aux systèmes CI / CD, et cherchant des preuves d'exfiltration ou de persistance. Checkmark a publié des indicateurs de compromis (IoCs) et des dispositifs malveillants que les équipes d'intervention peuvent utiliser pour enquêter; il examine son portail officiel de sécurité et les communications pour obtenir ces échantillons et signatures.

Quand un plugin Jenkins devient une porte arrière, l'affaire Checkmark expose les identifiants et la sécurité de la chaîne d'approvisionnement
Image générée avec IA.

Dans la partie opérationnelle, il convient d'examiner les pipelines à la recherche d'accès inhabituels, de commandes ou de téléchargements externes exécutés par des emplois, et de vérifier les registres des systèmes GitHub, Docker Registry et packaging. La révocation et la réémission de lettres de créance avec plus de restrictions (étendue limitée, courte échéance), le remplacement de lettres de créance persistantes par des mécanismes d'identité fédérés temporaires (p. ex., le cas échéant) et le renforcement de la ségrégation des environnements sont des mesures immédiates visant à réduire le rayon d'explosion. De plus, la vérification de l'intégrité des artefacts (signatures, somme de contrôle, bâtiments reproductibles) et la préférence pour les artefacts signés dans le pipeline rendent difficile l'acceptation automatique des colis non autorisés.

À moyen et à long terme, les organisations doivent améliorer leur hygiène de sécurité dans la chaîne d'approvisionnement : mise en œuvre systématique de politiques pour les jetons de machine dans les dépôts, blocage des pouvoirs dans les dossiers, examen des permis dans les comptes de service, et audits réguliers à des tiers et aux canaux de publication des plugins et paquets. Il est également temps de remettre en question les processus de développement qui permettent la publication d'appareils critiques sans examen de sécurité indépendant ni contrôle de signature et de traçabilité. Pour suivre la piste technique de l'engagement des chercheurs indépendants, les preuves publiques partagées par les analystes et les responsables de la divulgation peuvent être consultées, y compris le fil d'information documenté par le chercheur qui a identifié l'activité à GitHub : Adnan Khan en X.

Enfin, bien que Checkmark veille à ce que ses dépôts ne contiennent pas de données client et que l'environnement de développement soit séparé de l'environnement de production, les organisations doivent agir comme si elles étaient touchées si elles ont installé le plugin engagé et réponse complète: détection, confinement, éradication et apprentissage. La chaîne d'approvisionnement des logiciels est maintenant un objectif privilégié; réduire l'exposition exige à la fois des changements techniques et une discipline opérationnelle continue.

Couverture

Autres

Plus de nouvelles sur le même sujet.