Webinar in ingleseWebinar con Jason Lee, mer 14 ottYour newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkIscriviti

Le tue pipeline sono codice. Quindi le leggiamo.

I tuoi file di workflow letti come codice: injection, action non pinnate, token e trust, ognuno con la sua correzione.

Prova il cloudScopri VibeDefend
checkout-apiCI/CDProgetto dimostrativo
  • CriticaInjection in un workflowrelease.yml:24

    Il titolo della pull request arriva a run: nella shell.

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

    Fix prontoIl titolo passa in una variabile d'ambiente, fuori dalla shell.

Le falle della pipeline, trovate nel file.

  • Injection in un workflow

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

  • Action non pinnate

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

  • Token con troppi privilegi

    • permissions: write-all

  • Fiducia OIDC

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

L'injection, corretta nel workflow.

Come è scritto

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

Il titolo della pull request arriva a run: nella shell.

Con la correzione

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

Il titolo passa in una variabile d'ambiente, fuori dalla shell.

Corretto dal tuo agente, nella sessione.

Il tuo agente legge questi finding mentre scrive e li corregge nella stessa sessione.

Scopri VibeDefend
  1. CI/CDScansiona il repository a ogni push.Trovato
  2. VibeDefendPassa il finding al tuo agente di codice.Servito
  3. Il tuo agenteLo corregge nella sessione.Corretto
  4. CommitEntra senza la falla.Pulito
  • Claude Code
  • Cursor
  • Windsurf
  • GitHub Copilot
  • OpenAI Codex

Inizia da un repository.

Collega GitHub, GitLab, Bitbucket o Azure DevOps, scegli un repository e la prima scansione parte.

Prova il cloudPrenota una demo

Nel dettaglio

Sei falle di pipeline, trovate nel file.

  • Injection in un workflow

    Dati degli eventi, nomi di branch o titoli di pull request che arrivano a un blocco run:.

    CWE-77, CWE-78

  • Action non pinnate

    @v3, @main, @latest: ogni riferimento mobile è un futuro incidente di supply chain.

  • Token con troppi privilegi

    Nessun blocco permissions:, o permessi di scrittura che un job non usa mai.

  • Fiducia OIDC

    Identità federata da GitHub, GitLab o CircleCI verso AWS, Azure e GCP, concessa troppo ampiamente.

  • Fughe di segreti

    echo $SECRET, segreti passati come argomenti, lasciati negli artefatti o nei layer delle immagini.

  • Avvelenamento di cache e artefatti

    Pull request non affidabili che scrivono in cache lette dai branch protetti.

Tutto quello che controlla

Intercetta la misconfig prima che il runner giri.

La maggior parte degli incidenti di pipeline è già visibile nello YAML. Lo leggiamo come lo legge un attaccante.

  • Le pipeline, un asset a tutti gli effetti

    I file di workflow vengono analizzati con lo stesso rigore del tuo codice applicativo: parsing dell'AST, propagazione del taint, analisi da source a sink.

  • GitHub Actions, GitLab CI, Jenkinsfile

    Parser dedicati ai dialetti CI su cui gira oggi la maggior parte delle pipeline, inclusi i workflow riutilizzabili, le catene include: di GitLab e i Jenkinsfile (Groovy dichiarativo e scripted).

  • I finding arrivano nella PR

    Ogni finding compare come commento inline sulla riga YAML incriminata, come per il SAST.

Sei falle di pipeline, trovate nel file.

Convertiamo i tuoi workflow in un AST e in un grafo del flusso dei dati, poi applichiamo i nostri rule pack.

  • Workflow injection (CWE-77 / 78)

    Ogni volta che inserisci ${{ github.event.* }}, nomi di branch, titoli di PR o il testo delle issue in un blocco run:, esponi la tua stessa pipeline alla shell injection.

  • Action non pinnate e non affidabili

    @v3, @main, @latest: ogni riferimento mobile è un futuro incidente di supply chain.

  • Token troppo permissivi

    Per impostazione predefinita il GITHUB_TOKEN ha permessi write su quasi tutto. Rileviamo permissions: non impostati e scope troppo ampi che non usi, e suggeriamo il set minimo per ogni job.

  • Trust OIDC mal configurato

    Identità federata AWS, Azure e GCP da GitHub, GitLab e CircleCI.

  • Secret che trapelano

    echo $SECRET, secret passati come argomenti posizionali, secret loggati negli artefatti, secret incorporati nei layer del container.

  • Poisoning di cache e artefatti

    PR non fidate che scrivono in cache lette da branch protetti. Riuso di self-hosted runner senza isolamento.

