DEVOPSdigest

The benefits of shifting left in development are clear and well-known. Integrating security into the development process early on is a good idea. Ideally, effectively shifting left allows organizations to significantly lower their risk profile, which is a big part of why DevSecOps has become such a buzzword. Nevertheless, shifting left is not a silver bullet for cybersecurity.

The problem is this: the notion of shifting left is dependent on a linear development process, but real-life development is anything but linear. Companies are assembling increasingly complex tech stacks, and more and more stakeholders have the ability to stand up servers or provision apps, often without even alerting the security team. There isn't an organization on the planet that runs every piece of code past their security team, no matter how much they've emphasized "shifting left."

The current world of software relies heavily on recycled code, much of which is lifted from open-source repositories. No matter how tightly you integrate security into your development cycles, if the open-source code you borrowed is vulnerable, so are you. Even if you were to somehow achieve the unrealistic goal of "zero vulnerabilities in production," there's no guarantee that this will actually make your business secure.

Patch Management Doesn't Cover the Bases

Another issue companies face beyond just shifting their security left is the heavy reliance on patch management to find and fix vulnerabilities. While patch management certainly has its uses, there are a few notable shortcomings. Of 344 unique vulnerabilities ransomware operators exploited in 2021, 76% of the flaws were from 2019 or before. Not much has changed. When Equifax was breached in 2017, hackers exploited a vulnerability that had been reported months ago.

Even when done well, patch management is reactive and not completely effective. Somebody has to first find a vulnerability and then create a patch for it. Sometimes ethical hackers follow industry guidelines, but companies sometimes fail to patch the vulnerability quickly enough. It takes bad actors roughly a fortnight to turn a vulnerability into an exploit. If you don't move quicker than that to remediate a known vulnerability, you are leaving the door wide open for an attacker.

Have a Better Plan: Enable Proactive Security

Not everything that ends up in the production environment can be tested in development. Planning to catch vulnerabilities through shifting left or reactive patch management is a plan that will fail. Patch management and shifting left don't mean much if you can't move quickly to address the vulns you do find. You won't catch everything, and you won't patch what you do catch quickly enough.

Our increasing reliance on recycled code and the lack of visibility into unused or forgotten assets leave companies with more blind spots than ever. In the face of this ever-evolving digital landscape, companies cannot assume that their expanding external attack surface is protected just because they've introduced security into the development process — in fact, they should assume the opposite. It's not enough to shift left and supplement with patch management. Instead, companies should look to the right and consider how to continuously manage their expanding external attack surface in real-time.

Organizations need to transition from reactively chasing down vulns to holistically managing risk across their entire attack surface. Continuously testing the entire external attack surface, identifying forgotten assets and testing in a way that mimics how an attacker might exploit them is the only scalable form of defense. While it would be nice to catch all the vulnerabilities in development, that's unrealistic. Healthy cybersecurity begins with being proactive, thinking about what's next, and having a reliable plan in place.