L’open source n’est pas un périmètre de sécurité

Le 14 mai 2026, le Government Digital Service britannique a publié des recommandations sur l’IA, le code ouvert et le risque de vulnérabilités dans le secteur public. Elles répondent à la bonne question : l’IA peut rendre la découverte de vulnérabilités moins coûteuse, mais la confidentialité d’un dépôt ne devient pas pour autant un périmètre de sécurité.¹

Neuf jours plus tôt, un article indiquait que NHS England prévoyait de rendre privés des centaines de dépôts GitHub, après des inquiétudes internes sur la capacité d’outils d’IA à inspecter du code public à grande échelle.² L’inquiétude est compréhensible. Le contrôle proposé ne l’est pas. Masquer le code revient à traiter la découverte comme la menace. Un vrai travail de sécurité traite la faille non corrigée comme la menace.

La sécurité open source progresse quand les équipes réduisent l’exposition réelle : pas de secrets dans le code, des exceptions claires, des dépôts avec des responsables identifiés, des canaux de divulgation qui fonctionnent, des correctifs rapides et des preuves publiques que les corrections sont bien parvenues aux utilisateurs. La confidentialité d’un dépôt peut soutenir une exception précise, mais elle ne peut pas remplacer ce mode de fonctionnement.

En bref

Le GDS affirme que les équipes du secteur public doivent garder le code ouvert par défaut, examiner les exceptions avec discernement et se concentrer sur les facteurs pratiques qui modifient réellement le risque.¹ Cette réponse vaut mieux qu’une panique autour de la confidentialité des dépôts, car du code public peut déjà exister dans des forks, des miroirs, des caches, des artefacts de paquets, des images de conteneur, des captures d’écran, des clients générés et d’anciens clones. Plus important encore, le code public permet à davantage de personnes de l’inspecter, de le réutiliser, de signaler des problèmes et de l’améliorer.¹³

La bonne réponse à la découverte de vulnérabilités par l’IA n’est pas « tout rendre privé ». La bonne réponse est la suivante : retirer les secrets, classer le code sensible, publier des exceptions claires, exécuter des analyses de dépendances et de secrets, maintenir un canal de divulgation des vulnérabilités, corriger rapidement et conserver la preuve que le code ouvert a un propriétaire.¹⁴⁵

Points clés

• Pour les responsables d’ingénierie : la confidentialité peut réduire l’exposition dans des cas précis, mais elle ne remplace ni la responsabilité, ni l’inventaire, ni les correctifs, ni la divulgation.
• Pour les équipes du secteur public : l’ouverture par défaut reste viable quand elle s’accompagne d’exceptions explicites pour les secrets, les contrôles antifraude, l’architecture sensible et les politiques non publiées.
• Pour les équipes sécurité : l’IA augmente la valeur de la capacité de réponse. Un dépôt privé sans circuit de tri reste un échec.
• Pour les équipes qui travaillent sur des agents : la visibilité du code n’est qu’une surface d’attaque parmi d’autres. Les permissions des outils, les limites d’état, les contrôles de sortie réseau et les seuils de publication comptent davantage que l’apparence privée d’un dépôt.
• Pour les mainteneurs : publiez moins de zones d’ombre. Une bonne documentation, des points de contact sécurité clairs et de petits services bien attribués réduisent davantage le risque qu’un mur de dépôts privés.

La panique confond visibilité et vulnérabilité

Les outils d’analyse de vulnérabilités fondés sur l’IA changent l’économie de l’inspection. Une personne avait autrefois besoin de temps, de compétence et de patience pour fouiller une base de code. Un modèle performant peut inspecter davantage de code plus vite, relier des indices entre fichiers et produire plus de constats candidats. Ce changement accroît la pression sur les équipes qui avaient déjà du code fragile, une attribution floue et des chemins de correction lents.

La visibilité d’un dépôt ne se confond toujours pas avec une vulnérabilité. Du code public peut révéler un bug. Du code privé peut contenir le même bug. Un attaquant peut souvent déduire le comportement à partir de binaires, de trafic API, de paquets côté client, du contenu de paquets, de couches de conteneur, de journaux, de documentation, de métadonnées de dépendances ou d’un ancien clone. Le GDS formule le même point pratique : rendre privé un dépôt auparavant public ne supprime pas nécessairement l’accès pour des adversaires capables, car les projets populaires ont souvent des forks ou des miroirs, et même des dépôts peu visibles peuvent déjà être parvenus à des chercheurs ou à des attaquants.¹

Cette réserve compte, car « fermons-le » donne l’impression d’agir. Cette action peut réduire la responsabilité publique tout en laissant la faiblesse technique en place. Les équipes peuvent perdre l’examen externe, les correctifs partagés et la réutilisation, sans gagner grand-chose contre quiconque a déjà copié le code.

