Dependency management is the practice of tracking, approving, updating, and removing software components that an application or AI workflow relies on. In security terms, it reduces risk from vulnerable packages, hidden transitive dependencies, version drift, and untrusted code, while supporting reproducible builds, integrity checks, and controlled change across cloud and application environments.
What Dependency Management Does in Software and AI Workflows
Dependency management is the control point that keeps an application’s external components visible, approved, and maintainable. It is not just a build convenience, it is a security practice that helps teams know what code they rely on, where it came from, and when that code changes.
In modern software and AI workflows, dependencies often include packages, model-adjacent libraries, runtime helpers, and transitive components brought in indirectly by other libraries. The security value comes from reducing surprise: fewer unknown packages, fewer unreviewed upgrades, and fewer hidden paths for malicious or vulnerable code to enter production.
Why Dependencies Become a Security Boundary
Dependencies are a security boundary because they extend trust beyond the code a team writes itself. If a package is compromised, abandoned, typo-squatted, or updated with malicious content, the application inherits that risk even when the primary codebase has not changed.
This is why dependency management is closely tied to open source supply chain security. Open Source Security Guide covers the practical controls that matter here, including SBOMs, version pinning, trusted publishing, vulnerability data, and checks for transitive risk.
Security teams also care about package provenance, since reproducible builds and integrity verification reduce the chance that the binary or installed artifact differs from what was reviewed. The basic question is whether the dependency was selected intentionally, reviewed at the right level, and installed from a source the organisation trusts.
How Teams Manage Exposure Across the Dependency Lifecycle
Good dependency management starts with inventory. Teams need to know not only direct libraries, but also transitive dependencies that arrive through package managers, lockfiles, container images, and build tooling.
That inventory should be paired with source control for change. Version pinning, dependency update policies, and approval workflows help prevent silent drift, while vulnerability feeds and package health signals help identify when a component becomes risky after adoption.
For deeper background on the supply chain side of this discipline, OpenSSF is a useful reference point for open source security projects, scorecards, and community guidance.
In practice, dependency management works best when it treats software packages as governed assets, not invisible implementation details. That means tracking ownership, deprecating unused libraries, and removing dependencies that no longer have a valid business or security justification.
What Strong Dependency Hygiene Looks Like
Strong dependency hygiene combines prevention, verification, and removal. Teams should prefer trusted sources, minimise the number of packages they consume, and avoid importing libraries that are large, stale, or difficult to inspect.
Maintaining lockfiles and reproducible builds makes it easier to reproduce exactly what was shipped, while integrity checks and signed publishing reduce the risk that the build pipeline consumes tampered artifacts. These controls matter equally in application environments and in AI workflows that chain together libraries, tools, and model-serving components.
Dependency hygiene is also about lifecycle discipline. Old packages should be reviewed for abandonment, incompatible licenses, and known flaws, because unmanaged dependencies often become a long-term source of operational and security debt.
A practical rule is simple: if the organisation cannot explain why a dependency is present, who owns it, and how it is updated, then the dependency is not under control.
What Happens When Dependency Management Fails
When dependency management fails, the application may inherit vulnerable code, malicious code, or unstable update behaviour without any direct change to the primary source tree. The result can be compromise, data exposure, build instability, or hard-to-trace runtime failures.
A clear example is supply chain compromise through a package ecosystem. The LiteLLM PyPI package breach illustrates how a dependency incident can turn package trust into credential theft and downstream exposure for users who relied on the compromised component.
Because the damage often arrives through trusted update paths, dependency failures can be hard to notice in time. That is why teams need monitoring for unexpected package changes, build anomalies, and suspicious runtime behaviour after an update lands.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Dependency management depends on build provenance and artifact integrity. |
| Recommendation — Adopt SLSA-aligned build controls to verify artifact provenance before promotion. | ||
| CIS Controls v8 | CIS-5 — Account Management | Dependency approval and removal require ownership and control over software components. |
| Recommendation — Apply CIS-5 to govern who may add, update, or remove approved dependencies. | ||
| OWASP ASVS | V13 — Configuration | Dependency pinning, build settings, and safe defaults are configuration controls in software security. |
| Recommendation — Use V13 to enforce secure dependency configuration and controlled change. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Dependency management requires an accurate inventory of software components and transitive packages. |
| SI-2 — Flaw Remediation | Vulnerable dependencies must be tracked and remediated as flaws are discovered. | |
| Recommendation — Use CM-8 to maintain a complete inventory of software dependencies and components. Use SI-2 to patch, replace, or remove vulnerable dependencies on a managed timeline. | ||
Related resources from NHI Mgmt Group
- Why do generic vulnerability scanners miss risk in Kubernetes dependency management?
- What is the difference between vulnerability severity and remediation risk in dependency management?
- How should organisations evaluate SBOM import support for dependency risk management?
- What happens when open source vulnerability management is attempted without dependency mapping and SBOM visibility?