What is the difference between manifest-based dependency discovery and full dependency-tree resolution?

Why This Matters for Security Teams

The difference is not just semantic. Manifest-based discovery is useful for fast visibility into declared dependencies, but it can miss packages introduced through transitive resolution, lockfiles, or resolver rules. Full dependency-tree resolution is more operationally faithful because it mirrors what the build or package manager actually installs at scan time. That distinction affects vulnerability management, SBOM quality, license review, and incident response. The NIST Cybersecurity Framework 2.0 places this squarely in asset and risk management: if the inventory is incomplete, downstream control decisions are built on a partial picture.

Teams often assume a manifest scan is “good enough” because it is easier to run and simpler to explain. In practice, that shortcut can undercount real exposure, especially when package managers, build plugins, or pinned version constraints alter what gets installed. The result is a mismatch between developer intent and production reality. In practice, many security teams encounter missing transitive risk only after a vulnerable library has already been promoted through CI/CD and exposed in production.

How It Works in Practice

Manifest-based discovery starts with source files that declare dependencies, such as pom.xml, package.json, requirements.txt, or setup.py. It reads the declared inputs and records what the developer explicitly asked for. That gives a fast and stable baseline, but it does not always show what the resolver will actually pull, especially when version ranges, extras, optional modules, or platform-specific packages are involved.

Full dependency-tree resolution goes further. It uses package manager logic, lockfiles, metadata, and repository resolution rules to calculate the complete tree of direct and transitive dependencies. This is closer to the runtime or build-time truth, which makes it more suitable for vulnerability prioritisation and SBOM generation. For software supply chain work, the distinction matters because a transitive package may introduce the highest-risk weakness even though it never appears in the manifest.

Current guidance from supply chain and software assurance practice generally favours resolving as close as possible to the actual build artifact. That is consistent with the intent behind CISA software bill of materials guidance and the control emphasis in NIST SP 800-218, which both push toward reproducible, trustworthy software inventory.

• Use manifest discovery for quick scans, developer feedback, and pre-commit hygiene.
• Use full-tree resolution for release gating, SBOM creation, and exposure analysis.
• Compare manifest, lockfile, and resolved output to spot drift or hidden dependencies.
• Record the package manager version, because resolver behavior can change across releases.

If the organisation is also protecting build systems or automation accounts, the same inventory logic should extend to non-human identities that can alter dependency sources or install paths. Where those identities are weakly governed, dependency fidelity becomes a supply-chain trust problem as much as a scanning problem. These controls tend to break down in monorepos and multi-language build pipelines because different package managers resolve dependencies differently and there is no single tree that represents the whole application.

Common Variations and Edge Cases

Tighter dependency resolution often increases scan time and operational complexity, requiring organisations to balance accuracy against pipeline speed and engineering friction. That tradeoff is real, especially in large estates with many build targets or ephemeral environments. Best practice is evolving, but most teams now treat manifest-only results as a minimum signal rather than a final source of truth.

Edge cases matter. Optional dependencies may only appear on certain platforms, extras may be enabled only in production, and private registries may return different package graphs depending on credentials or mirror state. Container builds can add another layer of drift when the application manifest differs from the OS package set inside the image. In those environments, a single scan pass rarely captures the whole picture.

There is also a governance angle when organisations use agentic build automation or AI-assisted code generation. The question is no longer just which packages were declared, but which tools, identities, and policy engines are allowed to modify the dependency graph. That intersection is where manifest-only workflows most often miss hidden risk. For controls and reporting, the practical answer is to document which discovery method was used, when the tree was resolved, and whether the result reflects source intent or build reality. For deeper policy mapping, CISA software supply chain guidance is a useful reference point.

Related resources from NHI Mgmt Group

• What is the difference between network detection and identity-based discovery for AI agents?
• What is the difference between HAR-based discovery and seed paths?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between role-based access and API key governance for NHI security?