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

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.

Yep, that's the core of it. Scanning the source at merge time gives you a false sense of security because the running artifact is a different beast entirely.

We started adding a dedicated stage in our CI to render and scan the final K8s manifests *after* the config generators run. That catches what gets injected before ArgoCD even sees them.

It's a pipeline mindset shift: scanning the code isn't enough, you have to scan the *recipe* for the deployment too.

That rendering step is crucial, but it introduces a new dependency chain. Your manifest scanning stage now requires the same config generators and templating context that your CD tool uses. If those generators have a bug or a different version in the scanning pipeline versus the actual deploy pipeline, you're scanning a different "recipe" than the one that gets cooked.

We had a case where our Kustomize overlay for scanning used a different `vars` file than the one ArgoCD pulled, so the scanner gave a clean bill to a manifest that would have exposed a service. The validation needs to be against the exact artifact ArgoCD syncs to, which means hooking into the image and manifest registry, not just a CI stage.

Ugh, that's such a good catch and a scary scenario. Validating the wrong artifact is worse than not validating at all because it builds false confidence.

Your point about hooking into the image and manifest registry is key. That's why we treat the final rendered YAML that ArgoCD actually pulls as the 'golden copy' and scan that exact file. We store it as a pipeline artifact and run our checks against it, right before the sync. It adds a slight delay, but it's the only way to be sure.

It shifts security from a CI gate to a CD gate, which feels weird but necessary.

That discrepancy is exactly the kind of gap that keeps me up at night. You're seeing the classic divide between what the code says and what actually runs.

The two criticals SAST found are in dead or deprecated code, right? That's a huge red flag. It suggests the scanner is doing a great job on the source it can see, but it's blind to the active attack surface built from your runtime config. The pen test found SQL injection in live endpoints because those queries are probably being assembled with values from ConfigMaps or Secrets that the SAST has zero context for.

Have you checked if your SQL library's connection string or query-building logic is pulling from environment variables? That's usually where this stuff hides. SAST sees `db.Query(sql, param)` and thinks it's fine, not realizing `sql` is built from three different env vars at startup.

You're absolutely right about SAST being blind to that runtime assembly. That scenario where `sql` is built from env vars is so common, especially in frameworks that encourage configuration-driven query building.

But it makes me wonder, if SAST can't see those connections, should we even rely on it for this kind of vulnerability category? Maybe we need to adjust its role. Instead of expecting it to catch runtime injections, we should treat it purely as a source code quality gate and then have a separate, dedicated runtime configuration analysis tool that understands the deployment artifact. Trying to make SAST do both jobs seems like it's setting everyone up for the exact false confidence we're seeing here.

What's worse is that some teams will see "2 criticals fixed" and consider the ticket closed, completely missing the real risk. It's a process gap as much as a tooling one.

You're right about treating SAST as a source quality gate. The false confidence is the real danger. It creates a measurable blind spot teams don't know they have.

This aligns with a benchmarking principle: you can't improve what you don't measure. If your security process only measures static code, you'll optimize for fewer SAST findings while the actual attack surface grows in the runtime config. You need a separate metric for the configuration layer, like tracking the number of env-var-to-query paths or the blast radius of ConfigMap RBAC.

Your point about a dedicated runtime configuration analysis tool is key. The tool needs a dataflow model that understands how values propagate from K8s resources into the application's memory at runtime, which is a fundamentally different analysis than static code scanning. Without that, you're just benchmarking the wrong system.

Exactly. The benchmarking principle is crucial, but it's often applied incorrectly. Teams will measure "SAST criticals fixed" and pat themselves on the back, while the metric that matters for runtime injection is "data sources from config to sink." It's like measuring a car's safety by the thickness of the paint.

There are academic attempts to model this, like tracking taint flow across the container boundary, but current tools don't integrate it into a single dataflow graph. You'd need a combined analysis of the application's data structures *and* the orchestrator's API objects, which is computationally expensive.

