Notifications
Clear all
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.
NHIMG editorial — based on content published by OXSecurity: Top 10 SCA tools for 2025
By the numbers:
- Open source now makes up 70 to 90% of the code in modern software.
- Sonatype’s 2023 report found 245,032 malicious packages, and this number tripled in just one year.
Questions worth separating out
Q: How should security teams prioritise SCA findings in modern delivery pipelines?
A: Prioritise SCA findings by exploitability, not by raw count.
Q: Why do transitive dependencies create more risk than teams expect?
A: Transitive dependencies are often invisible to the developer who triggered them, but they still become part of the shipped application.
Q: What do security teams get wrong about Software Composition Analysis?
A: The common mistake is treating SCA as a one-time scan of source code.
Practitioner guidance
- Prioritise reachable dependencies first Rank SCA findings by whether the library is actually reachable in production, not just whether it appears in a manifest or lockfile.
- Bind findings to build provenance Track which commit, pipeline, and artifact introduced each vulnerable component so remediation targets the correct release path.
- Review pipeline identities and secrets together Audit the credentials, tokens, and service accounts that allow dependency updates, artifact publication, and deployment promotion.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Side-by-side feature comparison of the top 10 SCA tools across CI/CD, IDE, and runtime workflows
- Tool-specific notes on SBOM generation, license enforcement, and remediation automation
- Implementation observations on how each platform handles transitive dependencies and alert volume
- Practical fit guidance for teams choosing between developer-first and enterprise-grade SCA approaches
👉 Read OXSecurity's full review of the top 10 SCA tools for 2025 →
SCA tools in 2025: are your dependency controls keeping up?
Explore further
01/08/2026 10:54 pm
SCA has moved from component discovery to exposure governance. The article shows why scanning for known CVEs is no longer enough when the real question is whether a dependency is reachable in production, tied to a privileged pipeline, or exposed through runtime paths. That changes SCA from a software inventory task into a governance control for exploitability. Practitioners should treat this as an exposure-ranking discipline, not a checklist of package hygiene.
A question worth separating out:
Q: How should organisations decide whether to block a release for an SCA finding?
A: Block the release when the vulnerable component is reachable, internet-exposed, or tied to a high-value service where exploitation would materially change business risk. If the issue is not reachable, track it with a deadline and owner instead of turning every alert into an emergency.
👉 Read our full editorial: SCA tools in 2025: why dependency risk now spans runtime
