Hi everyone! 👋 Still getting my feet wet with integrating security scans into our CI/CD, and Veracode’s been… a lot to figure out. Our full pipeline scans were taking forever, especially on bigger PRs.
I got overwhelmed looking at the logs, so I tried building a simple Python wrapper that only runs Veracode scans on files changed in a pull request (using git diff). The idea was to speed up feedback for devs.
Here’s the basic flow I set up:
* Use the GitHub API (we’re on GitHub Actions) to get the list of changed files for a PR.
* Filter for just the source code files we care about (e.g., .py, .js, .java).
* Then, only upload and scan that subset with Veracode’s CLI.
But I’m running into two confusing issues and could really use some advice:
1. **Partial Scan Results**: When the wrapper uploads just 5 changed files, the Veracode scan sometimes reports “No flaws found,” but I *know* one of those files has a vulnerability (it’s in our baseline). Is it invalid to scan a small subset of the application? Does Veracode need the full context of the codebase?
2. **Policy Status Confusion**: Even when the scan finds flaws in the changed files, the overall policy status sometimes comes back “Passed” when I expected “Failed.” I’m not sure if I’m misreading the results or if our policy settings are affecting this.
Has anyone else tried something like this? I’d be super grateful for any pointers on whether this “scan-only-changed-files” approach is even workable with Veracode, or if I’m going down a totally wrong path here.
Attached a screenshot of the workflow output where it found 3 medium flaws but still passed the policy check – it’s got me scratching my head.
null
Interesting approach. That policy status confusion happens sometimes. Is the scan comparing just those few files against the full app policy? That mismatch might explain it.
On the partial scan results, I've seen similar issues in other tools. Scanning a tiny fragment of the app can miss how different pieces interact. Does Veracode's documentation mention anything about needing a complete build context?
Have you looked at how tools like Checkmarx or Snyk handle incremental scans? I'm curious if they have the same limitation.
You're running into the fundamental limitation of SAST tools. They need a full, compiled build artifact to analyze data flow across the entire application. Scanning isolated files misses the context of how data moves between them, which is where most serious flaws are found.
The policy status issue is a side effect. Veracode compares the scan results against the policy for the *entire application*. If you upload a partial app, the policy evaluation is broken.
If you need speed, look at Veracode's pipeline scan for PRs. It's designed for incremental feedback and uses your full baseline scan as context. Your wrapper is creating more problems than it solves.
Build once, deploy everywhere
That's a solid point about data flow, it's a real weakness with incremental SAST. We hit something similar with Checkmarx a while back.
But isn't the whole promise of pipeline scans from Veracode and others *also* incremental scanning? They must have some way to anchor to the baseline context without a full re-scan. I wonder if the OP's wrapper is just missing that anchoring step, like not properly linking to the last full app scan.
Still looking for the perfect one
Yeah, that anchoring is the key. Veracode's pipeline scan does a diff scan, but it's anchored to a previous, *complete* application baseline scan you've already uploaded. Your wrapper is trying to do the diff at the file-upload stage, which is too late.
The CLI command needs the `--baseline_guid` flag to point to that full baseline. Without it, you're just uploading random files and the platform has no idea how they fit into the larger app. That's why the policy status gets weird.
I think the intent is good, but you're basically trying to re-engineer their pipeline scan product. You might have more luck using their official action and just configuring it for PRs.