As tuas pipelines são código. Por isso lemo-las.

Análise estática dos teus ficheiros de workflow: injeções, actions não fixadas, tokens com privilégios a mais e desvios de OIDC.

Marcar uma demo de 30 min

commita3f9c2e · release.yml

build#4821 · #4822

controlo CybeDefendrelease.yml read

deployprod-eu

bloqueadapull_request_target · contents: writeem produçãouses: @7a3c…e4f · contents: read

commita3f9c2e · release.yml

build#4821 · #4822

controlo CybeDefendrelease.yml read

deployprod-eu

bloqueadapull_request_target · contents: writeem produçãouses: @7a3c…e4f · contents: read

Seis dialetos de CI alimentam um único parser: GitHub Actions, GitLab CI, Bitbucket, Azure DevOps, Jenkins, CircleCI.O commit a3f9c2e toca no release.yml. Duas execuções saem do build: #4821 e #4822.Na barreira, o release.yml é lido como o leria um atacante: trigger, permissões, cada uses: e run:.#4821 fica bloqueada: pull_request_target com contents: write e uma action não fixada nunca chegam ao job de deploy.#4822 segue para prod-eu: SHA fixado, token só de leitura, o título da PR fora da shell.

Seis falhas,
lidas no ficheiro.

Convertemos os teus workflows num AST e num grafo de fluxo de dados e aplicamos-lhes os nossos próprios packs de regras.

Por omissão, as permissões do GITHUB_TOKEN são write para quase tudo. Detetamos permissions: por definir e permissões amplas que não usas, e recomendamos o mínimo necessário para cada job.

permissions: write-all

permissions:

contents: read

id-token: write

PR não fiáveis a escrever em caches lidas por branches protegidos. Runners self-hosted reutilizados sem isolamento.

runs-on: self-hosted

runs-on: ubuntu-24.04

@v3, @main, @latest: cada referência flutuante é um futuro incidente de supply chain.

uses: actions/checkout@v3

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

Identidade federada com AWS, Azure e GCP a partir do GitHub, do GitLab e do CircleCI.

role/deploy › trust policy › sub

repo:acme/*

repo:acme/api:environment:production

Sempre que interpolas ${{ github.event.* }}, nomes de branch, títulos de PR ou o texto das issues num bloco run:, abres a porta a uma injeção de shell na tua própria pipeline.

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

env:

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

run: echo "$TITLE"

echo $SECRET, segredos passados como argumentos posicionais, segredos gravados em artefactos, segredos embutidos em camadas de contentor.

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

env:

NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

run: ./publish.sh

Passa o cursor sobre uma linha assinalada para ver a correção.Toca numa nota para ver a correção.

Apanha a má configuração
antes de o runner correr.

A maioria dos incidentes de pipeline já é visível no YAML. Lemo-lo como o leria um atacante.

.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"

Os ficheiros de workflow são examinados com o mesmo rigor que o código da tua aplicação: análise do AST, propagação de taint e análise de source a sink.