Open Source Security Foundation https://openssf.org Linux Foundation Projects Fri, 13 Mar 2026 17:02:56 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.1 https://openssf.org/wp-content/uploads/2021/09/cropped-favicon-150x150.png Open Source Security Foundation https://openssf.org 32 32 Securing Agentic AI in Practice: From OpenSSF Guidance to Real-World Implementation https://openssf.org/blog/2026/03/13/securing-agentic-ai-in-practice-from-openssf-guidance-to-real-world-implementation/ Fri, 13 Mar 2026 17:02:36 +0000 https://openssf.org/?p=9771 Agentic AI systems and AI-driven software workflows are evolving quickly, with more people building on top of them. With that shift comes new questions around trust, control, provenance, and secure interaction between models, tools, and users. Traditional cybersecurity models are being pushed to their limits, and the security stakes have never been higher.

Are you prepared to secure your AI workflow?

Join us on March 17th at 1:00 PM ET for an essential OpenSSF Tech Talk: “Securing Agentic AI in Practice: From OpenSSF Guidance to Real-World Implementation”

Register Here for the Webinar

Why This Talk Matters

Agentic AI introduces unique vulnerabilities, including agent autonomy risks, tool interaction trust issues, and context integrity. This session bridges the gap between high-level security guidance and the gritty reality of production level implementation.

What We’ll Cover:

  • The Problem Space: Angela McNeal (Thread AI) will dive into why agent autonomy and context integrity are the new frontiers of AI security.
  • Deep Dive into SAFE-MCP: Frederick Kautz (AI/ML Security Working Group, SAFE-MCP SIG Maintainer) will explore the Secure AI Framework Ecosystem (SAFE) and Model Context Protocol (MCP), discussing threat models and design tradeoffs.
  • Infrastructure Perspectives: Hugo Huang and Abdelrahman Hosny (Canonical) will share how security translates to the infrastructure layer.
  • Skills Development: Learn about the OpenSSF’s free course, Secure AI/ML-Driven Software Development (LFEL1012), to help you build your own expertise.

Meet the Speakers!

  • Moderator: Yesenia Yser (Senior Security Program Manager, Microsoft)
  • Angela McNeal (CEO & Co-Founder, Thread AI)
  • Frederick Kautz (AI/ML Security Working Group, SAFE-MCP SIG Maintainer)
  • Hugo Huang (Public Cloud Alliance Director, Canonical)
  • Abdelrahman Hosny (Silicon Alliance Manager, Canonical)

Event Details

Don’t miss this chance to hear from the experts building the frameworks that will keep AI safe and reliable.

 

]]> First Steps Towards Cyber Resilience Act Conformity: Biking the CRA with Balena at FOSDEM 2026 https://openssf.org/blog/2026/03/11/first-steps-towards-cyber-resilience-act-conformity-biking-the-cra-with-balena-at-fosdem-2026/ Wed, 11 Mar 2026 19:54:01 +0000 https://openssf.org/?p=9751 This blog was originally published on blog.balena.io written by Harald Fischer and modified for OpenSSF

Recently, I spoke at the Free and Open Source Developers’ European Meeting (FOSDEM) 2026 on “First steps towards Cyber Resilience Act (CRA) conformity: A practical introduction to cybersecurity risk management.”

To make the Cyber Resilience Act (CRA) easier to understand, I used bicycles as a metaphor for how to approach cybersecurity risk.

Key Points from My Talk:

  • It’s not only information security that needs to be considered, but also other aspects like the health and safety of users.
  • It’s important to understand the product’s risk over its full lifetime (which could span multiple years).
  • There is a legal obligation to produce technical documentation.
  • The first step is to start with your product. Be clear on the function, integration, and user profile.
  • Communicate clearly the remaining cybersecurity risks to your users.

You can view the full talk here (<13mins.), along with the extended slide deck.

Thank you to everyone who came to my talk in person (and watched online).

What I Learned About the CRA at FOSDEM

From attending the other CRA sessions and many interesting hallway conversations, I noticed some common themes:

  • There’s a tendency to rely on automated tools, which can numb the awareness of the underlying manual processes. We must continue to focus on manual work, such as understanding who our users are (user profiles), how systems operate (operational environments and system functions), and where the real potential risks lie.
  • The fundamental risk assessment for digital products isn’t on top of the developer’s minds. They’re kept busy shipping features on time, fixing bugs, handling incidents/outages.
  • Open Source maintainers view corporate involvement as a good and bad thing at the same time. Organizations face legal mandates to upstream vulnerability fixes (benefiting all), but some can treat volunteer maintainers like third-party vendors, demanding security questionnaires without contributing much themselves.
  • There’s still a large disconnect between Open Source, new standards, and real industry needs.

Working with the OpenSSF Community on CRA

Since the beginning of 2025, balena has been an active member of the Open Source Security Foundation (OpenSSF). We understood early that the Cyber Resilience Act (CRA) challenges would affect many members of the open source community, including ourselves. We prefer to work on the CRA within a community rather than in isolation. Consequently, I have been active with the OpenSSF Global Cyber Policy Working Group ever since.

I had the opportunity to volunteer at the OpenSSF booth at FOSDEM. The booth was so busy that we ran out of CRA stickers and flyers by Saturday morning – just a few hours into the conference! I was thrilled that many attendees stopped by to continue the discussion about my presentation and to make new connections.

I want to thank Susan Remmert from the Linux Foundation for organizing the booth. Thanks to Kris Borchers for the invitation and the excellent company at the OpenSSF booth. It was also great to see Roman Zhukov (Red Hat) stop by despite his hectic schedule!

Roman Zhukov, Kris Borchers, and Harald Fischer at the OpenSSF booth at FOSDEM.

A Remarkable Experience at FOSDEM

FOSDEM is widely recognized as the largest free open source community event. It would not be possible without the efforts of all the volunteers. In particular, I’d like to thank the ‘CRA in practice’ developer room organizers for all the hard work they did: Roman Zhukov, Madalin Neag, Megan Knight, and Philippe Ombredanne.

Experiencing FOSDEM in-person was… interesting! Being turned away from full capacity sessions, long queues for food, being crushed in the hallway, and the unmistakable aroma of 8000+ techies were just some of the challenges. However, the deep dives and technical insights into open source and the energy of being surrounded by such approachable passionate smart folks, made the experience so valuable.

Relevant Links

 

]]> What’s in the SOSS? Podcast #55 – S3E7 The Gemara Project: GRC Engineering Model for Automated Risk Assessment https://openssf.org/podcast/2026/03/10/whats-in-the-soss-podcast-55-s3e7-the-gemara-project-grc-engineering-model-for-automated-risk-assessment/ Tue, 10 Mar 2026 13:13:03 +0000 https://openssf.org/?p=9745

Summary

Hannah Braswell and Jenn Power, Security Engineers from Red Hat and contributors to the OpenSSF, join host Sally Cooper to discuss the Gemara project. Gemara, an acronym for GRC Engineering Model for Automated Risk Assessment, is a seven-layer logical model that aims to solve the problem of incompatibility in the GRC (Governance, Risk, and Compliance) stack. By outlining a separation of concerns, the project seeks to enable engineers to build secure and compliant systems without needing to be compliance experts. The speakers explain how Gemara grew organically to seven layers and is leveraged by other open source initiatives like the OpenSSF Security Baseline and Finos Common Cloud Controls. They also touch on the ecosystem of tools being built, including Queue schemas and a Go SDK, and how new people can get involved.

