SYNDICATED POST
By Tyler Jewell. Originally posted at The New Stack.
Lightbend CEO Tyler Jewell argues that open source infrastructure software projects, without corporate sponsorship or other forms of dedicated funding, can't provide assurances about their security.
The ongoing discourse around the security of open source software projects has recently become mainstream among developers and business leaders alike. In particular, the recent disclosure of a vulnerability in the xz compression library used by Linux has shaken the developer world, demonstrating that even the biggest and most active open-source projects are susceptible to bad actors introducing vulnerabilities.
While the open source community has touted their rapid, transparent, and collaborative response in addressing this issue, as well as the fact that the attacker failed instantly despite years of planning, the community has also downplayed the overall risk that reliance on open source can represent. The simple truth is that if your use case is contingent on either rock-solid security or regulatory compliance, commercial-backed software will likely be a superior choice for your development needs.
The bottom line is that any project with community-based governance creates greater risk than one with 100% commercial backing. Most open source projects are understaffed and underfunded, lacking the proper resources to implement security measures. Background checks on contributors are rarely performed. Dedicated security teams, formal security testing procedures, and established accountability measures to ensure the security and integrity of codebases and project operations are largely absent.
That often translates into open source that includes unaddressed vulnerabilities and doesn’t meet existing regulatory requirements, let alone the rapidly evolving world of new compliance requirements coming from the EU and, soon, the U.S. There are a number of ways that open source finds itself wanting when compared with the security and compliance capabilities of commercial software.
The biggest issue with underfunded open source projects is maintaining compliance with global regulations. Many vertical markets have stringent requirements for software compliance with security regulations due to the sensitive nature of the data they handle and the criticality of their operations. These applications represent a broad range of essential industries, including:
These industries must continuously update their security practices and software solutions to comply with evolving regulations and protect against new cyber threats. Most open source projects cannot keep up, while commercially-backed projects make this a cost of doing business.
More broadly, frameworks like SOC 2 (Service Organization Control 2) help ensure that service providers securely manage your data to protect your organization’s interests and its clients’ privacy. SOC 2 is specifically designed for service providers storing customer data in the cloud, and it has become a crucial component for technology and cloud computing entities that provide services to other businesses. How many open source projects have the resources to meet SOC 2 requirements, which require intensive and ongoing scanning for vulnerabilities?
In the E.U., the Cyber Resilience Act (CRA) is also coming to the fore and is a critical requirement for commercially-backed software. While open source projects may not be required to adhere to the CRA’s requirements, you’ll need to do the work on your own if you’re expected to sell a service or application based on open source software. That simply adds more work when you could purchase a commercially-backed, compliant solution.
Beyond regulatory compliance, It is now clear that community-governed open source can introduce significant new security risks. The disclosure of the xz Linux vulnerability placed a spotlight on the underbelly of open source: that nefarious actors can insert backdoor malware if they establish faux trust by making benign, helpful contributions to gain “maintainer” power.
On the other hand, commercial vendors go beyond by certifying a contributor’s trustworthiness. Vendors offer their customers indemnities with potent financial remedies if they fail to secure the software they distribute. Foundations cannot and will not provide such protections.
That’s not to say that commercial software is invulnerable, but commercially-backed entities almost always employ significantly more safeguards than free and open source software projects.
When you purchase a subscription from a commercial vendor, the open source project becomes safer, stronger, and more widely adopted.
With Akka, for example, since our license conversion, we’ve improved security and compliance capabilities for Akka in several ways that wouldn’t have been possible under our previous model. For example, we have fixed and indemnified 42 CVEs over 18 months. We have also resolved 45 bugs, most of which were identified by customers who could not post problems on public issues but can reveal them through confidential communications. We have established GDPR and SOC2 Type 2 compliance, and we’re near completion of our ISO 27001 compliance. We certify our trustworthiness by embracing multiple Secure Software Development Framework policies and a NIST-CSF attestation for software used by or sold to the US government.
The xz vulnerability served as a warning sign for the software industry. It’s certainly true this was resolved quickly and effectively. However, the overwhelming majority of active open source projects operate on shoestring budgets, relying almost entirely on voluntary contributions from individual developers. A 2021 report from Tidelift highlighted the chronic underfunding and lack of resources plaguing most open source projects. Without dedicated funding sources or corporate sponsorship, these projects lack the means to implement robust security processes, perform comprehensive code audits, or provide any assurances about the integrity of their codebases. These glaring security risks can no longer be ignored. If the application upon which you or your customers rely demands robust security and regulatory compliance, you owe it to yourself to consider a commercially-backed solution as an alternative to community-backed open source software.
