Spring4Shell Marks the end of ‘Snooze Button’ Security
While Spring4Shell may appear to be a replay of the initial Log4j alarm, what it actually signals is the changing cadence of zero-day attack frequency.
The combination of an easily exploitable RCE zero-day in a ubiquitous product isn’t usually a common event much less one that occurs back-to-back like Log4Shell and Spring4Shell. While the threat of these vulnerabilities themselves draws our attention, the more alarming part might be the timing and the suggestion that the frequency of these kinds of threats is accelerating.
As open source code continues to play a pivotal role in so many organizations’ tech stacks, we must consider the importance of proactive security as vulnerabilities get more pervasive. Zero-day attacks are increasing in frequency, and the proportion of those used by cybercriminals for the lucrative ransomware industry is growing.
Despite this ongoing pattern of similar alarms, security folks continue to hit the snooze button. But if this pace continues, it’s going to be harder and harder to ignore; leaders will begin to push for prioritization of security in development. Coupled with Log4j, Spring4Shell offers us a few key lessons for ensuring organizations are employing security best practices:
Security Debt can Leave you Bankrupt
The vast amount of security debt (technical debt specific to known infrastructure or software vulnerabilities) that exists in most organizations helps illustrate the major gap between the perceived risk and allocated budget in application security. Developers, in general, grapple with far more technical debt than anyone has the bandwidth to address. But those that do not regularly manage it—including open source components and all their dependencies—put their entire organization at risk, especially as it relates to security.
As companies grow, these debts build up and incur interest the same way financial debt does—just in the form of piecemeal fixes or workarounds. Startups begin with zero technical (or security) debt, and their goal is to focus on creating a valuable, manageable product. Bigger organizations have legacy code that is no longer cutting-edge technology and, on top of that, over time, struggle with the added workarounds that mitigated past issues. Technical debt is not always a critical issue needing a team’s full attention, but organizations should address it in an ongoing, consistent way. The optimal amount of investment in addressing it over time depends on many factors, the most important being company stage.
Taking into consideration the degrading of the code quality and the buildup of technical debt over time, early-stage companies should estimate an investment of around 10% of developers’ time to address this debt, if not more. For later-stage companies, this can be between 15% and 30%.
Holistic Visibility Helps Teams Move Quickly When it Matters Most
Even months later, Log4j is still demonstrating how difficult it can be to access critical information by looking at everything – custom code, open source, containers, etc. Since the vulnerability touched so much indirectly, some organizations are still scrambling to address it as attackers find new ways to leverage the vulnerability. Fast response for security matters is essential, whether for client demand or legal requirements, as in the example of Equifax.
Once you’re alerted about a critical vulnerability in your product or of a zero-day, a countdown timer begins—you can compare this to a fire starting in your office. This metaphor may sound exaggerated, but the emotions and stress involved can feel similar and the outcome might be equally devastating to an organization.
We couldn’t imagine an office that doesn’t have fire safety plans, training and drills. Just as we need to know the location of exits in an emergency, developer teams need a bird’s eye view of all code. This is especially important for those working for mid-market and enterprise companies using large amounts of content from different vendors.
While this helps us understand the importance of building incident response plans for the next emerging security hazard, organizations need to proactively prevent them, too. One way to do this is to find threats before they occur by designating a zero-day team or task force. It’s almost a guarantee you’ll find vulnerabilities when you go searching for them. While they’re not always urgent, organizations must be prepared as malicious actors are constantly looking for flaws to leverage for financial gain as a company grows.
Zero-day attacks accounted for less than half a percent of all vulnerabilities in the last decade, with 99% of vulnerabilities exploited being ones already known by IT teams, according to Gartner estimates. The changing cadence of zero-day attacks, however, warrants proactive and reactive vulnerability patching work—that is, addressing technical and security debt in addition to honing a plan of action should a vulnerability arise.
Native Tools Help Thwart Potential Attacks
The remediation and patching process is complicated and, especially with the attacks we’ve seen recently, there’s no one-size-fits-all approach for patching these vulnerabilities. Some experts say that new issues will continue to crop up for years.
But developers can’t all be expected to have deep security expertise. A developer-native approach to remediation should offer a solution to addressing these vulnerabilities analogous to a pull request.
There’s a future where developers can manage vulnerabilities as easily as general code quality control fixes; most vulnerabilities can be traced to a user input that wasn’t sanitized correctly. If a developer can be guided to those ambiguous points—or, even better, alerted when such a sanitation is missing or inappropriately implemented—we can eliminate the creation of vulnerable code.
In the meantime, organizations suffer from a lack of knowledge about where these problems may lurk and that leaves them susceptible to attack. As these more malicious, targeted attacks occur with more frequency in the open source community, the best-prepared companies are those with the greatest visibility into their code. If Log4j showed us just how pervasive some vulnerabilities can be across organizations’ supply chains, Spring4Shell is illustrating why back-to-back attacks are a ‘call to action’ for organizations to revise how they prioritize security best practices.
