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 shell-injectando la tua stessa pipeline. Lo scanner taint ogni input non fidato e lo segue attraverso ogni step finché atterra in una shell, anche attraverso composite action.
@v3, @main, @latest, ogni ref fluttuante è un futuro incidente supply-chain. Lo scanner flagga ogni action non pinnata a un SHA completo, ogni action da publisher non verificato, e fa cross-reference contro 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 su artefatti, secret cotti nei layer 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. Tainttiamo 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 di 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 stato già exploited.
Sì. Ogni voce `uses:` è cross-referenziata contro 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 flaggati separatamente, 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 è flaggato anche nei file CI/CD. Rileviamo anche secret passati come argomenti posizionali CLI (visibili in `ps`), secret loggati via `echo` e secret cotti 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, flagghiamo guardie tipo `actions/cleanup` mancanti, e avvertiamo su job che si elevano a root o montano la socket Docker.
Senza carta di credito. Senza call di setup. Scegli il tuo agente, incolla il comando, e Cybe applica le tue regole dal prossimo prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP hosted, nessuna installazione. Registra solo l'URL nel tuo agente.