Why the shift left dream has become a nightmare for security and developers

Source: Bleeping Computer

Written by Ivan Milenkovic, Vice President Risk Technology EMEA, Qualys

Introduction

For the better part of the last decade, we have engaged in a comfortable fiction around security and development. If we could only “shift left” and get developers to take a modicum more responsibility for security alongside their coding, testing, and infrastructure deployment, the digital world would become a safer, faster, and cheaper place.

Instead, the fundamental conflict between speed and security has gotten worse.

Why did this fail?

Developers are under crushing pressure. The classic triangle of project management—Fast, Good, Cheap; pick two—has been smashed to pieces.

Businesses now demand fast, good, cheap, and secure solutions. When push comes to shove, “fast” always wins. At the same time, we have piled too much cognitive load onto developers who were already drowning.

When they choose to use public container images to speed up development, they are trying to meet their goals, but they also expose themselves to potential risk.

So, how can we understand the real problem and then work to solve it?

Business Demands vs. Security Recommendations

There is a pervasive narrative in the security industry that developers are lazy or careless. That is not true.
Developers are overloaded, pragmatic professionals reacting to the incentives placed before them. If their bonus depends on shipping features by Friday and a security scan takes four hours to run and blocks the build, they will find a way around the scan.

Why security is seen as a barrier

• Speed pressure: Businesses demand results faster and faster.
• Noisy tools: Security tools that generate many false positives or run slowly interrupt the workflow.
• Disconnected processes: When security checks are not integrated into the CI/CD pipeline, they become an after‑thought rather than an integral part of engineering.

The consequences

• Organizations lose visibility into what is 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 an image on Docker Hub must be safe.

Trusting public registries is risky

The likes of Docker, Amazon, Google, and Microsoft all operate public container registries, so there is a natural assumption that they are safe. That trust is misplaced.

By the time a container image reaches the deployment pipeline, it is already a trusted artifact—baked into the application—yet it may still contain vulnerabilities or malicious code.

Takeaway: To bridge the gap between business velocity and security, we need tools and processes that are fast, low‑noise, and tightly integrated into developers’ workflows, rather than treating security as an external hurdle.

The 34,000‑Image Reality Check

Qualys Threat Research Unit (TRU) recently conducted an exhaustive analysis of over 34,000 container images pulled from public repositories to see what is really going on beneath the manifest.

• Malicious images: ~2,500 (≈ 7.3 % of the sample)
  • 70 % of these contained cryptomining software.
• Secrets exposure: 42 % of all images contained more than five secrets that could be used to access other resources or accounts (e.g., AWS access keys, GitHub API tokens, database credentials baked directly into the image layers).

Key takeaways

1. Typosquatting remains a major threat – attackers often rely on misspelled image names to get their malicious containers downloaded.
2. Simple advice like “check the spelling” is necessary but insufficient; it is a low‑effort response to a high‑stakes problem.
3. Telling developers to “be more careful” is not a security strategy.

Recommended approach

• Never pull directly from public registries in a mature environment.
• Proxy every external image through an internal artifact repository that acts as a quarantine zone.
• Balance speed and security by providing developers with a fast, vetted supply‑chain while shifting the heavy lifting to the infrastructure team.

This shift means more work for the infrastructure team, but the payoff is developers who can move faster and with far less risk.

Shift Down

Why “shift left” isn’t enough

• Fixing bugs early is cheaper, but moving security earlier in the SDLC simply pushes the burden onto developers.

• Developers are now expected to:

  1. Scan their own code.
  2. Vet third‑party dependencies.
  3. Harden configurations.
  4. Detect secrets.
  5. Perform compliance audits.

• At the same time, they are measured primarily on feature velocity.

The result? Security becomes another item on every developer’s to‑do list, not a collaborative effort.

The “Shift‑Down” Approach

Instead of forcing security into each IDE, make secure infrastructure the default and let developers work on a golden path that is already vetted.

If you stay on the golden path, security is automatic. If you go off‑road, you must handle the additional security steps yourself.

How to Make It Work

1. Platform‑engineered defaults

   • Terraform modules / Crossplane compositions / OPA policies enforce required settings (e.g., S3 buckets must have versioning).
   • Developers cannot create non‑compliant resources; the platform rejects the request.

2. Automated scanning & enforcement

   • CI pipelines automatically run container image scans.
   • Admission controllers block non‑compliant images before they reach the cluster.
   • Developers only need to know that a vulnerable image will be rejected, not how the scan works.

3. Self‑healing fixes

   • When a base‑image vulnerability is discovered, the platform creates a PR to upgrade it.
   • Runtime security tools automatically kill or isolate offending pods/nodes instead of merely sending alerts.

4. Clear business signaling

   • From the start, security and development present a united front on cost, risk, and effort.
   • The “cost of security” is baked into the platform, not added later as an after‑thought.

Benefits

• Least‑resistance path: Secure deployment becomes the easiest option.
• Reduced cognitive load: Developers focus on features, not on security minutiae.
• Faster remediation: Automated PRs and runtime actions eliminate manual lag.
• Shared responsibility: Both platform engineers and developers operate at the speed the business demands.

Risks of Staying “Shift‑Left”

• Developer burnout – piling security tasks on top of feature work.
• Control bypass – overwhelmed teams may ignore or work around safeguards.
• Increased incidents – manual steps are error‑prone and slower to fix.

Bottom Line

Shift down means moving security from the developer’s IDE to the infrastructure layer, managed by a specialized Platform Engineering team. By providing secure defaults, automated enforcement, and self‑healing mechanisms, we make security the path of least resistance and keep the business moving forward safely.

Sponsored and written by Qualys.