GitHub Actions vient de recevoir un bouton « attends une seconde » qui manquait cruellement à la chaîne logicielle. Depuis le 28 juillet, la plateforme peut retenir certains workflows jugés potentiellement malveillants avant leur démarrage sur les dépôts publics. Un collaborateur disposant des droits d’écriture doit alors examiner la modification et approuver l’exécution depuis une session web authentifiée. Ce n’est pas une révolution de la sécurité : c’est le retour tardif d’un contrôle humain là où un jeton compromis pouvait auparavant lancer du code avec la discrétion d’un stagiaire qui a trouvé la porte du local technique.
Le problème n’était pas le YAML, mais ce qu’il déclenche
Un fichier de workflow peut sembler banal : installer des dépendances, compiler, lancer des tests, publier un paquet. En réalité, il décrit une petite machine d’exécution qui peut lire des secrets, utiliser un GITHUB_TOKEN, accéder à un registre privé ou produire un artefact signé. Si un compte est compromis et pousse une modification dans le répertoire .github/workflows, le texte revu par les mainteneurs peut devenir une commande d’exfiltration dès que le prochain événement démarre.
GitHub explique que les attaques récentes ciblent précisément ce maillon : des identifiants volés servent à déposer des workflows capables de récupérer des informations de CI/CD, puis d’enchaîner d’autres actions. La nouvelle protection ne prétend pas comprendre parfaitement l’intention du code. Elle ajoute une barrière opérationnelle : certains déclenchements sont mis en attente, et une personne ayant les droits d’écriture doit les valider.
La nuance compte. Cette fonction concerne actuellement les dépôts publics sur github.com. GitHub Enterprise Server n’en bénéficie pas encore, et la documentation générale conserve ses propres réglages pour les workflows provenant de forks. Ce n’est donc pas un interrupteur magique qui transforme chaque pipeline en bunker ; c’est une détection ciblée qui réduit la vitesse d’une attaque suffisamment visible.
Illustration : visuel officiel de l’annonce GitHub Actions sur la mise en attente des workflows potentiellement malveillants. Source : GitHub Changelog — https://github.blog/changelog/2026-07-28-github-actions-holds-potentially-malicious-workflows-for-approval/
Une approbation ne remplace pas les permissions minimales
Le piège serait de croire qu’un bouton « approuver » suffit. La documentation GitHub rappelle que les workflows issus de forks peuvent exécuter du code contrôlé par un contributeur externe. Les règles d’approbation limitent le démarrage, mais elles ne rendent pas le code fiable après validation. Avec un exécuteur auto-hébergé, la prudence doit être encore plus sèche : le code finalement lancé touche une infrastructure qui dépasse largement la machine éphémère d’un fournisseur.
La première vérification doit porter sur les changements eux-mêmes, surtout dans .github/workflows. Ensuite viennent les permissions : un pipeline de test n’a normalement pas besoin d’écrire dans les paquets, de créer des demandes de fusion et de lire tous les secrets de l’organisation. Déclarer permissions: contents: read au niveau global, puis ouvrir une permission uniquement pour l’étape qui en a besoin, est moins spectaculaire qu’un nouveau produit de sécurité, mais nettement plus utile.
Il faut aussi se méfier de pull_request_target. Cet événement s’exécute dans le contexte de la branche de base et peut donc recevoir des secrets et un jeton plus puissant. GitHub recommande de ne pas récupérer puis exécuter le code non fiable de la demande de fusion dans ce contexte. Sinon, tu obtiens le classique « pwn request » : un dépôt accepte une contribution externe et lui offre, par une combinaison de déclencheur et de checkout, les clés de la maison.
La même semaine, npm serre les boulons
GitHub n’a pas limité le chantier aux workflows. npm a annoncé l’analyse automatique des paquets au moment de leur publication. Un paquet nouvellement envoyé peut être publié normalement, retenu pour une revue manuelle ou bloqué. Le délai annoncé tourne généralement autour de cinq minutes, avec des pointes pouvant dépasser quinze minutes. Les chaînes de publication qui supposent qu’un paquet est installable à la milliseconde vont donc devoir arrêter de confondre vitesse et disponibilité.
Les paquets aux capacités de sécurité ambivalentes doivent en plus déclarer un champ contentPolicy dans package.json et fournir un fichier DISCLOSURE à la racine. La déclaration n’autorise rien automatiquement : elle donne du contexte aux contrôles et peut déclencher une analyse adaptée. Pour publier ce type de paquet directement, npm exige une méthode avec authentification à deux facteurs, comme le trusted publishing par OIDC ou une publication progressive validée par un humain.
Le 31 juillet, GitHub a ajouté une autre restriction aux jetons npm capables de contourner le 2FA. Ils ne peuvent plus gérer des réglages sensibles du compte, des organisations ou des paquets sans défi interactif. La publication directe doit à son tour disparaître de ce type de jeton, avec une cible annoncée pour janvier 2027. Le message est limpide : un secret automatisé ne devrait pas pouvoir fabriquer un nouveau secret qui lui survivra.
Dependabot voit enfin le malware comme une catégorie
La troisième pièce du puzzle vient de Dependabot. La base GitHub Advisory Database ingère désormais les avis du dépôt OpenSSF Malicious Packages, ce qui élargit la couverture aux paquets malveillants de plusieurs écosystèmes, notamment npm et PyPI. Les équipes peuvent filtrer ces avis avec type:malware et recevoir des alertes si une dépendance correspondante est utilisée.
L’intérêt n’est pas de remplacer une analyse comportementale par une case à cocher. Le dépôt OpenSSF publie des rapports au format OSV, réutilisable par l’API OSV, osv-scanner et d’autres outils. Une information communautaire devient ainsi exploitable par les chaînes existantes, au lieu de rester dans un billet de blog que personne ne relira après l’incident.
Cela complète, sans l’annuler, le travail déjà fait côté verrouillage des versions, fichiers de blocage et âge minimal des paquets. Une dépendance publiée depuis dix minutes mérite davantage de suspicion qu’une version installée depuis deux ans, même si les deux portent un nom parfaitement respectable. Les attaquants adorent les noms respectables : c’est moins fatigant que d’inventer une marque.
Ce que tu dois changer dans tes dépôts
Commence par auditer les workflows, pas par acheter une nouvelle console. Liste les événements qui déclenchent des jobs, les permissions du GITHUB_TOKEN, les secrets réellement transmis et les actions tierces utilisées. Épingle les actions par commit lorsque c’est possible, sépare les tests de la publication et réserve les exécuteurs auto-hébergés aux tâches dont le périmètre est compris.
Ensuite, fais fonctionner les protections comme une chaîne : approbation des workflows suspects, analyse des dépendances, verrouillage des publications et alertes sur les changements de mainteneurs ou de scripts d’installation. Ajoute une vérification humaine pour les exceptions, mais évite la validation automatique « parce que le pipeline est rouge ». Une personne qui approuve un fichier qu’elle n’a pas lu n’est qu’un bouton avec un badge.
L’annonce de GitHub est donc utile précisément parce qu’elle est limitée. Elle ralentit certains scénarios, mais elle ne corrige ni une permission trop large, ni un workflow dangereux, ni un exécuteur mal isolé. La chaîne logicielle ne devient pas sûre en ajoutant une seule barrière : elle le devient quand chaque étape cesse de faire confiance à la suivante par défaut.
Sources
GitHub Changelog, « GitHub Actions holds potentially malicious workflows for approval », 28 juillet 2026 — https://github.blog/changelog/2026-07-28-github-actions-holds-potentially-malicious-workflows-for-approval/ — mise en attente et périmètre de la nouvelle protection.
GitHub Changelog, « npm publish-time malware scanning and dual-use metadata », 28 juillet 2026 — https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/ — analyse à la publication et règles pour les paquets à double usage.
GitHub Changelog, « Dependabot alerts on malicious packages across more ecosystems », 28 juillet 2026 — https://github.blog/changelog/2026-07-28-dependabot-alerts-on-malicious-packages-across-more-ecosystems/ — intégration des avis OpenSSF dans la base GitHub.
GitHub Changelog, « Restricting npm bypass-2FA granular access tokens », 31 juillet 2026 — https://github.blog/changelog/2026-07-31-restricting-npm-bypass-2fa-granular-access-tokens/ — restrictions sur les jetons npm contournant le 2FA.
OpenSSF, « What Is a Dependency Firewall? », 28 juillet 2026 — https://openssf.org/blog/2026/07/28/what-is-a-dependency-firewall/ — contrôles avant installation, âge minimal et dépendances transitives.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet