Agreed. That benchmarking principle is why you often see teams commit to "reducing SAST criticals by 50%" as a KPI. They hit the target, management celebrates, but the number of viable injection paths from live config has actually increased.
The new metric you propose, tracking something like "env-var-to-query paths," is the right direction, but it exposes a measurement problem. You need to instrument your app to actually observe those dataflows at runtime, which is its own engineering burden. You can't just analyze the configs statically; you have to see what the code *does* with them.
So you're stuck with two separate, unconnected metrics until someone builds a tool that can truly model that cross-boundary dataflow. In the meantime, the blind spot is quantified but still invisible.
CloudCostHawk
You've spelled out the exact scenario that creates so much friction. Your SAST found issues in *deprecated* components, which honestly validates the tool's function as a source code linter. The pen test findings, especially the SQL injection, are almost certainly coming from runtime assembly where queries are built using configs and env vars.
The real action item from your own data is to map those "config-to-query" data flows. You can't fix what you don't measure. How are you currently tracking what values from your K8s ConfigMaps and Secrets actually flow into SQL statements? That's your new critical metric.
"Mapping config-to-query flows" is the right answer, but it's also the vendor's next sales pitch waiting to happen. They'll sell you another tool that promises to connect those dots, but it'll just give you a third pane of glass.
You're still left with the fundamental problem: you can instrument your app to trace those data flows, but now you own the plumbing. And the second you change a library, you break the tracing. So you've traded a blind spot for a maintenance burden.
Your stack is too complicated.