The modern tech landscape is all about speed. In the great race to innovate, developers have been pushed to create and update applications at a hitherto unimaginable rate. As the bar is raised ever higher, and businesses scramble to keep up or get ahead, developers must build code faster than ever to speed development cycles.
The “shift-left” security movement grew out of this phenomenon. In order to save on human resources, cut costs and slash development time, organisations adopted processes to incorporate security requirements earlier into the development cycle.
As such, shift-left has taken the security world by storm – and it’s understandable. Closing security gaps in the early stages of development does save precious time, resources, and money.
But there’s a catch.
Shift-left provides the most value for new and emerging technologies. Before new tech is implemented, developers and their employers can easily establish security guidelines and parameters for the technology development process. Because new technologies have yet to be incorporated into the running infrastructure, they don’t need to retrofit any security capabilities.
However, the crux of the issue is that shift-left only identifies security gaps in the development stage. Shift-left capabilities cannot protect what’s already running in your environment. Anything already running within an environment is left unprotected. Jettisoning runtime monitoring and protection capabilities for shift-left tactics will leave existing running assets exposed.
This especially applies to application programming interfaces (APIs). APIs allow for the instant exchange of data across multiple platforms, and their usage has rocketed with the dramatic increase of digital services and online applications. In today’s API-driven economy, companies typically have hundreds or even thousands of APIs running, many of which they are completely unaware of. Shift-left, by its nature, isn’t going to help organisations discover these APIs.
Moreover, because APIs aren’t straight code, it’s impossible to identify all flaws in the development and testing phases. Business logic flaws in APIs can only be identified when APIs are ‘exercised’. This requires security capabilities external to the code base. It’s still worthwhile for organisations to use security testing tools to verify specific facets of API implementation, prominent misconfigurations or vulnerabilities for example – however, it’s crucial to recognise their limitations when it comes to assaults on business logic.
Another issue with shift-left is that it doesn’t reduce risk quickly enough. A recent study found that 62% of organisations remain unaware of vulnerabilities that could lead to a data breach. Worse still, the same study revealed that 60% of breach victims were breached to an unpatched but known vulnerability. In the case of high-severity vulnerabilities, the report found that an average of 246 days would pass before they were fixed.
Cutting down these excessive patch times requires starting with the right and then shifting left.
So, just what does starting with the right mean?
Starting with the right means starting with runtime protection. Runtime protection is essentially a tourniquet for cyber-wounds, protecting an organisation’s data and systems while security teams identify and patch whatever vulnerability may have been exploited. This means that all of your workloads have an immediate defence, cutting down security risks without any tinkering with code.
The best runtime protection services carry out behavioural analysis, allowing for ultra-fast attack detection and response. This essentially works by showing security teams what “normal” behaviour looks like in their environment, making spotting anomalies a whole lot easier.
It’s also worth noting that runtime protection complements shift-left tactics. Runtime insights dig out vulnerabilities that can be remediated in development, so that security teams can share data with development teams to inform future cycles.
To add some context, the infamous Log4j (Log4Shell) vulnerability would not have been discovered using shift-left tactics. One can only imagine the chaos that would have ensued were this the case. Worse still, the top six API threats on the OWASP top ten API threats list stem from business logic gaps, for which shift-left is useless.
Not all attacks can be uncovered by testing tools; they simply weren’t designed this way. Runtime protection allows organisations to spot security threats and respond to them faster.
Educating developers on the importance of secure coding and implementing responsible shift-left measures provides value and helps businesses think strategically about bolstering their security posture.
However, shift-left isn’t a one-stop fix – relying on it alone leaves organisations at enormous risk.
