What breaks when organisations rely on shift-left alone?

Why shift-left stops being enough once code becomes a running system

Shift-left is strong at catching defects before release, but it does not fully describe the risk surface after software is built, assembled, and deployed. The moment code is packaged, configured, connected to dependencies, and granted runtime permissions, new failure modes appear. That is where security posture is often decided in practice, not just in the pipeline.

A useful way to think about the gap is that pre-deployment checks answer “is this build clean enough to ship?”, while runtime reality answers “what can this thing do once it is trusted?” Those are related questions, but they are not the same control point.

For that reason, shift-left alone can give teams a false sense of closure. It may reduce vulnerabilities in source and build artefacts, yet still leave runtime permissions, ownership, and lifecycle controls outside the review boundary, especially where secrets, service accounts, or ephemeral infrastructure are involved.

What breaks at the assembly, configuration, and permission layer

The first thing that breaks is visibility. Build-time scanning rarely tells you whether the deployed service has broad network reach, inherited cloud privileges, stale credentials, or access paths created by orchestration defaults. A package can be clean and still land in a weak runtime posture because the real exposure is introduced after the build finishes.

The second break is configuration drift. Dependencies, container base images, environment variables, secret mounts, IAM bindings, and deployment templates can diverge from what was tested. Even when the application binary has not changed, the deployed behaviour can change materially because its surrounding configuration has.

The third break is privilege control. Shift-left tools may flag known code defects, but they do not by themselves constrain what the running workload can read, write, call, or impersonate. That matters because excessive privilege, overbroad access, and misbound identities can turn a minor defect into a material incident.

These are not abstract concerns. They are the same classes of issues addressed by baseline control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, configuration management, auditability, and integrity.

Why the control model has to extend into runtime and supply chain

Modern software is assembled from dependencies, build steps, containers, and infrastructure-as-code, so the security question is no longer just “is the source safe?” It becomes “is the artifact trustworthy, the deployment hardened, and the runtime bounded?” If any one of those layers is weak, attackers can still gain persistence, escalate privilege, or abuse trust paths without touching the original source.

That is why teams pair shift-left with controls that cover provenance, configuration integrity, and least privilege at runtime. Supply-chain integrity helps answer whether the artifact came from the expected build path, while deployment controls help answer whether the resulting system is isolated, permissioned, and observable once it is live. Those controls are complementary, not interchangeable.

This is also where container behaviour matters. A container can be scanned before release, yet still run with writable filesystem paths, mounted credentials, exposed metadata services, or default capabilities that were never part of the developer’s intent. Runtime containment must therefore be treated as part of the security model, not just an operations detail.

Frameworks that focus on provenance and deployment discipline, such as SLSA and the OWASP Non-Human Identity Top 10, are useful because they address the points where build assurance stops and operational trust begins.

Risk and Threat Considerations

When organisations rely on shift-left alone, the biggest risk is not missed code flaws, it is ungoverned runtime exposure. Attackers often prefer the later layers because misconfiguration, overprivilege, and secret exposure can deliver faster impact than exploiting a pristine code defect.

Failure mechanism: The build passes review, but deployment-time settings, inherited permissions, or environment drift create a broader attack surface than the pipeline ever evaluated. That can enable unauthorized access, lateral movement, or abuse of trusted integrations.

Impact: A low-severity code issue can become a high-severity incident when the deployed service can reach sensitive data, invoke privileged APIs, or operate with credentials that were never meant for that environment.

Practitioner Guidance

What to prioritise: Treat runtime permissions, deployment configuration, and dependency integrity as first-class security controls, not as post-release housekeeping. If a team can only evidence source scanning, it does not yet have a complete control model.

What to verify: Confirm that each deployed service has a known owner, a bounded permission set, a reviewed secret source, and an auditable link between the build artefact and the running environment. If any of those are unknown, the system is not fully controlled.

Common mistake: Teams often assume that a clean CI pipeline means the application is secure in production. The better test is whether the deployed workload can do anything material that the review process never explicitly approved.

Practitioner takeaway: Shift-left should reduce defects before release, but it cannot be the whole strategy unless you also control the layer where software is actually granted power.

Related resources from NHI Mgmt Group

• What breaks when organisations rely too heavily on shift-left API security alone?
• What breaks when shift-left programmes rely on tools alone?
• What breaks when organisations rely on MFA alone for digital interactions?
• What breaks when healthcare organisations rely on RBAC alone?