With the latest round of security disclosures comingled with the Equifax data breach, it’s reasonable for users of Struts to start questioning if they should be migrating to another framework.
It’s one hell of a year for Apache Struts. With the latest round of security disclosures comingled with the Equifax data breach, it’s reasonable for users of Struts to start questioning if they should be migrating to another framework. After all, there have been five possible remote code execution disclosures this year, and that’s quite a lot.
RELATED: Equifax, Apache Struts, and CVE-2017-5638 vulnerability
The easy answer to the question is “it depends.” Sorry folks, but I couldn’t resist going back to my consulting days with that one — but it’s true. What I want to do with this blog post is highlight some of the factors that should be part of your analysis — and they’re all positive items.
1. Apache Struts is a mainstream web framework. From a security perspective this is a double edged sword. On the consumption side of the equation, this means that you’re not alone. The Apache community is strong and vibrant and you can openly seek solutions to help you run a more secure application. Translation? You’ve got access to lots of brain power to help you resolve problems. If your day job includes contributing to Struts (and if you’re using it you should be contributing in some fashion), then this breadth of usage makes for a lot of people wanting you to “fix things.” Translation? Focus on being responsive and keep them happy.
2. Apache Struts, like most Apache Software Foundation projects, has a responsive security team. If you’re betting the success of your business (or your employer’s business) on an open source project, this is a critical item to consider. Projects with security response processes will have CVE disclosures, and will operate using responsible security disclosure policies. Projects without well-defined security response processes are far more likely to have no CVEs reported. This isn’t because the project code is defect free, but because the CVE process expects to work with a security team. Minimally, if there is no security response process, then you’re going to need to be actively engaged with the project community in order to learn of security issues.
3. Apache Struts is under active development, and currently maintaining multiple versions. The health of the developer community should always be a key consideration when adopting a project. For frameworks like Struts, this is doubly important as an individual developer is unlikely to have expertise across the breadth of the framework. When you add in the demands of security updates, an active development community also translates to a community that is responsive to security issues.
While Struts is currently under increased scrutiny due to the visibility of the Equifax breach and recent vulnerability announcements, project stats for Apache Struts, publicly available on Black Duck Open Hub, show that new versions have had relatively few vulnerabilities reported against them.
The Black Duck KnowledgeBase™ tracks open source project activity occurring on over 10,000 sites for projects of widely varying size, maturity and sophistication. Apache maintains a strong and active community, and their development and testing practices are as good as or better than many commercial software development teams. In both cases, flaws, including security vulnerabilities, can and do make their way into the code and may only be discovered years later. Consider this post from René Gielen on the role of Struts in the Equifax data breach. In it he not only provides some clear recommendations for proper application hygiene, but also directly addresses a question I hear quite regularly “if the vuln is so old, why is it only being fixed now?” In the post, René states:
“One has to understand that there is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years…. What we saw here is common software engineering business –people write code for achieving a desired function, but may not be aware of undesired side-effects.”
So, in the face of multiple potential remote code execution disclosures in a single week, how do you keep pace?
The easy answer is you need to have both a clear view of which applications are using Struts, and a way to proactively monitor for new security disclosures. If that system can also point you to public exploit code you can use to validate if your defenses are working properly, so much the better.
In the end, only you can decide if you are comfortable using Apache Struts, but it’s important to remember that all software, be it open source or proprietary, will have security issues. If you’re dependent upon any third party components or software, you need to be proactively monitoring for new security issues regardless of where they’re reported. Black Duck can help with that, and together we can minimize the work required to build and maintain secure applications and containers.
Tim Mackey is the Head of Software Supply Chain Risk Strategy within the Synopsys Software Integrity Group. He joined Synopsys as part of the Black Duck Software acquisition where he worked to bring integrated security scanning technology to Red Hat OpenShift and the Kubernetes container orchestration platforms. In this role, Tim applies his skills in distributed systems engineering, mission critical engineering, performance monitoring, large-scale data center operations, and global data privacy regulations to customer problems. He takes the lessons learned from those activities and delivers talks globally at well-known events such as RSA, Black Hat, Open Source Summit, KubeCon, OSCON, DevSecCon, DevOpsCon, Red Hat Summit, and Interop. Tim is also an O'Reilly Media published author and has been covered in publications around the globe including USA Today, Fortune, NBC News, CNN, Forbes, Dark Reading, TEISS, InfoSecurity Magazine, and The Straits Times Follow Tim at @TimInTech on Twitter and at mackeytim on LinkedIn.