Topic starter
01/08/2026 10:45 pm
TL;DR: Open-source dependencies now make up 70 to 90 percent of modern application code, and the article argues that Software Composition Analysis has shifted from a pre-merge scan to a broader runtime and pipeline governance problem, according to OXSecurity. The key implication is that teams need reachability, deployment, and exploitability context, not just CVE lists, to separate noise from risk.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “10 Best SCA Tools for 2025: Evaluating Software Composition Analysis for Modern Security Pipelines”.
Key questions
Q: What breaks when SCA stops at pre-merge scanning?
A: Teams lose visibility into whether a dependency is actually deployed, reachable, or exploitable in production.
Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?
A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews.
Q: How should teams decide which security findings to fix first?
A: Prioritise findings that are both reachable and tied to active code paths.
Practitioner guidance
- Map dependency findings to runtime exposure Prioritise components only when the vulnerable package is actually deployed in an exposed service or privileged execution path.
- Correlate SCA with pipeline provenance Record which build, artifact, and pipeline change introduced each dependency so remediation can target the right delivery stage.
- Triage transitive dependencies separately Treat deep transitive libraries as a distinct risk class because they often carry the most hidden exposure and the least developer visibility.
Bottom line: Modern SCA now has to answer where a dependency runs, not only whether it exists in source control.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 10:54 pm
Dependency governance is now a runtime problem, not just a pre-commit problem. SCA that stops at the manifest misses the point of modern delivery pipelines, where packages are promoted, containerised, and executed long after the original scan. The right governance question is no longer only what is in the repository, but where the component actually runs and whether the vulnerable path is reachable. Practitioners should treat dependency governance as part of runtime exposure management.
A question worth separating out:
Q: How should teams govern dependency risk across CI/CD and runtime?
A: Treat dependency governance as a lifecycle control, not a single scan. Use SBOMs, pipeline provenance, and runtime mapping to connect a vulnerable package to the artifact and service that actually shipped. That gives security and engineering teams a shared view of where risk entered, where it runs, and how far it can spread.
👉 Read our full editorial: SCA tools in 2025: why dependency risk now spans runtime