Présumer la compromission : ce que la brèche de GitHub apprend à quiconque développe du logiciel

En mai 2026, GitHub a révélé qu’un attaquant avait copié environ 3 800 de ses dépôts internes. La porte d’entrée n’était pas un exploit sophistiqué contre la plateforme GitHub. C’était l’ordinateur portable d’un seul employé, et dessus une version trafiquée d’une extension populaire de l’éditeur Visual Studio Code. La version empoisonnée n’est restée disponible sur la place de marché que quelques minutes avant d’être retirée, et cela a suffi. GitHub n’a trouvé aucun indice que des dépôts de clients aient été touchés.

La leçon est de celles que beaucoup d’équipes préféreraient ne pas entendre : si vous développez du logiciel, vous ferez un jour partie d’une brèche. Non par négligence, mais parce que l’ingénierie moderne repose sur des couches d’outils, d’extensions et de dépendances que personne ne maîtrise entièrement.

Présumer la compromission, minimiser l’impact

La prévention compte toujours, et nous y investissons. Mais une conception qui ne fonctionne que tant que rien n’entre est une conception qui échoue le pire jour. Nous partons de l’hypothèse inverse : quelqu’un entrera, faites donc en sorte qu’il reparte sans rien de valeur stratégique. En pratique, cela tient en quatre habitudes.

• La logique centrale derrière des interfaces. Les règles et algorithmes propriétaires ne se trouvent pas dans un dépôt sous forme de source lisible. Ils vivent derrière des services, des interfaces ou des modules privés, de sorte qu’un dépôt copié montre comment les choses se connectent, pas comment elles fonctionnent.
• Rien de sensible dans le code. Pas de secrets, pas de points de terminaison internes, pas de configuration qui cartographie l’infrastructure. Les secrets vivent dans un coffre et sont récupérés à l’exécution par une identité, jamais collés dans un fichier.
• Une abstraction délibérée. Le code est écrit pour être clair pour ceux qui y travaillent et pour révéler le moins possible à quiconque ne devrait pas le lire.
• Public par défaut. Chaque dépôt est écrit comme s’il pouvait être exposé demain. Si un fichier poserait problème en première page d’un site d’information, il n’a rien à faire dans le dépôt.

Le poste de travail est le périmètre

Le cas GitHub montre aussi où se situe aujourd’hui le vrai périmètre : sur la machine du développeur. L’éditeur, ses extensions et les outils en ligne de commande de cette machine s’exécutent tous avec les accès du développeur. Cela exige la même discipline que toute autre partie du parc : une liste courte d’extensions approuvées, des appareils managés et tenus à jour, des connexions liées à un appareil managé, et des accès limités à la tâche plutôt qu’à tout ce dont un développeur pourrait un jour avoir besoin.

Résilience, pas paranoïa

La sécurité ne consiste pas seulement à tenir les attaquants dehors. Elle consiste à faire en sorte que, lorsque quelque chose arrive, le dommage soit petit, contenu et rapidement réparé. La brèche de GitHub ne sera pas le dernier titre du genre. Ce qu’elle vous coûtera se décide un choix de conception à la fois, bien avant l’incident.

Nous gérons nos propres dépôts de cette façon, et nous aidons les équipes à adopter les mêmes habitudes : des secrets dans un coffre, des appareils de développement managés, une liste courte d’extensions d’éditeur approuvées et une revue sur chaque changement.

Découvrez notre offre en cybersécurité et conformité et en montée en compétences.