Why shift-left security is not enough for modern applications

Identifying security problems early is still one of the best ways to reduce application risk. But predeployment testing can’t account for every vulnerability, configuration change or suspicious action affecting an application once it is running. For containerized applications in particular, shift-left security must be complemented by continuous runtime protection.

Modern application security now starts much earlier in development. Teams can define security requirements while an application is being designed, assess code and dependencies during development and check infrastructure definitions and container images before release. Security controls embedded in CI/CD can also stop seriously vulnerable or noncompliant artifacts from progressing toward production.

This gives development teams more opportunity to correct weaknesses before they affect a live service and reduces reliance on security testing immediately before release, when significant changes are harder to make.

But a successful build is not the end of the application security process.

Once deployed, the application's risk continues to change. New vulnerabilities are disclosed in components that are already running. Permissions and configurations are modified. Container workloads scale, move and interact with other services. Some attacks also become visible only when security teams can observe processes, network connections and file activity in production.

Container security therefore has to address both sides of deployment: the security of the images being built and the environment in which the resulting containers operate. The Cloud Native Computing Foundation similarly describes cloud-native security across development, distribution, deployment and runtime rather than as a predeployment activity alone.

Shift-left security reduces the risks entering production. Runtime protection addresses risks that remain, change or become visible there.

What is shift-left security?

Shift-left security means addressing security earlier in the software development lifecycle instead of concentrating testing near release or after an application has been deployed.

It can start before code is written. Security requirements, architecture review and threat modeling help teams identify risks while the application is still being designed. During development, the wider AppSec toolchain can add secure coding practices, static and dynamic testing, software composition analysis, secrets detection and other automated checks. Container-specific controls can then assess images and infrastructure definitions before deployment.

Shift left is therefore a development and security approach rather than a particular scanner or product category.

Why is shift-left security more than pipeline scanning?

Threat modeling is a good examples. It asks teams to examine what they are building, how an attacker might target it and which controls are needed before those decisions become difficult to reverse. OWASP describes threat modeling as a structured, repeatable process that should begin early in the software development lifecycle and be updated as the system changes.

Automated scanning supports this process but cannot replace secure architecture, threat analysis or clear ownership of remediation. A pipeline containing multiple security tools may still allow fundamental design weaknesses to progress if nobody has examined the application as a whole.

A mature shift-left approach connects early design decisions with repeatable testing and gives developers findings they can act on while the relevant code and architecture are still fresh.

What are the benefits of shift-left security?

The main advantage of shift left is timing. Security problems are identified while teams still have more options for dealing with them.

A design review, for example, may reveal an unsafe trust relationship before the application is built around it. During development, dependency analysis can identify a vulnerable component while infrastructure-as-code checks expose risky permissions or configuration. Container image scanning adds another checkpoint before the workload reaches the cluster.

This early feedback also makes security easier to integrate into engineering work. Instead of receiving a lengthy security report near the end of a project, developers can investigate relevant findings as part of the normal build and release process.

NIST's Secure Software Development Framework takes the same lifecycle view. Its objectives include reducing vulnerabilities in released software, limiting the effects of weaknesses that remain and addressing root causes so that similar problems are less likely to recur.

In practical terms, shift-left security answers an important question: What risks can we remove before an application reaches production?

But it does not fully answer another: What happens when the application, its dependencies and its operating environment continue to change?

What security risks can AI-generated code introduce?

AI coding assistants can accelerate development, but generated output should be treated as untrusted until it has been reviewed. Code may compile and pass functional tests while still reproducing insecure patterns, omitting important authorization or input-validation controls or relying on inappropriate dependencies.

AI tools may also suggest packages or versions that are unsuitable, outdated or simply incorrect. They do not automatically understand the application's architecture, threat model, data classification or regulatory requirements well enough to decide whether a technically valid solution is secure in context.

Development teams should therefore subject AI-generated code to the same controls as human-written code: human review, dependency verification, secrets checking and the organization's normal application security testing. Developers should also avoid exposing proprietary code, credentials or other sensitive material to AI services that have not been approved for that use.

These are development-stage AppSec controls and belong firmly in shift left. The resulting application still requires assessment and protection after deployment as its components, configuration and behavior change. OWASP's current secure-coding guidance for AI-assisted development similarly recommends independent review and verification of AI-generated code and dependencies.

Why is shift-left security not enough on its own?

Predeployment testing assesses code, configuration and software artifacts using what is known at that point in time. It cannot guarantee that an application will remain secure throughout its operational life.

Why is a successful predeployment scan only a point-in-time result?

