Home Source code Spring4Shell marks the end of ‘Snooze Button’ security

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 in the frequency of zero-day attacks.

Combining an easily exploitable zero-day RCE into a ubiquitous product is usually not a common event let alone a back-to-back event like Log4Shell and Spring4Shell. While the threat of these vulnerabilities themselves grab our attention, the most alarming part might be the timing and suggestion that the frequency of these types of threats is accelerating.

As open source code continues to play a central role in the technology stacks of so many organizations, we must consider the importance of proactive security as vulnerabilities become more prevalent. Zero-day attacks are increasingly common, and the proportion of those used by cybercriminals for the lucrative ransomware industry is growth.

Despite this continuing pattern of similar alarms, security guards continue to press the snooze button. But if this rhythm continues, it will be more and more difficult to ignore it; leaders will begin to push to prioritize security in development. Coupled with Log4j, Spring4Shell offers us some key lessons to ensure that organizations use the best security practices:

Security Debt Can Leave You Bankrupt

The large amount of security debt (technical debt specific to known infrastructure or software vulnerabilities) that exists in most organizations helps to illustrate the main gap between the perceived risk and the budget allocated to application security. Developers, in general, are saddled with far more technical debt than anyone has the bandwidth to deal with. But those who don’t regularly manage it, including the open source components and all their dependencies, put their entire organization at risk, especially when it comes to security.

As businesses grow, these debts accumulate and accrue interest in the same way as financial debt, in the form of fixes or piecemeal workarounds. Startups start with zero technical (or security) debt, and their goal is to focus on creating a valuable and manageable product. Large organizations have legacy code that is no longer state-of-the-art technology, and on top of that, over time they struggle with additional workarounds that mitigated past issues. Technical debt isn’t always a critical issue requiring a team’s full attention, but organizations need to address it continuously and consistently. The optimal amount of investment to address it over time depends on many factors, the most important being the stage of the business.

Given the degradation of code quality and the accumulation of technical debt over time, early-stage companies should estimate an investment of around 10% of the developers’ time to settle 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 still demonstrates how difficult it can be to access critical information by examining everything – custom code, open source, containers, etc. Since the vulnerability affects so indirectly, some organizations are still scrambling to approach it as attackers. finding new ways to take advantage of vulnerability. Rapid response to security issues is essential, whether for customer demand or legal requirements, as in the example of Equifax.

Once you are alerted to a critical vulnerability in your product or zero day, a countdown begins – you can compare this to a fire breaking out in your office. This metaphor may seem over the top, but the emotions and stress involved may seem similar and the result can be just as devastating to an organization.

We couldn’t imagine an office that doesn’t have fire safety, training and drill plans. Just as we need to know the location of exits in an emergency, developer teams need an overview of all code. This is especially important for those who work for medium-sized companies and large enterprises using large amounts of content from different providers.

While this helps us understand the importance of developing incident response plans for the next emerging security hazard, organizations must also proactively prevent them. One way to do this is to detect threats before they happen by designating a zero-day team or task force. It’s almost a guarantee that you’ll find vulnerabilities when you look for them. While not always urgent, organizations need to be prepared as malicious actors are constantly looking for loopholes to exploit for financial gain as the business grows.

Zero-day attacks counted less than half a percent of all vulnerabilities over the past decade, with 99% of exploited vulnerabilities already known to IT teams, according to Gartner estimates. The changing cadence of zero-day attacks, however, warrants proactive and reactive vulnerability patching work, i.e. resolving technical and security debt in addition to developing a mitigation plan. action in case of vulnerability.

Native tools help thwart potential attacks

The patching and remediation process is complicated, and especially with the attacks we’ve seen recently, there is no one-size-fits-all approach to patching these vulnerabilities. Some experts say that new problems will continue to appear for years.

But not all developers can be expected to have deep security expertise. A native remediation approach for developers should offer a solution to deal with these vulnerabilities analogous to a pull request.

There is a future where developers can deal with vulnerabilities as easily as general code quality control fixes; most vulnerabilities can be attributed to user input that was not properly filtered. If a developer can be guided to these ambiguous points or, even better, alerted when such remediation is missing or improperly implemented, we can eliminate the creation of vulnerable code.

Meanwhile, organizations suffer from a lack of knowledge about where these issues may be hiding, leaving them vulnerable to attack. As these more malicious targeted attacks occur more frequently in the open source community, the best-prepared companies have the most visibility into their code. If Log4j showed us how pervasive certain vulnerabilities can be in organizations’ supply chains, Spring4Shell illustrates why back-to-back attacks are a “call to action” for organizations to revise how they prioritize best practices. of security.