Open source software community releases plan to tighten application security

0

Under pressure after the discovery of several open source vulnerabilities, including Log4Shell, major open source groups and software vendors have created a 10-point plan to ensure continuous improvements in the security of open source code.

The plan, released Thursday with encouragement from the White House, includes funding commitments of US$30 million 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 bring about a substantial improvement in the state of open source security,” OpenSSF chief executive Brian Behlendorf told reporters.

“They should be seen as a first draft,” he added, “with specific goals to address these key issues. We will continue to work with stakeholders. Now that it is public, we will also be looking to new participants to continue developing this plan.

The process officially began in January with a meeting at the White House between software companies, US government experts and open source software foundations to find ways to prevent security flaws and vulnerabilities from entering. open source code, improve the discovery and remediation of vulnerabilities, and shorten the response time for the distribution and implementation of patches.

Open source software and components are increasingly used not only in open source applications but also in commercial software. However, many components are created by individual developers working on packages in their spare time. Often, they don’t have the time or the financial incentive to research or respond to reports of vulnerabilities. As a result, some serious bugs can hide in software for years.

Vulnerabilities in the Log4j2 logging library are just the latest example.

The mobilization plan released on Thursday is a series of 10 so-called activity streams proposed to achieve the three objectives set out at the January meeting.

A key goal is to increase the ability of developers to create a software bill of materials (SBOM) for each project so that application users can find and fix code when vulnerabilities are discovered.

“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 create software at each of these points that automates the liquidity of software BOM metadata so that it flows seamlessly.”

Over the past two decades, “we’ve had several instances where a vulnerability in an open-source component presented dramatic risks to a broad spectrum of society,” he said. “Heartbleed in 2014, most recently Log4j2, put us all at risk. We’ve all spent a lot of time fixing these issues. During that time, we’ve systematically tried to help the hundreds of thousands of open source developers that exist and leaders responsible for critical components of the open source supply chain to help improve baseline security Today is one of the first times I’ve seen an action plan with goals concrete, but [also] most important is the industry’s willingness to provide this assistance in a meaningful way.

“The urgency here couldn’t be greater,” added Zemlin. “The adversaries are more and more sophisticated. Supply chain attacks are happening more often and cyber conflicts are intensifying around the world.

Although there are commitments of $30 million to help fund the streams, the creators of the plan believe it will take $150 million to meet the goals.

Briefly, the flows are:

  • provide basic training and certification in secure software development by improving training materials so that 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 all 10,000 open source software components;
  • accelerate the adoption of digital signatures on software releases so that developers and end users can verify that the components they use have not been compromised;
  • eliminate the root causes of many vulnerabilities by replacing in-memory insecure languages ​​like C and C++ with languages ​​like Go and Rust;
  • establish the Open Source OpenSSF Security Incident Response Team, possibly up to 40 experts who would help developers respond to a vulnerability. They might work full time for several days or weeks to help fix serious bugs;
  • Accelerate discovery of new vulnerabilities by maintainers and experts with advanced security tools and expert guidance;
  • perform third-party code reviews and any necessary remediation work on up to 200 of the most critical open source software components once a year;
  • coordinate industry-wide data sharing to improve 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 determine the content of the applications they use and measure risk if vulnerabilities are discovered;
  • Improve the 10 most critical open source software building systems, package managers, and distribution systems with better supply chain security tools and best practices.

One problem, some experts say, is that developers of small but critical free open source projects they’ve created in their spare time don’t have the financial incentive to spend more time finding bugs and releasing them. of fixes. “There is no simple solution,” Zemlin said. One possibility is that employers give these developers time during their day job to fix their projects. But some cases, funding direct to developers to maintain critical projects should be considered, he said.

Share.

Comments are closed.