Why does secure software development need to include the software delivery pipeline as well as the code itself?

Because attackers often exploit the path software travels, not only the source code. Build systems, CI/CD tools, artifact stores, and deployment workflows can all be manipulated to introduce malicious changes or weaken trust in a release. Protecting only the code leaves the delivery chain exposed, while securing the full software factory reduces the chance of tampering and improves release integrity.

Why the software delivery pipeline matters as much as the code

Secure development is not just about code review and static analysis. The delivery pipeline is where source is built, signed, packaged, promoted, and deployed, so compromise at any step can turn trusted code into an untrusted release. That is why build systems, CI/CD, artifact repositories, and release automation belong inside the security boundary, not outside it.

A strong codebase can still ship malicious or altered output if an attacker controls the pipeline inputs, build environment, or release permissions. The security question is therefore not only “is the code clean?” but also “can the path from commit to production be trusted end to end?”

How pipeline compromise changes the security problem

The pipeline introduces a different class of failure than application bugs. Attackers may tamper with dependencies, poison build steps, steal signing material, or replace artifacts after review but before deployment. In other words, the attack target shifts from source files to the systems that assemble and distribute them. That is why software supply chain integrity is central to release trust.

Pipeline weaknesses often break trust in ways that are hard to detect by looking at code alone. A malicious commit is visible in review, but a compromised runner, registry, or deployment workflow can inject changes after the last human check. The release may still appear “successful” while carrying altered behavior into production.

Teams should treat build provenance, artifact integrity, and deployment authorization as first-class controls. SLSA is useful here because it focuses on provenance and integrity across the artifact lifecycle, which is exactly where pipeline trust is won or lost.

What secure delivery actually needs beyond code quality

Secure delivery requires controls around the systems that transform code into a release. That includes access control for build and release infrastructure, short-lived credentials for automation, integrity checks for dependencies and artifacts, and tight separation between development, build, and production environments. Without those controls, the delivery chain becomes a bypass around code-level safeguards.

This is also where insecure automation practices create outsized risk. A pipeline with broad permissions can be used to exfiltrate secrets, alter release contents, or push unapproved code through trusted channels. CI/CD pipeline exploitation case study shows how mismanaged pipeline secrets and exposed infrastructure can turn a delivery workflow into a direct compromise path.

Practitioners should also think about third-party actions, packages, and build plugins as part of the trusted computing base. Reviewdog GitHub Action supply chain attack is a good reminder that popular automation components can become the entry point for credential exposure and malicious change injection.

Why release integrity is an operational security requirement

Release integrity is not an abstract compliance goal, it is an operational control that protects production from hidden tampering. If the pipeline cannot prove what was built, who approved it, and how it was promoted, then downstream teams cannot distinguish a trusted release from a manipulated one. That makes incident response, rollback, and forensic review much harder.

Delivery pipeline security also reduces the blast radius of stolen developer or automation credentials. When builds, signing, promotion, and deployment are segmented, one exposed secret does not automatically grant the ability to ship code everywhere. The best delivery pipelines are designed so that compromise of one step does not silently inherit trust for the next step.

That risk is not theoretical. Shai Hulud npm malware campaign illustrates how supply chain abuse can expose secrets and move through common development workflows, which is exactly why delivery controls must be treated as part of software security.

Risk and Threat Considerations

When the delivery pipeline is weak, an attacker does not need to defeat the application itself to reach users. Compromising CI/CD, artifact storage, or deployment automation can create a trusted path for malicious code, secret theft, or unauthorized releases, and those changes may be harder to spot than source-level defects.

Failure mechanism: The attacker abuses build trust, dependency trust, or release permissions to alter what is packaged or deployed after code review has already happened.

Impact: Organizations can ship backdoored or weakened software, lose the integrity of signed releases, and expose production systems, secrets, and downstream customers to compromise.

Standards & Framework Alignment

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

SLSA, OWASP SAMM and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	Covers build provenance and artifact integrity across the release path.
Recommendation — Adopt SLSA-aligned provenance and integrity checks for every build and release artifact.
OWASP SAMM	Software Assurance Maturity Model	Addresses security practices across the software delivery lifecycle.
Recommendation — Use SAMM to mature security controls across build, release, and deployment processes.
NIST SP 800-53 Rev 5	CM-8 — System Component Inventory	Pipeline security depends on knowing and governing build and release components.
	AU-2 — Event Logging	Trusted delivery needs auditable evidence of build and release actions.
Recommendation — Inventory pipeline components and keep the release toolchain under configuration control. Log build, signing, approval, and deployment events for release traceability.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Pipeline integrity depends on controlled configuration of build and deployment systems.
Recommendation — Apply configuration management to CI/CD tools, runners, and deployment workflows.

Practitioner Guidance

What to verify: Confirm that source control, build runners, artifact repositories, signing steps, and deployment permissions are separated and auditable. If the same identity can change code, run builds, approve releases, and deploy to production, the pipeline is too permissive.

Decision rule: If a control only protects source code but not the build and release path, treat it as incomplete. The right test is whether an attacker who cannot alter the repository can still influence the shipped artifact through the delivery workflow.

What good looks like: Every release should be traceable from commit to artifact to deployment target, with integrity checks at each handoff and minimal standing access for automation. The most important outcome is not just faster delivery, but a delivery path that can prove what entered production and why.

Practitioner takeaway: Secure development ends at the point where trusted code becomes a trusted release; if the pipeline is not secured, the code review process can be bypassed after it is already finished.