Hey folks, been wrestling with this for a few weeks now and wanted to see if anyone else has hit the same wall. We've got a monolithic Java service—think 500k+ lines, a sprawling legacy beast—and our Veracode pipeline scans have become a real bottleneck. What used to take 20 minutes is now pushing 90+ minutes consistently, which is throwing a wrench in our CI/CD cycle.
I know static analysis is computationally heavy, but this feels excessive. We're using the Maven plugin setup in a GitHub Actions workflow. The scan just seems to churn forever on the "Uploading and scanning" phase. I've double-checked the obvious: we're excluding the `target/` directories and third-party JARs via the `includes` and `excludes` pattern in the `veracode.config` file. Network latency to their servers seems fine from our runners.
Has anyone found effective tuning strategies for massive Java projects? I'm curious about:
* Splitting the scan by module vs. the whole monolith—does that even help with their analysis model?
* Any specific compiler flags or JVM args that might speed up the packaging step before upload?
* Is there a way to leverage incremental scanning more effectively, or are we stuck with a full scan each time due to policy?
Here's our current config snippet for reference:
```
com.veracode.vosp.api.wrappers=vosp-api-wrappers-java-22.6.7.6.jar
vid=our_username
vkey=our_key
appname=our_monolith
createprofile=false
filepath=target
includes=**/*.jar,**/*.war
excludes=**/target/**/*,**/*test*.jar
```
Any war stories or proven workarounds would be a huge help. We love the security insights, but the speed is becoming a deal-breaker for our devs.
ship it
ship it
Oof, 90 minutes is brutal. Been there.
On splitting by module: it can help, but Veracode's pricing/scan model sometimes gets weird with multiple app instances. A safer middle ground we used was to split the scan at the CI/CD stage. We run a "full" scan nightly on the main branch only, and for PRs we scan just the diff using a custom script that builds a minimal JAR of changed classes. It's a hack, but it keeps PR checks under 15 minutes.
For the packaging step, we found setting MAVEN_OPTS to limit memory (like -Xmx4096m) actually sped things up for the plugin, preventing GC thrash during the collection phase.
Have you looked at your scan preset? The "flaw severity" depth makes a huge time difference on big codebases. We dropped from "Very High" to just "High" and saved ~30% time with minimal loss for our guardrails.
null
Totally agree on adjusting the scan preset. That "Very High" setting can be a real trap for large apps.
The diff-scan approach for PRs is clever. We tried something similar but ran into issues with transitive dependencies - our hacky JAR missed some library classes and flagged false positives. Ended up using a "light" scan preset for PRs instead, which still catches the critical stuff but is much faster.
Your point about MAVEN_OPTS is spot on. We also saw better stability when we matched the plugin's heap to our build runner's available memory, rather than just letting it balloon.
Ship fast, measure faster.