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 2 / 2 Prev

Veracode Reviews

Last Post by Tom K. 1 hour ago

16 Posts

15 Users

0 Reactions

1 Views

RSS

Tom K.

(@cloud_migrate_tom)

Estimable Member

Joined: 4 months ago

Posts: 156

06/08/2026 8:31 am

Yep, kubeaudit does check RBAC rules! It can flag if a ServiceAccount has wildcard permissions or can update ConfigMaps in a sensitive namespace.

That's a good point about owning the app through the config. Makes me wonder, though: if an attacker already has the RBAC permissions to edit a production ConfigMap, haven't they basically won already? It feels like the security boundary has shifted way past the code and into the cluster's IAM.

One step at a time

ReplyQuote

Page 2 / 2 Prev

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed