At some point, the question changes. It is no longer how quickly we can identify vulnerabilities. It is whether we are addressing where they originate.
I have spent more than two decades in enterprise security. At Trend Micro, I watched organisations across Asia-Pacific and India deploy scanner after scanner, pipeline after pipeline, and still wake up to breach notifications.
Over time, I found myself returning to the same question: why hasn’t the problem gotten smaller as the detection has gotten better?
That question ultimately became one of the reasons I founded CleanStart.
The answer, I believe, starts with re-examining one of the most influential ideas in modern software security: Shift Left.
What Shift Left Promised
The Shift Left movement began with a genuinely good premise. Vulnerabilities discovered in production are expensive to fix. Vulnerabilities discovered earlier in the development lifecycle are generally easier and less costly to address.
The logical conclusion was straightforward: move security earlier. Give teams scanning tools. Embed security checks into the pipeline. Catch problems before they reach production.
The premise was sound. The execution produced something different.
What Actually Happened
Here is what that looks like in practice. A developer writes code and raises a pull request on their branch. A lead reviews and merges it. That merge triggers the build pipeline, and it is here, when the pipeline runs, that the base image is pulled. The DevOps team manages this pipeline; they control which base image the Dockerfile references.
But consider the image being pulled. The team is not using some obscure custom image. They are using the official Python image, the official Go image, the official Kafka image, pulled directly from Docker Hub and maintained by the language’s official communities. And yet the official Python image is itself built on Debian.
The Debian CVEs were not introduced by the DevOps team. They were not introduced by the developer. They were inherited from upstream, deep within the software supply chain.
The scanning tool flags 47 vulnerabilities. Now the ownership model begins to break down. If the CVE is in a library the developer directly imported, it is their responsibility to fix. If the CVE is in the base image, in the official Python layer or the Debian OS underneath it, it often falls to the DevOps team. But even DevOps cannot directly remediate what was inherited from upstream. The ticket enters a backlog. The alert remains open. In many organisations, no one directly owns the root cause.
The developer has three options: suppress the warning, spend hours pursuing a fix they do not control, or block their own deployment. DevOps faces a similar choice. None of these options eliminate the vulnerability. They move the work. The CVE remains in the image. The image ships to production. The dashboard still lights up.
We moved the burden. We did not solve the problem.
The Category Error at the Heart of Shift Left
Shift Left made a category error: it confused the location of the scan with the location of the solution.
A vulnerability in a base image, the foundation layer that hundreds of microservices are built upon, is not primarily a developer problem or even a DevOps problem. It is a software supply chain problem.
The DevOps engineer managing the pipeline did not introduce the CVEs inside the official Python image. The developer writing application code on top of it did not introduce them either. Yet both are asked to carry the operational burden. They scan them, document them, discuss them in sprint reviews, and often delay deployments because of them.
But responsibility and control are not the same thing.
Addressing the root cause requires going upstream: to the base image itself, to the package build pipeline, and ultimately to the software supply chain.
Moving a scanner to an earlier point in the pipeline does not change the security posture of the materials being scanned. Detection remains necessary. But identifying a problem earlier is not the same as eliminating it.
Shift Left moved security earlier. It did not always move it closer to the source of the problem.
Integrate Left: A Different Philosophy
The question Shift Left never really asked was this: what if the materials themselves were secure before anyone touched them?
I call this Integrate Left.
Instead of moving security checks earlier in the process, Integrate Left focuses on integrating security into the software supply chain itself: into the base images, the package build process, and the provenance of the artifacts being consumed by developers and deployment pipelines.
The difference is that it changes both ownership and outcome.
Under Shift Left, developers and DevOps teams inherit responsibility for vulnerabilities that often originate upstream. They are expected to identify them, triage them, document them, and manage the operational consequences.
Integrate Left starts further upstream. It focuses on improving the security posture of the materials entering the pipeline before they ever reach a developer workstation or deployment process.
That includes building images from verified source, validating packages before they enter the build, and establishing verifiable provenance for every artifact produced. The objective is not simply to detect vulnerabilities earlier. It is to reduce the amount of inherited risk entering the software delivery process in the first place.
When that happens, developers spend less time managing inherited vulnerability debt and more time building software. Security teams spend less time chasing recurring alerts and more time addressing higher-value risks. The burden shifts from managing symptoms downstream to improving software integrity upstream.
What This Looks Like for Real Engineering Teams
At CleanStart, we apply this philosophy by treating container images as software supply chain artifacts rather than static packaging formats.
Images are built from verified source in hermetic build environments. Packages are validated before they enter the build process. Every build runs without ambient network access, reducing opportunities for tampering during image creation. Every output is signed with SLSA Level 3 attestation, providing verifiable provenance for how the artifact was built and what it contains.
The practical outcome is that engineering teams inherit fewer security issues from the base layers they consume. Instead of spending time triaging vulnerabilities that originated upstream, they can focus their attention on the code and dependencies they directly control.
This approach does not replace runtime visibility, detection platforms, or vulnerability management programs. It complements them. Detection tools remain essential for understanding what is running across an environment. What Integrate Left adds is software supply chain context: where an artifact came from, how it was built, what controls were applied during its creation, and whether its provenance can be independently verified.
Detection tells you what you are running. Software supply chain integrity helps establish whether it should have been trusted in the first place.
The Organizational Implication
The challenge is not only technical. It is organizational.
For years, security teams have been asked to reduce risk while engineering teams have been asked to increase delivery speed. Both goals are reasonable. The friction appears when vulnerabilities originate in parts of the software supply chain that neither team directly controls.
Shift Left improved visibility into those issues. It helped organizations discover problems earlier. But discovering a problem and owning its root cause are not the same thing.
A developer can be held accountable for a vulnerability in an upstream base image. A DevOps team can be asked to remediate it. Neither necessarily controls where it originated.
That disconnect creates operational friction. Teams spend time triaging, documenting, suppressing, and debating vulnerabilities that were inherited rather than introduced.
Integrate Left approaches the problem differently. By improving the security posture of software supply chain components before they enter the development and deployment process, organizations reduce the amount of inherited risk that downstream teams are expected to manage.
The result is not the elimination of organizational tension. Security and engineering will always have different priorities. The goal is something more practical: reducing the number of issues that neither team can meaningfully influence, while increasing confidence in the components both teams rely on.
This is not a new organizational chart. It is a different starting point. When software artifacts arrive with stronger integrity, provenance, and security controls already in place, teams can spend less time debating inherited problems and more time focusing on the work they actually own.
An Invitation
The industry will not solve software supply chain risk by scanning more, scanning faster, or scanning earlier alone. Those capabilities remain essential, and the vendors delivering them continue to provide real value. But they are a ceiling, not a floor.
Reducing risk at scale requires more than identifying vulnerabilities after they have entered the development process. It requires improving the security posture of the software components entering that process in the first place.
Shift Left was built on an important insight: security should be part of software delivery, not an afterthought. That insight remains as relevant today as it was when the movement began.
But visibility is not the same as control.
Making developers and DevOps teams responsible for inherited vulnerabilities does not necessarily move organizations closer to the source of the problem, particularly when those vulnerabilities originate upstream in the software supply chain.
That is the idea behind Integrate Left.
Not moving security checks earlier.
Integrating security into the materials, artifacts, and software supply chain components that software teams depend on every day.
Because the most effective security decision is often the one that has already been made before the first build starts.
