Vos pipelines sont du code. Alors on les lit.

Analyse statique de vos fichiers de workflow. Injections, actions non épinglées, tokens aux droits excessifs, dérive OIDC.

Réserver une démo de 30 min

commita3f9c2e · release.yml

build#4821 · #4822

contrôle CybeDefendrelease.yml read

déploiementprod-eu

bloquépull_request_target · contents: writedéployéuses: @7a3c…e4f · contents: read

commita3f9c2e · release.yml

build#4821 · #4822

contrôle CybeDefendrelease.yml read

déploiementprod-eu

bloquépull_request_target · contents: writedéployéuses: @7a3c…e4f · contents: read

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.

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.

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.

permissions: write-all

permissions:

contents: read

id-token: write

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.

runs-on: self-hosted

runs-on: ubuntu-24.04

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

uses: actions/checkout@v3

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

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

role/deploy › trust policy › sub

repo:acme/*

repo:acme/api:environment:production

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.

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

env:

TITLE: ${{ github.event.pull_request.title }}

run: echo "$TITLE"

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.

run: ./publish.sh ${{ secrets.NPM_TOKEN }}

env:

NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

run: ./publish.sh

Survolez une ligne signalée pour afficher son correctif.Touchez une note pour afficher son correctif.

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.

.github/workflows/release.yml:12source
message: ${{ github.event.pull_request.title }}
.github/workflows/notify.yml:4hop
message: { type: string }
.github/workflows/notify.yml:10sink
run: echo "${{ inputs.message }}"

cybedefendcommented onnotify.yml:10

pull_request.title reaches run: through inputs.message.

run: echo "${{ inputs.message }}"

env: { MSG: "${{ inputs.message }}" }

run: echo "$MSG"

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.