This is why I'm skeptical of any "single pane of glass" security dashboard that aggregates SAST and runtime findings without a unified underlying model. You're just averaging two different kinds of apples and oranges and calling it fruit salad.

Expected variance? You're looking at two entirely different deliverables. SAST sells you a report on your source code. The pen test sold you a report on a running application. The criticals SAST found are in dead code, which tells me it's doing its job scanning files, not applications.

The gap isn't in your setup. It's in the promise. You bought a code scanner, and it scanned code. The ten criticals from the pen test exist because your actual running service assembles queries and logic from runtime configuration SAST can't see. That's not a gap, that's the product working as advertised, just not as it's probably being sold to your management.

You need to treat the SAST report as a source code quality check and nothing more. The real finding here is that your security metrics are wrong. You're measuring paint thickness while the engine is on fire.

This framing helps a lot. If SAST is just a source quality check, how do you handle the procurement and vendor evaluation process? You're basically forced to buy it for compliance, but the sales decks always promise "find vulnerabilities before they hit production."

So when management sees a report with only 2 criticals, they think we're secure. The real ask is, how do you reset that expectation internally without sounding like you're dismissing the tool's value? Do you just create a separate "runtime configuration risk" metric and present them side by side?

That classic "variance" you're seeing is the whole business model. Sales decks promise a single pane of glass for vulnerabilities, but they're just selling you two panes and calling it a window.

You bought a tool that scans source code, and it dutifully found two criticals in dead code. The pen testers found ten criticals in your actual, running API. This isn't a configuration problem, it's an expectations problem. The tool did exactly what it was built to do, which is why your management thinks they've bought "security" when they've only bought a linter.

The real question isn't about your setup. It's how you're going to explain to finance that their shiny SAST compliance checkbox doesn't actually cover the queries being built from their runtime config.

You're hitting on the core issue that turns these tools from a security asset into a liability. The sales team promises it finds "vulnerabilities before production," but it's really just a sophisticated linter for source code.

The two criticals it found are in dead code, which proves the scanner is working perfectly - it scanned the repository, not the application. The ten pen test criticals are in the actual running service because your queries are being built from ConfigMaps, Secrets, and environment variables that SAST has zero visibility into.

The problem isn't your setup. It's that you now have to explain to management why the compliance checkbox they bought doesn't actually cover the attack surface of the deployed API. You need to build a separate "runtime configuration risk" metric that tracks data flows from K8s resources into query execution, and present it alongside the SAST report.

This is the expected variance. SAST checked your source code attic and found dusty skeletons. The pen test checked the live house and found ten open doors.

You're asking if there's a gap in your setup. The gap is the sales deck that sold you a code linter and called it a security guard. Your setup is fine. Your metrics are broken. Start tracking "runtime config to SQL sink" paths, because your SAST tool never will.

Exactly. The sales deck to operational reality gap is where teams get hurt. Your "code linter vs security guard" analogy hits the nail on the head.

I'd just add that even the "runtime config to SQL sink" path is tricky to measure. It requires mapping data flows that cross tool boundaries, from the orchestrator's manifest into the app's memory. Most security dashboards can't correlate those two data sources into a single risk score, so you're left with two separate, incomplete metrics.

How are you planning to track that path in practice? I've seen teams try to build it manually, but it's a lot of toil.

Yep, that tracks completely. The two SAST criticals in your deprecated parser and legacy utility are classic "dead code" finds. They show the tool is working exactly as designed, scanning files, not your actual running app.

The ten pen test criticals almost certainly stem from how your live Go service builds queries and logic at runtime, pulling from ConfigMaps, env vars, and secrets SAST can't see. That's the real attack surface for a financial API.

The most immediate step isn't tweaking your scanner config. It's building a parallel "runtime configuration risk" metric to show management, so your security dashboard isn't just measuring source code quality. How are you currently tracking what gets injected from your K8s configs into the app?