Conversation Highlights

00:00 Welcome music + promo clip
00:22 Introductions
02:17 What is Gemara and what problem does it address?
03:58 Why do we need a model for GRC engineering?
05:50 The seven-layer structure of Gemara
07:40 How Gemara connects to other open source projects
10:14 Tools available to help with Gemara model adoption
11:39 How to get involved in the Gemara projects
13:59 Rapid Fire
16:03 Closing thoughts and call to action

Transcript

Sally Cooper (00:22)
Hello, hello, and welcome to What’s in the SOSS, where we talk to amazing people that make up the open source ecosystem. These are developers, security engineers, maintainers, researchers, and all manner of contributors that help make open source secure. I’m Sally, and today I have the pleasure of being joined by two fantastic security engineers from Red Hat. We have Hannah and Jenn.

Thank you both so much for joining me today and to get us started, can you tell us a little bit about yourselves and the work that you do at Red Hat? I’ll start with Jenn.

Jenn Power (00:58)
Sure. I am Jenn Power. I’m a principal product security engineer at Red Hat. My whole life is compliance automation, let’s say that. And outside of Red Hat, I participate in the OpenSSF Orbit Working Group, and I’m also a maintainer of the Gemara project.

Sally Cooper (01:18)
Amazing. Thank you, Jenn and Hannah. How about you? Hi.

Hannah Braswell (01:21)
Hey, Sally. Thanks for the nice introduction. I’m Hannah Braswell, and I’m an associate product security engineer at Red Hat. And I work with Jenn on the same team. And I primarily focus on compliance automation and enablement for compliance analysts to actually take advantage of that automation. Then within the OpenSSF, I’m involved in the Gemara project. I’m the community manager there. And then

I’m kind of a fly on the wall at a lot of the community meetings, whether it be the Gemara meeting or the orbit working group. I like to go to a lot of them.

Sally Cooper (02:01)
we love to hear that. I heard Orbit working group from both of you. That’s exciting. And I also really want to dive in to the project Gemara. So before we do dive into those details, let’s make sure that everyone’s starting from the same place. So for listeners who are hearing about Gemara for the first time, what is Gemara and what problem is it designed to address?

Jenn Power (02:23)
Sure, can start there. It’s actually secretly an acronym. So it stands for GRC Engineering Model for Automated Risk Assessment. So that’s kind of a mouthful, so we just shorten it to Gemara. And the official description I’ll give, and then I can go into it like a little bit more of a relatable example, is that it provides a logical model for describing categories of compliance activities, how they interact,

And it has schemas to enable automated interoperability between them. So like, what does that mean? I think a good, if we anchor this in an analogy, we could call Gemara like the OSI model for the GRC stack. In fact, that was one of the kind of primary inspirations for the categorical layers of Gemara. And Gemara also happens to have seven categorical layers, just like the OSI model.

So if you think about it in networking, if I want to send an email, I don’t have to understand like packet routing. I can just send my email. So in GRC, we can’t really do that today. We have security engineers that also have to be compliance experts to be successful. And so with Gemara, we want to outline the separation of concerns within the GRC stack to make sure that like each specialist can contain their complexity in their own layer while allowing them to exchange information with different specialists completing activities in different layers.

So like if I could give one takeaway, we want to make it so engineers can build secure and compliant systems without having to understand the nuance of every single compliance framework out

Sally Cooper (04:14)
I love that. So we have a baseline now. Let’s talk about the problem and get a little bit deeper into that. So Gemara is responding to a problem that you touched upon. Why do we need a model for GRC engineering and what incompatibility issue are you trying to solve? If you could go a little deeper.

Jenn Power (04:34)
Sure. So I think sharing resources in GRC is just really hard today. Sharing content, sharing tools, none of those tools and content, it doesn’t work together today, if I could say that. engineers are typically having to reinterpret security controls. They’re having to create a lot of glue code to make sure that a tool like a GRC system and a vulnerability scanner can actually talk to each other.

So we’re trying to solve that incompatibility issue on the technical side. But this is also a human problem. And I think that’s kind of the sneakiest part about it. A lot of times, we’re not even saying the same things when we use the same terms. And so that’s another thing that we’re trying to solve within the Gemara project.

This one comes up all the time. Take the word policy. If you say that to an engineer, you’re thinking immediately, policy as code, like a rego file or something you’re going to use with your policy engine. But if you’re talking to someone in the compliance space, they’re thinking like, this is like my 40 page document that outlines my organizational objectives. So we created definitions within the Gemara project to go along with the model to solve the human problem while we’re also trying to solve the technical problem.

Sally Cooper (06:05)
That’s interesting. Okay, I heard you say something about a seven-layer structure. Can you tell me why you chose a seven-layer structure for Gemara?

Jenn Power (06:17)
So this actually stemmed from an initiative under the CNCF called the Automated Governance Maturity Model. And that started as four concepts actually, policy, evaluation, enforcement, and audit. And that established the initial kind of lexicon that the project had been using.

And it initially got some adoption in the ecosystem, specifically in projects under the Linux Foundation, like FINOS Common Cloud Controls (CCC) and the Open Source Project Security Baseline (OSPS Baseline). And through the application of that lexicon, we found that there needed to be more granularity within that policy layer. So it expanded to two new layers called guidance and controls.

And I didn’t mention that we were creating a white paper yet, but we do have a white paper. And through the creation of that white paper, which Eddie Knight did so much work to create that initial draft there, we actually found that we were missing a layer. We had a seventh layer, and it was something that we had called sensitive activities. And it’s something kind of sandwiched in the middle of the Gemara layer. And so with that, we kind of organically grew to seven layers. So that I think is the kind of origin story on how the layers got to seven.

Sally Cooper (07:54)
I love that. And you’re really talking about how Gemara is not built in isolation, that you’re working with other open source projects. For example, you mentioned Baseline and the FINOS Common Cloud Controls. Can you tell me how Gemara connects to those projects?

Hannah Braswell (08:09)
Yeah. So in terms of Gemara connecting to the other open source projects, the first thing that comes to mind is really the CRA because of how prominent it is right now and just the future of its impact. And I really think that Gemara is going to be a catalyst for open source projects in general that are in need of some kind of mechanism to, you know, implement security controls and align with potential compliance requirements.

And the good thing about Gemara is that you don’t have to be a compliance expert to make sure that your open source project is secure. And so I would say that the OSPS Baseline is a great example of Gemara’s layer two, because it provides a set of security controls that engineers can actually implement. So in that case, other projects can reuse the baseline controls and then fit them to their needs.

And I think it also goes to say that, anyone that is actually building a tool they want to sell or distribute in the European Union market that’s using the open source components, they’re gonna have to think about what’s in scope and having something like the OSPS Baseline to understand how to effectively assess your open source components and their risks is really, really valuable and just gonna be super useful. And then in terms of the FINOS Common Cloud Controls, I think that’s

Also another great example, just in terms of the use case and implementation of Gemara, because they have their core catalog, which has its own definitions of threats and controls that’s then imported to their technology specific catalogs. And yeah, so that’s a great implementation within the financial sector.

