~8 minutes
GitHub a publié un billet qui liste 6 réglages de sécurité à activer sur un dépôt : SECURITY.md, signalement privé des vulnérabilités, secret scanning avec push protection, Dependabot, code scanning et protection de la branche par défaut.
En premier constat, c’est un bon rappel, honnête sur son ambition : c’est gratuit, ça prend une heure, et ça élimine les erreurs les plus bêtes. Mais je le dis sans détour : si votre dépôt publie un package consommé par d’autres, ces 6 cases cochées vous mettent au niveau zéro, pas au niveau suffisant.
Un attaquant qui vise la chaîne d’approvisionnement ne s’arrête pas devant un SECURITY.md.
Les 6 réglages GitHub
Je passe donc rapidement sur les 6 réglages, ils sont déjà bien expliqués côté GitHub, et je m’attarde surtout sur ce qu’il faut ajouter systématiquement pour durcir un dépôt, avec à chaque fois l’incident réel qui justifie l’effort.
| Réglage | ✅ Ce qu'il couvre | 🚫 Ce qu'il ne couvre pas | |
|---|---|---|---|
| B1 | 📄 SECURITY.md |
Indique où signaler une faille au lieu d'une issue publique | Rien sur la façon dont le code arrive dans le dépôt |
| B2 | 🔒 Signalement privé des vulnérabilités | Permet un triage confidentiel avant divulgation | Ne détecte rien, ne fait que canaliser un signalement humain |
| B3 | 🕵️ Secret scanning + push protection | Bloque un secret évident avant le push | Ignore les secrets déjà présents dans l'historique, les clés stockées ailleurs (CI, cloud) |
| B4 | 📦 Dependabot + dependency review | Alerte sur les CVE connues des dépendances directes | Ne détecte ni le typosquatting, ni un mainteneur upstream compromis, ni un package légitime qui devient malveillant après une prise de contrôle |
| B5 | 🔍 Code scanning | Détecte des patterns dangereux dans votre propre code | Ne regarde jamais vos fichiers de pipeline CI, qui sont eux-mêmes du code exécutable |
| B6 | 🛡️ Protection de la branche par défaut | Impose une PR et une revue avant fusion | Ne dit rien sur qui peut approuver, ni sur ce qui se passe dans la CI déclenchée par cette PR |
Note du PandaRedacteur: Les 6 réglages GitHub protègent le code source. Aucun ne protège la chaîne qui le transforme en artefact publié, or c’est précisément là que Notepad++ et Shai-Hulud ont frappé.
Le lien avec les attaques de supply chain
Voyons maintenant trois familles d’attaques que les 6 réglages de base ne couvrent pas, et pour lesquelles j’ai déjà documenté des cas concrets sur ce blog.
La compromission de mainteneur ou de dépendance amont. Dependabot alerte sur une CVE publiée, pas sur un mainteneur dont le compte a été phishé puis utilisé pour publier une version piégée d’un package légitime. C’est exactement le scénario que j’ai décortiqué dans la série Shai-Hulud sur npm, et dans l’incident réel Notepad++, où l’éditeur de texte lui-même est devenu le vecteur.
Le typosquatting et la dependency confusion. Un package.json qui tire une dépendance au nom presque identique à la vraie ; j’en donne un exemple concret dans mon article sur AST02 - Supply Chain Compromise, appliqué aux registres de skills IA mais le mécanisme est identique pour npm, PyPI ou un registre d’actions GitHub.
Le code scanning de GitHub n’analyse jamais vos fichiers .github/workflows/, alors que c’est exactement le point sur lequel je reviens le plus souvent depuis quelques mois : la CI/CD elle-même comme cible. Un pipeline mal configuré est pourtant une porte d’entrée directe vers vos secrets de déploiement ; j’ai détaillé le sujet dans CI/CD Fortress et plus récemment dans mon article sur les pwn requests, où actions/checkout a dû changer son comportement par défaut à cause de ce risque.
Et la cible n’est pas toujours votre propre dépôt : le 17 mars 2026, une réécriture de tag malveillante sur l’action tj-actions/changed-files a exposé des secrets dans plus de 23 000 dépôts d’un coup, simplement parce que ces dépôts consommaient l’action par un tag mobile plutôt qu’un SHA figé. C’est le scénario exact que Dependabot ne détecte pas : rien à voir avec une CVE, tout à voir avec la confiance aveugle accordée à une brique tierce non vérifiée. Un bot autonome baptisé hackerbot-claw a depuis montré qu’une IA pouvait scanner le web en continu pour repérer et exploiter automatiquement ce type de configuration d’Actions vulnérable.
Note du PandaRedacteur : 23 000 dépôts touchés par un simple tag réécrit, ça ne demande ni exploit sophistiqué ni 0-day. Juste un mainteneur pressé qui a écrit
@v4au lieu de coller le SHA complet.
Le cadre général de cette convergence entre infrastructure et supply chain, je l’ai posé dans La face cachée de la Supply Chain et son volet agents IA dans L’ennemi dans le terminal.
Ce qu’un mainteneur sérieux active en plus
Sur les dépôts que j’audite, je regroupe généralement ces réglages autour de trois questions :
Qui peut agir sur le dépôt
- 2FA obligatoire au niveau de l’organisation. GitHub le propose depuis des années ; beaucoup d’organisations ne l’imposent toujours pas. Un compte de mainteneur sans 2FA est la porte d’entrée la plus simple, et la plus utilisée en pratique.
- CODEOWNERS + revues obligatoires. La protection de la branche de base (B6) impose une revue ;
CODEOWNERSimpose que ce soit la bonne personne qui revoie le bon fichier, en particulier.github/workflows/et les fichiers de build. - Les rulesets valent mieux que la branch protection classique : ils s’appliquent à plusieurs branches et tags d’un coup, sont versionnés comme de la configuration, et permettent d’imposer la signature des commits au niveau de l’organisation entière plutôt que dépôt par dépôt. C’est là qu’on signe aussi les tags, en GPG classique ou avec Sigstore gitsign pour éviter de gérer une clé privée. Sans ça, rien ne garantit qu’un tag de release correspond bien au commit que vous avez revu.
Ce qui est exécuté
-
Permissions minimales par défaut.
permissions: read-all(ou l’équivalent organisation) doit être le point de départ de tout workflow ; l’écriture s’élève explicitement, job par job. -
Pin des GitHub Actions par SHA complet, jamais par tag mobile (
@v4peut changer de contenu du jour au lendemain sans que vous le sachiez ; c’est exactement ce qui s’est passé surtj-actions/changed-files). Une nuance à garder en tête : un SHA identifie un contenu, pas une provenance. Un commit vit dans le graphe d’objets partagé entre un dépôt et ses forks, donc le SHA est universel mais pas scopé àowner/repo. Le pinning règle la mutabilité du tag, pas toute la validation de provenance. - Consommer des actions tierces déjà durcies plutôt que de les auditer une par une. Annoncé le 17 mars 2026, Chainguard Actions republie les actions du marketplace les plus utilisées, reconstruites depuis les sources, avec les références internes épinglées et un rapport de durcissement documenté (injection de commandes, secrets mal interpolés, workflows trop permissifs).
Note du PendaRedacteur: Franchement : c’est une excellente initiative, une des rares qui s’attaque au bon maillon de la chaîne.
-
Restriction des pwn requests.
pull_request_targetetworkflow_runcombinés à un checkout non vérifié sont, à mon sens, le motif d’attaque le plus sous-estimé que j’ai rencontré ces derniers mois; cf => Pwn Request. -
OIDC plutôt que des secrets longue durée. Un jeton lié à l’identité du job et qui expire à la fin de l’exécution ne peut pas être exfiltré une fois pour toutes, contrairement à un PAT stocké en secret GitHub.
- Scanner l’assemblage du pipeline, pas seulement ses briques.
zizmorreste ma référence pour GitHub Actions ;plumberfait le même travail en couvrant aussi GitLab CI, et note le pipeline de A à E sur les permissions trop larges, les déclencheurs dangereux et les secrets mal exposés ;poutinejoue un rôle voisin. Durcir les actions consommées et auditer l’assemblage sont deux chantiers complémentaires : un dépôt peut consommer des actions parfaitement durcies et rester vulnérable à cause d’unpermissions: write-alldéclaré dans son propre workflow.
Note du PandaRedacteur : une action durcie par Chainguard qui tourne dans un workflow en
permissions: write-all, c’est un serrurier qui pose une porte blindée sur un mur en carton (et pas en bambou, car le bambou est plus dur…)
Ce qui sort du dépôt
- Générer un SBOM (SPDX ou CycloneDX) à chaque release documente exactement ce qui est réellement embarqué, au-delà des dépendances directes ; couplé au dependency graph exposé, ça donne à vos consommateurs une vue complète de ce qu’ils installent.
- Artifact attestations et provenance SLSA sur les releases. Signer et attester la provenance de vos artefacts publiés permet à vos consommateurs de vérifier que le binaire qu’ils installent correspond bien au code source public. J’ai détaillé la démarche complète dans SLSA : Mettre sa Supply Chain sous haute surveillance, l’implémentation pratique dans Atteindre SLSA Niveau 3 avec GitHub Actions et Sigstore, et la comparaison des approches dans Stratégies d’implémentation SLSA.
Note du PandaRedacteur : les 6 réglages GitHub protègent contre l’erreur. Ces pratiques protègent contre l’attaquant qui vise spécifiquement votre chaîne de publication
Vous me connaissez, j’aime bien avoir une visualisation propre de ce que je raconte… Alors passons a une vrai analyse
Analyse STRIDE des angles morts laissés par les 6 réglages de base
| Catégorie STRIDE | Couvert ? | Explication |
|---|---|---|
| Spoofing (Usurpation d'identité) | Non | Un mainteneur phishé sans 2FA obligatoire permet à l'attaquant de publier sous une identité de confiance ; aucun des 6 réglages n'impose le 2FA. |
| Tampering (Falsification) | Partiel | Le code scanning couvre votre code applicatif, jamais les fichiers de pipeline CI qui, eux, peuvent injecter du contenu arbitraire dans l'artefact final. |
| Repudiation (Répudiation) | Partiel | Sans commits signés ni provenance SLSA, rien ne prouve qu'une release publiée correspond au code effectivement revu en PR. |
| Information Disclosure (Divulgation) | Partiel | Le secret scanning bloque les secrets évidents au push, mais pas les secrets déjà présents dans l'historique ni ceux exfiltrés par un job de CI mal scopé. |
| Elevation of Privilege (Élévation de privilèges) | Non | Aucun des 6 réglages ne touche aux permissions des workflows CI ; c'est pourtant le point d'entrée principal des pwn requests. |
Impact potentiel d’un dépôt limité aux 6 réglages de base
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Élevé | Un secret ancien dans l'historique ou exposé via un pipeline non audité reste accessible malgré le secret scanning au push. |
| Intégrité | Sévère | Sans provenance signée, un artefact publié sous votre nom peut être remplacé sans que vos consommateurs en aval ne puissent le détecter. |
| Disponibilité | Modéré | La révocation d'urgence de credentials compromis interrompt les publications le temps de l'investigation. |
| Réputation | Critique | Un dépôt open source largement dépendu, compromis via sa chaîne de publication, expose tous ses consommateurs en aval, avec un effet de cascade documenté (Notepad++, Shai-Hulud). |
DevSecOps : où placer chaque contrôle dans le cycle de vie
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
Les fiches pratiques complètes de durcissement (permissions granulaires job par job, séparation build/deploy avec environment, configuration OIDC de bout en bout, checklist bloquante par plateforme) existent déjà en contenu premium pour GitHub Actions, GitLab CI et Jenkins ; elles complètent directement ce que j’ai détaillé dans l’article sur les pwn requests.