Un chercheur, un ordinateur portable et Claude : plus de 100 failles trouvées dans le code de sites gouvernementaux britanniques

Quand on parle d'IA et de cybersécurité, on dresse d'ordinaire un tableau effrayant : des modèles surpuissants qui piratent tout sur leur passage. La réalité, d'après un récent article de Wired, est bien plus prosaïque et plus gênante. Un chercheur a pris un ordinateur portable ordinaire, y a branché Claude Opus et Sonnet et, en peu de temps, a trouvé plus d'une centaine de vulnérabilités graves dans le code ouvert du gouvernement britannique.

Ce qui a été trouvé

Au Royaume-Uni, le principe selon lequel « le code écrit avec de l'argent public est publié en open source » s'applique depuis environ dix ans. C'est transparent, et la réutilisation permet d'économiser du budget. Crispin Nesbitt-Smith, de ControlPlane, a analysé 349 dépôts publics de 33 organisations, dont le ministère de la Santé et de la Protection sociale, le Home Office et des collectivités locales. Des vulnérabilités ont été trouvées dans environ deux tiers des bases de code.

Le cas le plus grave concerne le Planning Inspectorate, l'organisme chargé des questions d'aménagement du territoire en Angleterre. Des employés ont accidentellement commité sur un GitHub public des identifiants Microsoft Entra ID, sans les révoquer complètement. Selon le chercheur, ces identifiants donnaient un accès « divin » en lecture et en écriture à tous les sites SharePoint et aux OneDrive personnels des employés, y compris les dossiers du personnel et les bibliothèques de preuves des litiges d'urbanisme. Leur durée de validité, semble-t-il, n'expirait pas.

Au ministère de l'Éducation, des failles ont été trouvées dans le service d'achats pour les écoles, dans l'application destinée aux enseignants (qui contient des données personnelles, des qualifications et des scans de documents) et dans le registre principal des centres de formation accrédités. Sur le portail de données ouvertes du gouvernement écossais, n'importe quel visiteur pouvait lire les données des comptes administrateurs et modifier la configuration du site. Tout est désormais corrigé.

Il ne s'agit pas d'« attaques ultra-sophistiquées »

Le plus important dans cette histoire, c'est la banalité des découvertes. Nesbitt-Smith affirme que rien de tout cela ne nécessite la sophistication dont parle la presse : « Ce sont des bêtises ». Un audit informatique de routine en aurait détecté une bonne partie. L'IA n'invente pas de nouveaux exploits : elle rend bon marché et rapide ce qui exigeait auparavant un spécialiste coûteux et du temps. Analyser des centaines de dépôts est désormais à la portée de quiconque dispose d'un abonnement et d'un ordinateur portable. Y compris d'un attaquant.

Un représentant du Planning Inspectorate a déclaré à Wired que ses systèmes de surveillance avaient immédiatement repéré l'activité du chercheur en août, et que la vulnérabilité avait été fermée dans les 20 minutes suivant le signalement. Selon lui, il n'y a pas eu de fuite de données. Amanda Brock, directrice du groupe sectoriel OpenUK, souligne que le problème n'est pas le code ouvert, mais le non-respect de l'hygiène des processus. Les secrets ne doivent jamais arriver dans un dépôt.

Fermer le code n'est pas la solution

Après cette vague de découvertes, des voix s'élèvent dans le secteur public pour cesser de publier les sources. D'après certaines informations, le NHS aurait demandé en mai à ses équipes technologiques de s'éloigner de l'open source par crainte des modèles d'IA. Nesbitt-Smith qualifie la fermeture sans correction des failles de « pire scénario ». Les chercheurs cesseront de trouver des problèmes, tandis que les attaquants ont probablement déjà cloné les dépôts et conserveront l'accès aux anciennes versions. Il compare cela à un panneau « Ici il y a des dragons, mais ne regardez pas ».

Que faire en pratique

La leçon pour les équipes est simple et ennuyeuse, mais urgente :

• Activez l'analyse des secrets et la push protection dans GitHub pour que les clés n'arrivent pas dans les commits.
• Si une clé a fuité, révoquez-la complètement au lieu de simplement supprimer le fichier : l'historique des commits conserve tout.
• Accordez aux jetons des droits minimaux et des durées de vie raisonnables. C'est précisément l'absence de limites qui a transformé une erreur en catastrophe potentielle.
• Passez vos dépôts au crible avec le même procédé que le chercheur, avant que quelqu'un d'autre ne le fasse.

Cette histoire a aussi une limite : la publication ne donne aucun détail sur la proportion de faux positifs ni sur la quantité de vérification manuelle nécessaire. Mais cela n'annule pas la conclusion principale : l'IA a ramené le coût d'un audit presque à zéro, et la « sécurité par l'obscurité » a définitivement cessé d'être une stratégie.