And then where we’re trying to expand the ecosystem for Gemara, as in the Cloud Native Security Controls catalog refresh. And that’s actually an initiative that Jenn is leading. I’ve done a few contributions to it, but it’s essentially an effort to take the controls catalog that currently exists as a spreadsheet and make it available as a Gemara layer one machine readable guidance document. So Gemara is really connecting to projects that are all great to have on your radar, especially with the CRA coming up.

Sally Cooper (10:26)
Wow, that sounds great. But I’m just thinking about our listeners. They’re probably wondering, like, what does this look like in practice? And I’m curious if there are any tools available to help with the Gemara model adoption.

Jenn Power (10:39)
So we’re actually working on an ecosystem of tools. So we want to bridge that theory that we’re creating within the Gemara white paper to things that are actually implementable just to make sure that you don’t have to start from scratch if you’re trying to implement the Gemara model.

So we have a couple tools within the ecosystem. One would be our implementation of the model. We’re using queue schemas to allow users to create the models like in YAML, for instance, if you wanted to create your layer two, you would create YAML, you could use our queue schemas to validate that your document is in fact a Gemara compliant document. And then we’re also building SDKs. Right now we have a Go SDK, so you can build tooling around the programmatic access and manipulation of Gemara documents. A tool in the ecosystem that’s using this currently is a tool called Privateer that automates the layer five evaluations.

Sally Cooper (11:47)
Wow, that’s great. And of course, none of this works without the people. So I know you mentioned a few of them. How can new people get involved in the Gemara project?

Hannah Braswell (11:58)
So anyone that’s new and interested in getting involved in the Gemara project, my first piece of advice would just be to jump in a community meeting and listen in on what’s happening. I know I started out just by joining those meetings and I, you know, I didn’t necessarily have much to say, but I appreciated the culture and the open discussion, just like bouncing ideas back and forth off of one another.

And there’s also plenty of times when I joined a community meeting and still trying to understand the project if there was some kind of group opinion trying to be formed. Like I think it’s perfectly fine to say, you know, I don’t have the information right now. I don’t have an opinion. I’m still trying to learn about the project. But if something piques your interests and you want to contribute, then volunteer for it or show you’re interested because people are not going to forget about your willingness to step up and be part of the community.

But I started joining those meetings before we were rolling out the white paper. So that kind of brings me back to my first piece of advice. So I’d really suggest reading the white paper first, because it describes the problem and the trajectory of the project so well, and in a really clear way that I think is super important context for anyone that wants to start contributing. And I mean, from there, I mean, I’m the community manager, but I started with small contributions.

that ended up supporting the community in terms of documentation and some other aspects of the project I was excited about and that I could contribute to. So I really think the contributions are dependent on what you’re interested in. And even if there’s some difference in opinion and perspective or background, all of that can make a huge difference for the community and anything from documentation to code or discussion and collaboration will count as valid contribution and effort. So I’d say to anyone that’s wanting to join the Gemara community and start contributing, I think you should just find an area that truly interests you and makes you excited and get involved.

Sally Cooper (14:02)
Oh, that’s great. Well, thanks so much. And before we wrap, we’re going to do rapid, rapid fire. So I hope you’re ready because this is the fun part. No overthinking, no explanations, just the first instinct, okay, that comes to you. And I’m going to bounce. Yes, exactly. I’m going to bounce back and forth and ask you both some questions. Ready?

Jenn Power (14:17)
I’ll close my eyes then.

Sally Cooper (14:25)
Okay, Hannah, you’re up first. Star Wars or Star Trek?

Hannah Braswell (14:29)
Star Wars.

Sally Cooper (14:30)
Nice, I love it.
And Jenn, same question, Star Wars or Star Trek?

Jenn Power (14:335)
Star Wars.

Sally Cooper (14:36)
Okay, we’re all friends here.
Okay, back to Hannah, coffee or tea?

Hannah Braswell (14:42)
Definitely coffee.

Sally Cooper (14:43)
Yay, cheers. That’s solid.
Jenn, morning person or night owl?

Jenn Power (14:49)
Night Owl.

Sally Cooper (14:50)
Ohh that tracks. Hannah, beach vacation or mountains?

Hannah Braswell (14:56)
Hmm beach vacation.

Sally Cooper (14:58)
Nice choice. Jenn, books or movies?

Jenn Power (15:02)
Movies.

Sally Cooper (15:03)
Nice. All right, last round. Hannah, favorite open source mascot?

Hannah Braswell (15:08)
Oh…Zarf. I think that looks like an axolotl. I used to be obsessed with axolotls. And I mean, ever since I saw that, I was like, that’s the mascot.

Sally Cooper (15:18)
I love Zarf too. Cool. Okay. That’s a really strong pick.
Jenn, I’m going to give you the same question. Favorite open source mascot?

Jenn Power (15:26)
actually love the OpenSSF goose. I think it’s so cute.

Sally Cooper (15:30)
Teehee, Honk, he’s the best. Okay, let’s bring it home, Hannah, sweet or savory.

Hannah Braswell (15:38)
Savory.

Sally Cooper (15:39)
interesting. Okay, and Jenn? Spicy or mild?

Jenn Power (15:46)
mild. I can’t handle any spice. I’m a baby.

Sally Cooper (15:51)
love it. That’s amazing. Well, thank you both so much for playing along. And as we wind things down, do you have any other calls to action for our audience if someone’s listening, and they want to learn more or get involved? What is like the best next step for them?

Jenn Power (16:05)
I would say read the white paper. We are looking for feedback on it and that is really a way to understand the philosophy and the architectural goals of Gemara. And if you’re looking to just like, hey I want to learn GRC, that’s a good first step. So I think that’s what I would say.

Sally Cooper (16:28)
Fantastic. Hannah, Jenn, thank you so much for your time today and for the work you’re doing for the open source security community. We appreciate you both. And to everyone listening, happy open sourcing and that’s a wrap.

]]> Introducing the Gemara Model https://openssf.org/blog/2026/03/09/introducing-the-gemara-model/ Mon, 09 Mar 2026 20:21:54 +0000 https://openssf.org/?p=9726

By Eddie Knight, Hannah Braswell, and Jenn Power 

Software development has reached a point where traditional Governance, Risk, and Compliance (GRC) can no longer keep up. Compliance activities often exist only as a separate administrative layer, making it difficult for organizations to prove that security measures are in place long after the work is complete.

To tackle this problem head on, the industry has seen the rise of GRC Engineering and related topics such as policy-as-code or compliance-as-code. Yet, there have been massive alignment gaps pertaining to interoperability between tools, teams, and organizations. At the core, the industry suffers from split-brain attempts to cover related problems without standardizing on philosophies, language, or data schemas.

To enable a global standardization effort by beginning with philosophical alignment, we are excited to announce the publication of Gemara: A Governance, Risk, and Compliance Engineering Model for Automated Risk Assessment.

What’s Inside?

This model provides a structure designed to categorize compliance activities and define their functional interactions. These are activities which are inherent to governance and have existed in practice, but lacked a unified engineering architecture with predictable points of exchange. By decomposing these activities into discrete layers, the model facilitates standardized documentation, shared language, and creates a basis for collaborative maintenance of common resources.

