Global CISOs, White House, agree 10-point open source security plan
All hands on deck, as Linux Foundation, Open SSF convene meeting
White House officials, The Linux Foundation, OpenSSF and CISOs and other senior leaders from 37 private sector technology companies ranging from Dell to GitHub, JPMorgan to Intel, to have announced a 10-point open source and software supply chain mobilisation plan and $150 million of funding over two years -- as along with key security agencies they agreed key actions to improve the resilience and security of open source software.
The project has three key priorities: 1) Securing OSS production. 2) Improving vulnerability discovery and remediation. 3) Shortening ecosystem response time for distributing and implementing open source security fixes.
The Open Source Software Security Summit II this week was a rapid follow-up to the first Summit held January 13, 2022 that was led by the White House’s National Security Council (NSC); the speed at which participants have agreed the comprehensive plan emphasises the extent to which concerns about malicious attacks on the upstream software supply chain have reached the highest levels of goverment and the private sector.
(According to Sonatype data, 70-90% of any software “stack” consists of open source software.)
See also: Security researcher breaches Apple, Google, Microsoft in a major industry wake-up call, after compromising upstream software packages.
OWASP Founder Mark Curphey and pioneering software security author John Viega, are coordinating the plan's 10 streams. They said: “We’re excited to see the industry’s willingness to come together on a single ‘bill of materials’ format. It has the potential to help the entire industry solve many important problems, including drastically improving response speed for when major new issues in open source software emerge.”
Brian Fox, CTO of Sonatype and steward of Maven Central (a free store for software artifacts like libraries, binaries et al for Maven, a build automation tool used primarily for Java projects) added: “It’s rare to see vendors, competitors, government, and diverse open source ecosystems all come together like they have [this week].
"It shows how massive a problem we have to solve in securing open source, and highlights that no one entity can solve it alone. The Open Source Software Security Mobilization Plan is a great step toward bringing our community together with a number of key tactics, starting with securing OSS production" he added on May 12.
So what does the 10-point open source software security mobilization plan look set out?
Digested: The Open Source Software Security Mobilization Plan
Stream 1 -- Baseline education and certification
It's rate to find developers who have been formally trained to write software securely. The Open Source Software Security Mobilization Plan plan aims to bring a team together to "iterate and improve" training modules like the OpenSSF Secure Software Fundamentals, then partner with academies, industry.
Stream 2 -- Risk assessment dashboard for 10,000 OSS components.
This will see participants create a "public, vendor-neutral, objective-metrics-based risk assessment dashboard" for 10,000+ top open source components, and track vulnerabilities in dependencies via software composition analysis (SCA), to understand how a bug in an upstream component affects others for "situational awareness".
Stream 3 -- Accelerate adoption of digital signatures
Digital signatures help software builders and use confirm that the components that they use are kosher. This stream will aim to "drive improvement of the existing signing tools and infrastructure and encourage adoption by open source projects". The ultimate aim is to get 50 of the top 200 projects and 1000 of the top 10,000 projects using an interoperable software signing approach. Kubernetes is now using the Linux Foundation's Sigstore for this and its creators called on the software industry to standardize on on the open source signing protocol.
Stream 4 -- Phase out non-memory-safe languages
C and C++ are among the languages with memory safety issues; making it to detect and eliminate software defects. (Some 70% of Microsoft’s vulnerabilities in 2006-2018 were due to memory safety issues; 70% also for Chome vulnerabilities in 2020). This stream will see participants identify critical open source components that are "good candidates for being rewritten in a memory-safe language" like Go, or Rust.
Stream 5 -- Build an Open Source Security Incident Response Team to help maintainers
As the famous XKCD cartoon on your left notes, a lot of critical infrastructure is built on the wobbly and tired foundations of some thankless upstream OSS maintainer. The Open Source Software Security Mobilization Plan, recognising this, emphasises that the "maintainer community can be overwhelmed by the enormity and complexity of dealing with a serious security notification they’ve been served" -- and proposes to create a stable of up to 40 security experts who can be accessible on very short notice to tackle security notifications. (The coordinators aim to allocate $2.75 million for this in the first year.)
Stream 6 -- Advanced security tools
This stream will bring together "major source code repository hosts, security tool vendors, cloud platform providers and OSS maintainers to provision scanning and monitoring tools in a vendor-neutral uniform platform" -- to help identify and validate vulnerabilities and fixes. (Often software composition, static analysis, fuzzing etc. tools can get expensive for OSS communities.)
Stream 7 -- Annual third-party code reviews for 200 critical components
One of the most expensive streams, with $42 million per year allocated to it from year one, this proposes annual third-party code reviews and associated remediation work of the most critical OSS software. Contracted parties will be responsible for finding "yet-undiscovered high-impact vulnerabilities; improve developer, industry, and public sector confidence in critical software projects; set high standards for audit quality; remediate the vulnerabilities found, and report to the public all of the associated findings". This stream aims to cover 50 of the most critical projects in the first year, and cover the top 200 in years two and beyond, the open source security report says.
Stream 8 -- Data sharing on what software actually IS critical
A lot of data on open source component use is proprietary. Recent efforts by the Linux Foundation/Harvard Census have started to tackle that but more work needs to be done. This stream will help deliver a "metrics-driven approach to understanding global OSS usage and risk": i.e. identifying what IS really critical upstream OSS.
Stream 9 -- More Software Bills of Materials (SBOMs)
This stream aims to help the OSS world "remove the barriers to generation, consumption, and overall adoption of “Software Bill of Materials” (SBOM) use. Software companies like Docker have been working to make it easier to use commands that pull up an SBOM for a given bit of software and the stream aims for more.
See: Docker launches CLI command to pull a Software Bill of Materials
It promises, in short, to start "resourcing a team of developers to improve that tooling and bake it into the most popular software build tooling and infrastructure across all major programming languages."
Critically, it will provision a team at the cost of $3m to work directly with "critical projects to submit improvements directly to add SBOM support, removing last-mile barriers or resistance due to inertia."
Stream 10 -- Understanding build system, package risk management
Open source software is built, the report emphasises, using a range of language-specific build systems before being distributed to end users via package managers. This means wildly different levels of quality and risk permeate through the software supply chain as components from different ecosystems come together in a production environment: that makes unified risk management and mitigation something of a living nightmare.
This stream aims, at an annual cost of $8.1 million to "examine the most impactful security enhancements we can make to the distribution of those software artifacts; driving improvements at the package manager level to complement other streams focused on component level security and ecosystem risk."
Eric Brewer, VP of Infrastructure at Google Cloud and Google Fellow, noted: "“We’re thankful to the Linux Foundation and OpenSSF for convening the community to discuss the open source software security challenges we’re facing and how we can work together across the public and private sectors to address them... Security risks will continue to span all software companies and open source projects and only an industry-wide commitment involving a global community of developers, governments and businesses can make real progress."
