Yes. Build-time checks stop at the pipeline, but many malicious payloads execute only when imported or run in production, a laptop or an edge environment. Rechecking signatures, scan attestations and policy approvals at point of use gives you a second control plane that can block unsafe execution even if the pipeline was compromised.
Why runtime verification adds protection beyond CI
CI is the right place to catch known issues early, but it is not the only place where trust can fail. A package can look clean when the pipeline approves it and still become unsafe when it is fetched, imported, executed, or updated later in a laptop, server, container, or edge runtime. Point-of-use verification closes that timing gap.
This matters because the security decision changes at execution time. Build attestations, signature checks, and policy approvals are strongest when the artifact is still in the pipeline, but the operating environment is where the package can actually load code, reach secrets, call internal services, or trigger unsafe side effects. Runtime checks help confirm that the artifact being used is still the artifact that was reviewed.
What runtime verification should actually re-check
The practical target is not “scan everything again” in the abstract. It is to re-validate the controls that determine whether the package should be allowed to execute in that environment: signature status, provenance or attestation, repository origin, allowlist or policy approval, and any integrity markers tied to the exact artifact or version in use.
That second check is most valuable when the package can influence privileged actions. If the code path can access tokens, secrets, configuration, or internal APIs, then a compromised build step, poisoned dependency, or later substitution event can turn a nominally approved package into an execution-time risk. Runtime verification reduces trust in the pipeline as a single gate and makes the environment itself part of enforcement.
For teams building containers or server-side workloads, NIST’s container security guidance is a useful anchor for thinking about this split between image preparation and runtime enforcement, because it treats image, registry, and runtime as distinct control points. Open source software supply chain guidance from OpenSSF is also relevant here because it reinforces provenance, integrity, and consumer-side checks as part of the release and use path.
When runtime checks are most worth the overhead
Rechecking at runtime is most justified when the package is high impact, the environment is high trust, or the delivery chain is hard to fully trust. That includes production services, developer laptops with broad credentials, edge deployments with delayed patching, and any workflow where packages are installed dynamically rather than only through a tightly controlled release process.
The trade-off is latency and operational complexity. A runtime gate can slow startup, complicate offline execution, or create false failures if policy data is stale. The answer is usually not to remove CI checks, but to treat runtime verification as a narrower enforcement layer for the small set of packages or execution contexts where compromise would matter most.
Risk and Threat Considerations
Runtime verification addresses the risk that a package becomes dangerous after it has already passed the pipeline, whether through compromised provenance, dependency substitution, or malicious code that only activates at import or execution time. The attack is attractive because CI creates a false sense of safety if enforcement stops before the workload actually runs.
Failure mechanism: An attacker compromises the build, dependency source, or distribution path, then waits until the package is consumed in production or on an endpoint where the original pipeline trust no longer applies. If the runtime environment does not re-check integrity and policy, the malicious code executes with the privileges of the host process or the calling application.
Impact: The result can be secret theft, unauthorized API use, lateral movement, or persistence inside trusted software flows. The runtime control matters most when the package has access to credentials, internal services, or sensitive data, because execution-time abuse is what turns supply chain compromise into an operational incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, SLSA and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Runtime package verification is an integrity control for software at use time |
| CM-5 — Access Restrictions for Change | Rechecking policy at runtime constrains unapproved software changes from taking effect | |
| SI-4 — System Monitoring | Runtime checks complement detection by exposing suspicious package use in production | |
| Recommendation — Verify software integrity at execution points, not only in the build pipeline. Restrict software changes and approvals to authorized runtime paths. Monitor package execution and alert on integrity or provenance failures. | ||
| SLSA | Supply Chain Levels for Software Artifacts | The question concerns artifact provenance and trust across the build-to-run supply chain |
| Recommendation — Apply supply-chain provenance controls that remain verifiable after build completion. | ||
| OWASP ASVS | V13 — Configuration | Runtime policy enforcement depends on secure deployment and trusted configuration state |
| Recommendation — Enforce deployment-time policy so approved artifacts remain the ones that run. | ||
Practitioner Guidance
What to prioritise: Put runtime verification on the packages and environments where a bad import would have the largest blast radius, not on every dependency equally. The highest-value checks are the ones that can stop execution after a package has crossed the trust boundary into a live workload.
What to verify: Confirm that the runtime control is checking the same artifact identity the pipeline approved, not just a name or version string. If the control cannot detect substitution, tampering, or stale policy data, it is only a compliance signal, not an enforcement signal.
Decision rule: If the package can execute with access to secrets, tokens, or internal services, treat point-of-use verification as a required second control plane. If the package is low impact and tightly isolated, CI checks may be enough.
Practitioner takeaway: CI establishes trust early, but runtime verification is what preserves that trust at the moment execution can actually do harm.
Related resources from NHI Mgmt Group
- How should security teams verify users for high-risk actions instead of OTP?
- How should security teams implement runtime credential brokering for CI/CD workloads?
- How should security teams implement runtime testing in CI/CD pipelines?
- How should security teams handle packages that resolve control endpoints at runtime?