The use of open source components in software development increases both the speed of software development as well as risk. Our recent State of Software Security report found that approximately 97 percent of Java applications contained at least one component with a known vulnerability. An open source component with a known vulnerability is an attractive target for cybercriminals. Instead of spending time creating an exploit that can breach a single application, the cybercriminal can create one exploit that can potentially penetrate thousands of applications. Yet the problem is not the use of components, it is the lack of visibility into where components are used, what versions are in use and then patching or updating that component.
Our number one priority is to help our customers reduce application risk, and this was an extremely risky vulnerability.
This is exactly what happened with the Apache Struts 2 vulnerability – what we are calling Struts-Shock. This critical vulnerability was disclosed with an active exploit available – one that was remotely executable. This had the potential to create a “long tail” effect, like what happened with Heartbleed. Companies knew about the vulnerability, and began patching efforts, but because they had difficulty finding where the component was used, some instances were missed – leading to breaches.
“Patching a vulnerability in a component used in web development requires the development team to recompile the applications. This can delay the time it takes to get the vulnerability remediated. In addition, many vulnerable applications may have been finished and have not seen development for years. This means customers not only need to identify those apps but need to find the original code and rebuild the applications with the fixed Struts 2 component. This is what happened with Heartbleed, and we can expect to see the same thing again.”
The criticality of this specific vulnerability, as well as how hard it can be to find all instances of a vulnerable component in an application portfolio, is what led Veracode to provide all customers – software composition analysis customers or not – with information regarding where they were vulnerable. We felt it was our responsibility to let customers know where they were vulnerable, regardless of whether or not they purchased the specific technology we use to find the vulnerability. Our number one priority is to help our customers reduce application risk, and this was an extremely risky vulnerability.
We started by updating our SCA database to include the vulnerability. In doing so, we were able to check all the applications our customers have submitted for testing and create an inventory of all applications that included this component. From there, we reached out to all SCA customers and non-SCA customers letting them know they had a vulnerable component.
We accomplished all this within one day of being notified of the vulnerability, in part because of our embrace of DevOps, which enables us to rapidly update our cloud-based products to respond quickly to new threats and other business needs. In addition, our combined platform technology and services-backed approach make our SCA solution a powerful security tool.
As far as we know, no other SCA solution can provide this type of rapid vulnerability response. Because we offer a SaaS platform, we don’t need to rescan applications to determine if they have the component in question – another reason why we were able to respond so quickly, and to offer this information to customers not using the product.
It is critical that security companies don’t over react to vulnerability disclosures. Doing so can create a “boy who cried wolf” effect when a critical vulnerability is disclosed. But when a highly exploitable component vulnerability is disclosed, being able to work with a partner who can quickly provide information on where you are vulnerable and how you can remediate is crucial. When an exploit is available, time is of the essence. That is why we have a vulnerability response plan in place and help our customers when these incidents do occur. The systemic risk created by components can only be combated with rapid response and visibility – both of which we provide.