L’open source crée aussi une piste d’audit. L’historique public montre qui a changé quoi, quand un correctif a été intégré, comment les mainteneurs ont répondu à un signalement et si un projet bénéficie encore d’un entretien actif. Le code privé masque ces signaux aux équipes homologues, aux fournisseurs, aux chercheurs et aux autres organismes publics susceptibles de réutiliser ou d’améliorer le travail.

L’ouverture par défaut n’est pas naïve

Le GDS ne prétend pas que chaque ligne de code doit se trouver sur l’internet public. Les anciennes recommandations open source de GOV.UK nomment déjà de bonnes raisons de garder du code fermé, notamment les clés, les identifiants, les algorithmes de détection de fraude et les politiques non publiées.³ Le Technology Code of Practice associe lui aussi l’ouverture aux obligations de sécurité et de protection de la vie privée, sans les opposer.⁴

La règle la plus solide est l’ouverture par défaut avec des exceptions précises. Cette forme de politique oblige une équipe à nommer le risque au lieu d’utiliser « sécurité » comme catégorie fourre-tout. Un secret n’a rien à faire dans un dépôt. Un signal de fraude peut nécessiter une visibilité restreinte. Un service lié à une politique non publiée peut justifier un gel temporaire. Une base de code simplement gênante ne remplit pas les critères.

Le guide du secteur public britannique va dans le même sens. Il décrit l’attente selon laquelle les logiciels et le code de l’administration doivent être open source par défaut, développés au grand jour et publiés sous une licence approuvée lorsque c’est approprié.⁵ La politique de publication de code open source du DWP suit le même modèle : encourager la publication sous licences ouvertes tout en protégeant le code source sensible au moyen de contrôles définis.⁶

Cette distinction protège la qualité. Les équipes qui codent en public ont tendance à écrire de meilleurs README, des consignes d’installation plus propres, des historiques d’issues plus clairs et des limites de données plus explicites, parce que des tiers peuvent lire leur travail. Les recommandations de GOV.UK indiquent que publier le code peut améliorer la documentation, la maintenabilité, la clarté des données et les retours de sécurité.³ Ces bénéfices disparaissent quand une équipe répond à la pression de l’IA en enterrant tout.

Le vrai contrôle, c’est la vitesse de remédiation

L’IA change l’horloge. La découverte s’accélère. Le volume de signalements augmente. Les faux positifs aussi. J’ai déjà écrit sur cette même pression capacitaire dans Quand votre agent trouve une vulnérabilité : la découverte vaut peu sans vérification ni réparation. Les équipes ont besoin de tri, d’orientation vers le propriétaire, de correctifs, de divulgation et de preuves de publication. La confidentialité d’un dépôt ne leur donne rien de tout cela.

La plateforme Vulnerability Disclosure Policy de la CISA existe pour cette raison. Elle donne aux agences civiles fédérales un canal pour recevoir, trier et orienter les vulnérabilités signalées par des chercheurs publics.⁷ Le programme de divulgation coordonnée des vulnérabilités de la CISA couvre aussi les vulnérabilités dans les infrastructures critiques, y compris les logiciels open source et les systèmes d’IA, et insiste sur la coordination de l’atténuation avant divulgation publique.⁸

Le NCSC donne aux organisations britanniques le même cadre opérationnel à travers ses recommandations de signalement et de divulgation des vulnérabilités, avec une boîte à outils et un itinéraire prêt à l’emploi pour les ministères.⁹ Le fil conducteur est simple : acceptez que des tiers trouvent des bugs, puis faites fonctionner le signalement et la remédiation.

Ce cadre transforme la découverte de vulnérabilités par l’IA : ce n’est plus une raison de cacher, mais une raison d’améliorer la boucle de réponse. Si un modèle peut trouver un bug dans votre code public, l’équipe doit se poser cinq questions :

Ces réponses réduisent le risque, que le code soit ouvert ou fermé. Masquer le dépôt ne change que les personnes capables de voir la source aujourd’hui. Cela ne crée ni propriétaire, ni correctif, ni canal de divulgation.

Une meilleure règle de décision

Les équipes ont besoin d’une règle qui distingue la gêne, l’exposition et la sensibilité réelle.

Cette règle évite aussi un échec courant : tout fermer parce que l’équipe ne sait rien classer. Un inventaire de dépôts doit indiquer ce que fait le service, quelles données il touche, qui le possède, quels analyseurs de secrets s’exécutent, quelles dépendances comptent et comment les signalements parviennent aux mainteneurs. Si l’équipe n’a pas ces réponses, elle a un déficit opérationnel. Changer la visibilité du dépôt peut masquer ce déficit au public, mais le déficit demeure.

Les agents aggravent le problème de périmètre

Les agents de codage IA rendent la même leçon plus nette. Un périmètre de dépôt n’empêche pas un agent de prendre une décision dangereuse à l’intérieur des permissions autorisées. J’ai écrit sur ce schéma dans La sécurité du sandbox de votre agent est une suggestion : les actions dangereuses se produisent souvent à l’intérieur du jeu de permissions, pas en dehors. Le même problème de composition alimente les attaques de chaîne d’approvisionnement logicielle, où des éléments raisonnables pris isolément se combinent en un chemin nuisible.

