For a long time, security teams have been told that shifting left is the key to securing their apps and systems. And until recently, this was (mostly) sufficient. As long as security experts were included early enough in the development process, it worked to ensure that security awareness starts at the development and even design phase.
But times have changed. Attack surfaces have grown and become more complex, while the number of vulnerabilities is rising every year. According to one study, the number of new CVEs (common vulnerabilities and exposures) jumped 38% YOY in 2024, hitting an all-time high of 40,009 new CVEs. This adds up to a 520% increase overall since 2016. Not to mention that attackers and attacks are becoming increasingly sophisticated.
It’s all too much for security teams to keep up with, even with a shift left mindset. Scanners unearth thousands of risks, far too many for DevSecOps to handle. However, many of these security issues are purely theoretical. The chances that they might cause a security incident is minimal, but they receive the same attention as real risks that could result in severe incidents. Additionally, some of the flagged issues are risks that were accepted intentionally due to specific development choices and are integral to effective system operations.
This has created a vicious cycle of ticketing and alerting between security and DevOps/engineering teams. Thousands of security tickets are opened but the majority of them are ignored, while no real security is achieved.
It’s not surprising that in a recent survey ARMO conducted, we found that close to half of security teams are struggling with alert fatigue. The flood of urgent issues is actively harming cybersecurity. 89% of respondents acknowledged that their current processes fail to detect active threats.
To secure the cloud effectively and break this cycle, security teams need Kubernetes context and runtime insights. While shift left practices are valuable, they require context to be able to identify real-world threats. Additionally, security teams must complement their efforts with runtime security, which provides a crucial additional layer to actively address genuine risks as they emerge enabling practitioners to move beyond purely theoretical vulnerabilities.
Shifting Left Isn’t Enough Anymore
Shift left has been a popular cloud security tactic for a good four or five years, which is a long time in cybersecurity terms. It’s still crucial in cloud security to harden your environment and reduce your attack surface. IBM’s Cost of a Data Breach Report (2023) found that it costs 6x more to fix vulnerabilities post-deployment than those found pre-deployment. However, shift left is no longer enough.
This is partly due to the sheer number of risks. While shift left catches 70% of vulnerabilities, according to one report by Snyk, 30% still slip through, which is enough to cause serious security issues.
It doesn’t help that many risks only manifest at runtime. Aqua Security’s 2024 Cloud Native Threat Report found that 50% of Kubernetes attacks targeted misconfigurations or vulnerabilities that don’t appear in source code, and 40% of container attacks exploited factors that weren’t visible at build time.
Irrelevant Risks are Harming Your Security Posture
Additionally, there’s not enough visibility into which risks are real. In some findings, as many as 90% of CVEs can’t be reached for exploitation. For runtime threats, ARMO found that only approximately one out of every 6,994 alerts is legitimate, lowering the chances of finding the one that matters.
This leaves security teams bedeviled by false positives while DevOps teams feel like they are running up the down escalator, as SOC teams keep discovering runtime security issues. They fix as many as they can, but have to open tickets for DevOps to resolve the rest. Meanwhile, DevOps people are drowning in the issues they’ve discovered themselves from scanning on the left.
The result is a backlog that will never clear. DevOps teams are overwhelmed and security teams wonder which will happen first: Will the vulnerability be fixed, or will an attacker exploit it?
Cloud Runtime Security is Runtime Sec 2.0
For years, runtime security involved activities like endpoint security and firewalls that aren’t really relevant to cloud security. But now we’re seeing a new version of runtime security — cloud runtime security — which holds the key to clearing the app security backlog.
Cloud runtime security uses runtime data to identify real risks, provide much-needed context and help prevent attacks. Security and DevOps teams learn which risks to prioritize and which ones aren’t critical. This reduces the flood of alerts that DevOps teams have to deal with and helps to ensure that they address the real issues before they can be exploited, with IBM reporting that runtime security can slash MTTD by up to 50%.
Runtime and Build Time Need to Talk
As well as distinguishing between real and theoretical risks, security teams also need to determine which risks are accepted and deliberate risks. Frequently, a security tool will flag something as a misconfiguration when it’s not a mistake. One common example is privileged containers. This triggers an alert to correct the privilege level, but some containers need this level of privilege to operate effectively.
When build time intentionally accepts risks as vital for business operations, runtime security teams must be informed about these decisions. This awareness allows them to prioritize those code sections that are more vulnerable, focusing their attention on delivering proactive monitoring and tailored responses like refined network policies and seccomp profiles.
Between them, build-time security (i.e. shifting left) and runtime security can cover each other’s bases and harden overall security posture. Vulnerabilities that escape DevOps scanning are revealed by runtime security; SOC teams learn how to contain deliberate risks; and both teams receive the guidance they need to determine which issues should be prioritized.
Runtime Security Gives the Context You Need for Posture
The new cybersecurity landscape requires a layered approach to app security. Even if you’re excelling at shift left, you need to bring runtime context into security posture. Cloud runtime security context catches the risks that can’t be detected by shifting left, distinguishes between real and theoretical risk and directs DevOps to address the real vulnerabilities first.
But communication is not a one-way street. Build time also needs to feed context to runtime about which risks are accepted risks and cannot be removed, so that security can decide how to respond to alerts around those accepted risks and what other steps can be taken. Together, cloud runtime security and the shift left of build time form a virtuous cycle that helps protect your organization.
