DevSecOps & CI/CD Pipeline Security
DevSecOps and CI/CD security testing by OSCP engineers across Europe. We attack your pipeline the way a real intruder would, then hand you a fixed quote.
DevSecOps and CI/CD security is about the machinery between a commit and production: the runners, tokens, secrets and build steps that quietly hold the keys to everything you ship. We test that machinery the way an attacker would, because a compromised pipeline is a compromise of every application it deploys.
Most teams harden the application and leave the factory that builds it wide open. A pipeline can read your cloud, sign your artifacts and push to production, yet it often runs with standing admin tokens, pulls untrusted pull-request code onto a privileged runner, and stores secrets in plaintext environment variables. One poisoned build step and an intruder owns the deployment path to your whole estate.
What CI/CD security testing actually covers
We map the pipeline as an attack surface: every place code, configuration or a secret enters, every identity the pipeline can assume, and every system it can reach. Then we try to move from the lowest-privilege foothold a real attacker would have, usually a pull request, to code execution on a privileged runner and out into your cloud.
How we test a pipeline
We work against the platforms teams across Europe actually run: GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure DevOps and Bitbucket Pipelines. The methodology follows the OWASP Top 10 CI/CD Security Risks, and we measure the maturity of your controls against SLSA and the NIST Secure Software Development Framework so the report speaks a language auditors already recognise.
Reconnaissance and pipeline mapping
First we read the pipeline definitions and understand the graph: which triggers fire, which jobs run on which runners, what each job can read, and where a fork or a low-privilege contributor can influence a build. This is where most of the interesting attack paths reveal themselves before a single exploit.
Attacking the build
We test whether a pull request can alter what the pipeline executes, whether the default token grants more than the job needs, and whether secrets leak into logs or downstream jobs. On GitHub Actions we check the GITHUB_TOKEN permissions, use of pull_request_target with checkout of untrusted code, and script injection through unescaped run steps. On GitLab we look at protected-branch bypasses and CI/CD variable exposure to non-protected branches.
Poisoned pipeline execution
The classic path: a contributor opens a pull request that modifies a build script or adds a dependency, the pipeline runs it on a privileged runner with access to secrets, and the attacker exfiltrates a cloud token. We prove or disprove this path against your real configuration rather than assuming the defaults protect you.
Secrets and identity
We hunt for standing long-lived credentials that should be short-lived OIDC tokens, secrets committed to the repo or baked into images, and roles the pipeline can assume that reach far beyond what it needs to build. Least privilege in the pipeline is usually the single highest-value fix we recommend.
Supply chain and artifacts
We check whether dependencies are pinned and verified, whether your internal package names are vulnerable to dependency confusion, and whether the artifacts you ship are signed and carry provenance. A build that anyone can tamper with silently is a build you cannot trust to deploy.
Reporting
You get a written report with each finding scored, the attack path drawn out, and a fix that fits your platform, plus a call with the engineer if your team wants to work through the harder ones together.
Common weaknesses we find
Different platforms, same recurring mistakes. The categories below account for most of the serious findings in a devsecops cicd security review.
Untrusted code on privileged runners
A workflow that checks out and runs pull-request code in a context that holds secrets. On GitHub this is most often a misuse of pull_request_target; the fix is to separate the privileged step from the untrusted checkout, and we show exactly where.
Secrets that should not exist
Long-lived cloud keys stored as CI variables when the platform supports short-lived OIDC federation. We report the concrete keys at risk and the identity-federation setup that removes them.
Script injection in build steps
Interpolating a branch name, PR title or issue body straight into a shell command in a run step. Attacker-controlled text becomes attacker-controlled code on the runner. It is common and it is quietly severe.
Self-hosted runner sprawl
Shared, persistent runners that keep state between jobs, run as root, and sit inside a trusted network segment. One malicious job and the runner becomes a pivot point into everything around it.
No artifact integrity
Images and packages built without signing or provenance, so a tampered artifact is indistinguishable from a legitimate one at deploy time. We map this against SLSA levels and recommend Sigstore or cosign signing where it fits.
Tools and how we use them
We combine hands-on testing with the right analysis tools for the platform. Static workflow analysis flags risky triggers and permissions; infrastructure-as-code scanners like tfsec and Checkov catch insecure Terraform in the pipeline; container scanners such as Trivy and Grype find vulnerable base images and layers; secret scanners like Gitleaks and TruffleHog sweep the repo and its history. Every tool result is confirmed by hand. The tools point; the engineer decides what is exploitable and what is noise.
Want this tested on your own systems?
Free 20-minute scoping call, a fixed price with no hourly surprises, and a free retest once you fix what we find.
What you get
The report is built to be handed straight to the platform team and to satisfy whoever owns the risk.
- An executive summary framing pipeline risk in terms leadership can act on.
- Each finding with a CVSS score, the exact configuration at fault, the attack path, and a platform-specific fix.
- A maturity view against OWASP CI/CD Top 10 and SLSA, so you can see where you stand and what the next level requires.
- Prioritised remediation, a call with the reviewing engineer, and a free retest after you fix.
- An attestation letter mapped to your compliance obligation where you need one.
Compliance and standards
A pipeline review supports several obligations. ISO 27001:2022 control A.8.28 covers secure development and A.8.9 covers configuration management. SOC 2 change-management and logical-access criteria expect controlled, auditable deployments. DORA pushes financial entities to manage ICT and third-party risk, which includes the software delivery chain. We map the report to the framework you answer to and provide the attestation.
How an attacker turns a pull request into production access
It helps to see the whole path, because the individual steps each look harmless. A contributor, or someone who has taken over a contributor’s account, opens a pull request against a repository. It changes a build script, adds a dependency, or edits a workflow file. Your pipeline runs it automatically to check the change, and on many setups that run happens on a privileged runner holding cloud credentials and deploy keys.
The exfiltration step
The injected step reads the environment, finds the cloud token the pipeline uses to deploy, and sends it to a server the attacker controls. Nothing looks broken. The pull request can even be closed without merging. But the attacker now holds a credential that can push to your infrastructure, and the logs may not make it obvious what happened.
Why we test the whole chain
We reproduce this path against your configuration, from the pull request to the token to what that token can actually do in your cloud. Testing one link in isolation tells you little. Showing the full chain tells you exactly where to break it, usually by separating untrusted code from privileged context and moving to short-lived, tightly scoped credentials.
Continuous testing versus a point-in-time review
A pipeline changes constantly, so a single assessment is a snapshot. It is a valuable one, because it finds the structural problems that persist, but the best outcome is a team that can keep the pipeline secure between tests. We hand over the checks we ran and the reasoning behind them so your engineers can fold them into code review and into the pipeline itself.
Guardrails we recommend
Typical recommendations include pinning workflow actions to a commit hash rather than a floating tag, setting the default token to read-only and granting write scopes per job, requiring review on any change to workflow files, and replacing standing cloud keys with short-lived identity federation. None of these slow delivery once in place, and together they close most of the paths we exploit.
Pricing
The cost of a devsecops cicd security assessment depends on how many pipelines and platforms are in scope, how many runners and cloud accounts they touch, and whether you want a one-off test or a maturity roadmap alongside it.
| Engagement | What’s included | Timeline | Price |
|---|---|---|---|
| Single pipeline | One repository and its workflows on one platform, token and secret review, poisoned-execution testing, full report and free retest | 3–5 working days | from €3,000 |
| Platform review | Multiple pipelines on one platform, self-hosted runners, cloud-role analysis, dependency and artifact integrity, exec + technical report | 5–9 working days | €4,500–€10,000 |
| Estate & maturity | Several platforms and cloud accounts, SLSA/OWASP CI/CD maturity scoring, attack-chaining into cloud, remediation roadmap | 9–15 working days | €10,000–€22,000 |
| Compliance add-on | Mapping and attestation letter for ISO 27001, SOC 2 or DORA | with any tier | from €800 |
| Custom / large estate | Many teams, mixed platforms and a full software factory, scoped to your needs | on scoping | custom |
Every engagement is fixed-price, quoted after a free 20-minute scoping call — no hourly surprises, and a retest is included. Get a fixed quote
FAQ
How much does a DevSecOps and CI/CD security assessment cost?
Which CI/CD platforms do you test?
Will the testing disrupt our builds or deployments?
What is poisoned pipeline execution and do you test for it?
Do you look at secrets and cloud permissions too?
What will you actually deliver?
Does this help with ISO 27001, SOC 2 or DORA?
Can you help our team fix the findings, not just list them?
Related services
Platform, DevOps and security teams whose pipelines can deploy to production or read the cloud, companies moving fast on GitHub Actions or GitLab CI without a dedicated pipeline-security owner, and organisations preparing for ISO 27001, SOC 2 or DORA. We are a European offensive-security team working with clients EU-wide and remotely.
Security you can prove
The same standard on every engagement, big or small.
Evidence, not opinions
Every finding ships with a reproduction and proof of concept — no vague "maybe vulnerable".
Humans over scanners
Certified engineers find the logic flaws and chained attacks automated tools walk straight past.
Fixed price, free retest
You know the cost up front, and verifying the fix is part of the deal — not a second invoice.
Ready to lock this down?
Free scoping call, fixed price, free retest. Tell us what you're running and we'll take it from there — usually within one business day.
Tell us what you're running
Scoping is free. We reply within one business day, and under 30 minutes for active incidents.