Les experts en sécurité open source affirment que la récente faille RCE (Remote Code Execution) de GitHub, CVE-2026-3854, peut être corrigée, mais elle expose un problème bien plus important : la confiance implicite dans la chaîne d’approvisionnement logicielle.
La vulnérabilité n’est pas un incident isolé. Certains experts en sécurité y voient un signe avant-coureur de l’effondrement de la confiance basée sur le périmètre. Il sert d’étude de cas sur les raisons pour lesquelles l’identité n’est pas synonyme d’intégrité. Savoir qui a signé un colis ne signifie pas nécessairement savoir ce que contient le colis.
GitHub, une plate-forme de développement basée sur le cloud et un réseau social pour les programmeurs, a subi une faille critique d’injection de commandes qui permettait à tout utilisateur authentifié d’exécuter du code arbitraire sur ses serveurs backend avec une seule commande git push.
Ken Ammon, PDG de CodeHunter, l’a décrit comme une vulnérabilité d’injection classique qui a transformé une action de routine du développeur en un exploit « en mode divin ». Bien que corrigé, il y voit un exemple classique de la façon dont la confiance implicite dans les communications internes peut créer d’énormes failles de sécurité.
« Ce n’était pas seulement un bug de GitHub. C’était un échec de confiance implicite. Un utilisateur authentifié a émis une commande de routine, et les systèmes en aval ont traité cette entrée comme faisant autorité », a-t-il déclaré à LinuxInsider.
La confiance seule ne fonctionne plus
Ammon prévient que les contrôles de sécurité valident qui a initié une action, mais pas ce que cette action fera.
L’industrie a passé la dernière décennie à se concentrer sur le « qui » de la sécurité : l’authentification multifactorielle, la gestion des identités et les clés matérielles. Le GitHub RCE (CVE-2026-3854) suggère que nous entrons dans une ère où l’identité importe moins si les organisations ne parviennent pas à remettre en question le « quoi ».
Ammon a déclaré que l’incident met en évidence un changement plus large dans la façon dont les entreprises doivent considérer la confiance dans les logiciels.
« Nous avons construit une chaîne d’approvisionnement en logiciels qui suppose que les plateformes fiables produisent du code fiable. CVE-2026-3854 remet en question cette hypothèse. Si un système central comme GitHub peut être utilisé comme chemin d’attaque, alors la provenance seule ne constitue plus un signal de confiance suffisant. »
Les équipes de sécurité ont appris grâce à la porte dérobée XZ qu’un contributeur de confiance ne garantit pas la sécurité du code. « Ce nouveau CVE va encore plus loin : une infrastructure fiable ne garantit pas non plus un code sûr », a-t-il expliqué.
L’industrie de la sécurité doit changer d’orientation
Ammon convient que l’identité est toujours nécessaire. Toutefois, cela ne suffit pas à lui seul. Il indique qui a poussé le code, et non si l’exécution de ce code et des actions qu’il peut déclencher doit être fiable.
La sécurité des entreprises doit passer de la reconnaissance à l’intention. La question ne peut pas simplement être « Avons-nous déjà vu cela ? » Cela doit devenir « Que peut faire ce code ? »
Cette évaluation doit avoir lieu avant l’exécution, et non après, dans le cadre d’une approche zéro confiance du code, a-t-il déclaré.
Questions et réponses : Pourquoi l’identité seule ne fonctionne plus
Nous avons demandé à Ammon pourquoi la confiance implicite s’effondre dans les systèmes CI/CD et comment les entreprises peuvent améliorer la sécurité de la chaîne d’approvisionnement logicielle.
Ses commentaires ont abordé les limites de l’identité, de la provenance et de la signature en tant que signaux de confiance, ainsi que ce à quoi ressemble un modèle de confiance zéro pour le code dans la pratique.
LinuxInsider : Comment cet incident devrait-il changer la façon dont les entreprises perçoivent les utilisateurs de confiance ?
Ken Ammon : Cela nous oblige à séparer l’identité de l’intention. Un utilisateur de confiance peut être authentifié, autorisé et fonctionner à partir d’une session légitime, mais cela ne signifie pas que les utilisateurs en aval doivent faire confiance à chaque commande qu’ils émettent.
Les environnements de développement modernes sont hautement automatisés. Une seule commande peut déclencher des builds, des exécuteurs, des extractions de dépendances, des déploiements ou des intégrations sur plusieurs systèmes. Cela signifie que l’utilisateur ne représente qu’une partie de la décision de confiance. La sécurité doit également évaluer ce que l’action fera faire aux autres systèmes.
Le périmètre sécurisé est-il obsolète dans les chaînes d’approvisionnement logicielles modernes ?
Ammon : Le périmètre n’est pas obsolète, mais il n’est plus suffisant. Les chaînes d’approvisionnement en logiciels n’ont plus de frontières claires. Il s’agit d’un maillage de développeurs, de référentiels, de systèmes CI/CD, de gestionnaires de packages, d’exécuteurs, de services cloud et d’intégrations tierces.
Dans cet environnement, les attaquants n’ont pas toujours besoin de s’introduire par la porte d’entrée. Ils peuvent abuser de quelque chose déjà présent dans le flux de travail : une session authentifiée, un référentiel approuvé, un package signé ou un exécuteur automatisé.
L’ancien modèle disait : « Cela provient d’un utilisateur de confiance, alors continuez. » Le modèle le plus sûr dit : « Cela provient d’un utilisateur de confiance, mais qu’est-ce que cette action est capable de déclencher et ce comportement est-il autorisé ? »
Cet incident affaiblit-il la provenance en tant que signal de confiance ?
Ammon : Je dirais que c’est incomplet, pas faux. La provenance vous indique d’où vient quelque chose et comment il a évolué tout au long du processus. C’est utile. Mais cela ne vous indique pas si l’action ou l’artefact résultant peut être exécuté en toute sécurité.
C’est la même leçon plus large que celle que nous avons vue avec la porte dérobée XZ. Un contributeur de confiance n’a pas garanti un code sûr. Dans ce cas, une infrastructure fiable et une action authentifiée ne garantissent pas un comportement sûr. La provenance est nécessaire à la responsabilité, mais elle ne peut pas être le signal de confiance final.
Comment passer de la question « Qui a signé ceci ? » à « Est-ce réellement sûr ? »
Ammon : Nous devons traiter la signature comme un signal d’authenticité et non comme un signal de sécurité. Une signature peut prouver que quelque chose provient d’une certaine identité ou d’un certain processus. Il ne peut pas prouver que le code signé est inoffensif.
La prochaine étape est la vérification comportementale. Avant l’exécution du code, les organisations doivent se demander ce qu’elles peuvent faire : peut-il générer des processus ? Contacter le réseau ? Modifier les identifiants ? Établir la persistance ? Augmenter les privilèges ? Se déplacer latéralement ?
Pourquoi la confiance implicite entre les plateformes et les coureurs de CI est-elle aujourd’hui le maillon le plus faible ?
Ammon : L’automatisation transforme très rapidement la confiance en action. GitHub, les exécuteurs CI, les gestionnaires de packages et les outils de déploiement écoutent les événements et exécutent les instructions. Bien qu’efficace, cela crée également une hypothèse dangereuse : si l’événement provient d’une plateforme fiable, le système en aval devrait agir en conséquence.
Les attaquants exploitent cette hypothèse. Il n’est pas toujours nécessaire qu’ils compromettent tous les systèmes de la chaîne. Ils n’ont besoin de manipuler qu’une seule entrée fiable que d’autres outils considèrent comme faisant autorité.
C’est pourquoi la confiance implicite est si dangereuse en CI/CD. Le point faible n’est pas seulement la vulnérabilité originelle. C’est la cascade d’exécution fiable qui s’ensuit.
Quelle est la différence entre le Zero Trust traditionnel et le Zero Trust pour le code ?
Ammon : Le Zero Trust traditionnel se concentre sur les utilisateurs, les appareils, les réseaux et l’accès. Il demande si une identité doit être autorisée à atteindre une ressource. Le Zero Trust pour le code applique la même discipline à l’exécution des logiciels. Il demande si un artefact logiciel doit être autorisé à s’exécuter.
Cette distinction est importante car le code exerce également des privilèges. Une fois le logiciel exécuté, il peut accéder aux fichiers, appeler des API, modifier des systèmes, appeler d’autres processus ou déplacer des données. Si nous exigeons que les utilisateurs prouvent leur confiance avant l’accès, nous devrions exiger que le code prouve sa confiance comportementale avant son exécution.
Comment les entreprises doivent-elles vérifier l’intention du code en temps réel ?
Ammon : L’étoile polaire devrait être la confiance dans l’exécution : le pourcentage d’artefacts logiciels dont le comportement est vérifié avant d’être autorisés à s’exécuter. Les entreprises ont besoin d’une décision de confiance en temps réel pour le code, similaire à ce qu’elles attendent déjà pour l’identité et l’accès.
Le contrôle doit répondre clairement à une question : cet artefact est-il autorisé à s’exécuter dans cet environnement en fonction de ses capacités ? Cela nécessite une analyse des intentions comportementales, une application déterministe des politiques et une auditabilité. Si le code est autorisé à s’exécuter avant d’être compris, la décision de faire confiance existe par défaut.
