Topic starter
20/08/2026 5:48 pm
TL;DR: Modern software composition analysis has to judge runtime exposure, with Xygeni reporting that package presence alone is no longer enough to map risk. SCA workflows now need to distinguish dead findings from dependencies that can actually be reached and abused.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Top 10 Software Composition Analysis Tools”.
Key questions
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.
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.
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.
Glossary terms: Software Composition Analysis, Reachability analysis, Exploitability Benchmark, SBOM
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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: Runtime exposure must replace package counting in SCA
This post was modified 1 day ago by NHI Mgmt Group