← Penetration testing
Specialist penetration testing

CI/CD pipeline security review

Your pipeline holds the keys to production. We review it the way an attacker would: looking for the commit, the dependency or the leaked secret that gets them from your repository into your live environment.

Scope your test

Delivered under Layer 7's CREST accreditation for penetration testing, by our own in-house testers. See our accreditations

Why it matters

Why your pipeline is a target

Build pipelines have broad access by design: to source code, to signing keys, to cloud accounts and to production. That makes them one of the most valuable things an attacker can compromise, and one of the least often tested.

Supply chain attacks have shown that you don't need to breach production directly if you can change what gets deployed to it.

Scope

What we look at

Source control

Branch protection, review requirements, access control and who can change what reaches the main branch.

Pipeline definitions and runners

Workflow files, self-hosted runners and whether untrusted code, such as pull requests from forks, can run with privileged access.

Secrets and credentials

How secrets are stored, scoped and exposed to jobs, and whether they leak into logs or artefacts.

Third-party actions and dependencies

Plugins, actions and packages pulled into the build, and whether they're pinned and trusted.

Artefact integrity

Whether build outputs and images are signed, verified and protected from tampering between build and deploy.

Deployment access

The roles and trust relationships pipelines use to deploy, and how far they reach into cloud and production.

Our approach

How we test it

  1. 01

    Map the pipeline

    We trace how code moves from commit to production, and every system and credential it touches on the way.

  2. 02

    Review the configuration

    We review repositories, workflow definitions, runners and secrets handling for weaknesses an attacker could use.

  3. 03

    Prove the paths

    Where agreed, we safely demonstrate the attack paths we find, so the risk is clear rather than theoretical.

What we find

Common weaknesses

Every finding comes with evidence, a risk rating and practical remediation guidance, and a free retest once it's fixed.

  • Secrets available to untrusted builds

    Credentials exposed to jobs triggered by pull requests or forks, or printed into build logs.

  • Unpinned third-party actions

    Build steps that pull whatever version is current, so a compromised upstream changes your build.

  • Over-scoped deploy credentials

    Pipeline identities with far more access to cloud and production than deployment needs.

  • Shared or persistent runners

    Self-hosted runners reused across projects or jobs, letting one build tamper with the next.

  • Weak branch protection

    Paths for unreviewed code to reach a protected branch, and from there to production.

  • Over-permissive registries

    Registries that let too many people, or the internet, push images, so a tampered image can slip into production.

How it fits together

Build, package, run

Pipelines, images and clusters are one chain, and attackers move along it. Test one link, or the whole path from commit to running workload.

  1. Build

    CI/CD pipeline review

    Where code becomes an image. We check who can change what gets built, signed and pushed, and what the pipeline can reach in production.

    You're on this page
  2. Package

    Container security review

    What's inside each image and how it behaves running in its pod: the tooling, privileges and exposed services an attacker would inherit.

    Learn more
  3. Run

    Kubernetes security testing

    The cluster that schedules and connects your pods: identities, network policy, secrets and the control plane around every workload.

    Learn more
FAQ

Common questions

Which CI/CD platforms do you review?

We review pipelines on the common platforms, including GitHub Actions, GitLab CI, Azure DevOps and Jenkins. Tell us what you use when we scope the work.

Do you need access to our repositories?

Yes, read access to the repositories and pipeline configuration in scope. We agree exactly what we can see, and for how long, during scoping.

How does this relate to container and Kubernetes testing?

The pipeline is where your images are built and shipped from, so it's the first link in the chain. A container review covers what's inside those images and how they run, and Kubernetes testing covers the cluster they run in. Together they follow the whole path from commit to running workload.

Will the review affect our builds or deployments?

No. Most of the review is configuration analysis. Any active testing is agreed in advance and carried out in a way that doesn't touch production.

Specialist testing

More specialist testing

Images and podsContainer security reviewLearn moreOrchestrationKubernetes security testingLearn moreDesktop appsThick client penetration testingLearn moreIdentityActive Directory security reviewLearn moreAdversary simulationOffensive security & red teamingLearn more

See all our penetration testing

Between tests: attack surface management and continuous vulnerability management.

Find out who can really ship to production

Tell us what you need tested and we'll give you a fixed-price quote and a clear scope, with a free retest included.

Scope your test