Webinar en anglaisWebinar avec Jason Lee, mer. 14 oct.Your newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkS'inscrire

Vos pipelines sont du code. Alors on les lit.

Vos fichiers de workflow lus comme du code : injection, actions non épinglées, jetons et confiance, chacun avec son correctif.

Essayer le cloudDécouvrir VibeDefend
checkout-apiCI/CDProjet de démonstration
  • CritiqueInjection dans un workflowrelease.yml:24

    Le titre de la pull request atteint run: dans le shell.

    run: echo "${{ github.event.pull_request.title }}"env:  TITLE: ${{ github.event.pull_request.title }}run: echo "$TITLE"

    Correctif prêtLe titre passe par une variable d'environnement, hors du shell.

Les failles du pipeline, trouvées dans le fichier.

  • Injection dans un workflow

    • ${{ github.event.pull_request.title }}

  • Actions non épinglées

    • actions/checkout@v3
    • actions/setup-node@main

  • Tokens aux droits excessifs

    • permissions: write-all

  • Confiance OIDC

    • "sub": "repo:acme/*"

L'injection, corrigée dans le workflow.

Tel qu'écrit

run: echo "${{ github.event.pull_request.title }}"

Le titre de la pull request atteint run: dans le shell.

Avec le correctif

env:  TITLE: ${{ github.event.pull_request.title }}run: echo "$TITLE"

Le titre passe par une variable d'environnement, hors du shell.

Corrigé par votre agent, dans la session.

Votre agent lit ces résultats pendant qu'il écrit, et les corrige dans la même session.

Découvrir VibeDefend
  1. CI/CDScanne le dépôt à chaque push.Détectée
  2. VibeDefendTransmet l'alerte à votre agent de code.Servie
  3. Votre agentLa corrige dans la session.Corrigée
  4. CommitPart sans la faille.Propre
  • Claude Code
  • Cursor
  • Windsurf
  • GitHub Copilot
  • OpenAI Codex

Commencez par un dépôt.

Connectez GitHub, GitLab, Bitbucket ou Azure DevOps, choisissez un dépôt, et le premier scan démarre.

Essayer le cloudRéserver une démo

En détail

Six failles de pipeline, trouvées dans le fichier.

  • Injection dans un workflow

    Des données d'événement, des noms de branche ou des titres de pull request qui atteignent un bloc run:.

    CWE-77, CWE-78

  • Actions non épinglées

    @v3, @main, @latest : chaque référence flottante est un futur incident de supply chain.

  • Tokens aux droits excessifs

    Aucun bloc permissions:, ou des droits d'écriture qu'un job n'utilise jamais.

  • Confiance OIDC

    Une identité fédérée de GitHub, GitLab ou CircleCI vers AWS, Azure et GCP, accordée trop largement.

  • Fuites de secrets

    echo $SECRET, des secrets passés en argument, laissés dans des artefacts ou des couches d'image.

  • Empoisonnement de cache et d'artefacts

    Des pull requests non fiables qui écrivent dans des caches lus par les branches protégées.

Tout ce qu'il vérifie

Repérez l'erreur de config avant que le runner ne tourne.

La plupart des incidents de pipeline sont déjà visibles dans le YAML. Nous le lisons comme un attaquant.

  • Les pipelines, un actif à part entière

    Vos fichiers de workflow reçoivent la même attention que votre code applicatif : analyse de l'AST, propagation de taint, analyse de la source au sink.

  • GitHub Actions, GitLab CI, Jenkinsfile

    Des parsers dédiés aux dialectes de CI qui font tourner la majorité des pipelines aujourd'hui : workflows réutilisables, chaînes include: de GitLab et Jenkinsfile (Groovy déclaratif et scripté).

  • Les alertes arrivent dans la PR

    Chaque alerte arrive en commentaire sur la ligne YAML fautive, au même endroit que celles du SAST.

Six failles de pipeline, lues dans le fichier.

Nous analysons vos workflows sous forme d'AST et de graphe de flux de données, puis nous appliquons nos propres jeux de règles.

  • Injection dans les workflows (CWE-77 / 78)

    Dès que vous interpolez ${{ github.event.* }}, un nom de branche, un titre de PR ou le corps d'une issue dans un bloc run:, vous ouvrez votre propre pipeline à l'injection shell.

  • Actions non épinglées et non vérifiées

    @v3, @main, @latest : chaque référence flottante est un futur incident de supply chain.

  • Tokens aux droits excessifs

    Par défaut, le GITHUB_TOKEN a les droits write sur presque tout. Nous détectons les permissions: non définies et les droits trop larges que vous n'utilisez pas, et recommandons le strict minimum pour chaque job.

  • Confiance OIDC mal configurée

    Identité fédérée AWS, Azure et GCP depuis GitHub, GitLab et CircleCI.

  • Schémas de fuite de secrets

    echo $SECRET, secrets passés en argument positionnel, secrets journalisés dans des artefacts, secrets intégrés en dur dans des couches de conteneur.

  • Empoisonnement de cache et d'artefact

    PR non fiables qui écrivent dans des caches lus par des branches protégées. Runners auto-hébergés réutilisés sans isolation.

