Monitoring only top-level dependencies leaves the real attack surface exposed. Malicious code can arrive through indirect packages, dependency changes, or ecosystem-level compromise that never appears in the first layer of review. That gap undermines governance, because teams may believe they have control while dangerous code is already embedded in the build path.
Top-Level Dependency Checks Miss the Real Trust Boundary
When organisations stop at first-order packages, they are really checking only the names they already know, not the transitive code that actually ships. That matters because modern build systems resolve large dependency trees, and risk often sits several layers down where maintainers change, repositories are taken over, or a subdependency is quietly replaced. The practical failure is not just incomplete visibility. It is a false sense of assurance that can let unreviewed code reach production.
Supply chain security guidance such as the OWASP Non-Human Identity Top 10 is useful here because package and build ecosystems depend on machine-to-machine trust, tokens, and automated publishing paths that are easy to overlook when attention stays on the first layer only. In practice, many security teams discover the gap only after a transitive package or build-time dependency has already altered what their controls were meant to protect.
Why the Failure Persists in Real Builds
Top-level monitoring often looks strong on paper because it is easy to inventory direct dependencies, compare them against policy, and add approval gates. The problem is that the security boundary does not stop there. Package managers expand the graph automatically, and indirect dependencies can introduce new code, new maintainers, and new release pathways without any visible change to the top-level manifest. That is why the control feels complete while still missing the most changeable part of the ecosystem.
In practice, this breaks three things at once. First, it weakens provenance, because teams cannot confidently say which code paths were actually executed during the build. Second, it degrades policy enforcement, because allowlists and review workflows that only see the first layer cannot catch inherited risk. Third, it undermines incident response, because a team that never tracked the deeper graph cannot quickly answer which applications are exposed when an upstream subdependency is compromised.
- Direct dependency review is still useful, but it is only the entry point to the graph, not the whole graph.
- Transitive packages can change even when the top-level reference does not, which means “no change” at the first layer is not “no risk.”
- Build and release controls need visibility into resolved dependencies, not just declared ones.
That is why supply chain controls need to treat dependency resolution as part of the trusted execution path, not as a separate administrative step. Where the build process pulls from public registries, mirrors, or package signatures, the assurance boundary becomes broader than the codebase itself. The guidance breaks down when teams rely on static lists of direct packages and assume those lists are equivalent to what was actually compiled or deployed.
When the Usual Answer Stops Being Enough
Tighter dependency review often increases operational overhead, requiring organisations to balance assurance against release speed and maintenance effort.
The standard advice to “inspect dependencies” becomes incomplete in ecosystems with deep trees, lockfile churn, or frequent transitive updates. In those environments, the more important question is not whether the top-level package is approved, but whether the resolved dependency set is known, reproducible, and continuously monitored. Industry practice is not fully consistent on how much of the tree must be scanned at build time versus at ingest time, but the consensus is that first-layer-only review is too shallow for meaningful supply chain assurance.
Edge cases matter. A small direct dependency set can still hide a large inherited surface. Conversely, highly controlled internal packages may reduce the practical risk of depth, but only if their own publishing and signing process is tightly governed. Organisations also need to distinguish between dependency visibility and dependency control: seeing the graph does not stop compromise unless the pipeline can act on the signal. For teams using package attestations or lockfiles, the value comes from verifying that the resolved artifact matches the expected graph, not from storing the graph as documentation.
Where this guidance fails is in environments that cannot reproduce builds or cannot inventory the full dependency tree at all, because then even a strong policy becomes an unverified assumption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Transitive dependencies are part of application software assurance. |
| Recommendation — Scan resolved dependencies and gate builds on approved software components. | ||
| NIST CSF 2.0 | PR.DS-6 — Integrity Management | Dependency gaps weaken software integrity and trusted build outputs. |
| ID.SC-4 — Suppliers and Third-Party Services are Assessed and Prioritised by Risk | Indirect packages extend third-party supply chain exposure. | |
| Recommendation — Verify build integrity by tracking and validating the resolved dependency set. Assess downstream package suppliers by risk, not just direct vendors. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Missing transitive visibility leaves supply chain compromise paths unmonitored. |
| Recommendation — Hunt for compromise in transitive packages and build-time dependencies. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Lifecycle | Package ecosystems often rely on automated publishing and access tokens. |
| Recommendation — Inventory and rotate automation credentials used in package publishing and builds. | ||
Practitioner Guidance
What to prioritise: Treat resolved transitive dependencies as part of the asset inventory, not as background noise. If your governance only covers direct packages, you are measuring developer intent rather than build reality.
What to verify: Confirm that the control can answer three questions for every release: what was declared, what was resolved, and what was actually built. If any one of those is missing, the monitoring model is too shallow to support trust in the output.
What practitioners underestimate: The hardest failure is not the presence of a malicious subdependency alone, but the belief that first-layer review equals supply chain control. That false confidence delays escalation, broadens blast radius, and makes downstream investigation slower than the compromise itself.
Practitioner takeaway: A dependency program is only as strong as its view of the resolved graph; if the team cannot trace transitive code to a known build outcome, it does not yet have supply chain assurance.
Related resources from NHI Mgmt Group
- What breaks when organisations rely only on post-ingest application security scanning to stop malicious packages and supply-chain compromise?
- What breaks when organisations rely only on static vulnerability checks for software supply chain security?
- What should security teams monitor to detect SaaS supply chain abuse?
- What breaks when supply chain security relies on periodic audits instead of continuous monitoring?
