Why do we need a Software Composition Analysis tool against open source software vulnerabilities?
Well, that is a long story:
Commercial and industrial software is now primarily constructed from components. Open source components, to be exact. Open source software licenses dramatically decrease business frictions that arise from incorporating and integrating software developed by external entities. No more contract negotiation or in-house legal review!
Add to this the fact that many software use cases are more or less identical across systems: HTTP connectivity, encryption, spell checking, transaction management, database object mapping, unit testing, etc. The end result is predictable: in less time than it takes to read the 2-clause BSD open source software license, your developers are copying externally developed software libraries into your proprietary systems. Because: why not? The license allows it, and developers achieve their objectives with fewer bugs and time to spare.
Software developers can now easily obtain pre-fabricated high-quality software libraries to help implement significant portions of their software. Your colleagues only need to write a small amount of glue code to wire these libraries into the larger system. Software, like automobiles, is now made mostly from parts.
But unlike cars, the supply chain in the software world is complete mayhem and chaos. Consider this common clause found in the majority of open software licenses:
Unless required by applicable law or agreed to in writing, Licensor provides the Work on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.
Risk management would flag this as a major risk, and procurement policies would not allow such clauses to stand in a legal review. But the advantages of open source software outweigh the risk of running without warranties. You get what you pay for. But there are costs. People often say there is no such thing as a free lunch – the same is true of open source software.
In this article
1. The Upgrade Problem
2. How to manage open source software vulnerabilities and license risk?
3. Risk management for your open-source software
Some people, when confronted with a problem, think, “I know; I’ll use an open source software library.” Now they have two problems.
When I build my systems, I choose specific versions of open source libraries to incorporate into these systems. These versions quickly become stale as open source authors continuously update and evolve their libraries, issuing new releases periodically. Worse, you’ll start to find vulnerabilities in them.
At first glance, the problem looks pretty simple and straightforward. Somewhere in my build script, my software will contain a line like this:
<dependency>
<artifactId>apache-struts2</artifactId>
<version>2.5.22</version>
</dependency>
If I’m using JavaScript / NPM, then it would look a little different but essentially the same:
"dependencies": {
"apache-struts2": "^2.5.22"
}
To avoid any vulnerability to the infamous cyber security bug that took down Equifax in 2017, I just have to change the “” line in the text above to this:
<version>2.5.23</version>
Then I click “save” and “build” in my coding editor, and voila! My software is now safe. In the NPM example, things are even better thanks to that “^” character. The “^” symbol tells the build script to upgrade the library to 2.5.23 automatically.
However, despite how simple the example above appears, in actual practice, this problem is a complete f’ing nightmare. For several reasons:
The list above enumerates the tensions and problems we face when upgrading software components.
So what are people doing about it? First hand, “in the field,” I’ve seen three different approaches applied to this upgrade problem.
These tools operate similarly to the computer at your car dealership when the dealer types in your VIN and determines if your car has any outstanding recalls for any of its constituent parts. SCA tools immediately surface all library versions within your system that correspond to item 6 of my list above, helping software engineers prioritize their upgrading efforts to focus on the most urgent library updates.
Software Composition Analysis tools sometimes include additional features such as copyright license analysis and staleness checks. Finite State’s own SCA toolchain focuses exclusively on the recall problem.
In summary, the “Upgrade Problem” is a fundamental tension inherent to any software development practice that builds on reusable software components. The problem is not easy to resolve, but ultimately some libraries MUST be upgraded. Personally, I recommend tying the library upgrade decision to two factors: first, consider the library version’s current cyber security risk profile, and second, consider if the library’s own development team is relatively active and responsive.
In a nutshell, leave the library version alone (do not update it) if the following two factors hold (“if it ain’t broke”):
Otherwise, upgrade the library! In particular, if factor #1 no longer holds, migrate as soon as possible to an actively maintained competing library. Dead open source libraries like httpclient-3.x and apache-axis are notorious for accumulating CVEs, and emergency migrations with such defunct libraries become high-effort and high-risk – a terrible combination.
An SCA tool is critical for determining if a library should be upgraded. In my own experience, the “upgrade problem” is simply not tractable for manual best-effort approaches, and always-upgrade is too much work with too little benefit.
There’s one major caveat, though. If you’ve been using the “PURE MANUAL BEST EFFORTS” approach for a long time, you need to both don a safety mask and buckle your seat belt before first running an SCA tool against your system. The initial report is going to be intimidating and overwhelming.