Dallo YAML al fix

  • Lo YAML è insicuro.

    Trigger insicuro, scrittura, action non fissata.

  • Giudicato prima del run.

    Statico, sul file stesso, senza pipeline.

  • Fissato e limitato.

    SHA fissato, scope in sola lettura, input isolati.

Collega il repo, il resto è automatico.

Collega GitHub o GitLab. I nostri scanner pullano i file di pipeline e girano a ogni push (o a richiesta). Nulla da installare nella tua CI, nessuno step runner privilegiato. I finding affluiscono nella dashboard unificata e nella tua review PR.

Sei dialetti CI alimentano un solo parser: GitHub Actions, GitLab CI, Bitbucket, Azure DevOps, Jenkins, CircleCI.

Il commit a3f9c2e modifica release.yml. Dalla build partono due run: #4821 e #4822.

Al gate, release.yml viene letto come lo leggerebbe un attaccante: trigger, permessi, ogni uses: e run:.

#4821 è bloccata: pull_request_target con contents: write e un'action non pinnata non arrivano mai al job di deploy.

#4822 va in prod-eu: SHA pinnato, token in sola lettura, il titolo della PR tenuto fuori dalla shell.

Domande frequenti sullo scanner CI/CD.

Analizzate i file della pipeline dall'esterno, senza aggiungere uno step?
Esatto. Collega il repo una volta. I nostri scanner leggono direttamente .github/workflows, .gitlab-ci.yml, Jenkinsfile e gli altri, poi riportano i finding come commenti inline sulla riga incriminata e nella dashboard unificata. Nessuno step da aggiungere alla tua pipeline, nessun runner privilegiato da installare.
Quali formati di pipeline supportate?
Workflow di GitHub Actions (compresi i workflow compositi e riutilizzabili), YAML di GitLab CI (comprese le catene `include:`) e Jenkinsfile (Groovy dichiarativo e scripted). Leggiamo anche le definizioni delle action (action.yml e i wrapper Dockerfile), così seguiamo il taint anche da un'action all'altra. Altri dialetti vengono aggiunti su richiesta dei clienti.
Come trovate una workflow injection che si attiva solo con certi payload?
Il payload non ci serve. Marchiamo come contaminato (tainted) ogni valore che arriva da `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body` e dai ref di branch e tag provenienti da un fork, e lo seguiamo attraverso `env:`, `with:`, i valori di output e i confini delle composite action. Se il valore contaminato raggiunge un blocco `run:`, un `eval` in una action JavaScript o un comando con sostituzione di shell, è un finding, anche se nessuno ha ancora sfruttato la falla.
Intercettate GitHub Action malevole o di typosquatting?
Sì. Ogni voce `uses:` viene confrontata con il feed OpenSSF delle action malevole, con l'elenco dei publisher verificati e con le nostre euristiche di typosquatting sui nomi delle action. I tag non pinnati vengono segnalati a parte, perché anche un'action legittima diventa un rischio di supply chain se non la fissi a uno SHA.
E i secret nei file di workflow?
Tutto ciò che corrisponde ai pattern di entropia e dei provider del nostro rule pack Secret Detection viene segnalato anche nei file CI/CD. Rileviamo inoltre i secret passati come argomenti posizionali della CLI (visibili con `ps`), quelli scritti nei log con `echo` e quelli incorporati negli input dei workflow riutilizzabili. I finding vengono deduplicati con lo scanner dei secret, così non li vedi due volte.
Potete analizzare configurazioni di runner self-hosted?
Sì. Analizziamo le direttive `runs-on:`, rileviamo i runner che condividono lo stato del filesystem tra PR non affidabili, segnaliamo l'assenza di protezioni come `actions/cleanup` e avvisiamo sui job che ottengono i privilegi di root o montano il socket Docker.