Topic starter
20/08/2026 5:48 pm
TL;DR: Software composition analysis has moved beyond CVE lists toward reachability, exploitability, malware detection, and SBOM support as open source dependency risk becomes a supply chain problem, according to Xygeni. The governance question is no longer whether to scan dependencies, but whether teams can separate theoretical exposure from runtime risk fast enough to protect delivery.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Top 10 Software Composition Analysis Tools”.
Key questions
Q: Why is reachability analysis more useful than CVE-only scanning for SCA?
A: Reachability analysis tells you whether a vulnerable function can actually be called in the running application, which is far more actionable than a raw dependency list.
Q: What breaks when software composition analysis stops at the SBOM?
A: An SBOM gives visibility into what components are present, but it does not tell you which dependencies are exploitable, trusted, or malicious.
Q: How should teams govern supply chain risk when packages may be malicious?
A: Treat package intake as a trust decision, not just a vulnerability check.
Practitioner guidance
- Prioritise reachable dependencies first Rank open source findings by whether the vulnerable code path is actually executed in production, then treat unreached CVEs as lower operational priority until context changes.
- Separate malware checks from CVE scanning Add package trust and behaviour-based malware detection to your SCA pipeline so malicious dependencies are screened even when no CVE exists.
- Map dependency findings to delivery credentials Review which build and registry credentials can install, publish, or promote packages, then narrow those permissions to reduce supply chain blast radius.
Bottom line: Modern SCA now has to judge runtime exposure, not just list the packages present in a codebase.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:28 pm
Runtime context is now the dividing line between useful SCA and noisy compliance theatre. The article reflects a broader market shift from dependency enumeration to exposure judgement. Static manifest scans can tell you what is present, but not whether a vulnerable library is reachable in the running code path. Practitioners should treat reachability as the control that separates theoretical risk from actionable risk.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should DevSecOps teams do when SCA findings are tied to build credentials?
A: They should review which tokens, service accounts, and pipeline roles can install, publish, or promote dependencies, then reduce that access to the minimum needed. When build credentials are broad, a single package compromise can spread quickly through release systems and artifact stores.
👉 Read our full editorial: Software composition analysis tools now need runtime risk context