Open source is the lifeblood of modern software development, there’s no getting around it. It makes sense that development teams want to get a head-start when beginning a new project and don’t want to have to start from scratch every time. Because open source software is designed and “certified” with public use in mind, it is prevalent throughout the app dev community.
The dangers with open source, however, are at least the same as for custom software. If it’s not checked against industry standards for quality and security before it’s put into production as part of a bigger system, there can be trouble. This is where Equifax failed.
It’s surprising how few IT leaders have a software risk scorecard, and that most don’t even know to ask for one. At CAST, we’ve been tilting at this particular windmill for the better part of 10 years now. From our clients, we hear a lot of “We hire good developers to make sure we have good, secure code.” Or, “we hired XYZ vendor because they have a strong SDLC process.” Or, my all-time favorite these days, “we have an automated unit test environment in our DevOps toolchain.” Uh-huh. But, do you know if the application uses Struts and if it uses the Struts framework correctly?
Struts is a framework that developers commonly use for web applications. It’s one of the approximately 130 open source frameworks that are commonly used by developers around the world, and there’s a long tail of hundreds of other framework varietals out there. That doesn’t account for the fact that Struts has about 10 versions in wide use, and most other frameworks have multiple versions as well. So, for example, in the case of Equifax, the vulnerability was, CVE-2017-9805, which occurred in Struts 2.3.x and 2.5.x. Yet, Struts 1.2 – 1.3.10 do not have that vulnerability.
Using frameworks is considered best practice among developers and architects. It’s more productive, and you have less chance of introducing errors. The only problem is that most of them are open source, and thus can be studied closely by the “Black Hats.” If there are weaknesses in that code, they can figure out how to exploit them. There are two sources of such weaknesses: composition and construction. Composition has to do with which version you have and does that version have an exploitable flaw inside. Construction is how the framework is integrated into the rest of the application that’s coded around it. Both of these factors could be exploited by a Black Hat who’s studied the source code of a framework.
Aside from open source frameworks, there are many well-known software weaknesses that, even in the absence of open source components, can cause software to become unstable, inefficient, easy to hack into, and even hard to maintain.
Using a software risk scorecard can help you mitigate some, and in many cases most, of this risk. Something that uses the CISQ standards for Security, Reliability, Performance Efficiency and Maintainability, which are based on the well-defined canon of commonly known weaknesses and vulnerabilities (CWEs and CVEs). Something that covers construction and composition. Something that fills that blind spot that almost all app managers and enterprise architects have: understanding the level of security risk within the software that powers their company.
Until your organization has a software risk scorecard, it would certainly be smart to do a software portfolio risk audit. Quickly scan your software portfolio, find out your exposure to known vulnerabilities from open source frameworks and your structural risk hot spots, and get cracking to fix the most egregious problems in your most critical systems.
CAST can help you get started with our Application Intelligence Platform that blueprints entire applications to clearly visualize and pinpoint software security risks, keeping you ahead of the next big breach.