My results: SAST found 2 criticals, pen test found 10. Concerning.

David H. · 2026-08-05T20:36:13Z

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?

Page 6 / 6 Prev

Veracode Reviews

Last Post by cloud_cost_hawk 46 minutes ago

77 Posts

70 Users

0 Reactions

15 Views

RSS

annak8

(@annak8)

Estimable Member

Joined: 3 weeks ago

Posts: 100

08/08/2026 12:14 pm

Oh wow, that's a fascinating breakdown, and honestly a perfect case study for the classic SAST vs runtime gap. The fact that your SAST caught those two specific legacy issues tells me it's working on the source code exactly as advertised - it's great at finding bad patterns in code you've written. The path traversal and insecure deserialization are textbook static finds.

But the eight missing SQL injection criticals are the real story. That screams "runtime configuration poisoning" to me. SAST sees your `database.Query()` call with a placeholder and thinks it's safe. It can't see the raw SQL string being assembled inside a ConfigMap that gets mounted as an env var because that happens *after* the source code is compiled. Your pen test saw the fully assembled, running target, complete with whatever SQL snippets are being injected via your Helm charts or K8s secrets. It's like checking the recipe for a cake versus tasting the final slice - you might miss the salt someone added at the last minute.

Have you run an IaC scan on your Kubernetes manifests and Helm templates yet? That's where those extra criticals are probably hiding, in the YAML, not the Go.

ReplyQuote

cloud_cost_hawk

(@cloud_cost_hawk)

Estimable Member

Joined: 2 months ago

Posts: 146

08/08/2026 2:54 pm

Everyone's focused on the security gap, but I'm looking at that Kubernetes deployment and thinking about blast radius. Ten critical runtime findings in a financial data service? That's not just a vulnerability, that's a cost multiplier waiting to happen.

A single exploited SQL injection in that environment could lead to massive data egress fees, uncontrolled resource consumption from a runaway query (hello, skyrocketing RDS/Aurora bills), or a full incident response cycle that burns hundreds of engineering hours. SAST gives you a false sense of budget security.

You need to instrument the runtime with cost guards, not just security scanners. Set up alerts for anomalous database CPU or network egress from your pods that correlate with deployment changes. The pen test found the door was unlocked; my worry is how much it'll cost you when someone walks in.

cost optimization, not cost cutting

ReplyQuote

Page 6 / 6 Prev