Balancing Security Investments in Open Source and Proprietary Code
For over a decade now, enterprises have increasingly leveraged more open source and less proprietary code in their software stacks. This has happened because open source allows organizations to innovate considerably faster than developing everything in house, and competitors embracing open source effectively forces everyone else in their industry to keep up whether they were the first mover or not.
You need to look no further than the current generative AI boom to see evidence of this. As with any bleeding edge technology, it is almost impossible to deploy any LLM without relying on significant amounts of open source. As a result, 41% of enterprises reported a “substantial” increase in open source usage in 2023, despite almost all companies already using over 3 times as much open source code as proprietary code in 2022 (i.e., strong growth off a high base).
Open Source vs Proprietary Code in the Enterprise Software Stack
Your codebase probably looks something like this:
This data comes from Synopsys’ OSSRA Report, which uses statistically sound methodology and is therefore an excellent source of data on enterprise open source usage, security and risk. This is an average across all industries, but some sectors’ codebases are about 90% open source, and the lowest is still north of 50%. That means at least 1 out of every 2 lines of code in production at every company is probably open source.
Application of Security Investments and Vendor Support
The effectiveness of your software risk management probably looks something like this:
Allianz, one of the world’s largest insurers, suggests cybersecurity is the number one priority for enterprises of all sizes in their latest Risk Barometer report. Understandably, business leaders therefore demand that their proprietary software vendors offer robust security measures, regular updates, and dedicated support teams. Further, CISOs invest considerable resources in verifying that their vendors are delivering on their commitments.
However, open source software rarely has a formal vendor to make similar demands of. While this makes CISOs and risk managers uneasy, accepting this condition is clearly preferable to being outcompeted into bankruptcy. As a result, a thriving industry of OSS AppSec products has sprung up, such as popular SCA tools from Snyk, Sonatype and Synopsys (say that three times fast), and professional societies like the TODO Group evangelize best practices.
Recommended by LinkedIn
Securing and Supporting Open Source Software Like It Was Proprietary
To extend the commercially reasonable risk management practices of your proprietary solutions to your open source software stack, enterprises can, in order of effectiveness:
At a minimum, investing even more in securing your proprietary software stack likely offers a poor return, especially if you ascribe to the weakest link theory of defense. While the recommendations above require a substantial budget behind them, the cost of accepting the risk has been proven to be higher. Over a decade ago, Heartbleed cost industry at least $1 billion, and Log4Shell remediation is still ongoing almost 3 years later with a running tab in the billions plural.
The Hidden Cost of Open Source Software
Open Source Software often carries another adjective, Free (“FOSS”). Free is a pretty compelling value proposition, but, as Milton Friedman once titled a book of his, There’s No Such Thing as a Free Lunch. What you gain in innovation, competitiveness and velocity for no up front cost, you pay for in arrears with incident response costs, risk management investments and, most onerous of all, technical debt. Many a product manager’s annual plans have been completely sidelined by a critical CVE in an open source project demanding all software developer hands on deck.
The core problem in the Secure OSS (“SOSS”) ecosystem is that it currently emphasizes alerts, not solutions. Enterprises try to alert their developers not to use risky OSS projects in their code, hoping they will select alternative options that are perceived to be safer (but may not be). Products try to find vulnerabilities in existing OSS deployments, and alert enterprises that a fix might be required. A lot of alerts generating a lot of work to both triage and remediate, that often gets deprioritized, thereby accruing more risk.
The only real exception to this is the small number of OSS vendors offering commercial support for their projects, which doesn’t help when your devs want to use something else (which they do and already are). Kosai is the first, and therefore only, company offering the same enterprise support and security SLAs you demand from your proprietary vendors for every single piece of OSS that exists. No exceptions. For the first time, you can cover your entire tech stack with Kosai. No alerts, no work creation, just patches.