Every year, organizations spend billions fixing security problems that should never have reached production. The vulnerabilities were there from the beginning, buried in the code, hidden in container images, tucked inside dependencies nobody audited closely enough. The tools to catch them existed. The knowledge existed. What was missing was the discipline to act earlier, and the data to prove just how much that delay was actually costing. That data now exists.
Pruthvi Raj Seknametla is a researcher and published author specializing in cloud-native security architectures, DevSecOps pipeline engineering, and Kubernetes-based infrastructure. His research on shift-left security practices has appeared in the International Journal of Computer Techniques (IJCT), is indexed on Zenodo, and has earned him recognition across the DevSecOps and cloud-native security fields.
Seknametla does not talk about security the way most people in the industry do. Where others speak in frameworks and best-practice checklists, he speaks in numbers. His published study, Shift-Left Security Practices in Kubernetes-Based DevOps Environments: Measuring Impact on Software Vulnerability Reduction, followed real teams across nine organizations over fourteen months, measuring what actually changed when security moved earlier in the development process. The results were hard to dismiss: a 68% catch rate for critical vulnerabilities before code reached staging, a 44% drop in deployment rollbacks, and remediation costs that fell by an order of magnitude compared to teams still using late-stage review.
Since its publication, the study has drawn attention from practitioners across the DevSecOps and cloud-native security fields. Seknametla was candid about both the findings and the gaps he continues to see across the industry.
On Why Security Has Always Been Done at the Wrong Time
The starting point is a question the industry rarely asks openly: why has the traditional model failed for so long, despite so many smart people working within it?
For Seknametla, the answer is not about talent. The problem, he says, is built into the structure itself. In a conventional pipeline, security review comes near the end. By the time a vulnerability is found, it is already deep inside the product. Fixing it means reworking components, retesting dependencies, and re-releasing code that was otherwise ready to ship. His study found that reactive organizations faced remediation costs an order of magnitude higher than those catching problems during development.
“What we demonstrated is not just a speed improvement. When you catch a problem at the developer’s workstation versus in production, you are not just saving a few hours. You are changing the fundamental economics of the entire process. The cost curve does not just move — it bends.”
In Kubernetes-based environments, he adds, the stakes are even higher. A single insecure container image does not stay contained. It replicates.
“Kubernetes amplifies everything — including unaddressed vulnerabilities. An insecure container image that would have been a localized problem in a monolithic deployment becomes a distributed risk across dozens or hundreds of running instances. The argument for catching it before the image is built is not theoretical. It is a matter of basic multiplication.”
On What Shift-Left Actually Requires
Seknametla is careful not to reduce shift-left to a single tool or a policy memo. His research points to four layers that, when working together, drove the strongest outcomes.
The first is static application security testing (SAST), which checks source code for flaws before it is ever executed. The second is container image scanning, which inspects images for known vulnerabilities before they move through the pipeline. The third is policy-as-code, which turns security requirements into automated rules checked at build and deployment time. The fourth is admission control, a final gate at deployment that stops non-compliant workloads from reaching the cluster.
“Each of these layers catches a different class of problem. SAST catches coding vulnerabilities. Image scanning catches dependency vulnerabilities. Policy-as-code catches configuration and compliance violations. Admission control catches anything that slipped through. In the organizations that achieved the strongest outcomes in our study, all four layers were present and working together. The ones that relied on any single layer — even a very good one — had significantly higher rates of production-facing risk.”
He also pushes back on the idea that security and software quality are two different conversations.
“Security and quality are not separate concerns in a modern application. A vulnerability is a defect. A misconfigured container is a defect. An insecure dependency is a defect. The same tooling and process discipline that catches security problems earlier in the development lifecycle also catches quality problems earlier. The teams in our study that reduced their vulnerability rate also reduced their deployment failure rate. That is not a coincidence. It is a consequence of the same underlying improvement in how the application is built.”
On Why Most Organizations Still Fall Short
Given the data, why do so many organizations still struggle to make shift-left work? Seknametla points to two recurring issues: ownership and execution quality.
On ownership, he is direct. Putting security in the hands of developers only works if those developers are actually equipped to carry it.
“You cannot tell developers they own security and then not give them the tools, training, and feedback loops to do it well. In our study, the organizations that had the best outcomes had invested in developer security education and in tooling that gave developers actionable, context-rich feedback — not just a list of CVEs. The shift in ownership has to be accompanied by a shift in capability.”
On execution, he is equally candid. Getting the tools in place is not enough if they are set up poorly.
“A noisy SAST tool that generates hundreds of false positives does not shift security left — it trains developers to ignore security warnings. A policy-as-code implementation that blocks deployments for reasons developers do not understand does not embed security culture — it embeds resentment of security tooling. The quality of implementation matters as much as the fact of implementation. Our data shows significant variance in outcomes even among organizations that had nominally adopted shift-left practices.”
The teams that saw the biggest gap between expectation and outcome, he says, were not lacking tools. They were lacking alignment.
“We observed teams that had the right tools but had not aligned their engineering and security functions around a shared definition of what ‘done’ looked like at each pipeline stage. They had the technology, but not the process or the culture. The tools underperformed because the organizational conditions for using them well were not in place.”
He closes with the point he says the field most needs to hear.
“Most of the discussion around shift left in security has been prescriptive rather than empirical. People tell you to shift left. Fewer people have actually measured what happens when you do. Our study was an attempt to answer that question with real data from real organizations. The data we collected over fourteen months is, we believe, strong evidence that an application that ships with critical vulnerabilities is not a secure application awaiting a patch — it is an incomplete one.”
“The goal is not to move the tools. The goal is to move the outcomes — and the data now tells us clearly where in the application lifecycle those outcomes are determined.”
What makes Seknametla’s work matter is not just the numbers, though the numbers are compelling. It is the clarity he brings to a problem the industry has talked around for years without fully solving. Security has long been treated as something you add to software. His research makes the case, with hard data behind it, that it was never meant to be added at all. It was always meant to be built in from the start. For any organization still treating security as a final step, that distinction is no longer academic. It is the difference between shipping software that works and shipping software that holds.
