What is the difference between source code compromise and build pipeline compromise in a software supply chain attack?

Source code compromise affects the codebase itself, such as by inserting malicious logic into repositories. Build pipeline compromise targets the process that turns trusted code into release artifacts, which can let attackers alter outputs without changing source directly. Both are serious, but build compromise is especially dangerous because it can bypass review controls and spread malicious software at release time.

How Source Code Compromise Differs From Build Pipeline Compromise

Source code compromise means the attacker changes the repository, so the malicious logic is present in the code that developers review and merge. Build pipeline compromise means the repository may stay clean while the system that compiles, packages, signs, or publishes the software is tampered with. That difference changes where defenders look, which controls fail, and how quickly malicious output can spread.

In practice, source compromise is visible in the development layer, while build compromise is often visible only in the delivery layer. The first is usually a code integrity problem, the second is a release integrity problem. Both can lead to malicious software being shipped, but the build path can be more dangerous because trusted source can produce untrusted artifacts without obvious source changes.

That distinction also affects incident scope. If the source is altered, teams investigate commits, pull requests, branch protections, and maintainer access. If the build is altered, they must also inspect runners, build scripts, dependency resolution, signing steps, artifact repositories, and any secrets or tokens the pipeline can reach. A pipeline compromise often means the attacker has abused the trusted automation that organizations rely on to turn code into release-ready output.

Why Build Compromise Can Bypass Review and Release Controls

Source review is designed to catch suspicious logic before it is merged. Build compromise can sidestep that safeguard by altering the artifact after review has already happened, or by injecting behavior through the build environment itself. That makes the release artifact the point of trust, not the repository, so the defender has to validate provenance and not just code history.

This is why build compromise is so effective in software supply chain attack. If an attacker controls the pipeline, they may be able to inject compiled code, modify packaged dependencies, tamper with scripts, or change the output that gets signed and distributed. In other words, the attack can preserve a clean-looking source tree while still delivering compromised binaries to customers.

The practical impact is that normal development controls can give a false sense of safety. A strong code review process does not protect you if the build runner, signing service, or release automation can be manipulated. For that reason, source integrity and build integrity need different assurance checks, even when they are part of the same supply chain.

What Defenders Should Treat as the Real Control Boundary

The control boundary for source compromise is the repository and its change process. The control boundary for build compromise is the pipeline and everything it depends on, including credentials, runners, secrets, third-party actions, artifact stores, and signing infrastructure. That means the security question is not only “Was the code reviewed?” but also “Was the artifact produced by a trusted, observable, and reproducible process?”

Build integrity is often strengthened by provenance and reproducible release practices, because they let teams compare what was built against what was approved. Guidance from NIST SSDF (SP 800-218) supports secure development and release practices, while SLSA focuses directly on build provenance and artifact integrity. For organizations managing the broader software ecosystem, OpenSSF provides practical supply-chain security guidance and tooling.

When the compromise path is source code, the defender’s priority is access control and change review. When the compromise path is the pipeline, the priority shifts to isolation, secret hygiene, signed artifacts, and tamper-evident provenance. Those are not interchangeable controls, because one protects what developers write and the other protects what users actually receive.

Risk and Threat Considerations

The main risk difference is blast radius. Source compromise usually starts with codebase exposure and can be detected through repository history, suspicious commits, or unusual maintainer activity. Build compromise can be harder to spot because the source may remain intact while malicious output is produced at release time, which means downstream systems may trust a poisoned artifact that looks legitimate.

Failure mechanism: Attackers abuse build-time trust, such as runner privileges, signing steps, dependency fetching, or pipeline secrets, to alter the released artifact without needing to change the reviewed source.

Impact: The organization may ship malware, expose secrets, or distribute a backdoored release at scale even though the repository itself appears clean.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Build Provenance	Build compromise turns on release integrity and artifact provenance.
Recommendation — Require provenance for released artifacts and verify build integrity before promotion.
NIST CSF 2.0	PR.DS-10 — Integrity and authenticity of software and hardware are verified	The question is about preserving software integrity across source and build stages.
Recommendation — Verify software integrity from source through release artifacts.
NIST SP 800-53 Rev 5	SA-12 — Supply Chain Protection	Supply-chain compromise can alter code or build outputs before release.
	CM-5 — Access Restrictions for Change	Source compromise depends on unauthorized or excessive change access.
Recommendation — Apply supply chain protections to code, dependencies, and build services. Restrict who can modify repositories and build configurations.
OWASP ASVS	V15 — Secure Coding and Architecture	Source compromise targets the codebase and the trust placed in reviewed code.
Recommendation — Protect reviewed source with strict change control and secure review gates.

Practitioner Guidance

What to verify: Confirm that your release process can prove which commit, dependency set, and build environment produced each artifact. If you cannot tie the artifact back to a verifiable source and pipeline record, you do not have a reliable boundary between source compromise and build compromise.

Decision rule: If the suspicious change is in the repository, focus first on code review, maintainer access, and branch protection. If the suspicious change appears only in the artifact, focus first on pipeline isolation, signing keys, runner integrity, and secret exposure before spending time on source diff analysis.

Practitioner takeaway: Treat source integrity and build integrity as separate assurance problems, because a clean repository does not guarantee a trustworthy release.