Should teams verify packages again at runtime instead of only in CI?

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.

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?