A dedicated CI/CD security scanner. Static analysis on the workflow files in your repo: workflow injection, unpinned actions, over-privileged tokens, OIDC drift. Caught before any runner picks up the job.
Our scanners parse your pipeline configs into an AST and a dataflow graph, then run proprietary rule packs informed by OpenSSF Secure Workflows, StepSecurity playbooks and our own research on real-world poisoning incidents. Findings flow into the unified dashboard alongside SAST, SCA, IaC, Secrets and Container.
Any time you interpolate ${{ github.event.* }}, branch names, PR titles or issue bodies into a `run:` block, you're shell-injecting your own pipeline. The scanner taints every untrusted input and follows it through every step until it lands in a shell, even across composite actions.
@v3, @main, @latest, every floating ref is a future supply-chain incident. The scanner flags every action not pinned to a full SHA, every action from an unverified publisher, and cross-references against the malicious-action feed.
Default GITHUB_TOKEN scopes are `write` to almost everything. We detect unset `permissions:`, broad scopes you don't use, and recommend the minimal set per job.
AWS, Azure and GCP federated identity from GitHub, GitLab and CircleCI. We catch overly broad `sub` patterns, missing audience checks and trust policies that any fork can assume.
`echo $SECRET`, secrets passed as positional args, secrets logged to artefacts, secrets baked into container layers. Detected statically, before the runner emits a single line.
Untrusted PRs writing to caches that protected branches read from. Self-hosted runner reuse without isolation. Artefact uploads from untrusted contexts. The whole class of post-2024 cache-poisoning CVEs.
Most pipeline incidents are visible in the YAML. We read it the way an attacker reads it, statically, with full dataflow context, so the finding lands in the PR review, not in a post-incident retro.
Workflow files get the same scrutiny as your application code: AST parsing, taint propagation, source-to-sink analysis. The threat model is pipeline-specific: untrusted triggers, action sources, token scopes, OIDC trust, runner isolation.
First-class parsers for the CI dialects that ship most pipelines today, including reusable workflows, GitLab `include:` chains and Jenkinsfile (declarative and scripted Groovy). New dialects ship on demand.
Every finding lands as an inline comment on the offending YAML line, same surface as SAST. No new dashboard to learn, no separate triage queue, no privileged runner step to install.
Connect GitHub or GitLab. Our scanners pull the pipeline files and run on every push (or on demand). Nothing to install in your CI, no privileged runner step. Findings flow into the unified dashboard and into your PR review.
Browse all integrationsCorrect. Connect the repo once. Our scanners read .github/workflows, .gitlab-ci.yml, Jenkinsfile and the rest directly, then report findings as inline comments on the offending line and in the unified dashboard. No step to add to your pipeline, no privileged runner to install.
GitHub Actions workflows (including composite and reusable workflows), GitLab CI YAML (including `include:` chains) and Jenkinsfile (declarative and scripted Groovy). Action definitions (action.yml plus Dockerfile-action wrappers) are read too, so cross-action taint flows are tracked. Other dialects are added on customer demand.
We don't need the payload. We taint every value that comes from `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body`, branch and tag refs from a fork, and follow it across `env:`, `with:`, output values and composite-action boundaries. If the tainted value reaches a `run:` block, an `eval` in JavaScript actions, or a shell-substituted command, that is a finding, regardless of whether you've actually been exploited yet.
Yes. Every `uses:` entry is cross-referenced against the OpenSSF malicious-action feed, the verified-publisher list and our own typo-squat heuristics on action names. Unpinned tags flag separately, because even a legitimate action becomes a supply-chain risk if you don't pin to a SHA.
Anything matching the entropy and provider patterns from our Secret Detection rule pack is flagged in CI/CD files too. We also detect secrets passed as positional CLI args (visible in `ps`), secrets logged via `echo`, and secrets baked into reusable workflow inputs. Findings deduplicate with the secrets scanner so you don't get them twice.
Yes. We parse `runs-on:` directives, detect runners with shared filesystem state across untrusted PRs, flag missing `actions/cleanup`-type guards, and warn on jobs that elevate to root or mount the Docker socket.
No credit card. No setup call. Pick your agent, paste the command, and Cybe enforces your rules from the very next prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpHosted MCP, no install. Just register the URL with your agent.