Get the Response to Spring4Shell Right: Best Practices for Immediate Remediation
Table of Contents
With more than 38 percent of our customers impacted by the recently discovered Spring4 Shell zero-day vulnerability and more than 33 percent of impacted organizations having already remediated (removed) some or all their vulnerable libraries, I have been involved in many conversations over this incident.
The most common question I’m hearing is, “Who is getting the response to Spring4Shell right?”
Although we are only a few days out from the initial publication of the zero-day, we’ve already seen three effective best practices:
1. Knowing is more than half the battle
The 80’s cartoon G.I. Joe would end with useful safety tips followed by the catch phrase, “and knowing is half the battle”.
Effectively responding to this type of incident requires just that: knowing. In this case, it means having full visibility to the vulnerable libraries in your code and quickly mapping out a full inventory, enabling you to quickly identify and prioritize where you need to take action to protect your application.
Interestingly enough, while 38 percent of organizations were impacted, only 9 percent of distinct applications developed by those organizations had even a single vulnerable library. Looking at impacted code repositories, the number even drops further, with only 6 percent of distinct repositories being impacted!
Many of our customers shared that being able to quickly pull a report of the applications containing SpringCore from their software bill of materials (SBOM) was key to successfully executing a response. It allowed them to quickly understand which products in their organization were exposed, so they could contact the relevant engineering teams.
Customers that deployed native integrations reported that, in many cases, engineering team leaders were already on the case prior to being contacted by AppSec. That’s because they received Mend email alerts, automatically generated Jira tickets, or assigned security issues in their repositories.
2. Prioritize, prioritize, prioritize
Expediting an effective response in the hectic first days after the vulnerability’s discovery requires transparency across dependencies within the software. In the case of Spring4Shell, the use of the SBOM proved critical, because it enabled customers to map out which products used the impacted versions of Apache Tomcat and Java. Remediation activity could immediately focus on the most at-risk dependencies, to maximize the effectiveness of the fix.
Some customers honed their focus by using Mend Prioritize. This gives them the capability to analyze how their code interacts with open-source components. With Prioritize, they can see whether reported vulnerabilities are detrimentally affecting their code, so they know where the most pressing risks are and where the vulnerabilities don’t pose an immediate risk.
For example, one customer was able to determine that 68 percent of Spring4Shell vulnerabilities impacting one of their products were in fact not referenced, allowing them to prioritize others that were exploitable.
Our customers reported that quickly taking these first steps helped to ensure that temporary mitigation measures such as WAF policies were applied in the areas most impacted.
3. Keep your dependencies up to date
The most effective best practice is one that happens way before the zero-day response. It’s the practice of continuously keeping your dependencies up to date. This involves incorporating dependency automation into your workflow, to ensure agility and reduce risk in future situations where you need to act fast.
Open source libraries used to develop applications can be either direct or transitive. A direct open source dependency means that a developer explicitly included the open source library. A transitive dependency means that another open source component included it as something it needs to execute, so basically a ‘dependency of a dependency’. A developer could have no idea that this transitive library was even included when building an application.
As many of the SpringCore dependencies are transitive, remediating them is a time-consuming manual process, because it’s first necessary to understand how the dependency got into your application before you can figure out how to fix it.
An effective way to overcome this issue is to use Mend Renovate. Renovate is an open source project specifically designed for software dependency updates. This free solution scans your software, discovers dependencies, and automatically checks to see if an updated version exists. It then alerts you when a new version of a dependency is available and resolves outdated dependencies by opening pull requests to update them. This process identifies a component version’s age, adoption, and potential to break the build, giving development teams the data to make a remediation decision faster. The result: developers save time, reduce risk, and can easily mitigate the impact of security vulnerabilities.
With over one hundred million downloads, Mend Renovate has already identified and mitigated the Spring4Shell vulnerability for tens of thousands of enterprises around the world.
If you’re concerned about the potential impact of the Spring4Shell vulnerability, download our free command-line interface (CLI) tool that quickly scans projects to find vulnerable open source libraries for Spring4Shell.
And to maintain good dependency management practices as a preventative measure against future attacks, use Mend Renovate, totally free.