The model stems from the CNCF’s Automated Governance Maturity Model. It also incorporates lessons from prior art, such as NIST’s OSCAL, the FINOS Common Cloud Controls project, and the OpenSSF’s Open Source Project Security Baseline.

Just as the OSI Model gave us a common language for networking, Gemara provides a seven-layer architecture, detailing separation of concerns for the GRC stack:

  • The Definition Layers (1-3): These layers define what “good security” actually looks like for an organization.
  • The Pivot Point (4): This is where policy requirements meet real-world operational activities.
  • The Measurement Layers (5-7): These cover the techniques used to evaluate, enforce, and audit how well you’re sticking to those security definitions.

This structure ensures every stakeholder (and tool) has a clear place in the system. For teams looking to treat GRC as an engineering discipline rather than a checklist, the Gemara model offers a practical way forward.

Join Us

The Gemara Project is an open source initiative stewarded by the OpenSSF with founding maintainers from Sonatype, Red Hat, and more.

  • Learn about the model [Link]
  • Explore the schemas and SDKs on available on GitHub [Link] 
  • Join the ORBIT Working Group [Link]
  • Explore OpenSSF Membership [Link]

About the Authors

Jenn Power is a Principal Product Security Engineer at Red Hat where she leads upstream collaboration and cross-industry initiatives centered on automated governance and security data standardization. She serves as a Tech Lead for CNCF TAG Security and Compliance, a member of the ORBIT Working Group, and a maintainer of the OpenSSF Gemara project.

 

Hannah Braswell is an Associate Product Security Engineer at Red Hat, where she focuses on compliance automation and developing enablement tooling for compliance analysts. With a B.S. in Computer Engineering from NC State University, she brings a deep background in microarchitecture and embedded systems to her work in the open-source ecosystem. Hannah currently serves as the Community Manager for the OpenSSF Gemara project, driving collaboration and security enablement across the community.

 

Eddie Knight is a Software and Cloud Engineer with a background in banking technology. When he isn’t playing with his 3-year-old son, he combines his passion and job duties by working to improve the security of open source software. Eddie currently helps lead several security and compliance initiatives across the CNCF, OpenSSF, and FINOS.

]]> Your Voice Belongs Here: How to Get Involved in the OpenSSF Community https://openssf.org/blog/2026/03/05/your-voice-belongs-here-how-to-get-involved-in-the-openssf-community/ Thu, 05 Mar 2026 19:58:39 +0000 https://openssf.org/?p=9684 One of the most common misconceptions we hear in the OpenSSF community is that you need special permission to contribute. 

You do not.

OpenSSF is built on the belief that open source security is stronger when more voices are involved. Whether you work in developing software, security engineering, leadership, open source, policy, marketing, or community building, your experience matters, and your perspective belongs here.

You Don’t Need Permission to Contribute

Sharing knowledge at OpenSSF is not exclusive or limited to a small group. It is designed for members and the broader community to learn from one another.

There are many ways to contribute, including blogs, tech talks, podcasts, project updates, case studies, and white papers. These opportunities exist to share real-world insights, lessons learned, and practical experience from across the ecosystem.

If you have something to share, we want to hear from you.

Getting Started with OpenSSF

If you are wondering where to begin, OpenSSF offers a simple way to navigate your involvement through the OpenSSF User Journeys.

The Journeys are designed to guide people through the community based on their role, interests, and level of experience. It outlines practical entry points for software developers, security engineers, open source program offices, marketing, and communications professionals, along with curated resources to help you move forward.

Whether you are just starting to explore open source security or are ready to actively contribute, our Getting Started guide helps you understand what your next step could be and how to move forward at your own pace.

Staying Connected & Informed

OpenSSF offers several ways to help members share their work more broadly.

Members can participate in our communications effort in multiple ways such as podcast interviews, including new video options for Premier Members, present through the Tech Talks webinar program aligned to quarterly themes, and submit content to the OpenSSF newsletter, which reaches nearly 12,000 subscribers. We also help amplify member initiatives, events, and launches through our social channels and website. 

Staying engaged with OpenSSF helps you keep up with new resources, events, calls for proposals, and learning opportunities.

Following OpenSSF on social media, subscribing to the monthly newsletter, and joining Slack are simple ways to stay informed and support the visibility of open source security work.

Slack is where OpenSSF working groups collaborate, questions get answered, and community connections form.

There are dedicated channels for each working group and project, as well as for the Marketing Advisory Council, the Editorial Review Panel, and Developer Relations (DevRel). Once you join, you are welcome to explore and participate in the channels that match your interests. 

Member-Driven Impact & Working Groups

OpenSSF is a member-driven organization, but its technical initiatives, working groups, and community programs are open to everyone. While members help guide the foundation’s strategic direction, participation is not limited to membership.

For individuals who contribute outside of a member organization, your work is valued, and all credit will be attributed to you personally, not to your employer.

Everyone can get involved – whether that means to contribute occasionally, or support involvement by encouraging engineers and security experts from your organization to join. Any level of participation helps expand the reach of open source security work and strengthen the ecosystem.

OpenSSF currently has ten working groups focused on different areas of securing open source. These groups cover topics such as AI and machine learning security, best practices, global cyber policy, project security baselines, and belonging and representation. Working groups are where ideas turn into guidance, tools, and long-term impact for the community. View the calendar and join a meeting.

Participation and Member Opportunities

While everyone is welcome in our community, OpenSSF membership offers structured and accessible ways to participate and elevate your impact.

We support Premier, General, and Associate Members and provide clear contribution pathways based on interest and capacity. 

Being a member gives your organization dedicated channels to contribute technical reports and other thought-leadership content for publication through OpenSSF channels, sharing research, and practical guidance that help improve open source security across ecosystems. Opportunities also include membership spotlights, highlighted interviews, and coordinated social media promotion, enabling members to amplify their work while advancing community-driven security outcomes. See the full list of current OpenSSF members and membership benefits. 

Watch the short overview video to learn how to get involved in the OpenSSF community and explore the ways members can share, contribute, and participate.

Join Us and Get Involved

Open source security works best when it is collaborative.

If you have been waiting for permission to participate, this is your invitation. Start by attending a Working Group meeting, joining a community event, or simply listening in to learn how things work. Join OpenSSF as a member, get involved, and help shape the future of open source security.

 

]]> Case Study: Defending the Open Source Supply Chain in a New Regulatory Era https://openssf.org/blog/2026/03/02/case-study-defending-the-open-source-supply-chain-in-a-new-regulatory-era/ Mon, 02 Mar 2026 14:13:06 +0000 https://openssf.org/?p=9645

How Red Hat and OpenSSF are translating regulatory mandates into scalable open source community practices

Challenge

The European Union Cyber Resilience Act (CRA) introduces legally binding cybersecurity requirements for products with digital elements (including software) placed on the EU market. While designed to bolster digital safety, these requirements relied on standards historically shaped by proprietary software assumptions.

For Red Hat, whose products rely on thousands of upstream open source components, the risk was clear. If CRA standards failed to reflect the reality of how open source is built, the resulting compliance hurdles could increase cost and legal uncertainty for the enterprise while placing an unsustainable administrative burden on voluntary community maintainers.

As Red Hat Security Communities Lead Roman Zhukov, along with fellow Red Hatters from Product Security and Public Policy (Jaroslav Reznik, Pavel Hruza, and James Lovegrove), shared insights working on the CRA standards:

