How should teams govern dependency risk across CI/CD and runtime?

How to govern dependency risk across the full delivery lifecycle

Dependency governance works best when teams treat packages, images, build outputs, and runtime services as one traceable chain. The practical goal is not just knowing that a library has a CVE, but knowing which artifact included it, which pipeline produced that artifact, and which service instances are still running it. That is what makes risk actionable instead of abstract.

The strongest control point is the handoff between code, build, and deployment. A dependency may enter through source control, a lockfile, a base image, or a transitive package, but teams need one consistent record that links the vulnerable component to the shipped artifact and the running workload. Without that chain, remediation becomes guesswork, and teams waste time rotating or rebuilding things that were never exposed.

Lifecycle governance also means differentiating origin risk from exposure risk. A package can be known-bad long before it is actually deployed, and a deployed artifact can remain risky even after the upstream package has been patched. That is why runtime mapping matters: it tells you whether the issue is theoretical, staged, active, or already replaced. The most useful dependency view combines inventory, provenance, and deployment state rather than treating them as separate exercises.

Why provenance and runtime mapping belong in the same control

Provenance answers where a dependency came from and whether the build path can be trusted. Runtime mapping answers where that dependency ended up and what blast radius it has today. When teams keep those views separate, they usually miss one of two failure modes: a vulnerable component that slipped through a legitimate build, or a compromised build that introduced dependency risk the scanner never saw. Linking the two closes that gap.

SLSA is relevant here because dependency governance depends on build provenance, not only on package inspection. If the build record cannot prove what was assembled and from which inputs, the team cannot confidently decide whether the runtime instance is trustworthy.

CI/CD pipeline exploitation case study, ArtiPACKED 2024, and Codecov Supply Chain Breach all show why pipeline evidence matters as much as package evidence. In each case, the problem was not limited to a single dependency record, it involved how the artifact or secrets path was produced and then carried into use.

What good governance looks like in CI/CD and runtime

Good dependency governance gives security and engineering the same answer to three questions: what entered, where it entered, and what is still live. SBOMs help with the first question, provenance helps with the second, and runtime inventory helps with the third. Teams should expect those records to reconcile, or they should treat the mismatch as a control failure.

OpenSSF is useful as the broader ecosystem for supply-chain hardening, while NIST SP 800-190 Container Security helps teams think about image, registry, and runtime exposure together. That combination fits dependency governance because the risk is not just in the package index, it is in what actually runs.

For runtime operations, the practical question is whether a vulnerable dependency is reachable and observable. A transitive library in a dormant code path is lower urgency than the same library embedded in a public service handling authenticated requests. Teams should therefore combine dependency data with asset criticality, deployment scope, and exposure path before deciding whether to patch, isolate, rebuild, or accept temporary risk.

Risk and Threat Considerations

Dependency risk becomes material when teams can no longer prove where a component was introduced or where it is still executing. That uncertainty creates blind spots for patching, incident response, and blast-radius reduction, especially when the same package is reused across many services or environments.

Failure mechanism: A vulnerable or malicious dependency is introduced through the build chain, then copied into artifacts, images, or services without a reliable link back to the exact source and pipeline that produced it.

Impact: Teams may miss active exposure, rebuild the wrong artifacts, or underestimate spread across environments, which slows containment and increases the chance that a single dependency issue becomes a fleet-wide problem.

Practitioner Guidance

What to prioritise: Build one dependency view that ties together package metadata, build provenance, artifact identity, and runtime location. If those records cannot be joined, treat the control as incomplete rather than merely noisy.

What to verify: Confirm that every production service can be traced back to a specific artifact digest and pipeline run, and that the SBOM matches what was actually deployed. If the deployed object cannot be named, it cannot be governed.

Decision rule: If the dependency is in a deployed, reachable path, prioritise rebuild or replacement over passive watchlist management. If it is only present in source or an unreleased build, focus first on preventing release, not on runtime mitigation.

Practitioner takeaway: Dependency governance is strongest when it is evidence-driven across the whole lifecycle, because the real control objective is to know exactly what shipped, where it runs, and how quickly you can prove it is gone.

Related resources from NHI Mgmt Group

• How should security teams govern machine credentials across cloud and CI/CD environments?
• How should security teams govern software supply chain risk when CI/CD identities can publish code?
• How should security teams implement dependency mapping in CI/CD pipelines to reduce supply chain risk?
• How should teams apply Kubernetes governance across CI/CD, build, commit, and runtime stages?