What is the difference between build-time supply chain review and runtime script governance?

What build-time review is trying to prove

Build-time supply chain review is a pre-release trust decision. It asks whether the artifact, package, dependency chain, or signed build output is the one you intended to ship, and whether the provenance, approvals, and integrity checks hold before anything reaches users. In practice, that means focusing on source integrity, signing, dependency lineage, and release controls rather than on live execution.

This is why build-time review aligns closely with supply chain integrity work such as SLSA and with secure development and release governance in NIST SSDF (SP 800-218). The practitioner question is whether the release pipeline can prove what was built, who built it, and whether that output was altered before deployment.

That makes build-time review strongest at preventing malicious code from ever becoming the trusted baseline. It is also where teams detect poisoned dependencies, compromised maintainer accounts, and suspicious changes to the build process itself, because those threats are cheapest to stop before release.

What runtime script governance is trying to control

Runtime script governance is a live enforcement problem. It asks what code is actually executing in the browser at this moment, whether that code still matches the intended policy, and whether it can access customer data or perform actions beyond its authorized behavior. The control point is not the repository or the package registry, but the active page, DOM, and script execution environment.

This is materially different from build-time review because browser-side code can change after deployment through content delivery paths, third-party tags, injected snippets, compromised accounts, or later updates. Runtime governance therefore treats trust as conditional and continuously checked, rather than assumed once the build has been approved.

For that reason, runtime controls are a browser-execution and content integrity problem as much as a software supply chain problem. They are most effective when they constrain which scripts may run, what origins they may call, and what data they may read or transmit while the customer session is active.

Why the two controls answer different security questions

The simplest distinction is baseline trust versus continuous enforcement. Build-time review establishes the security posture of the artifact before release. Runtime script governance validates the security posture of the running page after release, when a malicious or unexpected script can still appear through dynamic delivery, tag managers, extensions, or compromised downstream services.

That difference matters because an approved build does not guarantee safe runtime behavior. A script can be legitimate at build time and still become unsafe later if its delivery path, dependency chain, or execution context is altered. Runtime governance closes that gap by checking the actual behavior seen by the customer browser, not just the signed-off package.

Teams often need both because they protect different failure points. Build-time review reduces the chance of shipping a bad baseline. Runtime governance reduces the chance that a good baseline is later abused, overextended, or silently replaced in the browser.

Risk and Threat Considerations

The main risk is assuming that pre-deployment approval is enough to protect customer-side execution. When browser scripts can be altered after release, the exposure shifts to account compromise, unauthorized tag injection, malicious third-party updates, and data exfiltration from the live session.

Failure mechanism: An attacker or misconfigured integration changes the script delivered to the browser after build approval, then uses that execution path to access customer data, capture input, or call unauthorized endpoints.

Impact: Sensitive data can be exposed in real time even when the shipped build was previously trusted, which weakens incident detection, complicates rollback, and expands blast radius across every user session that loads the modified script.

Practitioner Guidance

What to prioritize: Treat build-time review as a release trust gate and runtime script governance as a customer-exposure control. If a script can handle credentials, personal data, payment flows, or privileged UI actions, it needs both provenance checks before release and policy enforcement while executing.

What to verify: Confirm that approved build artifacts, pinned dependencies, and signed releases are stable at deploy time, then verify that runtime policy can detect unexpected script sources, unauthorized changes in behavior, and script execution outside the intended origin or path.

Common mistake: Many teams stop at the build pipeline and assume the browser will only ever execute what was reviewed. That assumption fails when delivery, third-party code, or post-deployment changes introduce new behavior after the release has already passed review.

Practitioner takeaway: Use build-time review to prove what should be trusted, and runtime governance to prove what is actually happening when the customer browser is live; the second control is what limits exposure when the first control has already been bypassed or outgrown.

Related resources from NHI Mgmt Group

• What is the difference between build-time attacks and runtime attacks in the software supply chain?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between vulnerability scanning and supply chain governance?
• What is the difference between entitlement review and runtime governance for AI agents?