“Working on traditional industry standardization ‘behind closed doors’ started as a big challenge for us, upstream-minded people, who used to openly share and collaborate on all the work that we do. But that was important. Because if those standards didn’t reflect how open source actually works, there would be a real risk of imposing corporate-level liability on the community, because of persistent compliance pressure by enterprise adopters.” 

Solution

As a Premier Member of the OpenSSF, Red Hat transitioned from collaboration to leadership, engaging with the European Commission to advocate for a clear understanding of open source development methods and helping shape CRA standards, policy, and implementation guidance.

Through OpenSSF and direct participation in European standards bodies, Red Hat has helped advance open source development practices into CRA standards and technical guidelines, including: 

  • Hardened development lifecycles: Advancing expectations that respect community workflows
  • SBOM and Vulnerability handling: Streamlining how data is shared across the supply chain
  • Supply chain integrity: Promoting frameworks that can verify security without slowing innovation

Red Hat also championed OpenSSF frameworks as essential reference points for industry preparing for CRA compliance, including:

Together, these efforts provided regulators and manufacturers with practical, community-vetted guidance for implementing CRA requirements. This helps shift the responsibility back to manufacturers and stewards through consistent data discovery rather than placing the burden of evidence upon voluntary communities.

Red Hat’s Portfolio Security Architect Emily Fox expanded on her thoughts regarding stewardship and shared responsibility under the CRA:

“True stewardship shields open source creators from legislative burden. We don’t ask maintainers to become commercial suppliers; we step in to absorb the complexity, turning commercial compliance mandates into engagement opportunities that drive real security for everyone.”

Results

Red Hat’s leadership within OpenSSF helped deliver ecosystem-wide impact:

  • Standardization Alignment: State-of-the-art secure development practices were incorporated into EU CRA technical guidelines
  • Framework Recognition: The OpenSSF Security Baseline and SLSA are now recognized as reference frameworks for development
  • Reduced Friction: Lowered compliance barriers across thousands of upstream open source components
  • Increased Confidence: Bolstered regulator and enterprise trust in open source maturity

Why This Matters

Open source software underpins 90% of modern technology stacks. By leading through OpenSSF, Red Hat helped the CRA reinforce shared responsibility and practical security improvements rather than shifting administrative weight onto open source maintainers.

Learn More

About

Roman Zhukov is a cybersecurity expert, engineer, and leader with over 17 years of hands-on experience securing complex systems and software products at scale. At Red Hat, Roman leads open source security strategy, upstream collaboration, and cross-industry initiatives focused on building trusted ecosystems. He is an active contributor to open source security and co-chair of the OpenSSF Global Cyber Policy WG.

 

Emily Fox is a visionary security leader whose sustained contributions have profoundly shaped both internal company strategy and the broader open source industry. With over 15 years of experience, she has consistently operated at the intersection of deep technical expertise and strategic leadership, driving critical initiatives in cloud native security, software supply chain integrity, post-quantum cryptography, and zero trust architecture at top-tier organizations including Red Hat, Apple, and the National Security Agency. Her career is marked by a rare ability to not only architect complex, cutting-edge solutions but also to lead global communities, influence industry standards, and mentor the next generation of technologists.

]]> OpenSSF Newsletter – February 2026 https://openssf.org/newsletter/2026/02/26/openssf-newsletter-february-2026/ Thu, 26 Feb 2026 14:21:39 +0000 https://openssf.org/?p=9637

TL;DR:

🇳🇱 Open Source SecurityCon Europe → Agenda live and registration open

🎙 Securing Agentic AI in Practice → March 17 Tech Talk on AI/ML security in action

📖 Compiler Annotations Guide → Practical C/C++ hardening without rewrites

🏆 Security Slam 2026 → 30-day challenge to level up project security

🇪🇺 CRA in Practice @ FOSDEM → Turning regulation into actionable steps

📦 Package Repository Security Forum → Cross-ecosystem collaboration in action

🎙 What’s in the SOSS? → CFP tips and a 4-part AIxCC deep dive

6 min read

Join Us at Open Source SecurityCon Europe 2026 in Amsterdam

Planning to attend KubeCon + Cloud Native Con Europe in March? Don’t miss OpenSSF’s co-located 1-day event! This gathering will bring together a diverse community, including software developers, security engineers, public sector experts, CISOs, CIOs, and tech pioneers, to explore challenges and opportunities in modern security. Collaborate with peers and discover the essential tools, knowledge, and strategies needed to ensure a safer, more secure future.

The agenda is live! Read the blog to learn what not to miss in Amsterdam and to see highlights from SecurityCon North America.

Read the blog | Register now | View the agenda

Mark Your Calendar For the Upcoming Tech Talk: Securing Agentic AI in Practice: From OpenSSF Guidance to Real-World Implementation

Tech Talk: Securing Agentic AI in Practice: From OpenSSF Guidance to Real-World ImplementationJoin us for the first OpenSSF Tech Talk of the year, focusing on agentic artificial intelligence (AI) security.

In this session, we will explore how the OpenSSF AI/ML Security Working Group is developing open guidance and frameworks to help secure AI and machine learning systems, and how that work translates into real-world practice. Using SAFE MCP and other solutions from OpenSSF member companies as examples, we will highlight community-driven efforts to improve the security of agentic AI systems, the problems they address, the design tradeoffs involved, and the lessons learned so far.

We will also feature OpenSSF’s free course, Secure AI/ML Driven Software Development (LFEL1012), which gives attendees a clear path to build practical skills and contribute to this rapidly evolving field.

Register and mark your calendar for March 17 at 1:00 p.m. ET. Additional speaker information will be shared soon.

Fill Out All The Margins 📖: OpenSSF Releases Compiler Annotations Guide for C and C++

OpenSSF has released a new Compiler Annotations Guide for C and C++ to help developers improve memory safety, diagnostics, and overall software security by using compiler-supported annotations. The guide explains how annotations in GCC and Clang/LLVM can make code intent explicit, strengthen static analysis, reduce false positives, and enable more effective compile-time and run-time protections. As memory-safety issues continue to drive a significant share of vulnerabilities in C and C++ systems, the guide offers practical, real-world guidance for applying low-friction hardening techniques that improve security without requiring large-scale rewrites of existing codebases. 

Read the blog

Security Slam 2026

Security Slam 2026 is a 30-day security hygiene challenge running from February 20 to March 20, culminating in an awards ceremony at KubeCon + CloudNativeCon Europe. Hosted by OpenSSF in partnership with CNCF TAG Security & Compliance and Sonatype, the event encourages projects to use practical security tools, including OpenSSF resources, to strengthen their security posture based on their maturity level. Participants can earn recognition, badges, and plaques for completing milestones, reinforcing a community-driven effort to improve open source software security at scale. 

Read the blog to learn more | Register now to receive reminders and instructions

EU Cyber Resilience Act (CRA) in Practice @ FOSDEM 2026: From Awareness to Action

At FOSDEM 2026, the CRA in Practice DevRoom brought together open source and industry leaders to turn the EU Cyber Resilience Act from policy discussion into practical action. Through case studies and panels, speakers shared concrete approaches to vulnerability management, SBOMs, VEX, risk assessment, and the steward role. 

Read the blog

