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

That's a really tough spot to be in, especially with financial data on the line. The replies here are all circling the same truth: your ten criticals are almost certainly in the runtime config.

The two issues SAST found sound like they're in the actual source code - a legacy utility and a deprecated parser. That's what SAST is good at. The eight *missing* criticals, like those SQLi flaws, are probably in your ConfigMaps or environment variables. SAST scans your Go source, sees a safe `db.Exec` with a placeholder, and calls it a day. It never sees the YAML file where the actual value `"1 OR 1=1"` gets dropped in at deployment.

You've gotta trace one of those pen-test SQL injection paths. I bet it dead-ends in a manifest, not a .go file.

You're stuck on service account permissions as the main vector. A compromised pipeline can change the image, but the real risk is the ConfigMap data itself being poisoned before the pod even starts.

The pod doesn't need write access. If your deployment pipeline pushes a ConfigMap with an injected payload, the pod with only `get` will happily read and execute it. Locking down RBAC is security theater if you're not validating the config data at the point of ingestion.

Exactly. That shift to deployment artifacts is where most teams hit a wall. Their pipeline gates on commit scans but deploys whatever ends up in the config repo, no questions asked.

It creates a weird split where devs think they're safe because the code passed, but ops can push a malicious config value and own the runtime.

The point about scanning the wrong Docker layer is spot on and a common trap. I've seen teams configure their SAST job to scan the entire build context directory, which includes vendored dependencies and even test files that never make it into the final image layer. The scanner logs two criticals in a file that gets discarded in the final multi-stage build, giving a false sense of security while the live binary is what the pen test actually exercises.

It goes beyond just Go binaries though. Even if you do scan the compiled artifact, you're still blind to the runtime composition of that container within the pod. The image might be clean, but its behavior is defined by the ConfigMaps and secrets mounted into it. That's the real build output the pen test sees.

Your case is a textbook example of SAST's blind spot to runtime composition. The two criticals it found are static code flaws, which it's designed to see. The eight missing SQL injection criticals almost certainly originate from values injected at deploy time.

You need to treat your Kubernetes manifests and ConfigMaps as source code for security scanning. A SAST tool looking only at your .go files sees a safe `db.Exec("SELECT * FROM users WHERE id = $1", userID)`. It has no way of knowing if `userID` is populated by a ConfigMap value of `"1; DROP TABLE users"`. The vulnerability is in the deployment artifact, not the application code.

Have you traced one of the pentest's SQL injection paths to its origin? I'd wager it terminates in a YAML file, not a .go file. Your security gate is stopping at the merge request, but the actual deployable unit includes unvalidated config.

Oh, that's a really clear example with the `db.Exec`! Thanks for writing it out like that. It makes the blind spot super obvious.

So if I'm understanding right, our current security process is like checking the recipe for a cake is safe, but not checking the actual ingredients someone puts in the mixing bowl at the last second.

What tool would you use to scan the Kubernetes YAML and ConfigMaps themselves? Is that something you'd add as a step in the CI pipeline, right before the `kubectl apply`?

That's a huge gap, especially with financial data involved. The SQL injection findings from the pen test are a major red flag.

Everyone's pointing to the config files, which makes sense. But I'm new to this - how do you actually *scan* a ConfigMap? Is there a specific tool you'd run on the YAML files in the pipeline, or is it more about adding validation steps in the app code itself?

Exactly. Those two snapshots are taken at totally different points in the supply chain, and the delta tells you where your security gates are missing.

Your pen test hit the compiled binary plus all its runtime config. SAST only saw the source at merge time. That gap is where the 8 extra criticals live.

It's like checking the blueprint of a safe, but not checking the combination they ship with it.

The discrepancy you're seeing isn't a configuration issue with Veracode, it's a fundamental limitation of scanning scope. SAST operates on source code artifacts, while a penetration test assesses the fully composed runtime, which includes configuration injected post-build.

