The Log4j vulnerability crisis that erupted in late-2021 heightened the security world’s awareness of supply chain risks in free and universally deployed open-source software. Following an intense holiday season push by admins and cybersecurity professionals to track and remediate the Log4j flaw, the White House held a meeting of industry leaders to discuss improving open source software security.
In a sign that the tech sector is stepping up efforts, the Linux Foundation and the Open Source Security Foundation (OpenSSF) have announced the Alpha-Omega Project. Backed by $5 million in initial funding from Microsoft and Google, the project seeks to improve software supply chain security for 10,000 open-source software projects by systematically looking for undiscovered vulnerabilities in open-source code and then working with project maintainers to get them fixed.
Alpha will target critical projects; Omega will identify flaws in 10,000 projects
The Alpha part of the project will target and evaluate the most critical open-source projects to help organizations improve their security postures. The projects will be selected based on the work by the OpenSSF Securing Critical Projects working group using a combination of expert opinions and data, including the OpenSSF Criticality Score and Harvard’s “Census” analysis identifying critical open source software.
For those projects, Alpha team members, initially composed of paid professionals funded under the initiative, will provide tailored help so that organizations can understand and address security gaps. That help can consist of, for example, threat modeling, automated security testing, source-code audits, and support with remediating vulnerabilities that are discovered.
The Alpha team will also track a series of important metrics providing stakeholders with a better understanding of the security of the open-source project they depend on. The team will further issue a transparent, standardized view of the project’s security posture and compliance with security best practices.
The Omega part of the initiative will use automated methods and tools to identify critical security vulnerabilities across at least 10,000 widely deployed open source projects using a combination of people, technology and processes. Omega will have a dedicated team of software engineers continually tuning the analysis pipeline to reduce false-positive rates and identify new vulnerabilities. Although both Alpha and Omega will launch with paid staff members, the initiative hopes to leverage a broader constituency of volunteers ultimately.
Initiative aims to fill a gap
Brian Behlendorf, general manager of the OpenSSF, tells CSO, “We realized that there was a gap when it comes to a set of needs, which I think really came to the fore with the call a few weeks ago with the White House.” Although motivated by Log 4j, “The meeting thought to ask these deeper questions about how is it that the open-source community writes code and where are useful places for support for better interventions to help mitigate the chances of a future Log4j. Then once they happen, how do you respond to them in a more graceful manner?”
“To meet the needs [of the spectrum of open-source software security projects], there are two things you need,” Behlendorf says. “You need better tooling and better automation to try not just to determine the security posture of a large number of projects en masse, but also to ask questions, to try to discover new facts about those projects.”
Secondly, “You can’t just roll in with a 300-page ‘thou shalt’ kind of like white paper on how everyone needs to run their open-source projects because every open-source project is different.” Behlendorf says a more hands-on approach is required. “You need to walk in and say: Have you done threat modeling? And here’s how you might think about it.”
A human approach to securing open source
Michael Scovetta, principal security project manager at Microsoft, highlights the importance of a human approach in the Alpha-Omega process. He tells CSO that having people engaged on a highly collaborative basis is an essential component of the Alpha projects, the most critical ones.
“What Omega definitely is not is a machine that runs tools and then throws findings back to the open-source developer,” he says. In a much lighter touch way, “what the open-source developer for an Omega project would receive from us is we would engage them only when we find a critical vulnerability that needs their attention, and we would be there to help them to some extent in remediating it.”
Michael Winser, group product manager at Google, says that an essential outcome of the initiative, aside from fixing open-source software flaws, is the element of education that comes along with those fixes. “One of those sorts of meta outcomes is we’re learning how to do this,” he tells CSO. “The industry as a whole is still figuring out how to have a proper security stance. We’re going to start scaling our approach and learning from that scaling and working with other parts of the OpenSSF, other groups and foundations, and open-source maintainers to understand how we can essentially lift everybody up a few inches at a time to make our security better industry-wide.”
SBOMs are vital drivers of open-source software security
Separate from the announcement of the Alpha-Omega initiative, the Linux Foundation has released a report entitled Software Bill of Materials (SBOM) and Cybersecurity Readiness, which addresses the relationship between open-source maturity and SBOM readiness. Based on a survey of 412 organizations worldwide, the report finds that 98% of the organizations surveyed say they use open-source software.
More importantly, the report finds that SBOM innovators are more likely to use open-source software without conditions, not because they are most risk-prone but because “they simply have a more comprehensive and sophisticated culture around the use of open-source software.”
Stephen Hendricks, vice president of research at the Linux Foundation, tells CSO that 66% of the organizations surveyed said that SBOMs are equally important to open-source software as closed-source software, while 20% said SBOMs are more important for open source.
“The reality here is that you’ve got two-thirds of the organizations saying SBOMs are important whether they are open source or not,” Hendricks says. “Everybody wants to know what the bill of materials is; everybody wants to know about vulnerabilities. There is a lot of open-source software that goes into closed-source software, and with pretty much every organization using open source, it’s important to get open source right, but it’s important to get all software right.”
Open-source security is critical to overall cybersecurity
The Alpha-Omega project and the Linux Foundation survey underscore the growing refrain among industry practitioners that getting open-source software security right is a critical driver of overall cybersecurity. Speaking at the inaugural Secure Software Summit held last week, Dan Lorenc, founder and CEO of Chainguard, said, “Open-source software is part of everyone’s supply chain, whether they know it or not. So, understanding the security of open-source software is pretty critical to understanding the broader supply chain security problems that we’re facing.”
Abhishek Arya, principal engineer and manager of Google’s Open Source Security Team, said, “As new vulnerabilities come in, we need to understand these security risks and be better prepared to handle them. We need to understand that open-source software is not free. It looks so, but it comes at a massive security cost. Much of open-source software is developed by volunteers in their free time where security often comes last in their priority list.”
Rob Tompkins of the Apache Software Foundation stressed the need to preempt future Log4j-type security issues with more secure production practices: “First things first, remediate your production environment. Fix your production software, please, please, please. I can’t stress it enough.”
Copyright © 2022 IDG Communications, Inc.