Advancing Package Repository Security Through Collaboration

On February 2, OpenSSF convened the Package Manager Security Forum, bringing together maintainers and registry operators from major ecosystems to address shared challenges in package repository security. Discussions highlighted common concerns around identity and account security, governance and abuse handling, transparency, and long-term sustainability. The session reinforced that package ecosystem risks are interconnected and that improving security requires cross-ecosystem coordination, shared frameworks, and continued collaboration through OpenSSF’s neutral convening role.

Read the recap

Getting an OpenSSF Baseline Badge with the Best Practices Badge System

Is your open source project meeting the “minimum definition” of security? The OpenSSF has officially integrated the Open Source Project Security Baseline (OSPS Baseline) into its Best Practices Badge Program.

In our latest blog, David A. Wheeler explains how you can quickly identify and meet essential security requirements to earn a Baseline Badge.

What’s in the SOSS? An OpenSSF Podcast:

#50 – S3E2 Demystifying the CFP Process with KubeCon North America Keynote Speakers

Stacey Potter and Adolfo “Puerco” García Veytia share practical, behind-the-scenes advice on submitting conference talks, fresh off their KubeCon keynote. They break down how CFP review committees work, what makes an abstract stand out, common mistakes to avoid, and why authenticity matters more than polish. The episode also tackles imposter syndrome and encourages new and diverse voices to shape the future of open source through speaking.

#51 – S3E3 AIxCC Part 1: From Skepticism to Success with Andrew Carney

Andrew Carney from DARPA explains the vision and results behind the two-year AI Cyber Challenge (AIxCC), which tasked teams with building AI systems that can automatically find and patch vulnerabilities in open source software. Despite early skepticism, competitors identified more than 80% of seeded vulnerabilities and generated effective patches at surprisingly low compute costs. The episode looks at what comes next as these cyber reasoning systems move from competition to real-world adoption.

#52 – S3E4 AIxCC Part 2: How Team Atlanta Won by Blending Traditional Security and LLMs

Professor Taesoo Kim of Georgia Tech describes how Team Atlanta combined fuzzing, symbolic execution, and large language models to win AIxCC. Initially skeptical of AI, the team shifted its strategy mid-competition and discovered that hybrid approaches produced the strongest results. The conversation also covers commercialization efforts, integration with OSS-Fuzz, and how the experience reshaped academic security research.

#53 – S3E5 AIxCC Part 3: Trail of Bits’ Hybrid Approach with Buttercup

Michael Brown of Trail of Bits discusses Buttercup, the second-place AIxCC system that pairs large language models with conventional software analysis tools. The team focused on using AI for well-scoped tasks like patch generation while relying on fuzzers for proof-of-vulnerability. Now fully open source and able to run on a laptop, Buttercup is actively maintained and positioned for broader enterprise and community use.

#54 – S3E6 AIxCC Part 4: Cyber Reasoning Systems in the Real World

CRob and Jeff Diecks wrap up the AIxCC series by exploring how competition teams are applying their systems to real open source projects such as the Linux kernel and CUPS. They introduce the OSS-CRS initiative, which aims to standardize and combine components from multiple cyber reasoning systems, and share lessons learned about responsibly reporting AI-generated findings. The episode highlights how collaboration through OpenSSF’s AI/ML Security Working Group and Cyber Reasoning Systems SIG is shaping the next phase of AI-driven security.

News from OpenSSF Community Meetings and Projects:

Upcoming community meetings

In the News:

  • The OpenSSF was featured in a Technology Magazine Q&A. CRob discusses OpenSSF’s goals, OSSAfrica, the BEAR Working Group, Security Baseline, and much more. This conversation was also covered by AI Magazine. 

Meet OpenSSF at These Upcoming Events!

Connect with the OpenSSF Community at these key events:

Ways to Participate:

There are a number of ways for individuals and organizations to participate in OpenSSF. Learn more here.

You’re invited to…

See You Next Month! 

We want to get you the information you most want to see in your inbox. Missed our previous newsletters? Read here!

Have ideas or suggestions for next month’s newsletter about the OpenSSF? Let us know at [email protected], and see you next month! 

Regards,

The OpenSSF Team

]]> Getting an OpenSSF Baseline Badge with the Best Practices Badge System https://openssf.org/blog/2026/02/25/getting-an-openssf-baseline-badge-with-the-best-practices-badge-system/ Wed, 25 Feb 2026 16:57:23 +0000 https://openssf.org/?p=9630

By David A. Wheeler

Many open source software (OSS) projects aim to securely develop software and have an easy way to communicate their security posture to others.

Overview

The OpenSSF developed the Open Source Project Security Baseline (OSPS Baseline) to act as a “minimum definition of requirements for a project relative to its maturity level”. It’s a three-level checklist (baseline-1 through baseline-3) to help OSS projects improve their security. The OpenSSF Best Practices Badge Program now supports the baseline criteria, making it easier for OSS projects to determine what they’ve already accomplished and what remains. OSS projects can then display their badge on their web pages, demonstrating what they’ve accomplished and making it easy for potential users to learn more.

This post introduces how to earn an OpenSSF baseline badge through the OpenSSF Best Practices Badge System.

Getting Started with the Best Practices Badge Program

First, visit https://www.bestpractices.dev. The site currently supports nine locales, and this URL automatically redirects you to your preferred language (e.g., https://www.bestpractices.dev/en for English).

Click on “Login” to add information. You can use your GitHub account to log in. Most users prefer this method. You must grant permission during your first visit. You can also create an account specifically for the site.

Click on the “Projects” tab to see projects currently pursuing badges, then click either the “+ Add” tab or the “Add New Project” button. The “New badge” form allows you to enter your project’s repository URL and/or home page URL. You can also decide whether to begin with the “metal” series or the “baseline” series. The baseline series is a focused checklist that includes only MUST security requirements and draws in part from global cybersecurity regulations and frameworks. The metal series is a larger set of criteria that includes suggestions and quality issues impacting security derived in part from the experiences of secure Free/Libre and Open Source Software (FLOSS) projects. Both focus on security, and we encourage projects to eventually complete both; simply choose a starting point. For the purposes of this blog post, we’ll assume you chose the “baseline” series.

When you click on “Submit Project”, the system assigns a unique numeric ID to the project. The system will pause to examine the repository and attempt to automatically determine the answers to various questions. For many, this automation can save a lot of time. Once that’s done, you’ll see a form to update project information. Information highlighted in yellow with the robot symbol 🤖 indicates data entered by automation. We recommend double-checking automation results for accuracy.

Understanding and Completing the Baseline Criteria

You can now fill in the form. Each criterion can be “?” (unknown), “N/A” (not applicable), Unmet, or Met. By default, each is marked “?” (unknown). As you identify more and more items that are Met (or N/A), the % completion bar will increase. We’ve intentionally gamified this; when you reach 100% in baseline-1, you’ve earned a baseline-1 badge. You can also provide justification text; we recommend including it (even when it’s not required) to help others understand the project’s current status. Badge claims are mostly self-assertions. In some cases, automation can override false claims. The answers given are presented for public scrutiny, incentivizing correct answers.

