What is the difference between bypassing CI/CD and compromising the build process?

Why the Difference Matters in Real Supply-Chain Security

Bypassing CI/CD and compromising the build process can end in a similar place, a bad artifact reaching users, but the security meaning is different. Bypassing CI/CD is mainly a control evasion problem: the release happens outside the approved gates. Compromising the build process is a trust-boundary problem: the pipeline itself is altered so it produces untrusted output that still looks legitimate.

The distinction matters because the containment strategy changes. If a team simply routed around CI/CD, the immediate issue is process failure and missing review. If an attacker tampered with the build system, the issue expands to code integrity, provenance, signing, secrets exposure, and the reliability of every artifact produced by that environment.

That is why build security guidance increasingly focuses on provenance and reproducibility, not just test coverage. A pipeline can be well tested and still be unsafe if an attacker can modify build steps, inject dependencies, or alter the output after checks have completed. SLSA is useful here because it frames build integrity as a supply-chain property, not just a developer workflow concern.

Control Evasion Versus Pipeline Tampering

Bypassing CI/CD usually means the organisation still has a pipeline, but someone chose not to use it. That can happen through ad hoc releases, manual uploads, direct deployment from a workstation, or publishing an artifact that never passed the expected validation steps. The risk is inconsistency, because the release path no longer matches the organisation's assumed control model.

Compromising the build process means the attacker, or a malicious insider, has changed the pipeline, runners, dependencies, build scripts, or artifact store itself. In that case the pipeline becomes the attack surface. The attacker is not avoiding the controls, they are controlling the controls, which makes the resulting artifact much harder to distrust downstream.

A practical way to tell them apart is to ask whether the release path merely skipped approval or whether the system that creates trust was altered. If the answer is "skipped", you are dealing with bypass. If the answer is "altered", you are dealing with compromise. That difference changes whether the response should focus on governance enforcement, host and runner forensics, dependency review, or full rebuild from known-good sources.

CI/CD abuse often overlaps with secrets exposure, because build systems commonly store deploy tokens, signing material, and repository credentials. NHIMG's CI/CD pipeline exploitation case study shows how exposed pipeline secrets and build misconfiguration can turn a delivery problem into a system takeover problem. The broader pattern is also visible in the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, where pipeline-adjacent trust was used to reach sensitive material.

Risk and Threat Considerations

Both conditions can expose software users to malicious or unreviewed code, but compromise is usually the more severe condition because it can persist across multiple releases. Once a build environment, runner, or dependency chain is trusted by default, attackers can reuse that trust to sign, package, or publish altered outputs that appear normal to downstream teams.

Failure mechanism: Bypass fails because the organisation depends on process compliance, and a release sidesteps the expected gates. Compromise fails because the attacker changes the build path, artifacts, or inputs, so the pipeline still runs but no longer produces trustworthy outputs.

Impact: Bypass increases the chance of untested or unaudited software shipping. Compromise can lead to poisoned releases, secret theft, credential abuse, hidden backdoors, and long-lived trust erosion across every consumer of the artifact stream.

Practitioner Guidance

What to verify: First determine whether the suspicious release was outside the approved pipeline or inside a pipeline that had already been tampered with. That distinction drives the evidence collection path, because bypass usually leaves process gaps while compromise usually leaves host, runner, dependency, or artifact integrity indicators.

Decision rule: If the artifact could have been produced or published without a trusted, reproducible build path, treat it as a provenance problem until proven otherwise. If the pipeline can reach production with broad secrets, mutable dependencies, or weak runner isolation, treat that as a build-integrity failure even if no malicious activity is yet confirmed.

Practitioner takeaway: The most important judgement is whether trust was skipped or subverted, because skipped trust calls for enforcement and audit controls, while subverted trust requires rebuilding confidence in the entire delivery chain.

Related resources from NHI Mgmt Group

• What is the difference between reproducible builds and ad hoc build fixes in CI/CD?
• What is the difference between securing developer workstations and securing CI/CD build agents?
• What is the difference between code integrity risk and identity exposure risk in CI/CD?
• What is the difference between workflow hardening and CI/CD identity governance?