Du YAML au correctif

  • Le YAML est risqué.

    Déclencheur risqué, droits en écriture, action non épinglée.

  • Jugé avant l'exécution.

    Statique, sur le fichier lui-même, sans pipeline.

  • Épinglé et restreint.

    SHA épinglé, droits en lecture, entrées isolées.

Connectez le dépôt, le reste est automatique.

Connectez GitHub ou GitLab. Nos scanners récupèrent les fichiers de pipeline et tournent à chaque push (ou à la demande). Rien à installer dans votre CI, aucune étape privilégiée sur un runner. Les alertes arrivent dans le dashboard unifié et dans la revue de votre PR.

Six dialectes CI alimentent un seul parseur : GitHub Actions, GitLab CI, Bitbucket, Azure DevOps, Jenkins, CircleCI.

Le commit a3f9c2e touche release.yml. Deux runs sortent du build : #4821 et #4822.

Au point de contrôle, release.yml est lu comme le lirait un attaquant : déclencheur, permissions, chaque uses: et run:.

#4821 est bloqué : pull_request_target avec contents: write et une action non épinglée n'atteignent jamais le job de déploiement.

#4822 part en prod-eu : SHA épinglé, token en lecture seule, le titre de la PR tenu à l'écart du shell.

Questions fréquentes sur le scanner CI/CD.

Vous scannez mes fichiers de pipeline sans ajouter d'étape dans le pipeline ?
Exactement. Connectez le dépôt une seule fois. Nos scanners lisent directement .github/workflows, .gitlab-ci.yml, Jenkinsfile et les autres fichiers, puis signalent les alertes en commentaire sur la ligne fautive et dans le dashboard unifié. Aucune étape à ajouter à votre pipeline, aucun runner privilégié à installer.
Quels formats de fichiers de pipeline savez-vous analyser ?
Workflows GitHub Actions (y compris les workflows composites et réutilisables), GitLab CI YAML (y compris les chaînes `include:`) et Jenkinsfile (Groovy déclaratif et scripté). Les définitions d'actions (action.yml et les wrappers d'actions Dockerfile) sont lues elles aussi, pour suivre les flux de taint d'une action à l'autre. D'autres dialectes s'ajoutent à la demande de nos clients.
Comment détectez-vous une injection de workflow qui ne se déclenche qu'avec certains payloads ?
Nous n'avons pas besoin du payload. Nous considérons comme contaminée chaque valeur issue de `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body`, des refs de branche et de tag venant d'un fork, puis nous la suivons à travers `env:`, `with:`, les valeurs de sortie et les frontières des composite actions. Si la valeur contaminée atteint un bloc `run:`, un `eval` dans une action JavaScript ou une commande avec substitution shell, c'est une alerte, que vous ayez déjà été exploité ou non.
Détectez-vous les GitHub Actions malveillantes ou victimes de typosquatting ?
Oui. Chaque entrée `uses:` est croisée avec le flux OpenSSF des actions malveillantes, la liste des éditeurs vérifiés et nos propres heuristiques de typosquatting sur les noms d'actions. Les tags non épinglés sont signalés à part, car même une action légitime devient un risque de supply chain si elle n'est pas épinglée sur un SHA.
Et les secrets dans les fichiers de workflow ?
Tout ce qui correspond aux motifs d'entropie et de fournisseurs du jeu de règles Secret Detection est aussi signalé dans les fichiers CI/CD. Nous détectons également les secrets passés en argument positionnel de CLI (visibles dans `ps`), les secrets écrits dans les logs via `echo` et les secrets figés dans les inputs de workflows réutilisables. Les alertes sont dédupliquées avec celles du scanner de secrets : vous ne les voyez pas deux fois.
Pouvez-vous scanner la configuration des runners auto-hébergés ?
Oui. Nous analysons les directives `runs-on:`, détectons les runners dont le système de fichiers est partagé entre des PR non fiables, signalons les contrôles de type `actions/cleanup` manquants et alertons sur les jobs qui passent en root ou montent le socket Docker.