What is the difference between securing code in the pipeline and protecting applications at runtime?

Pipeline security focuses on what enters the software supply chain, including code, dependencies, secrets, and infrastructure configuration before release. Runtime protection focuses on what happens after deployment, when attackers may use tampering, credential harvesting, overlays, or live exploitation. Mature programmes need both because build-time controls cannot stop every post-release attack path.

Pipeline security protects the software you ship, not just the code you write

Pipeline security is about controlling what is allowed to enter the software supply chain before release. That includes source code, open source dependencies, build scripts, secrets, and infrastructure-as-code, plus the integrity of the systems that compile, test, sign, and package the release. The practical question is whether the artefact leaving the pipeline is trustworthy, reproducible, and free from embedded attack paths.

The biggest mistake is to treat the pipeline as only a developer concern. A weak build process can turn dependency poisoning, secret exposure, or tampered build steps into a production issue long before an application ever reaches users. For that reason, controls such as provenance, dependency verification, secret scanning, and build isolation belong in the same conversation as release approval and change control.

In mature environments, pipeline security is also where you decide what must be blocked before promotion. If a build contains exposed credentials, unsigned components, or unauthorised configuration changes, the right response is usually to stop the release rather than rely on runtime controls to catch a problem after deployment. SLSA is useful here because it gives teams a structured way to think about build provenance and supply-chain integrity.

Pipeline failures are often invisible until they are already distributed, which is why build-time assurance has to be strong enough to prevent bad artefacts from propagating. That is also where secrets discipline matters most. NHIMG’s Guide to the Secret Sprawl Challenge and Reviewdog GitHub Action supply chain attack both show how build and repository exposure can become a release vehicle for secrets leakage.

Runtime protection assumes the application is live and under attack pressure

Runtime protection starts after deployment, when the application is exposed to traffic, authenticated users, external integrations, and active adversaries. At this stage, the focus shifts from build integrity to execution behaviour: request abuse, session abuse, tampering, code injection, credential harvesting, malicious overlays, and attempts to exploit flaws that were not caught earlier.

This is a different control problem because the application is now operating in a real environment with live state, live identities, and live data. Runtime protection typically leans on defensive layers such as WAFs, application monitoring, runtime policy, container or host hardening, session controls, and detection logic that can see suspicious execution rather than just suspicious code.

The runtime question is not whether the shipped artefact was clean at release, but whether the running system can resist or contain abuse after an attacker reaches it. That makes runtime controls especially important for internet-facing services, applications with privileged workflows, and systems that handle sensitive transactions. NIST SP 800-190 Container Security is relevant because it frames image, registry, orchestrator, and runtime risks as separate concerns that need explicit control points.

Runtime protection is also where post-release compromise becomes visible. NHIMG’s CI/CD pipeline exploitation case study and Shai Hulud npm malware campaign illustrate the practical link between exposed secrets, malicious code delivery, and downstream abuse once software is operating in production.

Why mature teams need both, and how to decide what each layer must catch

Pipeline security and runtime protection are complementary, not interchangeable. Build-time controls are best at preventing compromised artefacts from ever shipping. Runtime controls are best at limiting the blast radius when a vulnerability, stolen token, malicious request, or unexpected dependency behaviour slips through anyway. One layer reduces what reaches production, the other reduces what an attacker can do after reaching it.

A useful rule is to ask where the failure would first become observable. If the issue is a bad dependency, leaked secret in source, or tampered build step, treat it as a pipeline problem. If the issue is request abuse, live exploit attempts, privilege misuse, or post-deploy tampering, treat it as a runtime problem. Some scenarios require both, especially when a build compromise later turns into interactive exploitation in production.

There is no universal standard that says one layer can substitute for the other. Strong programmes verify release integrity before deployment, then assume the runtime will still be probed, tampered with, or abused. That is why the two control sets should be measured separately: pipeline success rates, secret leakage prevention, dependency provenance, runtime alerting fidelity, and containment time are different signals, not one blended metric.

Risk and Threat Considerations

When teams rely only on pipeline security, they create a gap between release integrity and live defence. A clean build does not stop credential theft, malicious overlays, request injection, or exploitation of a vulnerable production service after deployment, so an attacker who reaches the runtime can still cause material harm.

Failure mechanism: The pipeline prevents some bad artefacts from shipping, but it cannot stop every post-release attack path, especially when an application exposes live endpoints, active sessions, or runtime secrets.

Impact: Attackers can abuse the running application to harvest credentials, tamper with state, pivot through trusted integrations, or exploit flaws that were invisible at build time, expanding the blast radius beyond what release controls can contain.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 2 — Inventory and Control of Software Assets	Controls the software and dependencies entering the pipeline.
	CIS Control 4 — Secure Configuration of Enterprise Assets and Software	Addresses build and deployment configuration hardening for secure delivery.
	CIS Control 8 — Audit Log Management	Supports runtime detection and investigation of live abuse and tampering.
Recommendation — Inventory and approve software components before they enter build and release paths. Harden build, deploy, and runtime configurations to reduce tampering and drift. Collect and protect logs that reveal suspicious runtime behaviour and post-release abuse.
NIST CSF 2.0	PR.DS — Data Security	Protects code, secrets, and sensitive artefacts across delivery and execution.
	PR.PS — Platform Security	Covers secure build, deployment, and runtime platform protections.
	DE.CM — Continuous Monitoring	Needed to observe runtime abuse after deployment.
Recommendation — Protect source, secrets, and artefacts throughout delivery and production use. Harden the delivery and runtime platform so compromised software is harder to run. Monitor live application behaviour for tampering, abuse, and exploitation indicators.
NIST Zero Trust (SP 800-207)	5.1 — Policy Engine	Runtime policy enforcement depends on deciding what each request or session may do.
	5.4 — Continuous Diagnostics and Mitigation	Supports runtime telemetry and adaptive response after deployment.
Recommendation — Enforce runtime access and request decisions through centrally governed policy. Continuously assess live system signals and adjust protections as conditions change.

Practitioner Guidance

What to verify: Confirm that release gates actually block unsigned or tampered artefacts, secret leakage, and unapproved dependency changes before promotion. Then verify that the runtime stack can detect suspicious requests, unexpected process behaviour, and live abuse without waiting for the next deployment cycle.

Decision rule: If the problem can be prevented before an artefact is released, make the pipeline own it. If the problem appears only after the service is live, make runtime protection own it. When a control could belong to either side, place it where the failure would first be detected and where the response can reduce blast radius fastest.

Practitioner takeaway: The strongest programmes do not choose between build-time assurance and runtime defence, they use pipeline controls to stop unsafe software from shipping and runtime controls to contain whatever still gets through.