Open source security and sustainability remain unsolved problem

The ease with which developers can integrate third-party open source code has created a security and sustainability crisis, according to a senior executive at edge cloud platform Fastly.

Speaking to Computer Weekly during a recent visit to Australia, Mike Shaver, Fastly’s vice-president of security products engineering and a co-founder of the Mozilla project, warned that the rise of the software bill of materials (SBOM) as a security tool has not fixed the trust issues that have plagued the ecosystem.

“I certainly don’t think it’s a solved problem,” said Shaver. “The ease of integrating third-party open-source code into your application has never been better. It's trivial – 20 characters entered into your shell, and you’ve pulled down a library from somewhere.”

This simplicity, he noted, creates new attack vectors, from compromised repositories to node package manager (NPN) typo squatting. The challenge for developers is knowing whether to trust a new version or dependency, especially when they lack the internal expertise to build the component themselves.

While open source offers a level of transparency that proprietary software cannot match, Shaver said this can lead to a dangerous assumption of safety.

“You can actually inspect at a very deep level in a way that you can’t with more proprietary offerings. That’s an advantage, but it's easy to assume that someone else must be watching this so I’m safe,” he cautioned.

This leads to a critical disconnect that is putting essential software infrastructure at risk.

“There’s been a real imbalance, unfortunately, between how open source is consumed and creates value for companies, and the investment that goes back into securing that commons,” Shaver said.

“The bill of materials is not just about ‘do we have intellectual property rights to use this?’ and ‘has it passed a security audit?’ but also about deciding whether we’re comfortable about being dependent on a piece of software,” he added.

This imbalance has placed an unsustainable burden on the maintainers of open source projects, whose role has only recently come into the spotlight due to high-profile security incidents and reports of burnout. Shaver argued that corporations have a clear responsibility to support the ecosystems they rely on.

The role of an open source maintainer didn’t exist in a meaningful way 20 years ago, he said, and it wasn’t in the spotlight even three years ago. “I think there is really room for companies to contribute to the health of those ecosystems.”

He pointed to Fastly’s own Fast Forward project, which provides free infrastructure and security services to the Python and Ruby code repositories, as an example of how companies can make in-kind contributions. However, he acknowledged that incorporating such support into corporate workflows remains a challenge.

“It’s not as easy as placing a purchase order with a vendor and budgeting for it,” Shaver explained. “Different kinds of contributions, like weeding through bug reports or helping provide testing and feedback on pre-release versions, are a little harder to work into the mechanics of a lot of companies.”

The core issue, he believes, is that the direct benefits are not always obvious to a company’s leadership. “The link between ecosystem health and sustainable business results has not been as bright and clear as would be helpful for a lot of these maintainers.”

Discussing open source commercialisation models, Shaver noted the decline of some “open core” strategies, where basic functionality is free but enterprise features are paywalled.

“Having to pay extra to be secure can be a bit distasteful,” he said, but more generally it does provide a simple way for organisations to contribute towards the cost of maintaining the commons.

And if competing companies create their own proprietary versions of the same project there is a risk that they will “tribalise” the ecosystem.

A better model, he suggested, is demonstrated by companies like Confluent, which builds enterprise-grade tooling, support and services around the Apache Kafka project. This provides a clear value proposition for large organisations that need a traditional supplier relationship and someone to call when problems arise.