In October, the OSI hosted the State of the Source Track at All Things Open designed to connect developers with the big policy conversations shaping our ecosystem. Katie Steen-James, Jeremy Stanley, Barry Peddycord III, and Bob Callaway led the panel Policy: Cybersecurity, with updates on SBOMs, the Cyber Resilience Act, and what developers need to know.

Policy: Cybersecurity

Panelists: Jeremy Stanley (OpenInfra Foundation), Barry Peddycord III (SAS), Bob Callaway (Google) Moderator: Katie Steen-James (Open Source Initiative)

Security of Open Source software is a constant topic of conversation with policymakers as they work to understand how Open Source fits into the supply chain and broader cybersecurity efforts. It’s important that practitioner voices are heard in these policy discussions. This session will provide practitioners and other interested parties with information about the current policy landscape as it relates to Open Source and cybersecurity. Participants will hear the latest updates focusing on the US and EU / UK and learn about opportunities for community participation and feedback in forthcoming cybersecurity policy discussions. Specific topics will include: Software Bill of Materials, Encryption, the EU’s Cyber Resilience Act, and more.

Video summary

Introductions

Katie Steen-James:** ** Good afternoon, everyone, and thanks for joining us for our session on cybersecurity and policy. I’m Katie Steen-James, Senior U.S. Policy Manager at the Open Source Initiative. I’m joined by three experts in cybersecurity who bring a mix of industry, open source, and policy experience.

We’ll start with brief introductions, then I’ll ask a few questions to draw on their expertise and connect it to current policy developments. We’ll also leave time at the end for audience questions.

Bob Callaway:** ** I’m Bob Callaway, and I lead Google’s Open Source Security Team. We’re a global team of about sixty people contributing to a variety of upstream ecosystems. Our goal is to improve overall software security while reducing the burden on maintainers.

I also serve on the governing board and technical advisory committee for the OpenSSF—the Open Source Security Foundation—where we partner with other foundations and communities to make open source security more sustainable.

Barry Peddycord III:** ** I’m Barry Peddycord, and I work in the Open Source Program Office at SAS. My focus is on cybersecurity and compliance in our use of open source software. As we integrate open source components into our products, I help ensure we meet our security and legal responsibilities.

Jeremy Stanley:** ** I’m Jeremy Stanley from the Open Infrastructure Foundation. I’m a long-time systems administrator and serve as a vulnerability manager for the OpenStack project. I’m also involved in the Eclipse Foundation’s Open Regulatory Compliance Working Group, which focuses on how regulations like the EU’s Cyber Resilience Act affect open source.

---

Cyber Resilience Act (CRA)

Katie Steen-James**: ** Jeremy, can you tell us more about your work in the Open Regulatory Compliance Working Group and how it relates to the Cyber Resilience Act?

Jeremy Stanley:** ** Sure. Early drafts of the CRA were concerning because they didn’t make distinctions between commercial software and community-driven open source. Fortunately, later drafts incorporated feedback from the open source community.

The Eclipse Foundation formed the Open Regulatory Compliance Working Group to provide structured input to the European Commission. The group includes both industry and nonprofit representatives and now focuses on helping standards bodies understand open source.

Currently, we’re working to ensure open source perspectives are represented as these “harmonized standards” are developed. Historically, standards organizations haven’t fully understood how open source operates, so that’s a big part of our challenge right now.

---

Software Bills of Materials (SBOMs)

Katie Steen-James**: ** Barry, you have deep experience with Software Bills of Materials—SBOMs. Can you explain what they are and how you use them at SAS?

Barry Peddycord III:** ** Absolutely. A Software Bill of Materials, or SBOM, is essentially an inventory of all components—especially dependencies—used in a software product. It includes details like version numbers, origins, and licenses.

For SAS, which develops and sells technology products, SBOMs help us demonstrate to clients that we’re following security best practices and tracking our dependencies responsibly. They’ve also become a key part of procurement: customers increasingly expect them as part of due diligence.

SBOMs enhance transparency, making it easier to manage vulnerabilities and respond quickly when issues arise.

---

OpenSSF and the Alpha-Omega Project

Katie Steen-James**: ** Bob, can you tell us about your work with the OpenSSF and the Alpha-Omega project?

Bob Callaway:** ** The OpenSSF brings together people passionate about improving open source security. We focus on several areas—education, tooling, and best practices. Education is foundational: helping developers understand basic security hygiene and how to build secure software from the start.

We also develop tools that make secure practices easier to adopt and maintain. For example, we support projects that simplify vulnerability scanning, SBOM generation, and dependency management.

