What is the difference between build-time attacks and runtime attacks in the software supply chain?

Build-time attacks happen before software is packaged and released, when attackers alter source, dependencies, or build infrastructure to embed malicious logic into the output. Runtime attacks happen after deployment, when malicious code is already running in production and security controls try to detect or contain it. Build-time compromise is usually harder to recover from because the signed release itself may already be trusted.

How the attack window changes across the supply chain

Build-time attacks target the software before it is released, so the defender is fighting compromise at the point where trust is created. Runtime attacks target software after it is already deployed, so the defender is fighting active execution in a live environment. That single difference changes everything about where evidence appears, how quickly damage spreads, and whether the trust in a signed artifact is still usable.

In build-time compromise, the attacker wants to influence the artifact that downstream teams will trust, reuse, or distribute. That can mean poisoned source, tampered dependencies, compromised CI/CD runners, stolen build credentials, or malicious build scripts. The result is a clean-looking release that may carry the attacker’s logic everywhere it goes.

In runtime compromise, the malicious code is already present in production, and the question becomes how to detect, contain, and evict it without breaking the service. The attack may have arrived through an exploit, a compromised dependency, or a post-release intrusion path, but the operational reality is different: telemetry, isolation, patching, and incident response matter more than release integrity.

Why build-time compromise is usually harder to unwind

Build-time attacks are difficult because they contaminate the origin of trust. If the signing process, artifact repository, or release pipeline is compromised, every downstream consumer may inherit the poisoned output as if it were legitimate. That makes rollback less straightforward, because the trusted baseline itself may be suspect.

Runtime attacks are often more visible once security controls are in place, especially when monitoring, EDR, network controls, or application guardrails can observe suspicious behaviour. That does not make them easy, but it does mean defenders can sometimes isolate a host, revoke a session, patch the flaw, or remove the malicious process without reopening the entire software production chain.

Supply-chain analysis becomes more concrete when you compare how the compromise propagates. Build-time compromise tends to scale through distribution and reuse, while runtime compromise tends to scale through active environment access and persistence. If the attacker modifies the shipped artifact, the blast radius is the entire install base; if the attacker lands only in runtime, the blast radius is usually bounded by the deployed environment, though lateral movement can widen it.

For build integrity and provenance, standards like SLSA and NIST SSDF (SP 800-218) are the right references because they focus on how software is built, verified, and released. For production containment, NIST SP 800-190 Container Security is useful when the runtime target is containerised and you need controls around images, registries, and orchestration boundaries.

How practitioners should distinguish them in real incidents

The most useful first question is not “where did the malware execute?” but “what trust boundary was crossed first?” If the answer is the build system, dependency chain, or release pipeline, treat it as a build-time problem until proven otherwise. If the answer is a running workload, endpoint, container, or process tree in production, treat it as a runtime problem.

That distinction changes the evidence you preserve. Build-time cases demand pipeline logs, commit history, dependency diffs, signing records, and runner image inspection. Runtime cases demand memory, process, network, file, and authentication evidence so you can understand what the code did after execution began.

It also changes remediation order. For build-time compromise, the priority is to identify which artifacts may be tainted, invalidate trust in affected releases, and rebuild from a known-good source and pipeline. For runtime compromise, the priority is to stop the activity, preserve evidence, and remove the attacker’s foothold without assuming the release process itself is broken.

Where the supply chain is involved, one practical signal is whether compromise can survive redeployment. If reinstalling the software from the same pipeline reproduces the issue, the problem is probably upstream in the build path. If a clean rebuild removes the behaviour, the problem is more likely to have been runtime-only.

Risk and Threat Considerations

Build-time compromise creates disproportionate risk because it can turn one attack into many trusted deployments. Runtime compromise is usually easier to scope to a live environment, but it can still lead to credential theft, persistence, and lateral movement if the attacker gains enough execution authority.

Failure mechanism: Attackers tamper with source, dependencies, build scripts, or pipeline credentials so the released artifact is malicious before defenders ever observe it in production. At runtime, attackers exploit a deployed system or a post-release foothold to run code, steal secrets, or expand access inside the environment.

Impact: Build-time attacks can invalidate the trust model for signed releases and force broad rebuilds, revocation, and customer notification. Runtime attacks more often drive service disruption, data exposure, and incident response in the affected environment, but they usually do not compromise every downstream consumer unless persistence or lateral movement succeeds.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.SC-1 — Cyber Supply Chain Risk Management	Build-time vs runtime attacks are supply-chain risk distinctions affecting trust in releases.
	PR.DS-6 — Data-at-Rest Protection	Poisoned build artifacts and runtime compromise both hinge on protected software and secret material.
	DE.CM-8 — Vulnerability Monitoring	Runtime attacks require active monitoring and containment in deployed environments.
Recommendation — Map release-chain trust dependencies and enforce supplier and artifact risk management. Protect build outputs and sensitive runtime data with strict access and integrity controls. Continuously monitor deployed systems for suspicious process, network, and file activity.
CIS Controls v8	14.1 — Establish and Maintain a Security Awareness and Skills Training Program	Teams need role-specific discipline to distinguish build compromise from runtime compromise.
	16.9 — Perform Automated Log Collection, Alerting, and Retention	Runtime attack detection depends on telemetry from production systems and pipelines.
	4.1 — Establish and Maintain an Inventory of Enterprise Assets	Separating build-time and runtime scope depends on knowing affected build and production assets.
Recommendation — Train build and ops teams to recognise supply-chain and production compromise signals. Collect and retain pipeline and runtime logs to support investigation and containment. Maintain accurate inventories so you can scope contaminated builds and impacted production hosts.
NIST SP 800-63	IAL — Identity Assurance Level	Supply-chain compromise often involves trust in identities and credentials used to build or operate software.
Recommendation — Assure the identities that can sign, build, deploy, or operate software.
NIST Zero Trust (SP 800-207)	SC-7 — Microsegmentation and Network Segmentation	Runtime attacks are limited when production workloads are segmented and isolated.
Recommendation — Segment production workloads to contain post-deployment compromise and lateral movement.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Build-time attacks often abuse CI/CD secrets, tokens, and keys to poison releases.
	NHI-03 — Privileged Access and Overpermission	Build and deployment systems are frequently overprivileged, enabling release tampering.
Recommendation — Rotate and vault build-system secrets that can alter release artifacts. Reduce privileged access on build and deploy paths to limit artifact tampering.

Practitioner Guidance

What to prioritise: If you suspect build-time compromise, prioritise provenance, signing, dependency lineage, and release scope before spending time on endpoint-only hunting. If you suspect runtime compromise, prioritise containment and live-response telemetry before assuming the artifact itself is the source.

What to verify: Confirm whether the malicious behaviour reproduces from a fresh build and clean deployment. That single check often separates a poisoned pipeline from a compromised runtime host and keeps teams from fixing the wrong layer.

Practitioner takeaway: Build-time attacks are trust attacks on the artifact, while runtime attacks are execution attacks on the environment; the fastest way to make the wrong decision is to investigate them with the same playbook.