A container image may pass every required check when it’s built because no known critical vulnerabilities, exposed secrets or prohibited configurations are present at that moment.

That position can change without anyone altering the image. A vulnerability may later be disclosed in a base image, operating system package, framework or library already used in production. Newly available exploit code can change the significance of an existing weakness, while a configuration change may make an application more exposed than it was when originally assessed.

The artifact may be identical, but the organization's understanding of its risk is not.

A clean build result describes a particular artifact at a particular time – it’s not a permanent security guarantee.

How can deployment configuration change container risk?

Image content is only one part of the security decision. The same container image can present very different risks depending on how and where it is deployed.

A workload given unnecessary privileges, for example, presents different possibilities to an attacker from one operating with tightly restricted access. Similar issues arise when service accounts have excessive permissions, ports are unintentionally exposed, network restrictions are missing or containers can access sensitive host resources.

Kubernetes security guidance therefore covers not only image scanning and signing but also privilege escalation, root access, Linux capabilities, service accounts, role-based access control and network policies.

A predeployment image scan can’t determine by itself whether all of these operating conditions remain secure.

How can attackers misuse valid applications and credentials?

Not every attack requires a known software vulnerability. An attacker with legitimate credentials may be able to misuse an administrative function or take advantage of excessive permissions, and a compromised workload might begin executing unexpected commands or communicating with an external system without changing the image from which it was created.

These are behaviors that development-stage testing can’t always see. Once the application is running, security teams need operational evidence to distinguish expected activity from activity that may indicate misuse or compromise.

Why do containerized applications need runtime protection?

The gap between predeployment assessment and operating risk is especially important in container environments.

Containers are built for automated, flexible deployment. Orchestrators continually create, replace and scale workloads as application requirements change. An individual pod may exist only briefly even though the service it supports is long-lived, while the same application may be distributed across several clusters, namespaces or cloud environments.

Security teams therefore need more than a record of the images that were approved during development. They need to know what is actually running now, how it is configured and whether its behavior remains consistent with policy.

Why do dynamic container environments require continuous security?

The runtime environment does not remain fixed after release. Workloads scale, nodes join or leave clusters and configuration changes can take effect without a conventional deployment event.

An inventory created during development can therefore become outdated quickly. Runtime visibility needs to show the resources currently operating in the environment and connect them to the images, deployments and services they support.

A current resource inventory can also reveal workloads or resources that have no clear owner or have appeared outside normal deployment processes. These gaps are important because resources that are not accounted for are less likely to receive consistent security assessment or remediation.

How does shared container infrastructure affect security?

Containers provide process isolation, but their security still depends on the host, container runtime, orchestrator and cluster configuration.

That makes the execution environment part of the application security problem. A privileged container or poorly configured workload may weaken the separation protecting other applications or infrastructure on the same host.

The UK National Cyber Security Centre recommends securing both the image supply chain and the container execution environment. Its guidance also stresses low-privilege operation, appropriate separation, container-aware monitoring and protection of the runtime itself.

What security risks become visible only at runtime?

Production provides evidence that does not exist during a build. Once a workload is running, security teams can see which processes it launches, which files are accessed or changed and where inbound or outbound network connections are established. They can also observe communication between workloads and identify activity that does not match the application's expected behavior.

This information can expose misuse, policy violations or active compromise that image analysis alone cannot reveal.

What is container runtime protection?

Container runtime protection applies security monitoring, validation and control while containerized workloads are operating.

It complements the controls used during development. Rather than asking only whether an image was acceptable when it was built, runtime security asks whether the deployed workload still meets security requirements and whether its behavior is consistent with what is expected.

What does runtime visibility need to show?

Runtime protection begins with knowing what is present in the environment. Security teams need visibility into active resources, the images they use and where they are deployed, along with enough context to understand which application or service they support.

This current view helps identify deployed workloads affected by newly disclosed vulnerabilities and can expose unaccounted-for resources or ownership gaps.

What should container runtime monitoring detect?

Monitoring provides the behavioral side of runtime security. Depending on the environment, relevant evidence may include processes, file operations, inbound and outbound network traffic, privilege use and changes to container or cluster configuration.

The aim is not to flag every variation. It is to identify activity that violates policy or meaningfully differs from the workload's expected operation.

How can runtime policy enforcement control container risk?

Runtime security can also enforce what is allowed to operate. Policies may prevent workloads from running when an image has not been approved, does not meet defined security requirements, requests prohibited capabilities or comes from an unauthorized registry. Runtime profiles can apply restrictions to processes or network connections according to the needs of a particular workload.