The Alpha-Omega project, which I help oversee, provides targeted funding to help critical open source projects improve their security posture. The challenge isn’t just money—it’s focus. Sustained attention is what enables long-term security work. Alpha-Omega helps maintainers dedicate time and resources to those efforts.

---

Getting Started in Cybersecurity

Katie Steen-James**: ** What advice would you give to developers or maintainers who are new to cybersecurity?

Jeremy Stanley:** ** A great starting point is the OpenSSF’s Security Baseline guide—it maps directly to key parts of the Cyber Resilience Act and offers actionable steps. The Open Regulatory Compliance Working Group also maintains FAQs and white papers that explain what these new regulations mean for open source contributors and foundations.

Barry Peddycord III:** ** I’d add: learn from your peers. Look at mature open source projects to see how they handle vulnerability disclosure, security mailing lists, and incident reporting. Many repositories now include a SECURITY.md file outlining how to report vulnerabilities. That’s a great pattern to emulate.

Bob Callaway:** ** I agree. The most important first step is clarity—be explicit about what you’re willing to do as a maintainer. If you can’t handle vulnerability reports, say so. Setting expectations helps everyone.

Then focus on the basics:

• Use two-factor or hardware-based authentication.
• Be mindful of credential management and access control.
• Automate what you can—use tools for vulnerability scanning, dependency updates, and reproducible builds.

Security doesn’t have to be overwhelming. Start small, be intentional, and build on those habits.

---

Challenges in Implementing the CRA

Katie Steen-James**: ** Jeremy, as the CRA moves toward implementation, what challenges do you foresee for open source?

Jeremy Stanley:** ** There are still many unknowns. The law took effect last year, but compliance requirements are being phased in. One concern is that it assumes all software is produced by EU-based commercial entities, which doesn’t reflect how global open source projects actually work.

Another issue is that the European standards bodies still don’t fully understand open source workflows. If their compliance standards don’t account for community-driven development, we risk ending up with requirements that are impractical or even harmful to open source participation.

Finally, once vulnerability reporting requirements go into effect, we’ll likely see a surge in vulnerability reports directed at open source projects. Many maintainers aren’t prepared for that influx, which could be overwhelming.

---

Using SBOMs as a Management Tool

Katie Steen-James**: ** Barry, you mentioned that SBOMs can be an effective management tool. How do you use them to improve security?

Barry Peddycord III:** ** SBOMs give you situational awareness—they show what’s in your software, where it came from, and what’s vulnerable.

Take the Log4j incident, for example. Organizations with good SBOMs could quickly identify whether they were affected and respond confidently. Without that visibility, companies lost valuable time just figuring out where they stood.

Even with the complexity of modern open source ecosystems, SBOM generation tools are getting better at surfacing both direct and indirect dependencies. That visibility lets you build better incident response plans and communicate clearly with stakeholders when issues arise.

---

Sustaining Open Source Security Work

Katie Steen-James**: ** Bob, from your perspective at Google, what are the main challenges in sustaining open source security efforts?

Bob Callaway:** ** Sustainability starts with automation. Humans make mistakes—it’s inevitable—so you need automated systems for updates, dependency management, and credential rotation.

We also focus on process: documenting repeatable workflows so communities can respond consistently to issues. Reproducible builds, strong CI pipelines, and minimal dependency surfaces all help reduce risk.

Beyond that, there’s a social dimension. Much of the open source infrastructure the world relies on—like PyPI or NPM—is maintained by volunteers. We depend on their goodwill. We need to recognize that and support them, whether through funding, staffing, or simply by helping share the load.

Security and sustainability go hand in hand. A burned-out maintainer is a security risk.

---

Looking Ahead

Katie Steen-James**: ** As we look to the future, what major cybersecurity and policy trends do you see on the horizon?

Jeremy Stanley:** ** We’re already seeing the EU’s CRA inspire similar regulations in other regions. In the U.S., government and defense sectors are tightening their supply chain security requirements, but commercial software remains largely self-regulated.

Barry Peddycord III:** ** We’re also seeing new “bill of materials” concepts emerging—like CBOMs for cryptographic materials and AI BOMs for machine learning models. These tools aim to improve transparency across different parts of the supply chain.

Bob Callaway:** ** I think quantum computing is the next big shift. Post-quantum cryptography will eventually force organizations to rotate their signing keys and rethink encryption entirely.

The bigger lesson is adaptability. Whether it’s new regulations, new algorithms, or new attack surfaces, organizations that get the fundamentals right—identity management, automation, transparency—will be best prepared for whatever comes next.