Launched by Linux Foundation and Open Source Security Foundation (OpenSSF) Open source software security mobilization plan. This is in response to attacks on software supply chains and a growing interest in protecting them. Supply chains attract targets to malicious actors because they can compromise on a single point and have a cascading effect across consumer ecosystems, as SolarWinds and Log4j attacks have shown.
Software supply chain security became the focus of US President Joe Biden Cyber ​​Security Executive Order (EO) In 2021. Its “Enhancing Software Supply Chain Security” section seeks input from government, academia, and industry on best practices and guidelines. US National Institute of Standards and Technology (NIST) now Has revealed that information.
Participants in the White House Software Security Summit In early 2022, discussions were held on securing open source software (OSS), improving the ecosystem and accelerating adoption. Materials Software Bill (SBOM). The federal government is using its huge purchasing power to force software vendors to apply to the government to enforce safe development practices and prove compliance with the newly released version of the NIST. Secure Software Development Framework (SSDF).
Open source software security mobilization plans help ensure that the pace of this previous effort does not slow down. Here is the main takeaway for security leaders.
The goal of the open source software security mobilization plan
The plan has three high-level goals:
- Secure OSS production
- Discover weaknesses and improve remedies
- Minimize ecosystem patching response time
There is a stream associated with each goal that describes the strategic action to help achieve it. The plan also emphasizes how widespread the use of OSS is, with about 70% to 90% of software stacks containing OSS components. The plan emphasizes the need for strategic investment to achieve an resilient software supply chain ecosystem.
Secure OSS production
This goal focuses on slowing down the problems of insecure code at the source. Security knowledge needs to be democratized and developers need to be empowered with the knowledge to write secure code from the beginning of the Software Development Lifecycle (SDLC). The plan emphasizes three key actions to achieve this goal:
- Safe development education and certification, either free or affordable. An alternative is emphasized OpenSSF Secure Software is fundamental Providing these options and adopting driving through academia and industry can create more safety-conscious improvements.
- One objective for the top 10,000 OSS components is to create a matrix-based risk assessment dashboard. This will facilitate industry-wide visibility in protecting some of the most commonly used OSS components leaning towards alternatives such as secure scorecards. This can create better industry awareness about the protection of commonly used OSS components. It will also inform vendors who use ingredients in their products as well as lower-end consumers who have started creating software resource inventory by asking software vendors about their SBOMs / SaaSBOM and internal development efforts.
- The speed of digital signature acceptance of software releases. By doing this, those who build and consume software have a level of legitimacy around the OSS components they are using. If you dig into the appendix to the plan, you will see such efforts Sigstore There is an emphasis on Supply chain level for software artifacts (SLSA) And work stress identification and certification, where companies like ChainGuard and TestifySec are generating waves.
After all, like educating many developers, there are other methods that can be taken to completely eliminate vulnerabilities. One point is to replace non-memory secure languages. The most notable example here is moving from C and C ++ to alternatives like Go and Rust.
Discover weaknesses and improve remedies
While efforts by Bug Bounty and the like have helped discover and remedy vulnerabilities in commercial and government off-the-shelf software (COTS / GOTS) environments, the same cannot be said for the OSS ecosystem. OSS maintainers are basically volunteers and unpaid. The plan emphasizes an investment to improve both the detection and remediation of vulnerabilities in complex OSS components and projects.
The initial flow here involves building an OpenSSF Open Source Security Incident Response Team. This team will be funded and will need to address the gaps identified above and help OSS projects address identified vulnerabilities, especially where OSS projects may be understaffed or not equipped to resolve quickly. While this does not eliminate vulnerabilities, it does ensure that they are quickly addressed and that patches / updates are made available more quickly to downstream customers.
Many OSS maintainers lack security tools and guidelines to address vulnerabilities associated with their project. Stream 6 of the plan ensures that security equipment vendors, cloud service providers (CSPs) and other maintainers gain access to the security capabilities as well as access to the infrastructure and tools needed to address vulnerabilities.
Another stream of this goal involves reviewing third-party code on over 200 critical OSS components once a year. It provides secure code skills that are not directly involved in the project to review components to identify vulnerabilities for remediation.
The goal is to streamline the industry’s ability to determine which OSS components are most important. This will involve better data sharing and research collaboration between organizations.
Shorten the ecosystem patching response time
The goal is not only to detect and remedy vulnerabilities at the source of the components, but also to distribute and implement downstream updates connected to the software supply chain. You cannot prevent a vulnerable element from being destroyed unless downstream consumers are properly updated. This is an issue that we still struggle with as an industry when it comes to traditional patch management.
Streams associated with this goal involve adoption, training, and equipment development associated with SBOM. This is important because without the widespread acceptance and effectiveness of SBOM, companies will not be able to understand and respond to the elements they are using in their environment. These include baking it into leading software development tools, improving training and awareness, and normalizing SBOM production and use.
The last stream associated with this goal revolves around strengthening the most important OSS build systems, package managers, and distribution systems. Enhancing security in the software artifact distribution layer can reduce risks across the ecosystem. This will improve confidence in the composition and source of the software components, a key feature of the aforementioned NIST SSDF.
The next step
The Open Source Software Mobilization Plan highlights the key aspects associated with securing software supply chains, the scope of people, processes and technologies, the first of which is undoubtedly the most important of the three. For more details on planning, dig up the appendix and project costs associated with each of the streams discussed above.
While some may criticize the plan, it is a big step in the right direction. That being said, a good plan today is better than a perfect plan for tomorrow, and we can’t wait until tomorrow because corrupt actors today are increasingly exploiting fragmented and fragile software supply chains and we must take action.
Copyright © 2022 IDG Communications, Inc.