Dependency manifest

Expanded Definition

A dependency manifest is the project’s declared allowance list for software components, usually naming packages, version ranges, and sometimes optional features. It expresses intent, but it does not prove what was actually installed, executed, or later pulled in transitively. That distinction matters in NHI security because build systems, AI agents, and CI/CD runners often consume manifests while operating with secrets, tokens, and tool access.

In practice, the manifest is one layer in software supply chain control, while the lockfile, provenance data, and runtime telemetry provide stronger evidence of what was really used. Guidance varies across ecosystems: some package managers treat the manifest as a broad request, while others support tighter resolution rules, but no single standard governs this yet. For baseline governance, teams often map dependency control to the NIST Cybersecurity Framework 2.0 and then verify dependency integrity with an enforced lockfile. The most common misapplication is treating the manifest as proof of integrity, which occurs when organisations approve a package declaration without checking the resolved artifact set.

Examples and Use Cases

Implementing dependency manifest controls rigorously often introduces version-locking friction, requiring organisations to weigh developer agility against deterministic builds and reduced supply-chain risk.

• A Python project declares dependencies in LiteLLM PyPI package breach as a cautionary reminder that a manifest alone cannot stop malicious or altered releases from being installed.
• A CI pipeline reads the manifest to resolve packages, then enforces a lockfile so a later build cannot silently upgrade a transitive library.
• An agentic AI service uses a manifest to define approved SDKs and connectors, while runtime policy blocks any tool not present in the locked dependency set.
• A security review compares the manifest against an SBOM export to identify stale, abandoned, or unexpectedly broad package ranges.
• Release engineering signs the resolved artifacts after build, aligning manifest intent with the integrity expectations described in the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Dependency manifests become an NHI concern because build tools, automation runners, and agentic workflows frequently authenticate to registries, fetch packages, and execute code with secrets already in memory. If the manifest is broad, stale, or manually edited without verification, it can hide dependency drift that expands the attack surface and weakens software supply chain assurance. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means a compromised build path can quickly become a credential exposure event. That risk is especially important when package installation is coupled to service account permissions or release tokens, because the manifest’s apparent simplicity can mask a high-trust automation chain.

For NHI governance, the right question is not only “what did the project request?” but also “what did the pipeline actually resolve, download, and execute?” That is why dependency manifests should be reviewed alongside lockfiles, provenance checks, and secret-scoped pipeline controls. Organisational exposure often becomes visible only after a malicious package, poisoned transitive dependency, or CI compromise has already been used to retrieve secrets, at which point dependency manifest control becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between manifest-based dependency discovery and full dependency-tree resolution?
• When does a dependency compromise become an identity incident?
• How should teams slow down malicious dependency updates without breaking delivery?
• What is the difference between automating dependency updates and granting them blind trust?