The Shift Left movement has been a hot topic for a number of years. Building security into the development cycle as early as possible helps create fast feedback loops and accountability in development teams, reducing organizational risk by helping DevSecOps teams build more secure code. For a while, shifting left was the obvious thing for IT teams to do, since the historical model with a final "security gate" before release into production no longer works for a number of organizations.
But is the Shift Left movement a “silver bullet?” No, and it should not be treated as such.
Shifting left has its merits, but this approach has a fundamental problem; not all vulnerabilities will be found in staging environments. Many types of risk can only be found in the production environment, in part because the configuration for staging and production is never the same. Putting all an organization’s eggs in the Shift Left basket is foolhardy because trying to catch everything early is not only costly, but difficult to achieve.
A failure in shifting left
Because IT teams cannot catch everything by shifting left, organizations need other plans and tools for catching the vulnerabilities that do make it onto the attack surface. There are certain threats that only continuous testing in production will actually identify, such as subdomain takeovers. Shifting left does nothing to prevent subdomain takeovers because a subdomain takeover involves a CNAME pointing to a service that's no longer active. No matter how often security teams are testing pre-production, they are likely not testing assets that they do not even know about. Not every company will struggle with subdomain takeovers specifically, but many companies have hidden vulnerabilities that cannot be addressed just by shifting left.
Better patch management will not fix the problem
Patch management is also a critical component of an organization’s security strategy, but patch management is over-reliant on public disclosure processes like CVEs. CVEs only cover a fraction of the risks that occur in the modern technology stack, so just running a vulnerability management software will only take cybersecurity so far. And even with effective patch management, there’s no shortage of new CVE discoveries yearly, many AppSec vulnerabilities are never reported, and most of the stack is not covered by CVEs. This leaves organizations doubly exposed. To defend the organization, cybersecurity teams need a plan to understand if and where their environment is at risk and whether it's from publicly disclosed vulnerabilities.
How can CISOs protect what they don’t know they have?
One of the modern CISO’s biggest pain points is an overall lack of transparency — it’s hard to defend something IT didn’t know they had/doesn’t have access to. With companies embracing digital transformation and accelerating cloud migration projects, they are creating incredibly complex, interconnected environments with thousands of subdomains. The only way to manage this risk is by continuously discovering, inventorying and testing a company's external attack surface. This approach helps cybersecurity teams gain an attacker's view of the enterprise environment, eliminating blind spots and enabling the swift prioritization and remediation of any issues.
Look both ways to be safe
Shifting security left is required for effective DevSecOps. With the pace of development speeding up, organizations cannot only include security as a last-minute appendage to the development process. However, shifting left doesn't completely protect institutions as hackers probe companies’ rapidly expanding external attack surfaces. True DevSecOps requires shifting both left and right, testing in both staging and production environments continuously in real-time. Regardless of how well an organization shifts left, assuming that all vulnerabilities have been caught isn’t wise.
Companies need to look right using continuous testing to look for forgotten or exposed assets. Even if companies find 100% of the vulnerabilities in software development, without continuous testing to see if any back doors are open, malicious hackers will find a way in and try to take over the network.
