In this Help Net Security interview, we meet a prominent industry leader. Brian Behlendorf, CTO at the Open Source Security Foundation (OpenSSF), shares insights on the influence of his experiences with the White House CTO office, World Economic Forum, and Linux Foundation on leading the OpenSSF and addressing open-source security challenges.
Behlendorf discusses the trajectory of open-source software adoption, the unique challenges it faces regarding security, and how the OpenSSF is working to address these issues. Additionally, he highlights the role of automated tooling, best practices, and collaborative efforts with developers, auditors, and regulators in securing open-source supply chains.
How do your experiences with the White House CTO office, World Economic Forum, and Linux Foundation influence your approach to leading the OpenSSF and addressing open-source security challenges?
Throughout my career, I’ve been focused on reconciling the unique dynamics that drive open-source software development and other open technology endeavors with mainstream adoption and systematic integration. Trying to view the present day from where I was in 1994, it’s simply mind-blowing that modern society runs so thoroughly on open-source code, depending on a combination of enlightened self-interest and hard-nosed capitalism to drive a virtuous circle like a two-stroke engine.
There were more than a few of us idealistic mid-90s nerds who subsequently landed fortuitously in roles where we could fight for that adoption. But with ubiquity comes a whole new host of challenges – now failures are more expensive, now the critical infrastructure depends upon a gift economy. So, now the business heads and policymakers have moved on from asking, “Can we use this?” to “Can we trust this?” to “How do we manage the risk?” I watched that trajectory unfold up close at the White House, at the World Economic Forum, and now among the companies, governments, and other organizations at the Open Source Security Foundation.
In particular, the public sector has a unique role at every stage of that trajectory, from at first allowing its use by government systems; to seeing the advantages of using it from a first-principles perspective. Now, at the “how do we manage the risk?” stage, governments of all sorts are asking what can be done when systemic issues in the way software is written, built, and shipped can lead to widespread crises like Solarwinds; or the way a single and rather simple bug in Log4j can lead to such a disruptive process for upgrading to address it.
A combination of better software supply chain tools, better processes, developer security education, and when the time is right government regulation and government incentives can lead us to a place where those kinds of issues are much less frequent, where our software systems are more secure by default. Making those all come together at the right time is something we’re spending a lot of time on at the OpenSSF.
What unique challenges does open-source software face regarding security, and how does OpenSSF address them?
Like all software projects, open source software projects are never over-staffed; they are volunteers (many “volunteered” by their employers, of course) struggling not just to write the functionality they need but also to fix the bugs they and others find, paying down technical debt and implementing better security practices and tools often fall way behind in priority compared to new feature work and bug-fixing.
But what’s different about open source software is the availability of source code, the “right to fork,” and the transparency in the development process. By making the code available and everything involved in building software more visible, the recipients of code have more power and more freedom to dial up the security of their applications. But there aren’t a lot of great tools for assessing when one OSS project is more secure than another.
That’s why many brilliant people came together to create the Security Scorecard project at the OpenSSF – it’s a toolkit for automatically assigning a risk score between 0 and 9 for an open-source project based on many project characteristics. We also have the OpenSSF Badge, the security reports database, and other projects that work together to help consumers of OSS assess risk of the code they choose for their dependencies. We hope this will incentivize developers and their managers to prioritize security work, and understand where such work can have the greatest impact.
From another perspective, OSS development (like all software development, frankly) grew up in a time when the Internet was smaller, when we used many fewer dependencies when we ran build scripts that could ignore the prospect of Man-In-The-Middle attacks, social hacks, typosquatting, or other kinds of treachery that the modern software supply chain now requires us to guard against. Now we have tools like Sigstore to verify signatures on packages by their developers; and SLSA, a specification for understanding and verifying the build quality of components in the supply chain. These are but two of many examples of OpenSSF efforts to address these weaknesses.
Our efforts make the whole software world more secure, not just open-source code. We are seeing software teams using these standards and tools for their internal applications and others for proprietary software that build on top of OSS.
Can you elaborate on the role of automated tooling and best practices in securing open-source supply chains?
Automated tooling is an important part of securing open source at scale, by reducing the burden on developers by automating secure practices and making them easier to use. They play an important role in securing the OSS ecosystem by helping secure a large number of projects without overburdening open source maintainers. Some efforts in this vein we’re working on at the OpenSSF include the Security Tooling Working Group and the Omega toolchain as part of the Alpha-Omega project.
Best practices, on the other hand, provides members of the open source ecosystem with recommendations on how to work with open source, as well as an easy way to learn and apply them. They help strengthen the OSS ecosystem by encouraging the adoption of practices that enhance security and sustainability. The OpenSSF Best Practices Working Group provides best practices for open source developers, which includes efforts such as guides on developing and evaluating secure software, automating analysis of open source projects using OpenSSF Scorecard, and efforts on integrating secure software development practices into educational materials.
In what ways does OpenSSF work with developers, auditors, and regulators to create and distribute security policies?
The OpenSSF works with developers and members of the open source community through our working groups. Each of our working groups is available to the public to join, and we actively welcome participation from open source developers and other members of the community to help shape the working groups’ vision and priorities.
The OpenSSF also continues to engage with policymakers and regulators, from our work with the Open Source Software Security Mobilization Plan to our recent fireside chat on how government and the open source community can work together at OpenSSF Day North America.
Can you provide examples of some significant cross-cutting initiatives and projects that OpenSSF has successfully undertaken to impact the open-source ecosystem positively?
One initiative is the Open Source Software Security Mobilization Plan, an effort we launched in May 2022 to help organize and make concrete efforts that can sustain and secure the open source ecosystem for the long run. This plan has led to $30M in industry commitments around the vision and initiatives outlined in this plan.
Another of our efforts is Alpha-Omega, an initiative to improve the security of open source software through direct maintainer engagement and expert analysis. This project has invested in large, critical open source projects including Node.js, jQuery, Rust, Python, and Eclipse, and built the Omega toolchain to identify widely deployed projects and remediate vulnerabilities at scale.