I've recently concluded a comprehensive application security assessment for a new microservices-based API, and I'm encountering a significant discrepancy in the findings between Veracode's Static Analysis (SAST) and the results from a subsequent penetration test. This has prompted a deeper investigation into the tool's configuration and detection methodology, and I'm seeking community insight to determine if this is an expected variance or indicative of a potential gap in our setup.
The application in question is a Go-based service handling financial data, deployed on Kubernetes with a PostgreSQL backend. Our pipeline integrates Veracode SAST via the Jenkins plugin, scanning on each merge request to the main branch. The SAST scan, after full policy adjudication, reported only two critical-severity findings:
* A path traversal vulnerability in a legacy file upload utility.
* An insecure deserialization flaw in a deprecated configuration parser.
However, the mandated external penetration test, conducted by a reputable third party using both automated tools and manual exploration, identified ten critical issues. These included, but were not limited to:
* Multiple SQL injection vectors in newly built GraphQL endpoints.
* Broken object-level authorization allowing horizontal privilege escalation.
* Server-side request forgery in a webhook notification service.
The immediate and most pressing question is the apparent lack of overlap. The SQL injection and SSRF vulnerabilities exist in active, non-deprecated code paths that should have been within the scope of the SAST scan. My initial diagnostic steps have focused on the scan configuration:
```xml
true
3
prod-candidate-sandbox
primary-microservice.jar
```
I have verified that the correct binaries were uploaded and that the "All Rules" policy preset was applied. The build process does not use obfuscation or unusual packing techniques that would hinder analysis.
This divergence raises several methodological concerns:
* Is Veracode's SAST engine less effective against modern API frameworks (in this case, GraphQL implemented via `github.com/graph-gophers/graphql-go`), particularly for identifying authorization flaws and complex injection points that span multiple resolver functions?
* Could the microservice architecture, with its distributed nature, be creating a "context gap" where SAST cannot trace the data flow across service boundaries that a dynamic test observes?
* What is the typical expected ratio or correlation between critical SAST findings and critical penetration test findings in a mature CI/CD pipeline? Are we observing an outlier?
I am presently conducting a triage to map each pen test finding back to the source code to confirm it was in the scanned artifact. Before engaging Veracode support, I wanted to gather empirical data from other teams who have run similar comparisons. Specifically, has anyone performed a calibrated test, seeding known vulnerabilities (e.g., from OWASP Benchmark or deliberately vulnerable apps) into their codebase to measure the detection rate of Veracode SAST under their specific build and scan configuration?
Data over dogma
This discrepancy isn't unusual, but the scale is concerning for a Go service. SAST often misses runtime or environment-specific issues a pen test uncovers.
You mentioned the SAST found issues in deprecated components. That's a red flag - it might be scanning the entire codebase but your build configuration is excluding the active, compiled modules. Check if your `go.mod` and Jenkins build steps are only analyzing the main module without dependencies or if you're using build tags that exclude vulnerable code paths.
The SQL injection findings from the pen test likely exist in your database layer. SAST for Go should catch those unless the query construction is heavily abstracted or uses an ORM in a way that obscures the taint flow. Can you share if you're using `database/sql` directly, an ORM like GORM, or a custom wrapper? The detection gap might be there.
—Alex
That's a classic but concerning gap. The two SAST findings sound like they're flagging known libraries, while the pen test is hitting live endpoints with actual data flows.
Your SQL injection findings especially suggest the SAST tool might not be following taint through your specific database abstraction layer. I've seen this happen when teams use query builders or lightweight wrappers around `database/sql` that obfuscate the string concatenation from the static analyzer.
Did the pen test report include the exact endpoints and parameters for those SQLi issues? Cross-referencing those with the SAST results' data flow paths would be my first step to see where the analysis stopped.
Trust the data, not the demo.
That's a huge difference. I work with a lot of Go services too, and while I know the tools look for different things, a gap that big in a financial app is really worrying.
Since the SAST only flagged stuff in deprecated parts of your code, is it possible the scanner isn't even looking at the active endpoints the pen test hit? Maybe the build context for the scan is wrong?
I'm new to this depth of security testing - when you say "multiple SQL injection" were those found in the main API routes? I'd be curious if those routes are even in the same module as the deprecated utilities Veracode found.