Let's just get this out there: anyone using Veracode for the "full suite" and assuming their Software Composition Analysis (SCA) component is competitive with dedicated tools like Snyk, Mend (formerly WhiteSource), or even GitHub Advanced Security is kidding themselves. It's the classic "jack of all trades, master of none" scenario, but in this case, the SCA feels like an afterthought bolted onto their SAST engine to check a box on an enterprise procurement form.
The core issue is the lack of depth and actionable intelligence. Running a scan yields a list of CVEs, sure. But the prioritization is often flat, missing the crucial context that modern SCA platforms provide. Where's the reachability analysis? The exploit maturity scoring? The clear remediation path that doesn't just say "upgrade to the next major version," which might break half your dependencies? Veracode's SCA tells you *what* is vulnerable, but leaves you to do the heavy lifting on the *so what* and the *now what*. In a complex microservices environment, that's a non-starter.
Consider the developer experience. Their IDE plugin for SCA is rudimentary compared to the real-time, in-line feedback you get from a Snyk Open Source scan. It's a batch-process mentality in a shift-left world. Furthermore, their policy engine, while decent for SAST, feels clunky when applied to SCA. Creating rules to flag specific license types or block high-severity CVEs in development dependencies is a bureaucratic exercise in their UI, not a streamlined, code-centric workflow.
The data speaks for itself. Run a comparison on one of your own codebases. Here's a trivial example from a Node.js service I was auditing:
```
# Veracode SCA results (summary)
[email protected] - CVE-2020-28500 (Medium)
axios@0.19.0 - CVE-2020-28168 (Medium)
# Snyk CLI results on the same codebase
[email protected] - CVE-2020-28500 (Medium) - [Reachable via: lib/utils/helper.js:45]
axios@0.19.0 - CVE-2020-28168 (Medium) - [Fix available: upgrade to 0.21.1]
minimist@1.2.0 - CVE-2021-44906 (Critical) - [In dev dependencies, exploit: Published]
```
Notice the extra layers of metadata? The reachability info for lodash tells my team they can deprioritize it because the vulnerable function isn't actually called. The fix version for axios is explicit. And Snyk caught a critical in a *dev dependency* that Veracode completely missed because it wasn't configured to look at `devDependencies` by default—another configuration pitfall.
Ultimately, if you're already paying for Veracode SAST and your security team is wedded to the platform, fine. But treating their SCA as your single source of truth for dependency risk is a massive gap in your security posture. You're better off using their SAST and pairing it with a best-in-class SCA tool, even if it means managing another vendor. The cost of missing a critical, exploitable vulnerability in a third-party library far outweighs the perceived convenience of a single pane of glass that's only giving you a partial, blurry view.
-- Cam
Trust but verify.