Here is a run-down of the 10 streams from OpenSSF's Open Source Software Security Mobilization Plan.
Industries are fond of launching initiatives that make a big splash on day one, but often peter out shortly thereafter. That doesn't seem to be the case with the Open Software Security Foundation (OpenSSF)'s plan to overhaul software supply chain security. Not only has the foundation done a remarkable job of herding support for its Open Source Software Security Mobilization Plan, but it has also received commitments from some weighty industry players to pledge some big bucks to get its plan rolling.
"What impresses me most so far about this nascent open source software security plan effort is that it brings together a long list of major U.S. technology companies and their executives who collaborated and proposed strategies to get this effort to the starting line," Todd R. Weiss, an analyst at Futurum, wrote for the publication Converge.
"This is a big deal. When an organization can gain broad consensus from a large and diverse number of players and organizational needs."
—Todd R. Weiss
Pieter Danhieux, co-founder and CEO of Secure Code Warrior, called the plan "ambitious, bold, and exactly what is needed to drive developer responsibility for security." Writing for Software Developer Times, he observed,
"It took a 'Rebel Alliance' of some powerful players coming together, but this serves as proof that we are heading in the right direction and leaving behind the idea that the cybersecurity skills gap will magically fix itself."
—Pieter Danhieux
$30 million is not enough
At the announcement of the plan, companies backing it pledged $30 million, including $10 million from Amazon Web Services and $5 million from Microsoft. "Open source software is core to nearly every company's technology strategy. Collaboration and investment across the open source ecosystem will strengthen and sustain security for everyone," Microsoft Azure CTO Mark Russinovich said in a statement.
Intel, too, pledged to up its ante in efforts to secure open source software. "Intel has invested over $250 million in advancing open-source software security. As we approach the next phase of Open Ecosystem initiatives, we intend to maintain and grow this commitment by double-digit percentages," Intel Vice President for Software and Advanced Technology Melissa Evers said in a statement.
The $30 million pledged by the companies will just be the start for the first-of-its-kind initiative aimed at securing the production of open source code, improving vulnerability detection and remediation, and shortening patching response time. OpenSSF's executive director, Brian Behlendorf, said the foundation will need $150 million to fund the 10 "streams" it's proposing in the plan. "30 is not 150, but we have lots of continuing conversations with other types of organizations to contribute to [the plan]," he explained during a podcast recorded at the Open Source Summit, held in Austin, Texas, in June.
"Each of those 10 would have a tremendous combined impact. I think we'd make a serious dent in some of the instability that happens through a lack of security in open source code."
—Brian Behlendorf
Here's whats inside OpenSSF's open source software security mobilization plan.
1. Deliver baseline secure software development education and certification to all
This stream calls for a multi-pronged approach to addressing a historical problem with software development: developers aren't trained to code securely. "They highlight the issues we have discussed for some time, including the fact that secure coding is MIA from most software engineering courses at the tertiary level," Danhieux said of the education stream.
"It is incredibly encouraging to see this supported by individuals and departments that can shift the industry status quo," he continued, "and with 99% of the world’s software containing at least some open-source code, this realm of development is a great place to start focusing on developer training in security."
"Remember when O'Reilly books were the signal that an open source project had arrived?" Behlendorf asked during the OSS podcast. "There's still some of that, but the new signal is there's a course for it and I can certify to my employer that I know what I'm talking about."
2. Establish a public, vendor-neutral, objective-metrics-based risk assessment dashboard
According to the plan, the lack of a standardized risk assessment and monitoring solution in the open source software supply chain creates cyclical problems for various stakeholders. To address that, the plan proposes developing metrics for activities—code adoption, contributor growth and retention, organizational engagement, and downstream dependencies—and for vulnerabilities and best practices.
Among the companies pledging resources to this aspect of the plan is Dell. "Dell's best and brightest engineers will engage with peers to develop risk-based metrics and scoring dashboards, digital signature methodologies for code signing, and Software Bill of Materials (SBoM) tools—all to address the grand challenge of open-source software security," the company's CTO John Roese said in a statement.
3. Use digital signatures to deliver enhanced trust to the software supply chain
Digital signatures, when used or verified at all in the software supply chain, often only cover the “last mile” or use a variety of approaches that are difficult to automate and audit, the plan explained. Digital signatures for software distribution must be addressed end-to-end—from original developer and development teams all the way to the end user and end device—to address a range of attack vectors increasingly being deployed, it continued. They must be easy for developers to apply and users to verify.
4. Eliminate vulnerability root causes by replacing non-memory-safe languages
The plan noted that it is common for vulnerabilities to result from a program mismanaging memory. These types of vulnerabilities are called memory safety vulnerabilities. Such vulnerabilities exist because certain unsafe languages, mainly C and C++, allow programmers to easily make memory management mistakes.
Unlike many other types of vulnerabilities, it continued, it's known how to entirely rid ourselves of memory safety vulnerabilities, not just mitigate them. By moving software away from C and C++ to safer languages, memory safety vulnerabilities, which account for a huge percentage of all vulnerabilities, can be eliminated. According to Microsoft, 70% of vulnerabilities in their products over the past decade are memory safety vulnerabilities, while Google pegs that number at 90% of vulnerabilities in Android. The percentages are similar in open source software, the plan noted.
5. Establish the OpenSSF Open Source Security Incident Response Team
When a world-altering critical open-source software vulnerability like Heartbleed or Log4Shell occurs, open-source maintainers need to make quick decisions that can dramatically impact the cybersecurity posture of entire industries. What the OpenSSF is proposing is the creation of an open source security incident response team (OSSSIRT), a coordinated group of experts from across the industry who will be available to help open source maintainers with all aspects of remediating high-impact security vulnerabilities and related security emergencies.
6. Accelerate discovery, remediation, and coordinated disclosure of new vulnerabilities by maintainers and experts
The number of vulnerabilities in open source software is dramatically increasing, driven in part by the increasing velocity of software development, the plan explained. According to NIST, some 6,000 new vulnerabilities were discovered in 2016. That more than tripled in five years, to 22,000, and the OpenSSF says 2022 is on a pace to match or eclipse 2021.
The OpenSSF proposes an open, multi-forked approach to addressing this serious issue by increasing the use of software scanning and analysis tools—SAST, DAST, fuzzing, and so forth—by open source developers. Those tools will be provided to OSS maintainers via a centralized managed service manned by security experts who will engage with the maintainers , as well as systematically monitor the OSS code landscape for classes of vulnerabilities as they emerge as threat vectors. They will also work with the maintainers to improve the state of coordinated vulnerability disclosure.
7. Conduct third-party code reviews — and any necessary remediation work — of up to 200 of the most-critical OSS components once a year
Technical tools used to find vulnerabilities are unable to find some of the most critical and complex bugs. Those bugs need human experts to expose them, the plan explained. As a result, code that has not been reviewed carefully by an expert in secure code review generally contains security flaws which, if found and exploited by threat actors, could cause significant damage to enterprises and national security.
What the plan proposes is an industry-wide, coordinated effort, led by OpenSSF, to manage and facilitate third-party code reviews and associated remediation of critical vulnerabilities in OSS software. Reputable third-party security firms will perform code review and security auditing of critical open source projects and publish a public report of the findings from each audit.
8. Coordinate industry-wide data sharing to improve the research that helps determine the most critical OSS components
A major challenge to objectively determining which open source software is actually “critical” is that usage, download, and dependency data is often considered a proprietary advantage by the software distribution channels that are able to collect that data. A better list of critical open source software could be derived if concerns about sharing secret information can be addressed. The plan proposes to create a multilateral framework and agreement with a small number of organizations willing to pool their anonymized data at a neutral home for access to academic and commercial researchers, under the strict condition that the information can only be used to address the matter of identifying highly popular but under-maintained open source software.
9. SBOM everywhere — improve SBOM tooling and training to drive adoption
An SBOM is a list of the software components in a software system. It is typically maintained as an inventory list that enables developers and organizations to effectively and efficiently evaluate risk management use cases such as vulnerability analysis. However, SBOMs are not yet widely generated or consumed in the software industry. By enabling SBOMs everywhere, the plan maintains, it can improve the security posture of the entire open source ecosystem.
"The plan has a brilliant strategy to define key standards for SBOM creation, as well as tooling for ease of creation that fits with how developers work.These alone would go a long way in decreasing the burden of yet another SDLC task for developers who are already spinning a lot of plates to create software at the speed of demand."
—Pieter Danhieux
10. Enhance the 10 most critical OSS build systems, package managers, and distribution systems with better supply chain security tools and best practices
Open source software is built using a range of language-specific build systems before being distributed to end users via package managers, the plan explained. 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, making efforts to place unified policies around risk management and mitigation very challenging.
What the plan proposes to address that situation is to examine the most impactful security enhancements that can be made 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.
Longer term, the plan maintains, packaging and distribution improvements around composition and provenance data should support shortened patch time through faster detection and remediation, improved transparency of vulnerabilities and patches to downstream users, and better security tooling for all developers.
10 flags in the ground
Weiss called the plan an important step toward finding credible, reliable, and repeatable processes that can make software creation and use safer from cyberattacks and cybercriminals. "Absolute security is never possible but attacking security challenges using every means is a smart strategy in the constant battle against hackers," Weiss wrote. "By developing this mobilization plan and fully integrating it, the U.S. will be in a better position to defend its infrastructure against cyberattacks in the future."
“What we are doing here together is converging a set of ideas and principles of what is broken out there and what we can do to fix it. The plan we have put together represents the 10 flags in the ground as the base for getting started. We are eager to get further input and commitments that move us from plan to action.”
—Brian Behlendorf
All Stories
Software Supply Chain Security
Dev & DevSecOps
CI/CD Security
Container Security