Kaspersky Container Security, for example, connects these stages within the container lifecycle. It can assess images and infrastructure-as-code within CI/CD, apply security policies to container deployment and monitor or restrict runtime processes and network activity.

How can continuous container security support compliance?

Security policies also provide a way to check whether container environments continue to meet defined requirements after deployment.

This may include assessing images, cluster configuration and running resources against organizational controls or recognized security benchmarks. Continuous checks are particularly useful where configuration drift could cause an environment that was compliant at deployment to move out of alignment later.

Kaspersky Container Security includes automated security and compliance checks, cluster-node assessment against information security benchmarks and regulatory compliance auditing across container-environment components.

Runtime protection does not replace secure design, source-code assessment or other development-stage AppSec controls. It covers the conditions that only become known once containerized applications are deployed and operating.

How do shift-left security and runtime protection work together?

Shift-left security and runtime protection address different stages of the same application lifecycle.

Shift left concentrates on preventing avoidable weaknesses from reaching production. Runtime protection takes over where static predeployment knowledge becomes incomplete, helping teams identify new vulnerabilities affecting deployed workloads, insecure operating conditions and suspicious behavior.

A mature process connects these two sides rather than treating them as separate programs.

How can runtime evidence improve shift-left security?

Runtime findings often reveal where development-stage assumptions were incomplete.

If an application starts an unexpected process, relies on an outdated component or repeatedly communicates with a destination that was never considered during design, that information can improve future threat models, development standards or deployment policy.

The relationship works in the other direction too. Knowledge about an image's origin, scan history and expected behavior can help security teams decide whether it should be permitted to run and which runtime activity deserves investigation.

Runtime protection therefore does more than add another layer after deployment. Used well, it provides evidence that improves the controls applied to the next build.

What controls are needed for continuous container security?

Continuous container security follows an application from design through operation, but it does not mean repeating the same scan at every stage. Different stages answer different security questions.

1. Start with threat modeling and secure design

Threat modeling should examine application components, data flows, trust boundaries, identities and dependencies before implementation. Its value comes from influencing decisions while architecture can still be changed, not from producing documentation that is filed and forgotten.

2. Assess code, dependencies and infrastructure before deployment

No single control covers every part of application development.

The wider AppSec toolchain may assess source code and third-party components, while container-specific security can examine images, exposed secrets, infrastructure definitions and deployment configuration. These controls should be integrated into development and CI/CD workflows so that findings reach the teams able to address them before release.

This separation is important: source-code analysis and container security are complementary disciplines, not interchangeable capabilities.

3. Validate container images before deployment

Before an image reaches production, teams need to know whether it contains known vulnerabilities, malware, sensitive information or serious misconfiguration. They should also be able to establish where the image came from and whether it is the version approved for release.

Where a finding breaches a defined security threshold, automated controls can prevent the affected image from progressing. Kaspersky Container Security, for example, can fail a CI/CD step when image-scan findings meet criteria set in an assurance policy.

4. Enforce security policies when workloads are deployed

Deployment decisions should not depend on vulnerability severity alone.

Image origin and trust, signing status, requested privileges, registry source and configuration can all influence whether a workload should be allowed to run. Policy enforcement provides a consistent way to apply these requirements without forcing teams to make the same decision manually for every deployment.

The objective is to stop materially risky or unapproved workloads while avoiding blanket rules that obstruct releases for issues with little practical effect.

5. Reassess and monitor workloads at runtime

Once deployed, workloads need to be reassessed as information and conditions change.

A newly disclosed vulnerability may affect an image that was considered safe when released, configuration may drift, an unexpected image or resource may appear in the cluster, and processes or network activity may differ from the behavior that was originally approved. Runtime monitoring brings these changes back into view rather than allowing the security decision made at build time to stand indefinitely.

6. Feed runtime findings back into development

Operational evidence should result in changes upstream.

Examples: An incident might reveal a threat scenario that was missed during design or expose a control that is too weak. Repeated configuration problems can justify a new infrastructure-as-code rule, while unexpected application communications may lead to a tighter network policy. A base image found to create recurring risk should be removed from approved development templates rather than dealt with repeatedly after deployment.

The result is a practical feedback loop between what teams intended to build, what they approved for release and what the application actually does in production.

How can enterprises extend application security without slowing development?

Adding runtime protection should not mean creating another disconnected security process.

The more useful approach is to give each team the context it needs to act. Developers need findings tied to the relevant code, dependency or build artifact. Platform teams need to understand the deployment, cluster and configuration involved. Security operations teams need enough behavioral evidence to investigate activity that may indicate compromise.