The form shows the criterion requirements; click “show details” for more information. For example, baseline-1 criterion OSPS-AC-01.01 requires that, “When a user attempts to read or modify a sensitive resource in the project’s authoritative repository, the system MUST require the user to complete a multi-factor authentication process.” Any project hosted on GitHub automatically meets this requirement. GitHub has required multi-factor authentication since March 2023, and the system automatically fills in the required information. Not all projects are hosted on GitHub. Those projects must ensure they meet this criterion.

When you’re done, you can select “Save and Continue” or “Save and Exit” to save your work to the website. The “Save and Continue” option not only lets you continue, but also reruns automations to fill in currently unknown information.

The Best Practices Badge site currently supports version v2025.10.10, but it will soon integrate the recently released v2026.02.19. New requirements wil initially appear as “future” criteria, allowing maintainers to address updates without losing their current badge status. There is no reason to wait; projects should begin the process now, as the system will provide ample time to adapt to new criteria.

Displaying Your Baseline Badge

Once you’ve met the baseline-1 criteria, you can add some code to your repository to show off your badge. The site shows the code to add, and it follows the usual badge conventions. For example, in Markdown you would add this:

[![OpenSSF Baseline](https://www.bestpractices.dev/projects/ID/baseline)]
(https://www.bestpractices.dev/projects/ID)

If you’ve earned the baseline-1 badge, this Markdown code would show an image like this:

Advanced Integrations and Automation Options

We support various mechanisms to rapidly get information in and out of the badge system (replace “ID” with the project’s numerical ID), for example:

  • Project’s information (JSON): https://www.bestpractices.dev/projects/ID.json
  • Project’s baseline badge (SVG) https://www.bestpractices.dev/projects/ID/baseline
  • Proposed edit values: https://www.bestpractices.dev/projects/ID/SECTION/edit?PROPOSALS where PROPOSALS is &-separated key=value pairs. This highlights those proposals with a robot icon, so you can review them before accepting them. For example, in section “baseline-1” you can use the proposal “osps_ac_01_01_status=met” to propose setting the status of OSPS-AC-01.01 to “Met”. For more information, see the documentation on automation proposals.

You can also include a “.bestpractices.json” file in the repository that contains proposed values for a badge. If present, these values will be treated as automation results and highlighted during editing so users can decide whether or not to accept them. The .bestpractices.json documentation provides more details.

Why the Baseline Badge Matters

Our goal is to help OSS projects identify next steps to improve security and provide clear guidance. These capabilities help projects demonstrate measurable progress.

If you maintain an OSS project, visit https://www.bestpractices.dev and start working on a badge. If you use OSS, support those projects on which you depend as they strengthen their security practices.

About the Author

Dr. David A. Wheeler is an expert on developing secure software and on open source software.  He created the Open Source Security Foundation (OpenSSF) courses “Developing Secure Software” (LFD121) and “Understanding the EU Cyber Resilience Act (CRA)” (LFEL1001), and is completing creation of the OpenSSF course “Secure AI/ML-Driven Software Development” (LFEL1012).  His other contributions include “Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)”. He is the Director of Open Source Supply Chain Security at the Linux Foundation and teaches a graduate course in developing secure software at George Mason University (GMU).

]]> Advancing Package Repository Security Through Collaboration https://openssf.org/blog/2026/02/19/advancing-package-repository-security-through-collaboration/ Thu, 19 Feb 2026 21:12:19 +0000 https://openssf.org/?p=9607 By Kris Borchers

On February 2nd, the Open Source Security Foundation (OpenSSF) convened the OpenSSF Package Manager Security Forum, a cross-ecosystem working session focused on one of the most critical and complex challenges facing open source today: package repository security.

The forum brought together participants from across a wide range of package manager ecosystems, including JavaScript and Node.js via npm, the Python ecosystem via PyPI and conda-forge, Rust via crates.io, Ruby via RubyGems, PHP via Packagist and the Composer ecosystem, Erlang via Hex, the Java ecosystem via Maven Central, Perl via CPAN, the Swift ecosystem, as well as Go module ecosystems that operate without a traditional centralized registry.

While these ecosystems differ significantly in their technical designs, governance models, and historical paths, the discussion surfaced a strong set of shared challenges that cut across language, tooling, and community boundaries.

By design, the conversation was held under Chatham House Rule, enabling candid and experience-driven dialogue while ensuring that insights could be shared publicly without attribution.

Key outcomes from the discussion

While the details of individual contributions remain private, several cross-cutting themes emerged that resonated across ecosystems:

  • Identity and account security remain foundational challenges. Ecosystems that rely on external identity providers, as well as those operating their own authentication systems, face common difficulties in ensuring strong and durable maintainer identity over time, particularly as projects grow, change hands, or scale beyond their original communities.
  • Security expectations vary widely across packages and users. Participants highlighted the need for more nuanced ways to signal security posture, recognizing that package consumers range from individual developers to large enterprises and governments, and that not all projects can or should meet the same requirements at the same time.
  • Governance and abuse handling are under increasing strain. As package volume, automation, and dependency reuse continue to scale, registries are being asked to make harder decisions around malware handling, namespace and ownership disputes, account recovery, and policy enforcement, often with limited resources and volunteer capacity.
  • Transparency and auditability are gaining importance, but remain complex. Across ecosystems, there is growing interest in publishing security- and governance-relevant events in a structured way, alongside careful consideration of privacy, legal, and operational implications.
  • Sustainability is inseparable from security. Whether ecosystems are volunteer-driven, foundation-supported, or commercially backed, participants consistently acknowledged that long-term security improvements require clearer funding models, better cost visibility, and realistic expectations around support and service levels.

Why this matters

Package managers are deeply interconnected. A security failure, policy decision, or design choice in one ecosystem can quickly ripple into many others through shared tooling, transitive dependencies, and downstream consumption. The challenges discussed at the OpenSSF Package Manager Security Forum are therefore not isolated problems, but shared ecosystem concerns.

This discussion reinforced a clear conclusion: progress depends on coordination, not duplication. While no single solution fits every ecosystem, shared frameworks, common language, and mutual learning can significantly reduce friction and improve outcomes for everyone involved.

OpenSSF’s role

OpenSSF organized and facilitated the OpenSSF Package Manager Security Forum as part of its ongoing commitment to strengthening the security and sustainability of the open source ecosystem. By providing a neutral and trusted forum, OpenSSF enables maintainers, registry operators, and security practitioners from across ecosystems to exchange insights, surface common needs, and explore collaborative paths forward without prescribing outcomes or privileging any single approach.

Looking ahead

The OpenSSF Package Manager Security Forum represents an important step in an ongoing conversation, not a one-time event. As package manager ecosystems continue to evolve in response to new security threats, regulatory pressures, and user expectations, OpenSSF intends to continue convening space for dialogue, learning, and coordination across communities. Future work will focus on identifying where shared guidance, tooling, or frameworks can reduce duplication of effort, support ecosystem autonomy, and help package managers advance security in ways that are practical, scalable, and sustainable.

We look forward to building on the momentum created through these cross-ecosystem conversations. If you would like to join the conversations and help secure these package repositories, and especially if you work on or contribute to a package repository, come join the OpenSSF Securing Software Repositories Working Group via our Slack in the #wg_securing_software_repos channel and our community meetings.

Author Bio

