Ethical Hacking News
The traditional "shift left" mentality has been hailed as a solution to improve security and collaboration between development teams, but in reality, it's created more problems than solutions. In this article, we'll explore why the shift left dream has become a nightmare for security and developers and what we can do to fix it.
The "shift left" concept has not improved security, but rather worsened the conflict between speed and security. Developers are under pressure to meet deadlines, often at the expense of security, due to businesses' demand for fast, good, and secure results. Security protocols are seen as a barrier to productivity, not an integral part of engineering, leading to lost control over what's running in environments. Pulling a container from a public registry like Docker Hub is a trust decision that's misplaced. A recent analysis revealed that around 7.3% of container images contained malicious code. Instead of telling developers to be more careful, we need to work on enabling them to move faster while keeping security in place. Create a "golden path" for developers that incentivizes secure deployment by making it the path of least resistance. Moving responsibility down the stack to the infrastructure layer and collaborative work between developers and security can deliver secure software faster and cheaper.
The concept of "shift left" has long been touted as a solution to improve security and collaboration between development teams. The idea is simple: get developers to take a more active role in security by incorporating it into their daily workflows, from code reviews to infrastructure deployment. However, the reality is far more complex.
For much of the last decade, the industry has engaged in a comfortable fiction around security and development. The notion was that if we could just "shift left" and get developers to take on more responsibility for security, we would unlock a safer, faster, and cheaper digital world. Instead, the fundamental conflict between speed and security has only worsened.
The classic triangle of project management – Fast, Good, Cheap; pick two – has been smashed to pieces. Businesses demand fast, good, cheap, and secure, but when push comes to shove, "fast" always wins. This means that developers are under crushing pressure to meet deadlines, often at the expense of security.
The problem is not that developers are lazy or careless; it's that they're overloaded, pragmatic professionals reacting to the incentives placed before them. If their bonus depends on shipping features by Friday and the security scan takes four hours to run and blocks the build, they'll find a way around the scan. The narrative in the security industry that developers are lazy or careless is not only untrue but also misguided.
Businesses demand results faster and faster, which has created an environment where security protocols are seen as a barrier to productivity rather than an integral part of engineering. When security tools are noisy, slow, and disconnected from the workflow, they're a barrier. This is especially true for developers who are already drowning in a sea of competing priorities.
The result of this is that organizations have lost control of what's actually running in their environments. Pipelines deploy code automatically, infrastructure scales up and down without human intervention, and AI agents can now write and execute their own scripts. In this high-speed, automated chaos, we treat public registries like curated libraries, assuming that because an image is on Docker Hub, it must be safe.
But pulling a container from a public registry like Docker Hub is a trust decision. The likes of Docker, Amazon, Google, and Microsoft all operate public container registries, so there's a natural assumption that they're safe. However, this trust is misplaced. By the time a container image makes it to the deployment pipeline, it's already been trusted as a baked-in artifact.
A recent analysis by Qualys' Threat Research Unit (TRU) revealed that around 7.3% of over 34,000 container images pulled from public repositories contained malicious code. Of these, 70% contained cryptomining software, while 42% contained more than five secrets that could be used to gain access to other resources or accounts.
This isn't a new problem; it's an old one that has only grown worse. Typosquatting remains one of the most common methods attackers use to get their malicious containers downloaded. The standard advice to "check the spelling" is essential, but it's also a low-energy response to a high-stakes problem.
Telling developers to be more careful is not a security strategy; it's just a Band-Aid on a much deeper issue. Instead of letting developers pull from public registries at all, we need to work on how to help them move faster while keeping security in place.
This means more work for the infrastructure team, but that work should enable developers to move ahead faster and with less risk. It involves real collaboration between developers and security – developers must understand what they want to achieve and what will be required of what they build, while security must work around those requirements so they can be delivered securely.
In practice, this means creating a "golden path" for developers. If they use standard templates, pre-approved base images, and official CI pipelines, security is free. If they want to go off-road and build something custom, then they have to do the additional work of security reviews and manual configurations.
This approach incentivizes secure deployment by making it the path of least resistance. It moves the responsibility down the stack to the infrastructure layer, managed by a specialized Platform Engineering team. And if something different is needed, that work can be done collaboratively to ensure it's right the first time, rather than leading to more issues that need to be remediated.
For example, instead of asking a developer to please enable versioning on a specific S3 bucket, the platform team writes a policy using Terraform modules, Crossplane compositions, or Open Policy Agent that simply doesn't allow a bucket to exist without versioning. The developer literally can't make the mistake.
The platform corrects it automatically or rejects the request. Similarly, developers shouldn't have to remember container scanning in their workflows; the CI pipeline should do it automatically. The admission controller should reject non-compliant images before they ever hit a cluster. The developer doesn't need to know how the scan works; only that if they try to deploy a critical vulnerability, the door will be locked.
In conclusion, the "shift left" mentality has become a nightmare for security and developers. It's time to fundamentally change how we operate across teams. We need to make security proactive around how to implement and support the right platforms for the business, so they can be made secure automatically.
This means moving the responsibility down the stack to the infrastructure layer, managed by a specialized Platform Engineering team. It means creating a "golden path" for developers that incentivizes secure deployment by making it the path of least resistance. And it means working collaboratively between developers and security to deliver secure software faster and cheaper than ever before.
Related Information:
https://www.ethicalhackingnews.com/articles/The-Shifting-Sands-of-Security-Why-the-Shift-Left-Mentality-Has-Become-a-Nightmare-for-Developers-and-Security-Teams-ehn.shtml
https://www.bleepingcomputer.com/news/security/why-the-shift-left-dream-has-become-a-nightmare-for-security-and-developers/
https://insights.emutare.com/the-shift-left-lie-why-developers-hate-security-and-how-to-fix-it/
Published: Fri Feb 20 11:46:42 2026 by llama3.2 3B Q4_K_M
