Si vous maintenez un projet sur GitHub, la sécurité n'est pas quelque chose qu'on configure une fois pour toutes avant de l'oublier. C'est une poignée de réglages, quelques habitudes, et savoir à quels outils automatisés vous fier et desquels vous méfier. Voici ce que disent réellement les faits et la communauté des mainteneurs, pas la version marketing.
Commencer par verrouiller les paramètres du dépôt
Le guide GitHub Configuration Best Practices de l'OpenSSF propose des recommandations concrètes et vérifiables, plutôt que des conseils vagues. Côté dépôt, il recommande que la branche par défaut exige une revue de code, au moins deux reviewers et le succès de tous les checks avant le merge, et qu'elle bloque les force push ainsi que la suppression de la branche. Il recommande aussi de ne jamais autoriser les workflows CI/CD à approuver des pull requests, et de régler en lecture seule la permission par défaut du token des workflows GitHub Actions. Ce ne sont pas des suggestions abstraites : chacune ferme une voie précise par laquelle un workflow compromis ou écrit à la légère pourrait merger du code sans qu'un humain l'ait vraiment regardé.
Côté organisation, le même guide recommande d'imposer l'authentification à deux facteurs, d'utiliser le single sign-on et de restreindre qui peut créer des dépôts publics. Rien de bien exotique là-dedans. La plupart de ces réglages tiennent en une case à cocher, dans une page de paramètres que vous avez déjà sous la main.
Des secrets qui fuient dans votre code
La push protection de GitHub, annoncée en disponibilité générale et gratuite pour tous les dépôts publics, analyse les commits avant qu'ils n'arrivent dans le dépôt et bloque ceux qui contiennent des secrets reconnaissables à leur format, comme des clés d'API ou des tokens. Pour les dépôts publics, l'activer ne coûte désormais rien. Elle ne détectera pas tous les types de secrets et repose sur du pattern matching : c'est un filet de sécurité, pas une garantie.
GitHub Actions : restreindre avant de faire confiance
Les Actions sont l'un des moyens les plus simples de compromettre un dépôt, parce qu'un workflow peut exécuter du code arbitraire avec les permissions du dépôt. Le guide de l'OpenSSF recommande de restreindre les Actions à des dépôts sélectionnés et de les limiter aux actions vérifiées ou explicitement jugées fiables, plutôt que de laisser s'exécuter n'importe quelle action publique. GitHub lui-même a indiqué que d'autres protections par défaut sont en route pour les Actions, en publiant une roadmap sécurité 2026 pour GitHub Actions. Le détail de ce qui va changer est encore en train de se préciser : voyez-y une direction, pas encore un ensemble de fonctionnalités abouti.
Les scanners automatisés ne sont pas infaillibles
Autant être honnête sur les limites des outils auxquels on vous dit de vous fier. La documentation du projet OSSF Scorecard est un bon modèle de la manière dont un check de sécurité devrait être documenté : elle explique précisément ce que recherche le check Binary-Artifacts, pourquoi des binaires versionnés dans le dépôt représentent un risque (on ne peut pas les relire comme du code source, et ils peuvent diverger de la source au fil du temps), et ce qu'il exclut, comme le code source généré par des outils tels que bison ou flex. Ce niveau de transparence permet à un mainteneur de juger si un score faible veut vraiment dire quelque chose pour son projet.
Tous les outils ne sont pas aussi lisibles. Dans une issue GitHub ouverte sur le dépôt de CodeQL, un mainteneur explique recevoir 12 à 20 faux positifs par pull request, avec des paramètres et des variables signalés comme « inutilisés » alors qu'ils étaient en réalité lus une ou deux lignes plus loin dans le code. Il s'agit d'un seul rapport de bug, pas d'un taux de faux positifs mesuré sur l'ensemble des utilisateurs de CodeQL, et GitHub n'a publié aucune réponse dans ce fil à l'heure où ces lignes sont écrites. Mais c'est un rappel utile : un avertissement d'analyse statique est un indice, pas un verdict, et l'auto-merge à l'aveugle dès qu'un scan revient propre est en soi un risque.
Le cas Dependabot, ou pourquoi rester prudent
Un exemple plus frappant d'automatisation bruyante vient du développeur Go Filippo Valsorda, qui raconte pourquoi il a désactivé Dependabot. Après avoir publié un correctif d'une ligne pour une méthode de filippo.io/edwards25519 que, selon ses propres termes, « pratiquement personne n'utilise », il a vu Dependabot ouvrir des milliers de pull requests sur des dépôts qui n'étaient pas concernés, chacune accompagnée de ce qu'il décrit comme « un score CVSS v4 absurde, inventé de toutes pièces » et un « inquiétant score de compatibilité de 73 % ». Il souligne qu'une de ces alertes a même atterri sur le dépôt Wycheproof, qui n'importe pas du tout le package vulnérable, seulement l'un de ses sous-packages, qui n'est pas touché. Son argument, qui relève de son expérience et de son opinion plutôt que d'une étude contrôlée, est que les bases de vulnérabilités qui descendent jusqu'au niveau des symboles, comme la Go Vulnerability Database, permettent à un scanner de faire la différence entre « vous dépendez de ce package » et « vous appelez réellement la fonction défaillante », et qu'une exécution planifiée de govulncheck, doublée d'un passage des tests sur les dernières versions des dépendances, fait ce travail avec beaucoup moins de bruit.
La leçon dépasse le cadre de Go : une alerte incapable de vous dire si le chemin de code vulnérable est seulement atteignable dans votre projet finira par vous apprendre à ignorer les alertes tout court. C'est là le vrai coût d'un outillage de sécurité bruyant, et il mérite d'être mis en balance avec le confort, quel qu'il soit, que procure l'outil le plus bruyant.
Le bilan, en toute honnêteté
Aucune de ces mesures ne suffit à elle seule. La protection des branches, les permissions du token des workflows et l'authentification à deux facteurs ferment la porte à des vecteurs d'attaques et ne vous coûtent que quelques minutes dans les paramètres. La push protection et les checks de type Scorecard repèrent des risques précis et bien définis. L'analyse statique et les scanners de dépendances sont utiles, mais leurs résultats demandent la lecture d'un humain sceptique, pas un simple coup de tampon. Sécuriser un projet GitHub, c'est moins chercher l'unique réglage qui compte que veiller à ce qu'aucune couche ne soit jamais seule à se dresser entre votre code et une mauvaise journée.
Pour aller plus loin
- GitHub: What's coming to our GitHub Actions 2026 security roadmap
- GitHub issue #18359: So many false positives that I doubt it actually works
- OSSF Scorecard: Check Documentation
- GitHub: Push protection is generally available, and free for all public repositories
- OpenSSF: GitHub Configuration Best Practices
- Filippo Valsorda: Turn Dependabot Off
