Under pressure after the discovery of several open source vulnerabilities including Log4Shell, leading open-source groups and software firms have created a 10-point plan for ensuring ongoing improvements in the security of open-source code.
The plan, released Thursday with the encouragement of the White House, includes commitments of US$30 million in funding from Amazon, Google, Intel, Microsoft, and VMware. It was announced by senior members of the Linux Foundation and the Open Source Security Foundation (OpenSSF).
The plan “represents a collective effort against 10 different targets where meaningful work can be applied to make a substantial improvement in the state of open source security,” Brian Behlendorf, general manager of the OpenSSF told reporters.
“They should be viewed as a first draft,” he added, “with some specific goals to addressing those key problems. We will continue to work with stakeholders. Now that it’s public we will also be looking for new participants in further development of that plan.”
The process officially started in January with a meeting at the White House between software companies, U.S. government experts, and open-source software foundations to find ways of preventing security defects and vulnerabilities from getting into open source code, improving vulnerability discovery and remediation, and shorten the response time for distributing and implementing fixes.
Open-source software and components have become increasingly used not only in open source applications but also in commercial software. However, many components are created by individual developers working on packages on their own time. Often they don’t have the time, or the financial incentive, to look for or respond to reports of vulnerabilities. As a result some serious bugs can lurk in software for years.
The vulnerabilities in the Log4j2 logging library are only the latest example.
The Mobilization Plan released Thursday is a series of 10 so-called activity streams proposed to meet the three goals set out in the January meeting.
One vital target is to increase the ability of developers to create a software bill of materials (SBOM) for every project so application users can find and patch code when vulnerabilities are found.
“Software goes from a developer’s mind to a version control system to a package manager to a build system to a consumer,” said Jim Zemlin, executive director of the Linux Foundation. “The important thing is to build software at every one of those points that automates the liquidity of software bill of material metadata so that it seemlessly flows.”
In the past two decades “we’ve had multiple cases where a vulnerability in an open source component has posted dramatic risks to a broad set of society,” he said. “Heartbleed in 2014, most recently Log4j2, put us all at risk. We all spent a lot of time remediating these things. In that period we have systematically tried to get help to the hundreds of thousands of open-source developers who are out there and to leaders who are responsible for critical components in the open-source supply chain to help improve the baseline of security. Today is one of the first times I’ve seen an actionable plan with concrete goals, but [also] most importantly an industry will to offer that help in a meaningful way.
“The urgency here could not be greater,” Zemlin added. “Adversaries are getting more sophisticated. Supply chain attacks are happening more often and cyber conflict is escalating around the world.”
While there are commitments for US$30 million to help fund the streams, plan creators think it will take US$150 million to achieve the targets.
Briefly, the streams are:
- to deliver baseline secure software development education and certification by improving training materials so they can be considered an industry standard and used in courses and certifications;
- establish a public, vendor-neutral, objective, metrics-based risk assessment dashboard for the up to 10,000 open-source software components;
- accelerate the adoption of digital signatures on software releases so developers and end-users can verify the components they use haven’t been compromised;
- eliminate root causes of many vulnerabilities through replacement of non-memory-safe languages like C and C++ with languages like Go and Rust;
- establish the OpenSSF Open Source Security Incident Response Team, perhaps up to 40 experts who would assist developers when responding to a vulnerability. They could work full time for a number of days or weeks to help fix serious bugs;
- accelerate the discovery of new vulnerabilities by maintainers and experts through advanced security tools and expert guidance;
- conduct third-party code reviews, and any necessary remediation work, of up to 200 of the most critical open-source software components once a year;
- co-ordinate industry-wide data sharing to improve the research that helps determine the most critical open-source software components;
- improve software bill of materials (SBOM) tooling and training to encourage its use everywhere. A software bill of materials would help IT departments figure out what is in the applications they use and measure the risks if vulnerabilities are found;
- enhance the 10 most critical open-source software build systems, package managers, and distribution systems with better supply chain security tools and best practices.
One problem, say some experts, is that developers of small but critical free open source projects they created in their spare time don’t have the financial incentive to spend extra time on finding bugs and issuing fixes. “There’s no simple solution,” said Zemlin. One possibility is for employers to give these developers time during their day jobs to fix their projects. But some cases direct funding to developers to maintain critical projects should be looked at, he said.