Automation helps most when it removes repetitive decisions rather than generating more alerts. Organizations can use approved base images and deployment templates, apply blocking controls only to material risks and define how exceptions are reviewed. Clear ownership also matters: a vulnerability linked to a running workload is much easier to act on when the responsible application or platform team can be identified immediately.

Runtime and development data should remain connected. If the same type of operational problem keeps appearing, the goal should be to correct the relevant design, build or deployment rule rather than repeatedly handle individual alerts.

How should shift-left and runtime security be measured?

The number of scans completed or vulnerabilities reported says little about whether application risk is actually being reduced.

More useful measures show whether important problems are being prevented and resolved. For example, an organization may track how many critical images are assessed before deployment, how quickly it can identify running workloads affected by a newly disclosed vulnerability or how long runtime findings remain unresolved.

Recurrence is also instructive – if the same configuration error or insecure component repeatedly reaches production, remediation is dealing with individual instances without correcting the underlying development or deployment process.

Metrics should therefore help answer three practical questions:

• Are material risks being stopped before deployment?
• Can teams identify and investigate important changes after deployment?
• Are lessons from runtime reducing the likelihood of the same problems recurring?

Why must shift-left security continue into runtime?

Shift-left security remains one of the most effective ways to keep preventable application weaknesses out of production.

Threat modeling, secure design and early testing allow teams to address many problems while the application is still being shaped. Container image scanning and deployment controls add further opportunities to stop vulnerable or unapproved artifacts before they reach live environments.

But deployment changes the information available to security teams.

Previously approved components can become vulnerable, workloads move and scale under changing configurations and permissions, valid credentials or application functions can be misused, while unexpected processes and communications may reveal activity that could never have been seen in the build pipeline.

Modern application security therefore needs both perspectives. Shift-left controls reduce the risks entering production. Runtime protection maintains visibility over the deployed environment and identifies risks that arise or become observable once applications are running.

Neither replaces the other – together, they provide a more complete way to protect containerized applications across development, deployment and operation.

FAQs

Is shift-left security still effective?

Yes. Shift-left security helps teams identify design flaws, vulnerable code, insecure dependencies and configuration problems before deployment, when there are usually more options for correcting them. It becomes insufficient only when predeployment controls are treated as the end of the security process.

Why is shift-left security not enough on its own?

Predeployment controls assess an application using the code, configuration and threat information available at that time. They cannot identify every risk caused by newly disclosed vulnerabilities, changing configurations, stolen credentials or unexpected production behavior.

What is container runtime protection?

Container runtime protection monitors, validates and controls workloads while they are operating. It can include workload and resource visibility, vulnerability reassessment, process and network monitoring, file activity monitoring and policy enforcement.

Does runtime protection replace container image scanning?

No. Container image scanning identifies vulnerabilities, malware, secrets and configuration problems before deployment. Runtime protection addresses risks that arise, change or become visible while containers are running.

Can a container become vulnerable after deployment?

Yes. A vulnerability may be disclosed in a package, library, framework or base image after the container has entered production. Running workloads therefore need to be reassessed as new vulnerability information becomes available.

Why is resource inventory important for container security?

Container environments change rapidly, making inventories created during development or deployment easy to outdate. A current inventory helps security teams identify which resources are actually running, which images they use and whether there are unaccounted-for workloads or ownership gaps.

How does runtime protection support container compliance?

Runtime and configuration checks can identify workloads or cluster resources that no longer meet defined security policies or recognized benchmarks. This helps organizations detect configuration drift and compliance violations after deployment rather than relying only on periodic assessment.

What is the difference between shift left and shift right?

Shift left integrates security into design and development. Shift right applies testing, monitoring and security controls to deployed applications. Runtime protection is an important part of the latter, but effective application security connects both sides of the lifecycle rather than choosing between them.

What should container runtime security monitor?

Requirements vary by application, but relevant areas can include running images and resources, processes, file activity, network communications, privileges and changes to workload or cluster configuration.

Sources and further reading

• Kaspersky: Container Security
• UK National Cyber Security Centre: Using containerisation
• UK National Cyber Security Centre: Threat modelling
• OWASP: Threat Modeling Cheat Sheet
• OWASP: DevSecOps Guideline
• Cloud Native Computing Foundation: Cloud Native Security Whitepaper
• Kubernetes: Application Security Checklist
• NIST: Secure Software Development Framework, SP 800-218
• Iterasec: What is shift-left security?
• OWASP: Secure Coding with AI Cheat Sheet
• OWASP: Secure Code Review Cheat Sheet
• UK National Cyber Security Centre: AI and cyber security - what you need to know