We’re evaluating Veracode SAST. Their messaging emphasizes fast, incremental scanning integrated into the pipeline.
Our reality:
- Baseline scan for a ~500k LOC Java monolith took 4.5 hours. Acceptable.
- Subsequent “incremental” scans on a typical PR (touching 5-10 files) consistently take 45+ minutes.
- This breaks our 15-minute CI/CD gate requirement.
Key observations:
* The agent-based scan still seems to be analyzing large portions of the dependency tree, not just the changed files.
* The “pipeline scan” option had worse performance in our tests.
* Support cited “project complexity” and suggested we adjust scan settings, which degraded vulnerability detection.
Question for others: Is this typical? What scan configurations or pipeline setups have you used to get sub-15-minute feedback?
—D
Five nines? Prove it.
Oh, this hits home. We went through nearly the same evaluation last year with a similar-sized .NET codebase. Their marketing materials definitely paint a rosier picture of "incremental" than what we experienced.
The 45-minute mark for small changes was our breaking point, too. We found that, for our setup, the promise of analyzing "just the changed files" was a bit of a myth. The engine seemed to spend most of its time re-establishing context and re-analyzing dependencies touched by those files, which for a monolithic app was basically everything. Tuning the settings down to hit a 15-minute target made the results feel useless - we missed known issues.
We never got it under 25 minutes consistently. In the end, we had to shift the SAST scan to a nightly "aggregated diff" process and rely on a faster, linter-style tool at the PR gate. It was a compromise, but the 15-minute gate was non-negotiable for dev flow. Have you looked at splitting the monolith into smaller, independently scannable modules? That's the only way I've heard of folks making it work.
Yeah, that tracks. The "incremental" label is about the scan type, not the engine's actual workload. For a monolith with tight coupling, the engine has to rebuild the whole project graph to understand the context of your 5-10 changed files. It's not analyzing every line, but that graph resolution and dependency tracing is where your 45 minutes goes.
Their support's advice to cripple detection is a non-starter. You're trading a fast gate for a meaningless one.
Have you tried segmenting the monolith into separate Veracode "applications" for logical modules? It's a pain to set up, but it can create smaller analysis boundaries. The real answer, though, is that for a tightly-coupled 500k LOC monolith, a 15-minute SAST gate with their current engine is likely unrealistic. We moved to a nightly full scan with PRs just triggering a policy check against the latest results.