Developers the world over depend on the Apache Struts open source framework to build valuable and powerful applications.
This open source component and the Apache Software Foundation that stands behind it have provided organizations with a cost-effective force multiplier that allows their teams to develop faster and more efficiently. A very active project, GitHub shows Apache Struts as having 5,441 commits and 112 releases. However, like all software, Apache Struts contains a number of vulnerabilities that, due to the component’s widespread use throughout the industry, have had an outsized impact on software security.
The Notorious History of Apache Struts Vulnerabilities
Apache Struts made headlines with the breach of the US-based credit rating agency Equifax. Despite the warnings from government agencies and the National Vulnerability Database (NVD) that the version of Apache Struts 2 that they were using was extremely vulnerable to remote code execution attacks (CVE-2017-5638), the company appears to have been unaware that they were using the vulnerable open source component and failed to remediate the flaw when it was reported.
The rest of the story of how the hackers breached Equifax’s public-facing customer portal a number of months later, making off with the personally identifiable information (PII) of over 145 million people, and the dumpster fire that was their failure to properly disclose to the breach to the public, is now cemented in history.
When another Critical 9.5 rated vulnerability popped up in August with a remote code execution issue, many companies brace themselves for the next Equifax-level breach report. As of this writing, thankfully it does not appear that this has occurred.
With all this baggage associated with Apache Struts, it is worth asking whether the project is, in fact, deserving of all this negative attention. In hopes of understanding whether this reputation was in fact deserved, we decided to compare it with another popular project, Spring.
We looked at the numbers to compare Apache Struts vs Spring vulnerabilities to see pound-for-pound, who is the heavier hitter.
The Match Up — Apache Struts Vulnerability History Goes Toe-To-Toe With Spring’s
On first glance, Apache Struts would appear to have the edge as the more vulnerable project.
Total CVEs (2013-2018)
To start with, since 2013 Apache Struts has had three more (49 to 46) reported vulnerabilities than Spring. Delving into the severity scores, Apache Struts has succeeded in maintaining a lead over Spring when it comes to CVSS v2 ratings (since our research goes back to 2013, not all entries had a CVSS v3 score so we are using v2 for consistency), with an average score of 6.89 over Spring’s 5.96. During our observed period, Spring did not receive any Critical 10 rating on CVSS v2.
Average CVEs Severity (CVSS v2)
To be fair though, Spring has racked up some pretty harsh ratings on CVSS v3 over the course of the past year — including more than a fair share of 9.8s — but let’s leave that for another post.
When high-level Apache Struts vulnerabilities are found, they have been doozies. The Jakarta Multipart Parser vulnerability in CVE-2017-5638 that was used in the Equifax breach received a 10 (because 11s are not a thing yet) while CVE-2018-11776 picked a 9.5 for its effort.
But taking a step back, besides these two attention-grabbing CVEs, Apache Struts vulnerabilities have been relatively rare and tame as of late. So far only two CVE’s have been listed for Apache Struts so far in 2018.
In fact, we can argue that there has been a marked decrease in the number of CVEs listed for Apache Struts in the past two years, bucking the trend of CVEs rising across the board. According to CVE Details, the number of CVEs reported in 2017 spiked to 14,714 from 6,447 the year before. The current count is on pace to beat out 2018, with no signs of slowing down.
Reported Vulnerabilities in Apache Struts vs Spring (2013-2018)
More to the point for the purposes of our comparison, Apache Struts vs Spring vulnerabilities have crisscrossed, markedly dropping for Struts while Spiking for Spring. According to our records, Spring has had 32 CVEs since 2016, outpacing Struts’ 29. They have not been helped by the discovery of a whopping 18 CVEs that have been published so far this year.
Apache Struts vs. Spring Vulnerabilities: Do We Have A Winner?
In light of these statistics, and in contrast to a lot of popular wisdom, it would seem that Apache Struts may, in fact, be less vulnerable than Spring.
It is important to remember that even as new Apache Struts vulnerability discoveries are on the decline, it is likely that plenty of older CVEs for this project are still kicking around in more of our software products than we would care to admit.
We need to remember that hackers love to use published known vulnerabilities to look for new targets, knowing full well that far too many organizations fail to patch even after a fix becomes available.
If you are not using the right tools to keep an updated inventory of what you have, identifying which ones have known vulnerabilities than you could be exposed to a highly preventable attack.
Mo’ Code, Mo’ Problems — Key Take-Aways On The Apache Struts Vulnerability
Given the publicity that came out of the Equifax fiasco, it is safe to say that plenty of security researchers are pouring through the code, looking for the next big Apache Struts vulnerability. The relatively small number of CVEs that have been published should give us some pause though when thinking of bad mouthing the good folks at the Apache Foundation and their loyal contributors who put in the sweat effort of finding the vulnerabilities, bringing them to our attention.
Statistically, when you bring together so much code as we see in projects like Apache Struts or Spring for that matter, you are going to eventually turn over vulnerabilities in the code. The good news is that the team managing Apache Struts appears to have a better handle on their project and are putting out more secure components, or at the very least, components that are harder to exploit.
The publishing of more vulnerabilities can also be deemed as a good sign for the team over at Spring since it means that more security researchers are putting the time into searching for potential CVEs in their projects as well.
For the users of open source components (which is nearly everyone), the question should not be Apache Struts vs Spring vulnerabilities, but how do we manage them?
Open Source Security: Winning the Long Game
Open source security depends on security researchers finding vulnerabilities and reporting them to the project owners and the community before criminal hackers can. Once these vulnerabilities have been posted, it is up to the developers who use these open source components for building their software products to use them responsibly and patch or update when necessary.
This means avoiding the use of open source components with known vulnerabilities, and utilizing the right tools to identify which open source components they are using in their products and receive alerts when new vulnerabilities are reported for those projects.
From a management perspective, t also means that we need a deeper understanding of which vulnerabilities actually impact our products, guiding us in how we prioritize our remediation operations. Just because a vulnerability is present in a component that you are using does not mean that the product is, in fact, making calls to it.
Analyzing which vulnerable functions are in fact effective can help teams to get the most out of the open source components that they depend on while minimizing the effort needed to work securely with them.