Kris Borchers is a Senior Technical Program Manager for the OpenSSF who helps drive key open source security initiatives that strengthen software supply chains, advance public-sector engagement, and empower global communities. His work spans vulnerability data, secure-by-design practices, policy collaboration, and academic accreditation, connecting industry, government, and academia.

]]> EU Cyber Resilience Act (CRA) in Practice @ FOSDEM 2026: From Awareness to Action https://openssf.org/blog/2026/02/17/eu-cyber-resilience-act-cra-in-practice-fosdem-2026-from-awareness-to-action/ Tue, 17 Feb 2026 20:20:41 +0000 https://openssf.org/?p=9593 By Madalin Neag, Megan Knight, Philippe Ombredanne, and Roman Zhukov

Over the past few years, the free and open source (FOSS) community has engaged deeply with the CRA, highlighting its significance and potential impact. With the clock ticking towards mandatory compliance, it is essential to move from abstract awareness such as,“Oh no, regulations!” to practical, actionable steps: “Here’s how we actually do this.” 

The CRA in Practice DevRoom at FOSDEM 2026 brought together developers, maintainers, stewards, and manufacturers to do just that: explore practical approaches to the upcoming EU Cyber Resilience Act (CRA). With less than two years until the regulation becomes mandatory, the topics in this DevRoom took the conversation from policy awareness to concrete readiness – offering guidance, tooling, and collaboration strategies for achievable, transparent, and sustainable compliance.

We want to begin by acknowledging Roman Zhukov (Red Hat and co-chair of the WG Global Cyber Policy) as the primary driver and main organizer of this DevRoom. His leadership and dedication with the coordination, communication, organization, and logistics for the DevRoom was instrumental for its success.

Our gratitude also goes to the other organizers for their vision and coordination shaping the program and supporting the DevRoom: Megan Knight (Arm; Global Cyber Policy Awareness SIG chair), Philippe Ombredanne and Adam Herzog, and Madalin Neag (OpenSSF).

And thank you to our volunteers for ensuring all of the sessions ran smoothly throughout the day, including Arnaud Le Hors (IBM), Cassie Crossley, Dan Applequist, Götz Martinek, Charlie Dixon (Arm), Jaroslav Reznik (Red Hat).

The DevRoom featured a rich mix of case studies, practical demonstrations, and panel discussions, including the following:

  • Deutsche Bahn shared how modular FOSS tools helped them translate CRA obligations into both organizational and technical workflows for a large, complex organization. 
  • The challenges of multi-vendor EV charging infrastructure were highlighted, showing how compliance can be integrated directly into operational protocols like OCPP to manage tens of thousands of devices efficiently. 
  • Erlang/OTP and the Yocto Project presented their approaches to CRA readiness for open source and embedded systems, including automated vulnerability scanning, SBOM generation, OpenVEX statements, and lifecycle tracking, illustrating how both community-driven projects and complex hardware/software systems can implement compliance in practice. 
  • Security attestations were discussed and how, if implemented correctly and with respect for open source communities, they could help manufacturers demonstrate due diligence while supporting ecosystem sustainability. 
  • Community management, stewardship, and open data sessions emphasized the human and ecosystem dimensions of CRA readiness, showing that practical compliance relies not only on tools but also on structured processes, collaboration, and clear workflows. 
  • A panel on CRA stewards explored the practical realities of implementing the steward role as defined by the regulation, the responsibilities emerging in practice, and how organizations are approaching this evolving function. 
  • Separately, a panel on FOSS maintainers focused on the questions that volunteer contributors face: which CRA obligations might affect their projects, how to position projects proactively without formal compliance structures, and how industry stakeholders can support the open source components embedded in their products.
  • Sessions on VEX and curated open data demonstrated how accurate, machine-readable information can streamline compliance automation and provide actionable insights for both maintainers and manufacturers. 
  • Finally, risk management sessions guided participants through assessing product context, identifying assets and threats, and defining risk treatment strategies, highlighting that CRA compliance is ultimately a structured, repeatable, and risk-based practice.

The discussions reinforced that:

  • CRA readiness is a shared responsibility. 
  • Open collaboration, community-driven tooling, and structured workflows enable compliance for projects of all sizes. 
  • Stewards and foundations play a crucial role in guiding maintainers and contributors, while manufacturers can meet due diligence requirements efficiently. 

Effective CRA readiness depends on the right combination of open source tooling, repeatable processes, and collaboration across projects and organizations, ensuring compliance efforts are practical, transparent, and aligned with the principles of the open source community.

The FOSDEM 2026’s CRA in Practice DevRoom successfully translated the EU Cyber Resilience Act from abstract legislation into practical, actionable steps. Attendees left with concrete strategies, reusable workflows, and inspiration to move from uncertainty toward a secure and compliant future.

Special thanks go to all submitters, presenters, and panelists. We apologize that we could not fit all the excellent submissions into the program: every contribution was highly valuable, and the selection process was extremely difficult. We hope to have a full day next year to accommodate everyone!

We also deeply thank the FOSDEM organizers and volunteers for their tireless efforts, and the huge number of participants who joined us, engaged with the discussions, and showed genuine interest in CRA readiness. Your presence, questions, and feedback energized the sessions and reaffirmed the importance of collaboration in the open source ecosystem. Apologies to those who were patiently waiting when the room was completely full – we very much value your interest. On behalf of open source community, a very special thank you goes to the representatives from the EU Commission, EU member states agencies, policymakers, standardization bodies officials who attended and supported CRA in Practice DevRoom, reinforcing commitment to joint, open collaboration as the only way to achieve the CRA goals.

We are already looking forward to repeating this exercise and hope to see you all next year, continuing to build a path toward a more resilient, transparent, and sustainable future for open source software, where practical compliance strengthens communities, fosters trust, and enables innovation across projects of all sizes. For those who could not attend or want to revisit the sessions, all videos from the DevRoom are available at the following link. 

 About the Authors

Philippe Philippe Ombredanne is the lead maintainer of the AboutCode stack of open source tools for Software Composition Analysis and license and security compliance, including the industry-leading ScanCode, DejaCode, PurlDB, Package-URL, and VulnerableCode. Philippe contributes to other open source projects, including the Linux kernel SPDX-ification, SPDX, ClearlyDefined, strace, ORT, and several Python tools.

Megan Knight is the Director of Software Communities at Arm where she leads upstream engagements with open source communities across the stack. She wears a variety of hats including OpenSSF Governing Board Member and Global Cyber Policy SIG Lead, Yocto Project Board Member and Advocacy Chair, UXL Foundation Steering Committee Member, and Zephyr Project Board Member Representative. Prior to Arm, Megan was building the IoT and Automotive open source portfolio at Amazon Web Services.

Roman Zhukov is a cybersecurity expert, engineer, and leader with over 17 years of hands-on experience securing complex systems and software products at scale. At Red Hat, Roman leads open source security strategy, upstream collaboration, and cross-industry initiatives focused on building trusted ecosystems. He is an active contributor to open source security and co-chair of the OpenSSF Global Cyber Policy WG.

Madalin Neag works as an EU Policy Advisor at OpenSSF focusing on cybersecurity and open source software. He bridges OpenSSF (and its community), other technical communities, and policymakers, helping position OpenSSF as a trusted resource within the global and European policy landscape. His role is supported by a technical background in R&D, innovation, and standardization, with a focus on openness and interoperability.

]]>