Topic starter
01/08/2026 10:45 pm
TL;DR: A pre-merge scan misses whether a dependency is deployed, reachable, or exploitable, with OXSecurity's post arguing that Software Composition Analysis must follow risk into builds and runtime. Dependency governance becomes useful only when scans are tied to pipeline provenance and live exposure.
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: 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.
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.
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.
Glossary terms: Software Composition Analysis, Reachability analysis, Software Bill of Materials, Transitive Dependency
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 hours ago by NHI Mgmt Group
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