Le problème de l’agent invisible s’applique aussi à la politique open source. Les équipes ne peuvent pas gouverner ce qu’elles ne voient pas : chemins d’outils, artefacts générés, caches, état de publication, files de divulgation et transferts de propriété comptent tous.

La politique open source devrait apprendre de la sécurité des agents. Les limites utiles se situent aux couches d’action et de réponse :

• classer les entrées non fiables avant que les outils les manipulent ;
• retirer les secrets du code, de l’historique, des journaux, des paquets et des ressources générées ;
• séparer les caches de compilation et les artefacts de publication par niveau de confiance ;
• restreindre les chemins réseau sortants des flux automatisés ;
• exiger des preuves avant de publier, déployer ou déclarer une correction terminée ;
• donner aux chercheurs externes un chemin de signalement sûr et documenté.

Ces contrôles ne dépendent pas du secret de la source. Ils dépendent de la capacité des équipes à savoir où se trouve la matière sensible et quelles actions peuvent causer un dommage. Si un dépôt contient un vrai secret, le rendre privé après exposition résout le mauvais problème. Faites tourner le secret, retirez-le de l’historique lorsque c’est possible, invalidez les anciens artefacts et documentez le chemin d’incident. La frontière de publication compte parce qu’une sortie externe exige une barrière plus forte qu’une analyse locale.

C’est pourquoi les recommandations du GDS sonnent juste. Elles ne nient pas que l’IA change la découverte de vulnérabilités. Elles refusent la conclusion superficielle. L’IA rend les systèmes faibles plus faciles à inspecter ; la réponse doit donc rendre les systèmes plus faciles à attribuer, auditer, signaler et réparer.

Ce que je ferais aujourd’hui

Une équipe confrontée à une panique liée aux dépôts et à l’IA devrait mener un examen du code ouvert en 48 heures avant de changer ses réglages par défaut :

1. Inventorier les dépôts publics et associer chacun à un propriétaire.
2. Exécuter une analyse de secrets sur l’arborescence actuelle et l’historique git.
3. Vérifier si chaque dépôt dispose d’un contact sécurité ou d’une politique de divulgation.
4. Identifier les exceptions liées à la fraude, aux abus, à l’architecture active et aux politiques non publiées.
5. Confirmer les chemins de mise à jour des dépendances, de publication de correctifs et de retour arrière.
6. Fermer ou différer uniquement les dépôts précis qui correspondent à une exception nommée.
7. Publier la règle de décision pour éviter que les équipes suivantes répètent la panique.

Ce plan donne aux responsables une vraie surface de contrôle. Il crée aussi des preuves. Un futur relecteur pourra voir pourquoi un dépôt est resté ouvert, pourquoi un autre est devenu privé et quel travail a réduit le risque réel.

FAQ

L’IA rend-elle le code public plus dangereux ?

L’IA peut rendre le code public plus facile à inspecter ; les équipes doivent donc s’attendre à davantage de signalements de vulnérabilités et à davantage de sondages automatisés. Le danger vient des vulnérabilités non corrigées, des secrets exposés et des boucles de réponse faibles. La visibilité publique peut augmenter la découverte, mais la confidentialité ne supprime pas le bug sous-jacent.¹

Les équipes doivent-elles parfois rendre des dépôts privés ?

Oui. Les équipes doivent restreindre le code qui contient ou révèle des secrets, des contrôles antifraude, une architecture active sensible, une politique non publiée ou d’autres dommages précis. Elles doivent documenter l’exception et la réexaminer quand la raison expire.³⁶

Pourquoi ne pas tout fermer jusqu’à la fin de l’examen ?

Une fermeture générale échange des bénéfices publics réels contre une protection incertaine. Le GDS avertit que du code auparavant public peut déjà exister dans des miroirs, des forks ou des copies clonées.¹ Un examen court et ciblé vaut mieux qu’un réglage par défaut indéfini qui masque les problèmes d’attribution.

Que doit contenir un dépôt public avant qu’une équipe le juge suffisamment sûr ?

Au minimum : aucun secret, un propriétaire, une licence, des notes d’installation claires, une pratique de mise à jour des dépendances, un contact sécurité ou un canal de divulgation des vulnérabilités, et un processus de publication capable d’expédier rapidement les correctifs.

Quel est le lien avec les agents de codage IA ?

Les agents élargissent le même problème de périmètre. Le risque se trouve rarement dans un seul fichier visible. Il se trouve dans les permissions, les artefacts générés, les caches, les requêtes sortantes, l’état de compilation et l’autorité de publication. Une bonne sécurité des agents et une bonne politique open source exigent toutes deux des preuves à ces limites.

Références