On February 25, Black Duck released its tenth annual Open Source Security and Risk Analysis (OSSRA) report. The OSSRA “examines vulnerabilities and license conflicts found in over 950 codebases across 16 industries” and “offers recommendations to help security, legal, risk, and development teams better understand open source security and the license risk landscape.”

The report found that 86% of commercial codebases evaluated contained open source software vulnerabilities, with 81% of them known to be high or critical risks.

The few remaining holdouts against the use of OSS in enterprise settings often seize upon this kind of data to support their misguided views about OSS. However, we don’t see it that way, and we don’t believe the overwhelming majority of enterprise users and developers see it that way. Here’s why:

1. Initiatives such as the OSSRA report are part of the open source community’s organic processes for ensuring security and quality control. They serve as public service announcements of sorts and embody the idea that sunlight is the best disinfectant, especially when we are humble enough to reflect it upon our own selves.
2. Ultimately, humans are responsible for maintaining codebases. We can and should automate as many processes as possible, but that sometimes makes it easy to forget that when something goes wrong, it’s human error that is ultimately to blame. No human, and hence no technology, is ever perfect.
3. What’s perceived as being open source’s biggest liability is actually its biggest strength. It’s true that the transparency of open source software allows bad actors to find and exploit vulnerabilities, but it also allows communities to examine every beta version and every release candidate with a fine-toothed comb, hunt for vulnerabilities, and contribute patches. When Equifax was hacked in 2017, it issued a meandering press release in which it blamed the hack on a six-month old vulnerability in Apache Struts. What Equifax failed to acknowledge–which Apache had pointed out in its own press release the previous day–was that the vulnerability had been patched by Apache as soon as it was discovered. Equifax simply failed to install the patch. In fact, according to subsequent reports, Equifax became aware of the vulnerability and the patch two months prior to the hack, but dragged its feat on performing the necessary security updates.
4. In light of these considerations, open source solutions carry no greater likelihood of compromise than their closed-source counterparts. This is not to say that closed-source software vendors don’t care about security or don’t exercise diligence in testing their software for vulnerabilities. But when that task falls solely on the vendor, all of the vendor’s users and customers are subject to the vendor’s blind spots. In contrast, security and quality control in the open source world are driven by one of the foundational principles of OSS: with enough eyeballs, all bugs are shallow.
5. All of this is to say that these realities of open source software are opportunities for COSS developers. We are well beyond the point where open source became a permanent fixture of the technology landscape. There are too many benefits to using open source software for the tide to be turned by any perceived disadvantages. Now we are at the point where the task of managing open source software is a realm where opportunities abound for COSS developers.