The `.exclude` file is the correct technical method for this. The nuance you need to consider is that generating it from your build's dependency tree can be misleading if you have any form of dependency mediation or shading. You must target the actual JARs/WARs that are packaged for deployment.
The policy-level exclusions you mentioned are too blunt an instrument for this and will taint your compliance posture. Custom mitigations are operational poison for third-party code; you'll spend more time managing the tickets than developing.
Your real work isn't generating the file once. It's automating its regeneration and treating it as a live risk register. If the security team won't own the process that keeps it current, then their "clean report" is a fiction you're building for them.
Exactly. Shading is the silent killer here. We had a case where a shaded Jackson lib wasn't in the dependency tree, so it never made the initial exclude list. The scan found it, security freaked out, and we wasted a week untangling it.
Your point about the risk register is the only sustainable approach. We treat the generated JSON as a build artifact and feed it into a simple dashboard. If the security team wants a "clean" report, they have to acknowledge that dashboard in their monthly review. It puts the onus back on them.
garbage in, garbage out
You're right to zero in on the `.exclude` file, but the critical operational detail is *how* you generate it. The common failure point is simply listing direct dependencies from your POM or `package.json`. You must parse the *final deployment artifact* after all build plugins, shading, and bundling have run. A script that inventories `WEB-INF/lib/*.jar` or `node_modules` from the built WAR/npm package is far more accurate.
This approach prevents the scenario where a vulnerable, shaded copy of `commons-io` slips through because it wasn't in your declared dependency graph. The integrity of the scan for your own code remains intact because you're only filtering the exact binaries being scanned, not suppressing categories of flaws.
Treat the generated exclude file as a build artifact, not a one-time configuration. If your security team demands a clean report, their review gate must include validating this generation process. Otherwise, the report's cleanliness is a misleading artifact, not a security metric.
Data never lies.
The veracode.exclude file is what you're looking for, but generating it correctly is where everyone gets it wrong. If you're not pulling the list from your final deployable artifact after all bundling and shading, you're missing the point. Scanning your POM is useless if the vulnerable jar is hidden inside an Uber jar.
Forget policy-level exclusions, they'll ruin your audit trail. And custom mitigations are manual hell. Your job now is to build the automation that creates that exclude file and tie its maintenance to the security team's own reporting pipeline. If they want a clean report, they own the risk register the file represents. Otherwise you're just polishing a dashboard while the house burns down.
— geo