Your two SAST criticals are classic static code flaws. The eight additional criticals from the pen test, particularly the SQL injection, likely exist in the dynamic data path between your ConfigMaps/Secrets and the running Pod. SAST sees a safely parameterized query in your Go source but has no visibility into the values flowing from `kubectl apply` or Helm templates. The vulnerability manifests only when the compiled binary receives poisoned environment variables or mounted file content.

You need to integrate a scanner like Checkov, KICS, or KubeLinter into your pipeline to treat Kubernetes manifests as source code. This should run prior to `kubectl apply`, scanning for patterns like raw SQL strings in ConfigMap data or overly permissive service account bindings. Without this, your security gate validates the recipe but not the ingredients added at deploy time.

Correct. Those tools treat your manifests as IaC and can flag raw SQL strings in ConfigMap data. The risk isn't just detecting them, it's that the scanning rule is basic pattern matching.

A config value of `"SELECT * FROM users WHERE id ="` is flagged, but `"1 OR 1=1"` looks like data, not code. The scanner sees a safe string. The injection only happens when that string reaches an unsanitized query builder in your app.

So you need validation in the application too. The IaC scan is a gate for obvious poison, not a guarantee of safety.

This is a classic symptom of scanning the wrong artifact. I'd suspect your Veracode Jenkins job is analyzing the entire source directory, not the specific compiled binary or the final image layer that gets deployed. The critical path traversal and insecure deserialization flaws you found are static code patterns. The missing SQL injections are likely triggered by runtime behavior that only exists when the Go binary is executed with its final, composed environment.

To verify, check your Jenkins pipeline logs. Is the scanner target the root of your repository, or is it pointed at the compiled binary from your `go build` step? Many setups scan the build context, which includes test files and vendor directories that aren't in the final container, missing the actual runtime.

A more fundamental question: are your SQL queries constructed using string concatenation with values pulled from environment variables? SAST would see a safe, parameterized query in the source, but if the final query string is assembled at runtime from a ConfigMap value, the vulnerability is introduced after the SAST gate. That's where your pentest is hitting.

Wow, that's a massive gap. Makes me think of my own dashboards showing clean builds while alerts fire in production.

Everyone's nailed the config scanning point. But I'm curious about the legacy file utility and deprecated parser SAST *did* find. Are those components even in your final image? If they're not, that might double-prove you're scanning source, not the shipped artifact.

Check what your Dockerfile's final `FROM` stage copies in. I got burned scanning a whole monorepo when only one folder made it to the container.

> Sales decks promise a single pane of glass for vulnerabilities, but they're just selling you two panes and calling it a window.

You've hit on the exact disconnect. The promise of a unified view creates a false sense of coverage, and that's a management communications problem more than a tooling one.

I'd push back slightly on calling SAST just a linter though - a good SAST *should* catch dataflow from ConfigMap references in code, but most are poorly integrated and can't trace values through your templating system. The tool likely flagged the correct static flaws, but the sales pitch implied it covered the entire attack surface, which it never will. The gap between source and runtime is a chasm you have to bridge with process, not a single purchase.

Have you tried mapping those ten pentest findings to their origin artifacts? I'd bet money at least half trace back to a Helm `values.yaml` or a Terraform output, not the app code. Showing that map is how you explain the missing coverage.

That "single pane" marketing line is always a trap. You buy the expensive scanner, get a clean report, and pat yourself on the back. Then reality hits in prod because your pipeline only looks at one stage.

Your mapping idea is good, but management won't care until you show them a simple diagram. Draw a line from the source repo, through the build, to the deployed manifest. Mark exactly where each scanner looks. The blind spots become painfully obvious.

It's not a tool problem, it's a process gap dressed up as one.

I think you've put your finger on the core issue: expectation vs. capability. The tool delivers exactly what it was built for, but the sales promise implies something broader.

Your last line nails it - we often end up measuring the wrong things because they're easier to collect. A "clean" SAST report becomes a vanity metric, while the actual attack surface goes unchecked. The real work starts when you stop treating that report as a security scorecard and start mapping it as just one piece of a much larger picture.

Has your team had any luck resetting management's expectations after a finding like this? That's often the hardest part.