Le CERT-FR décrit une campagne TeamPCP qui vise la chaîne d’approvisionnement logicielle et les secrets présents dans NPM, PyPI, GitHub et les environnements de développement. Selon du bulletin CERT-FR sur TeamPCP.
Les attaques observées depuis septembre 2025 et relancées à partir de la fin avril 2026 cherchent des jetons, clés SSH, secrets Kubernetes, accès Claude Code, Azure, AWS et bases de données. La seconde source rapporte également du rapport BleepingComputer sur TeamPCP.
Le risque ne s’arrête pas au poste qui installe un paquet malveillant. Un jeton de publication ou de CI peut permettre de contaminer le projet suivant et de déplacer l’incident vers les clients.
Pour relier cette analyse à la pratique, consultez la sécurité de la chaîne d’approvisionnement logicielle et la surveillance des fuites de données et la détection des menaces d’identité.
Le signal confirmé est le suivant : TeamPCP est actif dans les attaques de chaîne d’approvisionnement décrites par le CERT-FR. Il faut séparer ce fait des hypothèses. Pour inventaire des dépôts, la question utile n’est pas de savoir si le titre paraît alarmant. Il faut déterminer quel actif est concerné, quel chemin est accessible et quelle personne peut le modifier. Cette distinction garde la réponse précise tout en donnant au risque le niveau d’urgence nécessaire.
Écrivez la décision avec des mots opérationnels. Indiquez ce qui est connu, ce qui reste à vérifier, les systèmes concernés et la date du prochain contrôle. Une note courte est plus facile à utiliser qu’un avis recopié. Elle donne aussi aux équipes sécurité, réseau, identité et exploitation le même point de départ quand le sujet traverse plusieurs responsabilités.
Une réponse avec un responsable, une échéance et un emplacement de preuve est plus utile qu’une étiquette de gravité. Reliez chaque action à un actif ou à une identité. Si la réponse n’est pas encore connue, notez l’incertitude et attribuez la vérification. L’état inconnu doit rester visible jusqu’à sa résolution.
Les sources publiques décrivent le fait suivant : les cibles incluent NPM, PyPI et GitHub. Elles ne prouvent pas que chaque installation est vulnérable ni que chaque organisation concernée a été compromise. Pour paquets NPM, cette limite est importante : il faut éviter à la fois la panique et l’attente. Utilisez la source pour définir les premières vérifications, puis les données internes pour établir la situation locale.
Séparez quatre affirmations dans le dossier : le produit ou service est présent, la version ou la configuration est concernée, le chemin était accessible et une activité suspecte apparaît dans les journaux. Ces points peuvent relever d’équipes différentes et avoir des niveaux de confiance différents. Les réunir dans un seul oui ou non rend le suivi moins fiable.
Quand une source corrige ou précise une information, mettez à jour le dossier sans effacer la décision initiale. La réponse doit montrer pourquoi l’organisation a corrigé, isolé ou surveillé un actif à ce moment-là. C’est essentiel lorsque l’exploitation est annoncée puis précisée, ou lorsqu’une campagne est évoquée sans liste confirmée de victimes.
Commencez par les actifs qui peuvent exposer paquets PyPI : serveurs de production, services en bordure, postes de développement, ressources cloud, équipements et systèmes gérés par des fournisseurs. Le fait confirmé est le suivant : la campagne cherche des secrets GitHub, NPM, SSH et Kubernetes. Reliez-le aux noms d’hôte, adresses, comptes cloud, propriétaires et environnements. Le seul nom du produit ne suffit pas, car plusieurs équipes peuvent utiliser des versions différentes.
Notez le système, la version, le chemin de déploiement, l’adresse publique, le service à l’écoute, la méthode d’authentification et la dernière activité observée. Pour le cloud, ajoutez le compte, la région, le groupe de sécurité et le rôle qui peut modifier la ressource. Pour un système géré par un tiers, indiquez le responsable du contrat et la preuve demandée au fournisseur.
Le registre doit avoir des états explicites : concerné confirmé, corrigé confirmé, non concerné, impossible à vérifier et inconnu. Ajoutez l’heure de l’observation et sa source. L’exposition change après une modification de route, de DNS, de pare-feu ou de déploiement. Un état qui ne peut pas être actualisé devient trompeur lors de la prochaine alerte.
Donnez la priorité à l’instance qui combine une condition connue, un chemin accessible et un accès métier important. Pour jetons de publication, les recherches mentionnent aussi les accès Claude Code, Azure, AWS et aux bases de données justifie de vérifier d’abord la route externe. Une faille sévère sur un système de test isolé peut suivre le calendrier normal. Une faiblesse moins visible sur une passerelle, une identité ou une base de données peut exiger une modification immédiate.
Vérifiez le DNS public, les groupes de sécurité cloud, les proxies, les routes VPN et les règles de pare-feu. Comparez les observations externes avec l’inventaire interne. Si l’adresse correspond à un ancien service ou à un prestataire, gardez l’élément ouvert jusqu’à l’identification du propriétaire. Un port ouvert indique un chemin à examiner, pas une compromission prouvée.
Utilisez une phrase de priorité compréhensible par une autre équipe : actif concerné, origine accessible, rôle métier, activité observée, contrôle immédiat et échéance. Le gestionnaire des changements dispose ainsi du contexte nécessaire pour approuver une mesure ciblée. Les analystes savent aussi quels journaux préserver avant une reconstruction ou une rotation de clé.
Si le service concerné n’a pas besoin d’être public, retirez ou restreignez ce chemin pendant la préparation de la correction. S’il est nécessaire, autorisez uniquement les sources, protocoles et identités utiles. Pour workflows GitHub, la mesure temporaire doit traiter directement le groupe est associé à des attaques contre des paquets et des environnements de développement, sans créer une panne générale qui empêcherait de vérifier la réduction de l’exposition.
Utilisez une demande de changement qui décrit exactement la règle, la route, le compte ou la fonction modifiée. Indiquez l’approbateur, le test du trafic légitime et la date d’expiration. Demandez au propriétaire du service ce qui doit continuer à fonctionner. Un blocage temporaire sans plan de correction devient souvent une exception oubliée.
Le confinement réduit la possibilité d’accès ; il ne corrige pas la condition initiale. Un pair de confiance compromis, un jeton volé, une route privée ou une nouvelle règle peut rouvrir le chemin. L’actif doit donc rester dans la file jusqu’à la correction et jusqu’au contrôle de l’état interne et externe.
Fermez le dossier seulement lorsque l’état logiciel ou de configuration correspond à l’état de reachabilité. Pour runners CI, le fait que un jeton CI oublié peut permettre un accès après la première rotation des secrets explique le contrôle à réaliser. Vérifiez la version installée, le processus actif, le pare-feu ou le contrôle d’identité, puis l’observation externe. Un ticket « corrigé » ne constitue pas une preuve si le mauvais hôte a été traité ou si le service n’a pas redémarré.
Conservez l’identifiant de la mise à jour, l’heure d’installation, le redémarrage, la modification de configuration et le résultat du test. Si un scanner fournit une version, comparez-la aux données de l’endpoint ou de la plateforme. Si une vérification externe signale un service, comparez-la à la cartographie prévue. En cas de désaccord, classez l’actif comme inconnu.
Répétez le contrôle après un nouveau déploiement, une modification réseau ou une rotation de secret. La correction est un état qui doit rester vrai, pas un événement isolé. Conservez l’exposition initiale et les preuves avant-après dans le même dossier pour expliquer ce qui a changé et quel risque résiduel a été accepté.
Un actif concerné ou exposé mérite une revue limitée dans le temps même si aucune compromission n’est confirmée. Définissez la période entre la première exposition connue ou le premier déploiement vulnérable et le confinement. Pour clés SSH, les paquets compromis peuvent exécuter du code dans un poste ou un runner de build indique ce qu’il faut rechercher, mais l’analyse doit aussi couvrir l’identité, les processus et les connexions sortantes.
Exportez les journaux du service, de l’hôte, du pare-feu, du fournisseur d’identité, du plan de contrôle cloud et de l’endpoint avant l’expiration de la conservation. Gardez l’heure, le fuseau, la source, le compte, l’action et le résultat. Examinez les actions réussies et les échecs. Une connexion réussie ou un changement de configuration peut compter davantage que des scans bloqués.
Ne transformez pas une première recherche vide en preuve d’absence d’accès. Précisez les systèmes disponibles, les journaux manquants et la période couverte. Si une séquence suspecte apparaît, préservez les données, isolez l’actif selon le plan de réponse et étendez l’analyse aux systèmes et identités qu’il pouvait atteindre.
La faiblesse ou l’exposition initiale peut ne pas demander de mot de passe, mais la suite touche souvent des identifiants, des jetons ou des secrets de configuration. Pour secrets Kubernetes, demandez-vous si la vérification doit couvrir les dépendances directes et transitives peut donner un chemin vers un autre système. Examinez les comptes locaux, comptes de service, clés API, rôles cloud, clés SSH, certificats et secrets des fichiers ou chaînes de déploiement.
Faites la rotation après avoir identifié l’usage du secret et le mode de diffusion de la nouvelle valeur. Révoquez les sessions et jetons qui peuvent survivre au changement de mot de passe. Séparez les identifiants d’urgence des comptes quotidiens. Après la rotation, examinez les usages privilégiés, car un attaquant a peut-être déjà copié un secret ou créé un autre accès.
La fiche d’identité doit préciser le propriétaire, l’usage, le périmètre, la dernière utilisation, le stockage et la procédure de récupération. Un secret sans propriétaire est difficile à changer. Un secret trop puissant augmente l’impact d’un hôte exposé. Réduisez les accès inutiles dans le travail correctif, après avoir conservé les preuves nécessaires.
Les équipes sécurité ne possèdent pas toujours les systèmes liés à accès cloud. Le fait confirmé est TeamPCP est actif dans les attaques de chaîne d’approvisionnement décrites par le CERT-FR, mais la réponse locale peut relever d’un fournisseur, d’une équipe cloud, d’une application ou d’un opérateur industriel. Envoyez une demande précise : identité de l’actif, version concernée, exposition, preuve de correction, journaux disponibles, contrôle temporaire et contact incident.
Demandez au fournisseur d’identifier le tenant, l’équipement, le compte ou le paquet vérifié. Demandez les horaires et la méthode. La responsabilité contractuelle ne supprime pas l’impact métier. Si la preuve manque, classez l’actif comme inconnu et appliquez la restriction réseau ou d’identité raisonnable jusqu’à la confirmation du propriétaire.
Gardez une communication factuelle et réversible. N’envoyez pas de journaux sensibles ou de secrets via un canal non approuvé. Notez qui a autorisé l’isolation, qui a confirmé le retour du service et qui a accepté le risque restant. Ce dossier peut ensuite soutenir une notification, une revue ou un exercice de réponse.
Les indicateurs liés à environnements de développement sont utiles, mais une adresse, un nom de fichier ou un hash ne constitue pas une règle de détection complète. Commencez par la séquence suggérée par les cibles incluent NPM, PyPI et GitHub : création de processus, persistance, action administrative, usage de jeton, accès aux données ou connexion sortante. Comparez l’événement au rôle normal de l’actif.
Recherchez sur les hôtes et les identités la même source, le même compte, le même processus, paquet, domaine ou appel cloud. Cherchez une activité brève suivie d’une période calme. L’infrastructure peut changer ou les fichiers peuvent disparaître, mais les journaux d’identité et du plan de contrôle peuvent rester. Reliez les signaux endpoint, réseau et identité.
Documentez la requête, les sources, la période et le résultat. Un résultat négatif reproductible est utile, car il montre ce qui a été vérifié. Un résultat positif fait passer le sujet du traitement de vulnérabilité à la réponse à incident. Une donnée indisponible doit devenir une action, pas une conclusion rassurante.
Le rétablissement doit restaurer le service et supprimer la condition qui a créé l’exposition. Pour reconstruction des dépendances, le fait connu est la campagne cherche des secrets GitHub, NPM, SSH et Kubernetes. Confirmez l’état corrigé, testez le chemin métier, examinez les changements privilégiés et vérifiez que la surveillance fonctionne avant de revenir à l’usage normal.
Une reconstruction peut être nécessaire si l’intégrité ne peut pas être établie, mais elle ne doit pas effacer l’équipement ou les journaux avant la collecte. Après une rotation de clé ou de jeton, testez chaque dépendance et retirez l’ancienne valeur. Après une règle réseau temporaire, testez le parcours légitime et supprimez l’exception arrivée à échéance.
Le rétablissement doit aussi réparer l’inventaire. Actualisez le propriétaire, la version, l’adresse publique, les dépendances, la source de journal et la date de revue. Notez ce qui a empêché une réponse plus rapide. Le but est de réduire le délai lors de la prochaine alerte, pas de consigner une réussite ponctuelle.
Ne comptez pas seulement les tickets fermés. Pour rotation et suivi des secrets, mesurez le délai d’identification des actifs, le délai de réduction des chemins accessibles, le délai de vérification, le nombre de propriétaires inconnus, le nombre d’instances publiques encore ouvertes et la disponibilité des journaux. les recherches mentionnent aussi les accès Claude Code, Azure, AWS et aux bases de données explique pourquoi ces mesures doivent être visibles par les propriétaires de services.
Un tableau de suivi doit distinguer concerné, exposé, activité observée et corrigé vérifié. Ce sont des états différents. Affichez le dossier le plus ancien, son propriétaire, l’action suivante et la preuve manquante. Un nombre sans état peut donner une impression de progrès alors que l’actif le plus important attend toujours.
Utilisez les résultats pour améliorer le processus. Ajoutez les champs d’inventaire manquants, raccourcissez le passage entre l’alerte et le propriétaire, testez les changements urgents et répétez les rotations de secret. Les indicateurs doivent conduire à une décision : accepter, financer, corriger ou supprimer le risque.
Le dossier final doit permettre à une autre personne de reproduire la décision concernant rotation et suivi des secrets. Commencez par la date de la source, le produit, la liste des actifs et la preuve qui relie le signal public à l’environnement. Conservez les exports et résultats avec leur horaire, sans considérer une capture isolée comme un contrôle suffisant.
Pour les dépôts, paquets, pipelines CI et secrets des équipes de développement, décrivez le chemin contrôlé : DNS, adresse, port, route, compte, rôle, paquet ou endpoint. Indiquez aussi ce qui n’a pas été vérifié. Cette précision rend l’incertitude visible et évite de croire qu’un contrôle d’une adresse couvrait tous les tenants, serveurs, runners ou fournisseurs.
Reliez le résultat technique à une décision métier. Expliquez si l’actif a été isolé, corrigé, reconstruit, surveillé ou accepté pour une période définie. Ajoutez le responsable, l’approbateur, la prochaine revue et l’emplacement de la preuve. Une décision claire évite de recommencer le même travail lors d’une nouvelle alerte.
La trace doit rester utile après la fin de l’alerte. Comparez l’exposition initiale à l’état final, notez les accès résiduels et testez le contrôle après un déploiement ou un changement réseau. TeamPCP est actif dans les attaques de chaîne d’approvisionnement décrites par le CERT-FR justifie ce suivi, sans signifier que le travail s’arrête à la fermeture d’un ticket.
Enfin, rendez le passage de relais explicite. Indiquez au propriétaire ce qui a changé, à la supervision quel comportement doit déclencher une nouvelle alerte et au responsable incident quelle preuve rouvrirait le dossier. Cela relie la correction à l’exploitation quotidienne de les dépôts, paquets, pipelines CI et secrets des équipes de développement.
Gardez la trace tournée vers l’état observable suivant. Il doit être possible de décrire un actif sain, d’identifier le responsable qui peut le confirmer et de préciser le signal qui invaliderait la conclusion. Cette discipline transforme une revue ponctuelle en contrôle répétable pour rotation et suivi des secrets.
Notez la date de revue et gardez les preuves accessibles au prochain analyste.
Non. Le paquet peut s’exécuter dans un runner CI, accéder à des secrets de publication ou atteindre des environnements de test et de production. Cartographiez les identités et les routes disponibles au moment de l’installation.
Révoquez-le, recherchez son usage dans les journaux et l’historique, examinez les workflows qui l’ont lu et vérifiez les systèmes accessibles. Supprimer la ligne du dernier commit ne retire pas les copies historiques.
Une dépendance indirecte peut être résolue automatiquement par le gestionnaire de paquets. Les fichiers de verrouillage et les arbres de dépendances montrent la version réellement installée.
Réduisez les droits des jetons, isolez les runners, exigez une revue des changements de dépendances, contrôlez la publication et testez la reconstruction depuis une base sûre avec de nouveaux secrets.
Defendis relie l’exposition externe, le renseignement sur les menaces et les signaux de sécurité pour aider votre équipe à traiter les risques qui comptent le plus. Suivez les actifs, identités et accès exposés avant qu’ils ne deviennent un incident.
