Un scanner de sécurité CI/CD dédié. Analyse statique sur les fichiers de workflow de votre repo : workflow injection, actions non pinnées, tokens trop privilégiés, dérive OIDC. Détectés avant que le moindre runner ne prenne le job.
Nos scanners parsent vos fichiers de pipeline en AST et en graphe de dataflow, puis appliquent des packs de règles propriétaires nourris par OpenSSF Secure Workflows, les playbooks StepSecurity et nos propres recherches sur les incidents de poisoning observés en prod. Les findings remontent dans le dashboard unifié à côté du SAST, du SCA, de l'IaC, des secrets et du Container.
Dès que vous interpolez ${{ github.event.* }}, un nom de branche, un titre de PR ou un body d'issue dans un bloc `run:`, vous shell-injectez votre propre pipeline. Le scanner taint chaque input non fiable et le suit à travers chaque étape jusqu'au shell, même à travers les composite actions.
@v3, @main, @latest, chaque ref flottante est un futur incident supply-chain. Le scanner flagge chaque action non pinnée à un SHA complet, chaque action publiée par un éditeur non vérifié, et croise avec le feed des actions malicieuses connues.
Les scopes par défaut du GITHUB_TOKEN sont `write` à presque tout. On détecte les `permissions:` non définies, les scopes larges inutilisés, et on recommande le minimum par job.
Identité fédérée AWS, Azure et GCP depuis GitHub, GitLab et CircleCI. On détecte les patterns `sub` trop larges, les audience checks manquants et les trust policies que n'importe quel fork peut assumer.
`echo $SECRET`, secrets passés en argument positionnel, secrets loggés dans des artefacts, secrets baked dans des couches d'image. Détectés statiquement, avant que le runner émette une seule ligne.
PR non fiables qui écrivent dans des caches lus par des branches protégées. Runners self-hosted réutilisés sans isolation. Upload d'artefact depuis des contextes non fiables. Toute la classe de CVE cache-poisoning post-2024.
La plupart des incidents de pipeline sont visibles dans le YAML. On le lit comme un attaquant le lit, statiquement, avec tout le contexte de dataflow, pour que le finding atterrisse dans la review de PR, pas dans un retro post-incident.
Vos fichiers de workflow reçoivent la même attention que votre code applicatif : parsing AST, propagation de taint, analyse source-to-sink. Le threat model est spécifique au pipeline : triggers non fiables, sources d'actions, scopes de token, trust OIDC, isolation runner.
Parsers de premier rang pour les dialectes CI qui font tourner la majorité des pipelines aujourd'hui : workflows réutilisables, chaînes `include:` GitLab et Jenkinsfile (déclaratif et scripté Groovy). De nouveaux dialectes sont ajoutés à la demande.
Chaque finding atterrit en commentaire inline sur la ligne YAML concernée, même surface que le SAST. Pas de nouveau dashboard à apprendre, pas de file de triage séparée, pas d'étape runner privilégiée à installer.
Connectez GitHub ou GitLab. Nos scanners récupèrent les fichiers de pipeline et tournent à chaque push (ou à la demande). Rien à installer dans votre CI, pas d'étape runner privilégiée. Les findings remontent dans le dashboard unifié et dans votre review de PR.
Voir toutes les intégrationsExactement. Connectez le repo une seule fois. Nos scanners lisent .github/workflows, .gitlab-ci.yml, Jenkinsfile et le reste directement, puis les findings remontent en commentaire inline sur la ligne concernée et dans le dashboard unifié. Aucune étape à ajouter à votre pipeline, aucun runner privilégié à installer.
Workflows GitHub Actions (y compris workflows composites et réutilisables), GitLab CI YAML (y compris les chaînes `include:`) et Jenkinsfile (déclaratif et scripté Groovy). Les définitions d'actions (action.yml plus wrappers Dockerfile-action) sont lues aussi, pour suivre les flux de taint cross-action. D'autres dialectes sont ajoutés à la demande client.
Nous n'avons pas besoin du payload. Nous tagons en taint chaque valeur issue de `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body`, des refs de branche et de tag depuis un fork, puis nous la suivons à travers `env:`, `with:`, les outputs et les frontières des composite actions. Si la valeur taintée atteint un bloc `run:`, un `eval` dans une action JavaScript ou une commande shell-substituée, c'est un finding, que vous ayez été exploité ou non.
Oui. Chaque entrée `uses:` est croisée avec le feed OpenSSF des actions malicieuses, la liste des éditeurs vérifiés et nos propres heuristiques de typo-squat sur les noms d'actions. Les tags non pinnés sont flaggés séparément, parce qu'une action légitime devient un risque supply-chain si elle n'est pas pinnée à un SHA.
Tout ce qui correspond aux patterns d'entropie et de providers du pack Secret Detection est flaggé dans les fichiers CI/CD aussi. Nous détectons également les secrets passés en argument positionnel CLI (visibles dans `ps`), les secrets loggés via `echo` et les secrets baked dans les inputs de workflow réutilisable. Les findings sont dédupliqués avec le scanner de secrets, vous ne les voyez pas deux fois.
Oui. Nous parsons les directives `runs-on:`, détectons les runners avec un état filesystem partagé entre PR non fiables, flaggons les guards `actions/cleanup` manquants et warnons sur les jobs qui élèvent en root ou montent le socket Docker.
Sans carte bancaire. Sans appel de configuration. Choisissez votre agent, collez la commande, Cybe applique vos règles dès le prochain prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpMCP hébergé, aucune install. Enregistrez juste l'URL dans votre agent.