Uno scanner di sicurezza CI/CD dedicato. Analisi statica sui file di workflow nel tuo repo: workflow injection, action non pinnate, token troppo permissivi, drift OIDC. Intercettati prima che qualunque runner prenda il job.
I nostri scanner parsano le tue config di pipeline in un AST e un grafo di dataflow, poi applicano rule pack proprietari nutriti da OpenSSF Secure Workflows, playbook StepSecurity e la nostra ricerca su incidenti di poisoning reali. I finding affluiscono nella dashboard unificata accanto a SAST, SCA, IaC, Secrets e Container.
Ogni volta che interpoli ${{ github.event.* }}, nomi di branch, titoli di PR o body di issue in un blocco `run:`, stai facendo shell injection sulla tua stessa pipeline. Lo scanner marca come tainted ogni input non fidato e lo segue attraverso ogni step finché atterra in una shell, anche attraverso le composite action.
@v3, @main, @latest, ogni ref fluttuante è un futuro incidente supply-chain. Lo scanner segnala ogni action non pinnata a uno SHA completo, ogni action da publisher non verificato, e la incrocia con il feed delle action malevole.
I default scope del GITHUB_TOKEN sono `write` su quasi tutto. Rileviamo `permissions:` non settati, scope larghi che non usi, e raccomandiamo il set minimo per job.
Identità federata AWS, Azure e GCP da GitHub, GitLab e CircleCI. Intercettiamo pattern `sub` troppo larghi, audience check mancanti e trust policy che qualunque fork può assumere.
`echo $SECRET`, secret passati come argomenti posizionali, secret loggati negli artefatti, secret incorporati nei layer del container. Rilevati staticamente, prima che il runner emetta una singola riga.
PR non fidate che scrivono in cache lette da branch protetti. Riuso di self-hosted runner senza isolamento. Upload di artefact da contesti non fidati. L'intera classe di CVE di cache-poisoning post-2024.
La maggior parte degli incidenti di pipeline è visibile nello YAML. Lo leggiamo come lo legge un attaccante, staticamente, con contesto completo di dataflow, così il finding atterra nella review PR, non in un post-mortem.
I file di workflow ricevono lo stesso scrutinio del tuo codice applicativo: parsing AST, propagazione di taint, analisi source-to-sink. Il threat model è specifico per pipeline: trigger non fidati, sorgenti di action, scope di token, trust OIDC, isolamento runner.
Parser di prima classe per i dialetti CI che oggi muovono la maggior parte delle pipeline, inclusi reusable workflow, catene `include:` GitLab e Jenkinsfile (declarative e scripted Groovy). Nuovi dialetti arrivano a richiesta.
Ogni finding atterra come commento inline sulla riga YAML incriminata, stessa superficie del SAST. Nessuna nuova dashboard da imparare, nessuna queue di triage separata, nessuno step runner privilegiato da installare.
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.
Esplora tutte le integrazioniEsatto. 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.
Workflow GitHub Actions (inclusi composite e reusable workflow), YAML GitLab CI (incluse catene `include:`) e Jenkinsfile (declarative e scripted Groovy). Anche le definizioni di action (action.yml più wrapper Dockerfile-action) sono lette, così i taint flow cross-action sono tracciati. Altri dialetti vengono aggiunti su richiesta del cliente.
Non ci serve il payload. Marchiamo come tainted ogni valore che viene da `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body`, ref di branch e tag da un fork, e lo seguiamo attraverso `env:`, `with:`, valori di output e i confini delle composite action. Se il valore tainted raggiunge un blocco `run:`, un `eval` in action JavaScript o un comando con shell substitution, è un finding, indipendentemente dal fatto che tu sia già stato sfruttato.
Sì. Ogni voce `uses:` è incrociata con il feed OpenSSF di action malevole, la lista dei publisher verificati e le nostre euristiche di typo-squat sui nomi di action. I tag non pinnati sono segnalati a parte, perché anche un'action legittima diventa un rischio supply-chain se non la pinni a uno SHA.
Tutto ciò che corrisponde ai pattern di entropia e provider del nostro rule pack Secret Detection viene segnalato anche nei file CI/CD. Rileviamo anche secret passati come argomenti posizionali CLI (visibili in `ps`), secret loggati via `echo` e secret incorporati negli input di reusable workflow. I finding sono deduplicati con lo scanner di secret così non li vedi due volte.
Sì. Parsiamo le direttive `runs-on:`, rileviamo runner con stato filesystem condiviso tra PR non fidate, segnaliamo l'assenza di guardie tipo `actions/cleanup`, e avvertiamo sui job che si elevano a root o montano la socket Docker.
Un solo comando collega ogni agente di coding sulla tua macchina a CybeDefend: le tue regole di business, i tuoi framework di compliance e guards che bloccano le chiamate distruttive prima che partano.
npx -y @cybedefend/vibedefend@latest install
Claude Code
Cursor
OpenAI Codex
Windsurf
VS Code Copilot