Home / Knowledge hub / Build pipeline compromise
Knowledge hub
Build pipeline compromise
An attacker altering your build system so every release carries their code.
What it means
A build pipeline compromise is an attacker getting control of the systems that turn your source code into a release: the build server, its scripts, its plugins or its stored credentials. They then change what comes out, without touching the code your team reviewed or approved.
The point is that the source repository can look clean. The tampering happens between the commit and the package, so everyone who trusts the output inherits the problem. The result is software that looks genuine and is not. It is one route into a wider supply chain attack.
Why it matters
Your customers install what the pipeline produces, not what your developers wrote, so the pipeline is part of your product. If the pipeline adds a backdoor, it ships with a valid signature, passes your release checks and lands on every customer's system with your name on it.
The pipeline also holds powerful secrets: deploy keys, cloud credentials, signing keys. An attacker who reaches them can publish packages, change production and read private repositories. Cleaning up means rebuilding trust in every release made while they had access, which can take weeks.
How it shows up
The usual weak points are a build job that runs untrusted code from a pull request, a plugin or action pulled in without pinning, a hardcoded secret in a pipeline file, and a build agent shared between projects. Each lets outside input run with the pipeline's own permissions.
Check who can edit pipeline definitions, which steps can reach secrets, and whether builds run in clean, short-lived environments. Pin third-party steps to a fixed version. Record how each release was built so you can later tell a genuine artefact from a swapped one, as build provenance allows.
Questions people ask
Build pipeline compromise, answered
Is a build pipeline compromise the same as a supply chain attack?
It is one kind. A supply chain attack is the wider idea of reaching you or your customers through something you depend on. Compromising the build system is a way to do that from the inside, by changing your own output.
How would we know our build was tampered with?
It is hard to see from the code alone, because the source can be unchanged. Signs include artefacts that differ between two builds of the same commit, unexpected network calls during a build, or new pipeline steps nobody remembers adding.
Reproducible builds and recorded provenance make the comparison possible.
Does code signing prevent it?
Not by itself. If the attacker controls the build, the tampered output can be signed with your real key, and the signature then vouches for it. Signing helps when the key is kept apart from the build and the build is itself verified.
Are hosted CI/CD services safer than running our own?
Neither is safe by default. A hosted service removes some server upkeep, but the risky parts are mostly yours: who can change a pipeline, which secrets a job can read, and which third-party steps it runs.
Both need the same review of permissions and inputs.
What is the first thing to fix?
Reduce what a build job can reach. Give each job only the secrets it needs, keep long-lived credentials out of the pipeline where you can, and require review for any change to pipeline files. That limits the damage from any single weak step.
Sources
Where this comes from
Related
Terms that sit next to this one
Supply chain attack
Reaching you through a library, a build tool or a vendor you trust.
Build provenance
A signed record of where, when and how a piece of software was built.
CI/CD
The pipeline that builds, tests and ships code on every merge.
Reproducible builds
Builds that produce identical output every time, so tampering shows up.
Code signing
Signing software so users and systems can check who released it and that it is intact.
Who can change your build?
Pipeline secrets, exposed build endpoints and flaws in the apps your pipeline ships all fall within what we test. In CI/CD our run can gate a build on a proven finding. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.