Détectez les erreurs de workflow et les failles de sécurité avant de pousser.

Deux choses à la fois. D’abord, il analyse le YAML de votre workflow et signale les erreurs de syntaxe, les mauvaises indentations et les erreurs structurelles — celles qui font échouer une exécution avant même qu’une seule étape ne s’exécute. Ensuite, et c’est le plus important, il exécute un ensemble de contrôles de mauvaise configuration de sécurité que les linters ordinaires ignorent : le motif « pwn request » pull_request_target + checkout, l’injection de script via des expressions ${{ github.* }} non fiables, les actions tierces épinglées à un tag mutable plutôt qu’à un SHA de commit, et les permissions trop larges telles que write-all. Vous obtenez les erreurs et les motifs dangereux en une seule passe.

Non. Le validateur s’exécute à 100 % côté client. Le YAML de votre workflow est analysé à l’intérieur de votre onglet de navigateur — rien n’est envoyé à un serveur, et il n’y a ni compte ni inscription. Vous pouvez coller en toute sécurité des workflows internes ou propriétaires, y compris ceux contenant des noms de secrets et des étiquettes de runner privées.

actionlint excelle dans la syntaxe, le typage des expressions et l’intégration de shellcheck — et vous devriez continuer à l’utiliser. Mais les erreurs qui compromettent réellement les dépôts sont des erreurs de sécurité : exécuter du code non fiable avec un jeton privilégié, interpoler du texte contrôlé par un attaquant directement dans un shell, ou récupérer une action tierce par un tag que son auteur peut déplacer en silence. Cet outil se concentre sur ces mauvaises configurations de sécurité, valide aussi le YAML, et ne nécessite aucune installation.

Un workflow déclenché par pull_request_target s’exécute dans le contexte du dépôt de base — avec accès à ses secrets et un GITHUB_TOKEN en lecture/écriture — mais il peut être déclenché par une pull request provenant de n’importe quel fork. Si ce workflow extrait également le head de la PR (actions/checkout avec la ref de la PR) puis compile, teste ou exécute des scripts à partir de celui-ci, le code du fork d’un attaquant s’exécute avec vos secrets. C’est la classique « pwn request ». Le validateur signale pull_request_target chaque fois qu’il est associé à un checkout de code de PR non fiable.

Lorsque vous intégrez une expression comme ${{ github.event.issue.title }} ou ${{ github.head_ref }} directement dans un bloc shell run:, GitHub substitue la valeur brute, contrôlable par l’attaquant, dans votre script avant que le shell ne l’analyse. Un titre tel que a"; rm -rf / # devient exécutable. La solution consiste à transmettre les valeurs non fiables via une variable env: et à les référencer sous la forme "$TITLE" afin que le shell les traite comme des données, jamais comme du code. Le validateur signale les expressions de contexte github non fiables utilisées à l’intérieur des étapes run.

Une référence comme actions/checkout@v4 ou some-org/action@main pointe vers un tag ou une branche que le mainteneur de l’action — ou un attaquant qui compromet son compte — peut déplacer vers du nouveau code à tout moment, et ce code s’exécute dans votre pipeline avec votre jeton. Épingler à un SHA de commit complet de 40 caractères (uses: actions/checkout@<sha>) rend la version immuable. Le validateur signale les actions tierces épinglées à un tag ou une branche mutable.

Non. Ce validateur est un outil communautaire indépendant et n’est ni affilié à GitHub, Inc., ni approuvé ou sponsorisé par celle-ci. « GitHub » et « GitHub Actions » ne sont utilisés ici qu’à titre descriptif, pour identifier le format de workflow que l’outil vérifie.

Collez le YAML du workflow dans un validateur basé sur le navigateur pour détecter les erreurs avant de valider — aucune installation ni aucun push nécessaires. Cet outil exécute l’ensemble complet des contrôles (structure YAML plus mauvaises configurations de sécurité) entièrement dans votre navigateur, vous obtenez donc un retour instantané sur les erreurs de syntaxe, l’absence de runs-on, les mauvais noms de déclencheurs et les motifs dangereux comme les actions non épinglées ou l’injection de script avant que le workflow n’atteigne GitHub.

Les problèmes fréquents incluent un runs-on manquant sur un job, une étape qui spécifie à la fois uses et run, une référence needs pointant vers un job qui n’existe pas, un nom d’événement déclencheur invalide, et une mauvaise indentation YAML. Le validateur détecte chacun d’eux comme des erreurs structurelles avec le numéro de ligne où le problème se produit, afin que vous puissiez les corriger avant que l’exécution n’échoue sur GitHub.

La plupart des vérificateurs statiques — actionlint, zizmor, action-validator — nécessitent une CLI ou une chaîne d’outils Rust/Go. Ce validateur est gratuit, ne nécessite ni installation ni inscription, et s’exécute entièrement dans votre navigateur. Il vérifie à la fois la validité du YAML et les mauvaises configurations de sécurité (actions non épinglées, injection de modèle, déclencheurs dangereux, permissions de jeton trop larges) que couvrent les outils en ligne de commande, sans aucune configuration locale.