Les valeurs par défaut sécurisées : une protection essentielle

Une valeur par défaut est une décision que les responsables d’un outil prennent au nom de tous ceux qui ne la modifient jamais. Et la plupart des gens ne la modifient jamais. Pour la majorité des installations, la valeur par défaut n’est pas un point de départ : c’est la configuration finale. Cela fait du choix des valeurs par défaut l’une des décisions de sécurité les plus lourdes de conséquences dans n’importe quel logiciel — et elle est prise par quelqu’un d’autre que vous.

La Cybersecurity and Infrastructure Security Agency (CISA) américaine l’exprime clairement dans son cadre Secure by Design : un produit est « sécurisé par défaut » lorsqu’il est livré avec des configurations sécurisées déjà activées, protégeant ses utilisateurs — selon les mots de la CISA — « sans exiger du client qu’il soit un expert en sécurité ».

Les huit derniers mois ont fourni une série d’études de cas d’une clarté inhabituelle. Plusieurs montrent des valeurs par défaut sécurisées qui font exactement leur travail. Une autre montre, dans un détail pénible, ce qui arrive quand on désactive délibérément une valeur par défaut sécurisée.

#L’année difficile de l’écosystème npm

Peu de maillons de la chaîne d’approvisionnement logicielle ont été mis à l’épreuve aussi durement que le registre npm.

En septembre 2025, une campagne d’hameçonnage visant un responsable de paquets bien connu a compromis dix-huit paquets — dont chalk et debug. Ensemble, les paquets touchés totalisent des milliards de téléchargements par semaine. Quelques jours plus tard, le ver auto-propagateur Shai-Hulud a déferlé sur plus de 500 paquets, récoltant des jetons GitHub et des identifiants infonuagiques sur chaque machine qui installait une version infectée, puis se servant de ces identifiants pour infecter encore d’autres paquets. En mars 2026, deux versions malveillantes d’axios — l’un des paquets les plus utilisés de l’écosystème — ont livré une charge utile qui communiquait avec l’infrastructure de l’attaquant.

Puis, le 11 mai 2026, le groupe suivi sous le nom de TeamPCP a publié 84 versions malveillantes réparties sur 42 paquets @tanstack/* en six minutes. Le postmortem publié par TanStack mérite d’être lu en entier, car la chaîne d’attaque est une véritable visite guidée des mauvaises valeurs par défaut.

Ces incidents ne relèvent pas de la malchance isolée. Ils sont le résultat prévisible d’une chaîne d’approvisionnement dont les valeurs par défaut présument la confiance. Le cadre de développement logiciel sécurisé du NIST comme les bonnes pratiques de sécurité de la chaîne d’approvisionnement de la CNCF traitent le code tiers comme non fiable jusqu’à preuve du contraire — l’inverse exact du comportement historique de la plupart des outils de gestion de paquets.

#Choisir ses outils, c’est choisir ses valeurs par défaut

Voici la partie que les équipes contrôlent directement.

#Les gestionnaires de paquets

Presque toutes les charges utiles des attaques contre npm reposent sur le même mécanisme : les scripts de cycle de vie exécutés à l’installation. Quand un paquet déclare un script preinstall ou postinstall, le comportement classique de npm install est de l’exécuter — automatiquement, avec les privilèges de votre utilisateur, avant même qu’on ait exécuté, révisé ou seulement importé une seule ligne du code. Installer un paquet suffisait à se faire compromettre.

Ce comportement a persisté pendant des années au nom de la rétrocompatibilité. Bien des paquets légitimes utilisent des scripts d’installation pour compiler des modules natifs ; changer la valeur par défaut « briserait » donc leur fonctionnement.

pnpm a fait l’autre choix. Depuis la fin de 2025, pnpm est livré avec strictDepBuilds activé par défaut : les scripts de cycle de vie des dépendances sont bloqués à moins qu’on les autorise explicitement. Un paquet qui veut exécuter du code à l’installation doit désormais figurer, par votre main, sur une liste. Le cas pratique fonctionne toujours — il exige simplement une ligne délibérée dans votre configuration plutôt qu’une confiance silencieuse et universelle.

C’est précisément pour cela que le gestionnaire de paquets qu’on choisit est une décision de sécurité, et non une affaire de goût. Ce site est construit avec pnpm pour exactement cette raison. npm a depuis évolué dans la même direction, en complétant une refonte majeure de son authentification en décembre 2025, et Dependabot peut maintenant refuser les pull requests pour des paquets plus jeunes qu’un âge qu’on définit — ce qui laisse aux versions malveillantes le temps d’être repérées avant qu’elles ne nous atteignent.

#Les déclencheurs d’intégration continue

L’attaque contre TanStack ne s’est pas arrêtée à npm. Son point d’entrée était un déclencheur de GitHub Actions — et le contraste entre deux déclencheurs est, dans toute cette histoire, la leçon la plus limpide sur l’importance des valeurs par défaut.

Quand un workflow s’exécute sur pull_request, une pull request provenant d’un dépôt forké reçoit un jeton en lecture seule et aucun accès à vos secrets. C’est la valeur par défaut sécurisée, et elle l’est pour une bonne raison : le code d’une pull request forkée est, par définition, écrit par quelqu’un qu’on n’a pas vérifié.

pull_request_target est la porte de sortie. Il existe, selon les propres mots de GitHub, pour que les workflows puissent « étiqueter les PR » ou « commenter la PR » — des tâches qui nécessitent un accès en écriture au dépôt. Il s’exécute avec l’ensemble de vos secrets et un jeton en lecture-écriture. Il n’est sûr que tant qu’il n’extrait jamais le code de la pull request pour l’exécuter. Dès qu’un workflow combine pull_request_target avec une extraction de la branche de la pull request, il remet vos identifiants à un inconnu. Le GitHub Security Lab appelle cela une « pwn request » ; l’OWASP la répertorie sous CICD-SEC-4, l’exécution de pipeline empoisonnée.

C’est exactement ce qui est arrivé à TanStack. Un attaquant a forké un dépôt, ouvert une pull request et déclenché un workflow pull_request_target qui a extrait et exécuté le code du fork. De là, il a empoisonné la cache de compilation d’Actions ; lorsqu’une modification légitime d’un responsable a ensuite été fusionnée, la cache empoisonnée a été restaurée et utilisée pour voler un jeton de déploiement dans la mémoire de l’exécuteur.

Observez la forme de l’échec. pull_request — la valeur par défaut sécurisée — ne l’aurait pas permis. pull_request_target n’existe que pour faire fonctionner une catégorie de workflows de commodité. Le danger n’a jamais été la valeur par défaut ; c’était la porte de rétrocompatibilité construite à côté. (GitHub a depuis renforcé cette porte : depuis le 8 décembre 2025, les workflows pull_request_target exécutent la définition du workflow depuis votre branche par défaut plutôt que depuis la branche de base de la pull request.)

#La fuite de la CISA : la valeur par défaut fonctionnait ; quelqu’un l’a désactivée

Si npm et pnpm montrent des valeurs par défaut en débat, l’incident de la CISA en montre une qu’on a délibérément contournée — par l’agence même qui a rédigé la doctrine.

En mai 2026, des chercheurs en sécurité ont découvert un dépôt GitHub public nommé « Private-CISA ». Il était ouvert depuis environ six mois. À l’intérieur, comme l’a rapporté Brian Krebs, se trouvait un fichier nommé importantAWStokens contenant les identifiants administrateurs de trois comptes AWS GovCloud, ainsi qu’un tableur de mots de passe en clair pour des systèmes internes de la CISA. Les clés AWS exposées seraient restées valides pendant 48 heures après le retrait du dépôt.

Voici le détail qui compte pour ce billet. GitHub offre une fonctionnalité appelée protection contre les poussées (push protection) qui analyse les commits à la recherche d’identifiants et bloque la poussée lorsqu’elle en trouve. Elle est activée par défaut. C’est, dans le vocabulaire même de la CISA, une valeur par défaut sécurisée — une protection qui protège ses utilisateurs sans exiger qu’ils soient des experts en sécurité.

L’historique des commits a montré que le titulaire du compte avait désactivé la protection contre les poussées.

La protection était présente. Elle fonctionnait. Elle aurait intercepté importantAWStokens dès le tout premier git push et l’aurait refusé. La fuite ne s’est pas produite parce qu’une valeur par défaut sécurisée était absente ou insuffisante. Elle s’est produite parce que quelqu’un disposant de l’accès nécessaire pour la désactiver l’a fait, puis a versé les secrets que la fonctionnalité existait précisément pour arrêter. L’outil a fait son travail. Une personne l’a contourné. Cette distinction résume tout l’argument : quand la valeur par défaut est solide, l’échec, c’est le contournement — et la responsabilité revient à quiconque l’a effectué.

#La rétrocompatibilité n’est pas une dérogation de sécurité

Un thème traverse tout cela. Un comportement non sécurisé survit parce que le modifier briserait quelque chose.

npm install exécutait des scripts arbitraires parce que certains paquets en dépendent. pull_request_target expose les secrets au code des forks parce que certains workflows ont besoin d’un accès en écriture. Ce sont là de véritables enjeux de compatibilité. Aucun n’est une raison de faire du comportement dangereux la valeur par défaut.

La solution n’est pas de retirer la capacité. C’est d’inverser le fardeau. Faire du comportement sécuritaire l’option automatique et du comportement dangereux quelque chose qu’on choisit explicitement — nommément, de façon consignée, là où un réviseur peut le voir. pnpm n’a pas supprimé les scripts d’installation ; il oblige à énumérer ceux auxquels on fait confiance. GitHub n’a pas supprimé pull_request_target ; il a fait de l’extraction sécuritaire la valeur par défaut et de l’extraction dangereuse un geste explicite. AWS n’a pas retiré la possibilité de rendre un compartiment S3 public ; depuis avril 2023, il a simplement cessé de le faire par défaut, de sorte qu’exposer un compartiment est désormais un acte délibéré et visible plutôt qu’un accident en puissance. Le même réflexe a produit IMDSv2 par défaut sur EC2 et se retrouve tout au long du pilier Sécurité du cadre AWS Well-Architected.

La rétrocompatibilité mérite un chemin de migration, une fenêtre de dépréciation et une documentation claire. Elle ne mérite pas d’être la valeur par défaut. Une valeur par défaut qui privilégie « rien ne brise » plutôt que « rien ne fuit » a simplement choisi à qui le risque incombe — et elle vous a choisi, vous.

#Ce que cela signifie pour votre équipe

On ne contrôle pas la façon dont npm ou GitHub livrent leurs produits. On contrôle les valeurs par défaut qu’on accepte et celles qu’on contourne. Une courte liste de vérification concrète :

Privilégier les outils sécurisés par défaut. À tâche égale entre deux outils, celui qui est sûr dès la sortie de la boîte est le meilleur choix — de façon mesurable, pas philosophique.
Traiter la désactivation d’un garde-fou comme une décision de sécurité à réviser. Un commit qui désactive la protection contre les poussées, qui autorise un script d’installation ou qui ajoute pull_request_target devrait recevoir le même examen qu’une modification d’une règle de pare-feu.
Auditer les valeurs par défaut qu’on a déjà modifiées. Cherchez pull_request_target dans vos workflows, et surtout ceux qui extraient le code d’une pull request. Vérifiez si quelqu’un a assoupli la protection contre les poussées ou l’analyse des secrets à l’échelle de l’organisation.
Faire du chemin sécuritaire le chemin facile. Si les développeurs contournent un contrôle, c’est que le contrôle est mal conçu — corrigez l’ergonomie plutôt que l’exception.

Les valeurs par défaut sécurisées ne sont pas une touche finale qu’on applique une fois le vrai travail terminé. Elles sont la protection qui tient bon quand l’attention faiblit, quand une échéance approche, quand la personne au clavier n’est pas une experte en sécurité et ne devrait pas avoir à l’être. Il faut les traiter comme essentielles — parce qu’au moment où l’une d’elles est désactivée, comme une agence fédérale de cybersécurité vient de le démontrer, c’est exactement ce qu’elles s’avèrent avoir été.

#Sources

CISA — Secure by Design et le guide conjoint Shifting the Balance of Cybersecurity Risk
NIST — Secure Software Development Framework (SP 800-218)
CNCF TAG Security — Software Supply Chain Security Best Practices
GitHub Security Lab — Preventing pwn requests
OWASP — Top 10 CI/CD Security Risks : CICD-SEC-4, Poisoned Pipeline Execution
AWS — S3 Block Public Access activé par défaut pour les nouveaux compartiments
TanStack — npm supply-chain compromise postmortem
Krebs on Security — CISA Admin Leaked AWS GovCloud Keys on GitHub