Scanning only one layer leaves blind spots. A team may know a vulnerable package exists, but not whether proprietary code actually reaches the risky function. Combining code analysis with dependency analysis helps identify whether a flaw is truly exploitable, which improves prioritisation and reduces noise. That distinction matters because security teams need to focus on exposure, not just presence of a weakness.
Why scanning only one layer creates a misleading picture
Scanning code or dependencies in isolation gives you only part of the exposure story. A dependency may be vulnerable on paper, but if the application never reaches the dangerous function, the practical risk can be much lower. The reverse is also true: custom code may call an unsafe path in a package that looks harmless until runtime context is considered.
That is why combined analysis is more useful than a single-layer scan. It helps teams separate theoretical weakness from reachable weakness, which is the difference between an inventory problem and an exploitable problem. In supply chain work, exposure is usually what matters, not just the existence of a flaw somewhere in the tree.
One useful way to think about this is that code analysis answers "where does the application actually go?", while dependency analysis answers "what external behaviour is it relying on?". When those two views are merged, security teams can see whether a risky package is truly on a reachable path or whether the vulnerable code is effectively dead in the current build.
If you want a broader reference point for software supply chain integrity, the NIST SSDF (SP 800-218) and SLSA both reinforce the need to manage software trust at build and dependency boundaries, not just at the package-list level.
What changes when reachability is part of the scan
The main operational change is prioritisation. When teams only know that a vulnerable package exists, they often create large remediation queues full of issues that may never be exploitable. Once reachability is included, they can focus first on flaws that are actually invoked by the application and therefore capable of causing damage.
This also reduces noise for developers and security reviewers. A combined view can prevent unnecessary rewrites, unnecessary emergency patches, and wasted time validating issues that sit in a dependency but are never exercised in the deployed code path. For large estates, that difference matters because false urgency is itself a scaling problem.
For software supply chain governance, that is also where layered controls become valuable. OpenSSF resources and the NIST Cybersecurity Framework 2.0 both support a broader control posture that includes asset understanding, software provenance, and risk-based treatment rather than raw vulnerability counting.
When combined scanning is missing, remediation decisions can become distorted. Teams may overreact to a dependency issue that is not reachable, while missing a custom-code path that makes an otherwise ordinary package genuinely dangerous.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Reachability-based scanning supports risk-based software prioritisation. |
| Recommendation — Prioritise reachable software weaknesses using risk-based treatment in your governance process. | ||
| CIS Controls v8 | 16 — Application Software Security | Scanning code and dependencies is part of securing software before release. |
| Recommendation — Apply application security testing that covers code and third-party dependencies together. | ||
| NIST AI RMF | GOVERN 2.2 — AI system and component inventory | Dependency visibility depends on knowing the software components and their relationships. |
| Recommendation — Maintain an accurate software component inventory before relying on vulnerability results. | ||
Practitioner Guidance
What to prioritise: Treat combined code and dependency scanning as a triage mechanism, not a reporting exercise. The first question should be whether the flaw is reachable in the deployed path, because reachability usually determines whether the issue belongs in the urgent queue or the backlog.
What to verify: Make sure scan results can be tied to actual call paths, runtime usage, and deployment context. If your tooling cannot show whether proprietary code reaches the risky function, you do not yet have enough evidence to rank the issue confidently.
Common mistake: Teams often confuse "present in the build" with "exploitable in practice". That shortcut creates remediation noise, hides the issues that matter most, and makes security teams less trusted by developers over time.
Practitioner takeaway: The best supply chain scans tell you not just what is vulnerable, but whether the vulnerable surface is actually reachable, because that is what turns a theoretical issue into a real security decision.
Related resources from NHI Mgmt Group
- What is the difference between code-only AppSec scanning and end-to-end software supply chain visibility?
- Should organisations treat licence compliance as part of software supply-chain risk?
- Why do vulnerable dependencies create such a large software supply chain risk?
- Why do transitive dependencies create more software supply chain risk than direct packages alone?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
