🏛️ Contexte

Publiée le 14 mai 2026 par le Government Digital Service (GDS) et le Department for Science, Innovation and Technology (DSIT), cette guidance s’adresse aux responsables technologiques du secteur public britannique. Elle répond à la question de savoir si l’accélération de la découverte de vulnérabilités par l’IA justifie d’abandonner la politique de publication du code source « en open » par défaut.

🔍 Constat principal

La guidance affirme que le principal facteur de risque d’exploitation reste la présence de faiblesses dans les systèmes (vulnérabilités non corrigées, implémentation non sécurisée, configuration défaillante) et l’incapacité à les corriger rapidement. La publication du code source ne crée pas ces faiblesses, mais peut réduire modestement l’incertitude des attaquants et accélérer l’analyse, un effet susceptible de croître avec l’assistance de l’IA.

🤖 Impact de l’IA sur la découverte de vulnérabilités

L’UK AI Security Institute rapporte que les modèles frontier récents montrent des capacités cyber significativement renforcées dans des évaluations contrôlées, notamment :

  • Le rapport Frontier AI Trends (décembre 2025)
  • L’évaluation des capacités cyber de Claude Mythos Preview (13 avril 2026)

L’IA compresse la fenêtre entre l’existence d’une faiblesse et son exploitation, rendant la capacité de remédiation plus critique que jamais.

📋 Recommandations clés

  1. Respecter le standard minimum pour les systèmes publiquement accessibles (propriété claire, secure-by-design, hygiène automatisée, capacité de remédiation)
  2. Maintenir l’open by default — la fermeture systématique ajoute des coûts et réduit la réutilisation et le contrôle externe
  3. Rendre les exceptions explicites et révisables — toute fermeture doit s’appuyer sur un modèle de menace court, être limitée dans le temps et réapprouvée périodiquement
  4. Renforcer la capacité de remédiation — définir des SLA de patching, automatiser la gestion des dépendances et des vulnérabilités

🛡️ Standard minimum pour les systèmes publiquement accessibles

  • Propriétaire nommé et plan de maintenance (fichiers CODEOWNERS)
  • Contact sécurité et processus de signalement (fichier SECURITY)
  • Aucun secret ni détail opérationnel sensible dans le code
  • Baseline secure-by-design (modélisation des menaces, moindre privilège)
  • Hygiène automatisée (scanning de dépendances, de secrets, protections de trunk)
  • Délais de patching définis pour les vulnérabilités critiques et élevées
  • Code non maintenu clairement archivé ou service décommissionné

⚠️ Risques du « private by default »

La guidance met en garde contre plusieurs pièges :

  • Les dépôts privés créent un faux sentiment de sécurité (security-by-obscurity)
  • La fermeture après publication ouverte ne supprime pas l’exposition (miroirs, forks, indexation)
  • La fermeture peut devenir une porte à sens unique réduisant la réutilisation
  • La fermeture ne supprime pas les faiblesses sous-jacentes d’un service en production

📌 Type d’article

Il s’agit d’une recommandation de sécurité officielle du gouvernement britannique, visant à fournir un cadre décisionnel structuré aux responsables technologiques du secteur public pour arbitrer entre ouverture du code et gestion du risque cyber à l’ère de l’IA.

🔴 Indice de vérification factuelle : 25/100 (basse)

  • ⬜ gov.uk — source non référencée (0pts)
  • ✅ 13904 chars — texte complet (fulltext extrait) (15pts)
  • ⬜ aucun IOC extrait (0pts)
  • ⬜ pas d’IOC à vérifier (0pts)
  • ⬜ aucune TTP identifiée (0pts)
  • ✅ date extraite du HTML source (10pts)
  • ⬜ aucun acteur de menace nommé (0pts)
  • ⬜ pas de CVE à vérifier (0pts)

🔗 Source originale : https://www.gov.uk/guidance/ai-open-code-and-vulnerability-risk-in-the-public-sector