Open Source Security – Open Source Security Foundation

Jun 16

What’s in the SOSS? Podcast #63 – S3E15 Big Thoughts, Open Sources: Driving Enterprise Security and Career Growth Through Open Source with Jamie Thomas (IBM)

By OpenSSF Podcast

Summary

In this episode of Big Thoughts, Open Sources, host CRob sits down with Jamie Thomas, IBM Enterprise Security Executive and OpenSSF Governing Board Member (former Chair!), to tackle the vital shifting dynamics of enterprise open source engagement. From IBM’s historical “billion-dollar bet” on Linux to modern supply chain wake-up calls like SolarWinds and Log4j, Jamie pulls back the curtain on what it truly means to move from accidental consumption to intentional stewardship. Tune in to discover how active participation in neutral foundations like the OpenSSF acts as a fast track for engineering career trajectories, why soft skills like “the art of influence” are critical for upstream collaboration, and how organizations can protect their crown jewels while implementing a powerful “give-back strategy.”

Listen on Apple Podcasts Listen on Spotify Listen on Overcast Listen on Pocket Casts

Conversation Highlights

00:00 – Intro Music + Promo Clip
00:21 – Introduction & Welcoming Luminary Jamie Thomas
01:32 – Wearing the Enterprise Security Hat at IBM
02:10 – Supply Chain Wake-up Calls: From SolarWinds to Log4j
03:14 – Unlocking Open Ecosystems: IBM’s Early History with Java and Linux
05:21 – Mainframe Debates and Portability: The Evolution of Open Source Adoption
06:24 – The Red Hat Acquisition and Monetizing the Developer Ecosystem
08:20 – The Myth of “Free” Software: Securing Regulated Enterprise Deployment
10:15 – Why a Seat at the Table Matters: The Value of Neutral Foundations
11:29 – The Art of Influence: Upstream Contributions as a Career Catalyst
13:50 – Moving Innovation from Open Source Kernels to Commercial Value
16:12 – Storming, Norming, and Conversation: Lessons from the Kubernetes Era
17:38 – Pitching Upstream Time: Helping Developers Sell Open Source to Management
19:30 – Beyond Code: Bringing Domain Expertise and Soft Skills Upstream
21:40 – Conquering the Chasm: Automating CI/CD Pipelines and Testing at Scale
22:56 – Consuming with Intent: Active Stewardship and the OpenSSF Scorecard
25:21 – Rapid Fire Round: Mainframes, AI-Generated Code, and Star Trek nostalgia
27:53 – Call to Action: Crafting Your Organization’s “Give-Back Strategy”

Episode Links

Transcript

Music & Intro/Promo clip (00:00)
If you’re a direct consumer of open source, do it with intent. And intent means that you’re responsible for what that means to your organization, both from a productivity perspective, but also from a security perspective and what you can expect from an investment point as well. You have to be an active steward in the maintenance of your open source strategy, just like you would have to be a steward of the maintenance of your own home.

CRob (00:26)
Welcome, welcome, welcome to Big Thoughts Open Sources. My name’s CRob. I’m your host today. This is a special video series where we’re talking to some of the leaders within open source. And today we have an amazing treat. We have Jamie Thomas from IBM. It’s a little company you might’ve heard of. And she’s here today to kind of talk about maintaining a career and influence within open source. Welcome, Jamie.

Jamie Thomas (00:54)
Thanks, Crob. Thanks for having me.

CRob (00:56)
I think we’re going to have a pretty amazing conversation today. For those of you that might be unfamiliar with kind of the luminaries that exist within our little slice of open source security heaven, Jamie has been alongtime contributor and member to the OpenSSF, predominantly through influence through our Governing Board. You actually were our Governing Board Chair for a period of time. So for those that may be unfamiliar with you, could you maybe talk about what your current role is at IBM and kind of what you do within the OpenSSF?

Jamie Thomas (01:32)
Absolutely, and thanks for having me again. I think this is a really interesting topic. At IBM, I have a couple of hats, but the main hat that is important to this discussion today is IBM Enterprise Security Executive. And I’m therefore responsible for the protection of the IBM company. It includes our CISO office, our Cybersecurity Operations, as well as our Product Security, which has to span a number of our units, including our software, hardware, our consulting unit. So it’s an interesting job.

CRob (02:05)
Really big job.

Jamie Thomas (02:10)
Yeah, and you know, as you know, CRob, I got involved in OpenSSF from the very beginning of the Governing Board. And I remember when I got involved in enterprise security, someone told me, by the way, it’s all quiet, there’s not much going on right now. And, and the first thing that I recall happening not long after that was SolarWinds, which was one of the first interesting supply chain attacks. And then of course, we had Log4j, which is another whole realm of fun.

But certainly I felt that joining OpenSSF has been important for us, the IBM company, to stay abreast of what’s happening in the industry and to be a participant in this open source security realm. It continues to be an ever changing landscape.

CRob (02:53)
Absolutely, a blink and it totally changes. It’s a pretty wild space we get to live in. Thinking back through your career here, was there a moment or something that really sparked your interest that kind of drew you towards more open source perspectives, participation?

Jamie Thomas (03:14)
Yeah, yeah, absolutely. I mean, when I started IBM, I did start as a programmer in the software organization. And at that time, of course, we worked on, like all of the industry, probably at that time, closed source systems. But at some point in IBM, we got very involved in something called Java. As part of…

CRob (03:32)
I’ve heard of it.

Jamie Thomas (03:34)
Haha, yeah you’ve heard of Java…As part of Java, we wanted to engender an open ecosystem around the Java programming model.
And to that end, we realize we’re not going to attract developers at scale without a different approach.

And so we made some concerted decisions at that time. One was that we would invest in Linux. There was something called Linux at that time. And we made a decision to put into the corporation Linux Technology Center to invest in Linux, be open source contributors to the Linux operating system. And the other big decision we made is that we would outsource some of our Java development tooling to something called the Eclipse Foundation.

CRob (04:16.691)
Mm-hmm, oh yeah.

Jamie Thomas (04:17)
So it seems like, you know, tribal knowledge at this point, but to say the least, embarking on some of these endeavors was quite unique for the IBM company at the time. And getting people to understand their role within an open source community as opposed to what we had always traditionally done in terms of how we provided software to clients was very, different.

And I had the pleasure of being involved in both the Java effort and the Eclipse Foundation effort through our Rational Software Division. And at that time, I actually owned all of the folks that were contributing to Eclipse and got to see that evolve for a period of time. You know, that was very, very fascinating times for IBM and also, I think, important for the evolution of open source that we have today.

CRob (05:09)
Well, in thinking further downstream, the folks, the organizations that would be your customers, Java was probably one of their, also their entry points into the open source ecosystem.

Jamie Thomas (05:21)
Mm-hmm. It absolutely was because you found through the eyes of lot of our enterprise clients as they adopted Java, they were naturally then adopting Eclipse. And over a period of time, they certainly became very strong supporters of the Linux operating system. And in fact, I remember one of the first meetings we had where we actually were in a room with all these clients and there became this huge argument, this huge argument about whether we should put on the IBM mainframe.

And you can imagine, there were a variety of opinions in that room. But what made sense, if you thought about it, is that Linux would give us portability. And if folks developed on Linux, of course, then ultimately portability to different hardware platforms, of course, would be gained through Linux. And that’s exactly what did happen.

But at that time it was a very, very novel concept that we should embrace this new operating system. And so it was fun, fun stories.

CRob (06:24)
Speaking of fun stories, several years back, IBM made the air quotes, billion dollar bet on Linux and kind of looking back at kind of IBM’s initial involvement with the ecosystem and Java, and then through the acquisition of Red Hat, kind of thinking about what was the most difficult part kind of moving these massive enterprises towards an open source first mindset.

Jamie Thomas (06:53)
Well, I think that by the time we made that multi billion dollar bet on something called Red Hat, our perspective of open source had matured quite a bit. We had then already discovered and learned that we did.

CRob (07:02)
Mm-hmm.

Jamie Thomas (07:03)
We had then already discovered and learned that we did. monetize quite well the Java ecosystem and part and parcel to what we did around Eclipse and Linux. We’d also adopted scale Linux on our platforms on both the Z platform in particular and Power and also we were stewards of Linux on x86 for our clients. So we had a different perspective. And I think at the time we acquired Red Hat though, we did understand the needle had moved quite a bit on the developer ecosystem. In that period of time since we had first started some of these efforts and that Red Hat would enable us to have a bigger stake in the open source community as well as the ability to reach developers at scale.

And that was part of the motivation for the acquisition and I think that it definitely served us well. I believe that what Red Hat does, curated open source is something that’s really important for the industry to have a competent enterprise level open source provider, but that once again,has their finger in the pie around the open source community because that’s where everything happens. It happens in the community and then it has to bubble upstream and be effective for the enterprises that are consuming it.

CRob (08:20)
I know we’ve talked many times that you get the opportunity to talk to a lot of business and cyber leaders at firms that you partner with. Kind of when you’re providing advice and counsel to these leaders, how do you kind of reassure them that they’re not going to be contributing to open source isn’t going to be giving away their secret sauce or their crown jewels? How do you encourage them in engaging more and more effectively with open source?

Jamie Thomas (08:50)
Well, I think there’s two different perspectives. And when you talk when I talked to a lot of the client organizations, I think they have pretty much accepted that open source is a valuable asset to them. What they’re then looking for is who can help me ensure that I’ll have operational fidelity, security around this open source. And that’s when they then start to say, should I have a trusted vendor to work with on that point? Or am I going to consume it directly?

And, and certainly, Isee that early on in the acquisition of technology that many enterprises just take the open source and try it out. I mean, that’s one of the benefits, right? You can try it out. You can test drive it, you can decide if it works for you. But then normally, if you go into enterprise deployment, you do want someone that’s going to be there. In many cases I’m going to provide the care and feeding for you, particularly if you’re in a regulated industry. And of course, we deal with a lot of regulated firms and in our environment.

I also also make sure that I remind everybody involved, including ourselves and our ecosystem, that open source is really not totally free. I mean, it’s something that we all have an obligation to support. So if we’re consuming it, we need to understand what that means and we need to be stewards of ensuring that the open source communities are successful going forward.

CRob (10:15)
That’s an interesting point that leads me to my next question. How vital is it for enterprises to participate in neutral bodies like the OpenSSF or Eclipse or CNCF, rather than just trying to take all these amazing tools and kind of assemble it themselves, how does that neutral collaboration help them?

Jamie Thomas (10:36)
Well, I think it’s very important for you to, as an organization to have a seat at the table, if you will, realizing that in today’s world, you know, software doesn’t stay in the boundaries of one company. I mean, there’s an extensive ecosystem out there, we’re all somewhat interconnected. And if you’re at the table, you have an ability to influence the direction of a lot of these projects, you had the ability to contribute uniquely, but most importantly, to make sure that the projects understand your unique point of view. Certainly there’s a point of view of technology organizations like IBM. There’s a there’s a the the point of view of the startups out there that are so critical to the ecosystem. And there’s the point of view of the consuming enterprises, the downstream enterprise, I think all of those play a critical role in having that seat at the table.

CRob (11:29)
I absolutely agree. So as we continue our conversation here and getting more to, think, is one of your true areas of passion.

From your perspective, you’ve seen a lot of engineers in your career and you’ve seen them become kind of strong speakers and potentially global influencers through this open source ecosystem. From your perspective, do you see active participation in like open source projects as some type of a fast track towards leadership for engineers?

Jamie Thomas (12:04)
I think it’s one of those many facets that can really improve your career trajectory. The reason I think this is that for any accomplished computer science engineer today, you really have to have the ability to influence others. You have to have the ability to influence networks. Maybe that’s outside of your organization or inside of your organization. You have to have the ability to influence your customers.

And so how do you build that kit bag of resources and skills that allow you to do that? And I think participation in an open source community gives you a lot of industry perspective.

You know, when I go to the OpenSSF, I don’t just go there and understand, of course, what my point of view is, I’m understanding the collective point of view. And that collective point of view is very interesting and fascinating. Learning from others and then having that ability to share your unique perspective with clients and even in your internal organization is a skill that many people often underestimate.

The skill of influence is something that’s really important in today’s world. And I think that you can build that. You can also strengthen your own personal presentation skills.

I’ve seen many people presenting in a lot of these forums, whether they’re presenting at one of the conferences or presenting in a governing board or presenting at one of the breakouts. And it really is, once again, an opportunity for you to build your own personal presentation skills, understand how you can represent your ideas more effectively to another organization or set of organizations. And that is something I think is critical for a lot of individuals that are pursuing a different career trajectory.

CRob (13:50)
Mm-hmm. I really appreciate that insight. If thinking about this, how important is it for an engineer to have kind of this open source pedigree, whether it’s like a recognition, like your IBM Open Innovation Awards or other types of awards? How does participating in those things help that individual stand out, especially in this age where organizations are rapidly changing and pivoting?

Jamie Thomas (14:19)
Well, thanks for bringing that up IBM does have an open innovation award that we give to individuals every year who are standouts in the participation of open communities. And I think that’s really important. And we have both executive contributions as well as non-executive contributions and I always recognize those individuals in my all hands meetings to make sure they get their name in lights a bit internally. But I think that this is particularly important for individuals who once again want to take the learning from these kind of communities and use that to more broadly influence the direction of organizations. In many cases and I was just on one of these today in fact a lot of the innovation does start in an open source format because once again it’s very easy to get your ideas out there to start seeing them scale understand what really appeals to clients and what is not then how do you take the open source kernel and then create something that is of commercial value right.

You either have to have the concept like we did with Eclipse that it’s going to enable developers to use other products more effectively, or you have to take the kernel and then become an enterprise open class support organization like what Red Hat did eventually…

CRob (15:41)
Mm-hmm.

Jamie Thomas (15:42)
Very accomplished open source curation organization. So I think for individuals to help companies like IBM or to help their team to help their little asset that they created become more successful, then this participation is absolutely critical. And without a few individuals along the way that really understand how to do this, then I think many, many rewarding projects will not get from point A to point B and be as successful as they could have been.

CRob (16:12)
Right, Yeah, I definitely agree with that. So how…

Jamie Thomas (16:17)
I mean, look at things like probably, you know, Kubernetes or many of the things that we recognize today is just we take for granted without that kind of vested participation support would they have become what they are today? I mean, Linux is the best example, of course.

CRob (16:36)
I absolutely agree. Kubernetes is another example of where we had an organization that had an idea and there were some competing ideas at the same time. And then that project was donated to a neutral foundation where all these fierce competitors could get together and work together in that space to help make the technology itself far more impactful than it ever would have been.

Jamie Thomas (17:00)
Yes. And I hear I hear behind the scenes, even though I was not part of all of that directly, that there was a little bit of storming and norming and maybe a few disagreements along the way and everything.

CRob (17:10)
Yep.

Jamie Thomas (17:11)
But eventually, you know, some really good things came out of that. And, you know, it’s like anything when you nothing, nothing really good is achieved in my mind without conversation, you know, without really having a human dialogue to understand what’s working and what’s not. Certainly big things are not achieved typically through subterfuge and so I think that is the value of a lot of these communities.

CRob (17:38)
I agree. So when you’re thinking about, again, from the developer maintainer perspective, what’s advice you would give to give a developer to pitch to their manager about spending some part of their time working upstream, hopefully in security, but participating in an upstream project? How do you help them sell that to their management?

Jamie Thomas (18:01)
Well, I think in many cases, the individual needs to take a point of view of what’s in it for my manager, right? I mean, it’s kind like when you’re trying to sell anything, right? There are certainly clear attributes that help you as an individual, right? Can improve your leadership skill, your ability to help the manager from that perspective, I think is quite valuable. Problem solving is something we often take for granted today, but it’s not always there, right? But then the other thing is what what particular.

But will the participation aid from a business perspective? And I think there’s a lot of different aspects of that. If someone’s working in the security domain, I think there’s really clear outcomes.

where their participation will benefit for the enterprise you learn so much right in terms of what you need to do. If you’re working in a particular project that is going to have downstream impacts possibly to the organization I think there’s a clear linkage there. But first of all never take for granted that everyone does understand open source.

I find that even in today’s environment, there’s a lot of upline management or senior executives perhaps don’t understand the importance of open source and open source participation. It’s kind of like the water that’s running in our house and we just think it’s gonna always be there. It’s always gonna be on, right? So building that cell package is important. It’s important.

CRob (19:30)
So from, again, your perspective, outside of having some coding skills or some other technical ability, what other types of specific things should people think about when they’re going to go engage upstream? Are there other abilities or skills they might be able to bring to bear to help upstream?

Jamie Thomas (19:52)
Well, I think that coding skills are one but don’t underestimate just basic ability to influence basic ability to bring technical perspectives together and drive a conclusion. I mean, we’ve certainly seen a lot of that in the OpenSSF right where the technical committees have really had to come together and you’ve been a big part of that to render a recommended outcome right that’s influence and getting people to agreements really important back to your Kubernetes point. Somebody had – a group of people had to get some level of agreement to move forward. So influence is really important. Having domain knowledge of things like security, of secure CICD practices, sharing that with organizations I think is really, important. That’s one of the things you know that we’re really focused on is not how do we just create best practices and tools, but how do we help other projects consume those tools at a faster rate and pace.

So individuals that have that passion, who have the ability to help teams be more successful, those are maybe some soft skills that I think a lot of projects really need.

CRob (21:04)
And I think that that’s, hear this a lot from non-developer folks that are interested in contributing is, you what could I possibly bring to the table? I’m not a coder. I don’t understand C or Rust or Go. And I tell them, you have value, you have domain expertise, you understand networking or like CI systems far better than most software engineers do because software engineers are studying the language or a particular community. They don’t necessarily have a lot of these additional skills like program management and communication.

Jamie Thomas (21:40)
Yeah, and one of the things I remember the most about, you know, one of the IBM projects I worked on WebSphere is one of the most fundamental investments we made was automating the CI-CD pipeline in a really cool way. And of course, this was 20 years ago. But I’ll remember that point, like it was yesterday, because our lives change when we achieve this automation at scale. And so I think that that kind of thing can have a huge impact on the projects today. One of things we’ve been talking about as you know with all the AI mania that’s out there these days is one thing to find the defects but how do you fix the defects and actually test them at scale?

So we all know the secret of many software projects is while we have a lot of software out there, testing them in an automated fashion even is quite a challenge for many organizations and many projects. So those people that are able to conquer those leaps across the chasm help with that CI/CD automation, help infuse security, or help create a different perspective of how to automate the test associated with not only remediating but making sure that we’re not breaking everything that’s out there that uses that particular asset. Small thing.

CRob (22:58)
Yeah, very small. So again, let’s pivot back to your conversations with enterprises and leaders broadly. How do we help move the industry from thinking about open source is something that’s consumed to something that is more of your steward? Your participant in this shared infrastructure?

Jamie Thomas (23:21)
Well, I think we have to continue what we’re doing here in this session. Really, we have to continue to provide a lot of education and perspective about what happens when you don’t do that. Right. This is, you know, it’s like, you know, my house, I do wake up every day and I expect the plumbing, the water and electricity to run. But on the other hand, if I’m not a good steward of the basic underpinnings of some of that capability, it might not always be that way. And I think there’s the same can be said about open source.

So when you consume it, you have to consume it, I think, with a recognition that it’s a critical part of your infrastructure investment. You should understand what you’re consuming. should typically I don’t think it should be accidental consumption unless you’re depending on perhaps a packaged app vendor to provide it to you. And then that could be something that you’re unaware of, right? S bombs and things like that are particularly making that more apparent, of course.

But I think if you’re a direct consumer of open source, do it with intent. And intent means that you’re responsible for what that means to your organization, both from a productivity perspective, but also from a security perspective and what you can expect from an investment point as well. One of the things that we’ve learned through the OpenSSF is not every project maintains a healthy state over a period of time. And so that’s why we’ve created this scorecard that gives organizations a perspective of whether the project is healthy.

And I think today, if you’re consuming open source, you need to be using those kind of assets to understand, are you consuming healthy projects? If not, what do you want to do about that? Right? So it’s you have to be an active steward in the maintenance of your open source strategy, just like you would have to be a steward of the maintenance of your own home.

CRob (25:21)
I love that. participating with intent and having a strategy. That’s excellent advice.

Jamie Thomas (25:25)
Yeah, it shouldn’t be an accidental consumption approach. It should be with intent.

CRob (25:36)
Right. Well, let’s move on to the rapid fire part of our talk. I have a couple wacky questions. I would just like the first answer off the top of your head, please. Blue suits or blue jeans?

Jamie Thomas (25:53)
I think both. I have a blue jacket on today. What am I supposed to say?

CRob (25:55)
Both very nice. That was kind of a leading question. Next question, mainframe or microservice?

Jamie Thomas (26:10)
Oh, both. Oh, I’m cheating on this quiz. But you know, I do have the fondness for mainframes. Here’s my little mainframe chip, you know, the chip package here. It’s like a little paperweight, right? This one is z 16. I don’t have z17. But anyway, and then microservices, I think the world does depend on microservices. Very, very important part of the architecture.

CRob (26:33)
And I heard you can run open source microservices on a mainframe.

Jamie Thomas (26:37)
That’s right, that is true.

CRob (26:40)
AI generated or hand coded?

Jamie Thomas (26:44)
Well, I think in today’s environment AI generated is becoming quite prevalent, but I do believe that developers who are standouts are gonna be those individuals that go back in there and use it to their advantage. So I think there will be humans in the loop or humans somewhere in many cases, and it’s up to the human to decide how do I use this cool innovation to my personal advantage.

CRob (27:12)
That’s amazing. And then finally, most importantly, Star Trek or Star Wars?

Jamie Thomas (27:19)
Now I have to confess that I was a Star Trek person growing up, right? I watched those cool Star Trek episodes and everything so I guess I’m more partial to Star Trek.

CRob (27:34)
There are no wrong answers, both are good, but it’s just kind of fun. I love both. I grew up on Star Wars and then Star Trek and then Star Wars changed my life in 77.

Jamie Thomas (27:43)
Well, I do like Princess Leia, of course. Being a woman, Princess Leia was a hero for all of the young ladies out there. Quite good. Good stuff.

CRob (27:53)
Absolutely. Well, and so as we wind down, Jamie, thank you for playing along. Your call to action. So if we have an enterprise that’s only consuming open source today, what’s one thing that you would suggest to them to get them to start participating?

Jamie Thomas (28:12)
I would ask everybody to think about what is your give back strategy?

Because if you’re consuming open source, but you’re not participating in open source projects, maybe with your developers, you’re not participating in an organization in terms of lending your unique perspective of your strategy and how the foundation or the open source project could help you with your strategy. You could do that even through maybe just the use of open source and beta testing, but be an active participant.

Think about consuming with intent. And what does consuming with intent mean for you as an organization?

CRob (28:54)
I love it. Thank you, Jamie Thomas, for participating in Big Thoughts Open Sources. This was a delight. Thank you very much.

Jamie Thomas (29:06)
And thank you very much, CRob. It’s always good to talk with you.

CRob (29:09)
Absolutely – and to those of you listening today, please check out the transcript, we’re gonna have some really great links and you know, stay cyber safe and sound. Bye everybody

Jamie Thomas (29:20)
Bye.

Jun 02

Love0

What’s in the SOSS? Podcast #62 – S3E14 The Ghost in the Dependency Tree: Navigating Open Source End-of-Life with HeroDevs

By OpenSSF Podcast

Summary

In this episode of What’s in the SOSS, host CRob sits down with Isaac Wuest, Product Line Leader at HeroDevs, to explore the critical and often overlooked “gray area” of the software supply chain: End-of-Life (EOL) software. While the industry heavily relies on CVEs to track vulnerabilities, Isaac explains how maintainer abandonment creates a vacuum where risks are present but remain undiscovered and unreported. From the origins of HeroDevs supporting AngularJS to the nuances of the EU Cyber Resilience Act (CRA), this conversation provides a practical framework for distinguishing between inherent hazards and actual risk in your dependency tree.

Listen on Apple Podcasts Listen on Spotify Listen on Overcast Listen on Pocket Casts

Conversation Highlights

00:04 Host CRob welcomes Isaac Wuest from HeroDevs to discuss secure open source ecosystems.
00:45 The HeroDevs origin story: How Google sunsetting AngularJS created a need for secure drop-in replacements.
02:44 Isaac’s path to open source: Transitioning from product management to supporting maintainers.
04:06 Exploring the “Gap” in CVEs: Why dictionary-based vulnerability tracking misses EOL and malicious packages.
07:03 The challenge of “Maintainer Attestation”: Why most open source projects lack a formal EOL calendar.
09:52 Compliance and Risks: How EOL dependencies create blank spots for security professionals and auditors.
11:27 The Shark in the Tank: Using a food regulation analogy to differentiate between hazard and risk.
13:22 Navigating the EU Cyber Resilience Act: Preparing for increased manufacturer accountability in software.
14:08 Maintainer Abandonment: Identifying the moment a project stops receiving patches without formal notice.
16:14 Scanning for Gaps: Why standard industry tools currently struggle to provide a complete EOL picture.
18:49 Practical Remediation: Recommendations for researching upgrade paths using tools like endoflife.date.
20:49 Analyzing SBOMs: How engineers can leverage free datasets to identify and fix deep dependency risks.
23:00 Rapid Fire: Coffee, Star Wars, spicy food, and the favorite apocalyptic robot.
25:01 Final Thoughts: A call to action for educating yourself on your application’s EOL exposure.

Transcript

CRob (00:04.053)
Welcome, welcome, welcome to What’s in the SOSS, the OpenSSF’s podcast where I talk to people that are in, around, and creating this amazing open source ecosystem that we all benefit from. Today, we have a pretty interesting guest with some pretty cool and timely topic. We have Isaac from Hero Devs. Isaac, welcome to the show.

Isaac Wuest (they/them) (00:26.474)
Awesome, thanks for having me. I’m glad to be here.

CRob (00:29.197)
Yeah, so everybody that listens to our podcast may or may not know the HeroDev story. Could you maybe explain a little bit about your company that you’re representing and then maybe give us a little peek into your open source origin story? Like what got you into this space?

Isaac Wuest (they/them) (00:45.694)
Absolutely, absolutely. So the story of Herodevs actually goes back to the story of AngularJS and when Google decided to sunset support for Angular. So Herodevs as a company started a few folks that were on the Angular team, realized that Google was sunsetting support and that there would be breaking changes and people would need a secure version that was supported and being patched in the future.

CRob (00:52.256)
Mmm.

Isaac Wuest (they/them) (01:11.754)
And that was the birth of HeroDevs. HeroDevs as a company has expanded out of AngularJS to many other types of large open source frameworks where we offer secure drop-in replacements for the end-of-life versions. And that was kind of the inception of the company. What we do today is keep those versions secure. That being said, what we’re now doing and kind of moving more into is that end-of-life space more broadly, saying how can we support not just individual frameworks,

But when things go end of life, how can we make sure that there are secure versions available across a deeper range down in the dependency tree for companies?

CRob (01:52.545)
Makes a lot of sense. I just had the opportunity to read the recent Sonotype stated supply chain report. And I think the new number of dependencies for commercial applications is around 1,100 on average. So this is a pretty, pretty big issue, huh?

Isaac Wuest (they/them) (01:59.79)
Mm.

Isaac Wuest (they/them) (02:06.754)
Yep, yep.

Isaac Wuest (they/them) (02:11.178)
It really is. We actually partnered with Sonatype on some sections of that report there came from some of our data. you’re absolutely right. It’s a growing issue, both because the velocity of open source ecosystems, like the rate of new packages and new versions, continues to accelerate. And as you know, more more CVEs are getting reported year over year. So there’s this whole volume problem that is, I’m sure we’ll talk more about aspects of that. yeah.

CRob (02:15.585)
Thanks.

CRob (02:31.965)
yeah.

CRob (02:37.109)
We sure will. But before we get to that, how did you get into open source? What brought you to this meeting today?

Isaac Wuest (they/them) (02:44.744)
Absolutely, absolutely. So my interest in open source goes back about three to four years at this point. So a previous company that I worked at, I was good friends with several developers who were in the open source space. And they said, hey, we think you might really enjoy the space and enjoy learning about open source as a product manager. And I said, absolutely, I’d love to. So I first started working in open source in that environment where you’re working directly with maintainers. So I got to know

several hundred maintainers and was like, this is a really, really robust and a really, I love the ethos of the open source community. So I feel like you kind of get a taste of it and you go, wow, this is for me and I’ve been in the open source space ever since. Not as someone doing the hard work that everyone else does, but as a PM thinking, how can I support and help with all the important work everyone else is doing?

CRob (03:38.525)
What I love about open source is not everybody has to be the developer. There’s a room for a lot of different skills. That’s pretty great. Speaking of some different skills, and this is something that a lot of developers sometimes struggle with, let’s talk about security. Broadly, the ecosystem uses a tool called CVE, which used to stand for common vulnerabilities and exposures.

Isaac Wuest (they/them) (03:46.913)
Absolutely.

CRob (04:06.889)
And that was kind of a dictionary of these are the discovered vulnerabilities and this is how you can go learn more to protect yourself. CVS is an interesting methodology in a program. Had a couple challenges over the last few years. And there are also whole categories of things that lay people may see as a problem. Like your.

the end of life you teased or malicious packages. And these are things that aren’t accounted for in the CVE methodology. So from your perspective, what does that gap in the CVE program, what kind of risks or problems does that, not ignoring, but that not accounting for these other types of problems, what does that incur to consumers of open source?

Isaac Wuest (they/them) (04:59.083)
Yeah, yeah, that’s a really good question. And I will say that the answer to that question is still evolving. Now, my angle, like my perspective on it from the end of life side, is that, know, CVEs, of course, rely on this kind of public disclosure where someone discovers it, someone who’s kind of certified, I think they’re called a CNA, this is someone who’s allowed to report CVEs in the standard way, reports them.

And that’s great. Of course, CVEs have their limitations. So we have these other scores that are evolving, your EPSS and the known exploited and that system. But the predicate for all of those are that the vulnerability has been discovered and reported. Now, the problem there is that as packages or versions within packages in the open source space go end of life, meaning they’re no longer getting

security updates from that upstream maintainer, that upstream community. As that occurs, a second thing is happening as well. They’re not going to get patches or updates for CVEs. In addition, they’re typically no longer investigated for vulnerabilities to begin with. So it creates this, we just don’t even know, right? Maybe it’s vulnerable, maybe it’s not. Oftentimes, the maintainers around those packages don’t have the time to…

CRob (06:10.783)
Right.

Isaac Wuest (they/them) (06:21.557)
retroactively investigate every CVE on their entire version range to even see if it applies or not. So that space, those unknowns, create a real concern that the broader security market and the SDA space is trying to figure out how to react to.

CRob (06:39.937)
So from your experiences, especially dealing with upstream maintainers, how much attention does upstream pay to end of life? Is this something like I know commercial vendors generally will advertise we do support between X and Y dates. So from your experiences upstream, what does end of life look like or how much do they advertise that stuff?

Isaac Wuest (they/them) (07:03.373)
Yeah, it’s a good question. it’s extremely variable. So for large frameworks, if we’re talking about your Angular’s, your Views, your Springs, you can often use tools like endoflife.date or go directly to their sites and you’ll see their schedules. When, these are the versions, this is when it goes, LTS for that long-term support. And then here’s when LTS is dropped and that’s when it goes end of life. The problem is that that covers a very thin slice of the total number.

packages that are in open source. Most maintainers don’t have time to publish a calendar for their specific packages. As a result, it’s often very ambiguous. Unless we’re talking about those big frameworks, those big libraries, outside of that, it’s kind of like the maintainers know when they’re going to generally they’ll stop supporting major release lines once it’s two or three in the past.

When you talk with maintainers, what you learn is that it’s kind of ambiguous even for many of them. They’ll say, well, if a CVE is reported, I might be able to release a security patch. I might not. It kind of depends how busy I am. They’re volunteering their time. And that ambiguity makes it really challenging to know, well, how secure is it? Is it supported? That initial problem of are we investigating and reporting and patching risk on those older versions?

CRob (08:30.645)
And so again, from your experiences, how have developers or projects articulated this or do they at all?

Isaac Wuest (they/them) (08:38.871)
Great question. So apart from those large frameworks where they publish them on their sites, most of the time it’s an array of methodology. So sometimes they’ll post in the readme’s on their projects. You’ll see information about what’s being end of life. Status is like deprecated where in certain registries, NPM and others, can mark, a maintainer can mark and say, this release line or this version is deprecated. That’s a bit of a proxy for end of life.

Sometimes though, I’ve seen Twitter or X, like social media, be a primary mode where the maintainers of packages are saying, this is when I’m gonna be no longer supporting version 1.1.1. And it’s highly variable and that makes it really brittle for any large enterprise to rely on.

CRob (09:28.769)
Mm-hmm. Well, hey, let’s switch our focus a little bit. Let’s move a little bit more downstream. So let’s say I’m a security professional at an organization, or I’m a developer that’s working on some type of internal app that’s leveraging open source components. What does it mean to them when some dependency or package that they’re using becomes end of life?

Isaac Wuest (they/them) (09:52.814)
Yeah, that’s a great question. I will say, firstly, they’re still learning what it means in terms of compliance frameworks. So when something goes into life, there’s the security implications that we just talked about. Hey, it’s not going to get security patches, and it likely won’t get reports of vulnerabilities that may exist on it. Now, if I’m a security professional working at a company that

CRob (10:03.139)
yeah, yeah.

Isaac Wuest (they/them) (10:19.915)
You know, we have some number of applications we’re building that use that dependency. I know immediately that there’s this kind of blank spot there where even if risks aren’t being flagged by, you know, my security scanning tool of choice, I know that there may still be risks present. That might be a problem for that own company’s security posture, where they have their own standards and say, Hey, we can’t rely on that. Oftentimes what I see though, is that

The main motivation is the fact that it puts them out of compliance with these frameworks that exist. Where if you’re dealing with health data, or you’re dealing with credit card data, and you’re subject to HIPAA, high trust, PCI, as a security team, you can’t tolerate dependencies that won’t get updates. That’s too much risk. And that’s created a real vacuum in the space of open source end of life.

CRob (11:17.857)
And so from your perspective, if something is end of life, does that automatically mean that package is a problem? What options do people have?

Isaac Wuest (they/them) (11:27.883)
Yeah, that’s a great question. So there’s an analogy I sometimes draw from in the food regulation space. If you ever get into how FDA or the EU thinks about risk in food. there’s a difference between risk and hazard. Hazard is just anything can kind of, anything could be a hazard. If I go to an aquarium, the fact that there’s a shark in a tank is a hazard.

Oh boy, if something were to happen, I fell in that tank, slipped, However, the risk is quite low. security teams within companies are trying to figure out the balance within the context of end of life. Is end of life is inherently hazardous. How much risk does it represent though? And based on the risk, what should we do? How much effort should we as a company invest? We can tolerate some risk, we can’t tolerate all risk.

And then the question becomes, what are my options if I’m an engineer or security person who I discover I have several end of life packages in my dependency tree for some application? What should I do? The first problem they have is, how risky are these packages? And the fact that they’re end of life means, what are my options for fixing it? Do have to migrate? Can I patch it myself? That becomes the natural.

kind of next questions and problems that these folks are facing.

CRob (13:01.087)
And we’re definitely going to see that in the coming months and years as the EU’s Cyber Resilience Act comes online, because manufacturers are held accountable for all components within their products. And they need to do that risk calculus to understand what am I going to do if there is a critical vulnerability in one these things that doesn’t have support potentially upstream.

Isaac Wuest (they/them) (13:22.626)
Yeah.

You’re absolutely right. The landscape around shipping secure software continues to get more more strict, which I think is a very healthy orientation for the industry. It’s important that we’re responsible as technologists for the code we’re shipping, even if that’s open source code. But that doesn’t mean that it’s not going to be a really challenging problem to solve as the EU cybersecurity

actor or many others continue to gain traction.

CRob (13:58.525)
And with your interactions both up and downstream, are people aware of kind of this end of life opportunity that’s before them?

Isaac Wuest (they/them) (14:08.641)
folks are becoming increasingly aware. There’s actually a distinction now in two different types of end of life that’s been emerging when talking about it. there’s end of life, similar to those large frameworks and the calendars I was mentioning, that’s often categorized as maintain or attested end of life. And that attestation is often the very compliance-y legal term, where the maintainers are attesting that it is end of life or that it is supported.

And if I’m an auditor, I can rely on that when I’m auditing some large company’s project. The category that’s emerging as a term is maintainer abandonment when it comes to end of life. Now there’s other terms you’ll hear that are similar. Really all we mean is there’s a point at which that maintainer can no longer continue to support. It could be a specific kind of major release line. They’ve moved on.

It could be even specific miners that they’re no longer going to be supporting. you think about that SIMVR, that 1.1. Or it could be the entire package gets abandoned. So they rename the package, or the maintainer has experienced burnout, and they’re no longer able to support it. They’re going to need to take a step back. No one’s filling that vacuum or that void. That maintainer abandonment category is proving to be a real opportunity.

to say how do we identify and report on this even when the maintainer doesn’t have a way to clearly tell everyone and broadcast like the big players in open source do the large frameworks.

CRob (15:41.439)
Interesting. Thinking about the tools we have today and end of life, have for good or bad, the CVE program, we have software builds materials, we have a whole fleet of scanners, AI or not. We have bug bounty programs. Now, from your perspective, do these tools and maybe ones that I didn’t mention, do they give a consumer

Kind of that full security picture or are there gaps?

Isaac Wuest (they/them) (16:14.625)
Right now, the gaps are really starting to show. Most of the available kind of industry standard tools, be it SBOMs, Cyclone DX or SPDX, even the biggest kind of formats out there, or most scanning tools as well, they’re still focused on publicly reported vulnerabilities as the top priority. And then they do talk about end of life. Most of the end of life that you see reported,

are those maintainer attested schedules, where your big frameworks tend to be tracked well, which is really important to be clear. Those big frameworks often represent a lot of risk and a lot of pain if you have to make a migration or something like that. Very few tools exist today in the security scanning space that have a robust picture, a complete picture of that maintainer abandonment side. There’s people doing kind of innovative work there trying to

and understand, but it’s a pretty open field space right now even for these large security scanning tools.

CRob (17:19.947)
Well, that’s always been an historic challenge, of that information sharing upstream is, you know, is the project active? When was the last commit? How many stars and like all that kind of normal lifecycle stuff helps, but is not that developer attestation saying on this day, I’m stopping this particular stream.

Isaac Wuest (they/them) (17:32.488)
Absolutely.

Isaac Wuest (they/them) (17:42.722)
Yep, yep, you’re absolutely right. And yeah, that’s been a challenge for some time. It’s also often a challenge because these tools need certainty in order to report on a scan. Like you said, they get that complete picture. They wanna be able to say with confidence, it’s this or it’s that. It’s supported or it’s not supported. And when you talk with maintainers, there’s a lot more gray there where they say, well, I could support it if I need to. If someone tells me I’m willing to try and do them a favor, because open source is so…

CRob (18:06.209)
Mm-hmm.

Isaac Wuest (they/them) (18:11.329)
Everyone’s so willing to pitch in and help each other. And that’s a feature of the space, but it becomes a bug for those consumers, those large enterprises that need certainty when they’re reporting on compliance, alignment, and all that sort of stuff.

CRob (18:15.595)
There it is, yep.

CRob (18:26.721)
So I’m thinking about this from the developer perspective and end of life. Are there any practical steps that you would recommend a project to consider or do to help be a little bit more communicative around this to deflect a lot of downstream questions? You know, ideally.

Isaac Wuest (they/them) (18:49.335)
Yeah, yeah, absolutely. There are some practical things that are available today. And then there’s some opportunities where I’m really hoping as an industry, security scanning focuses on solving this problem more broadly. Today, though, I the way it’s typically done when I talk with enterprises and work with developers on the front lines is they usually get a notice that something has a CVE on it. And then,

I mean, I’m sure you know well that they end up going and researching. You grab that package name and the version, and you go to Google, and you start looking at the registries. And you say, is this supported? If there’s not an obvious patch version I can just upgrade to, Like oftentimes, engineers stumble upon the reality of it being end of life if it’s not that large framework where there’s a clear calendar. That’s, of course, painful because it means

Do I need to migrate? What do I have to find a replacement, et cetera? So my recommendation today is there’s tools like endoflife.date. That’s a great tool, site and project out there. There’s other ways to go research. However, there are some free tools available that you can load an SBOM or a manifest into. There’s one that we’ve been working on called the eoldataset.com that you can.

Loads free tool that has a large database detecting maintainer abandonment. I’m hopeful many other organizations work on this problem so that engineers don’t have to spend far too much time researching everything one off and get some confident data about what is almost certainly end of life and what is likely supported even for that long tail of packages.

CRob (20:31.329)
That’s good advice. if from your perspective, how accessible, how easy are these systems to kind of get in there and get the data you need so you can make your risk decision? Do I want to continue with this particular branch or not?

Isaac Wuest (they/them) (20:49.293)
Yeah, so if for existing SEA tools, most of them, of course, they’re going to tell you about that maintainer attested. And if you load in your SBOM, there’s usually some other version or remediation path where they say, hey, here’s what you can do about it. There is a supported version. And at that point, it becomes a question of how quickly do you need to migrate? Or can you get some sort of support right now? For the other side of it.

when it comes to maintainer abandonment. I would definitely recommend using the tool I just mentioned where you can load in that SBOM. And once you get that full picture of, here’s all those other packages that are end of life or likely end of life, the next step becomes, OK, well, are there supported versions that I can upgrade or migrate to? Most of them there are. Then it becomes a question of, of course, breaking changes.

How challenging is that? Is it deep in the dependency graph such that the version is constrained and it becomes this kind of gotcha problem? And oftentimes, even knowing something is end of life, that’s not enough for engineers. They need to know what are their upgrade paths if they have to fix that one package, that one version. Our tool that I mentioned that’s free to use has some of those, but many others.

do as well. Your SEA tools often do contain migration options and engineers can often use those tools. They’ll load in data sets like ours or others about end-of-life data that then connects to the dependency graphs and says here are your migration options. You’d have to upgrade these two direct dependencies. That gets you into the versions you need that are no longer end-of-life deeper down.

CRob (22:42.657)
This is an amazing topic that I think not everyone is aware of it as they should be. So thank you for joining us today and kind of sharing a little bit about end of life. But let’s move on to the rapid fire part of our talk.

Isaac Wuest (they/them) (22:57.357)
you

CRob (23:00.405)
That’s spicy. I have a handful of questions that we’ll ask you. Just give me the first thing that comes off the top of your head. What’s your favorite beverage?

Isaac Wuest (they/them) (23:09.441)
Got it.

Ooh, I’m gonna have to go with a cappuccino. I love coffee, but I love espresso, so give me that. Give me that right there. Yes, I need that caffeine.

CRob (23:14.593)
Ooooo

CRob (23:20.193)
Yum. All right. Star Trek or Star Wars?

Isaac Wuest (they/them) (23:24.885)
I’m so sorry, but it’s gonna be Star Wars for me. It’s gonna be Star Wars. Okay, good, good, good. Well, I appreciate Star Trek. I certainly love it, but Star Wars, there’s just something about it that speaks to me.

CRob (23:27.723)
There are no wrong answers, but Star Wars is a pretty good one.

Well, do you prefer spicy or normal food?

Isaac Wuest (they/them) (23:42.024)
I love spicy. Please.

CRob (23:43.751)
ooo that’s spicy

Isaac Wuest (they/them) (23:47.853)
Yeah, I don’t understand people that don’t like spicy food. It’s just more exciting. It’s more interesting.

CRob (23:49.249)
Thank

Right? Exactly. And then, you being that we are in the a new age here, who’s your favorite apocalyptic robot?

Isaac Wuest (they/them) (24:06.029)
Ooh, my favorite apocalyptic. is this, ooh, is this existing AIs or is this fictional robots? my goodness. I think I could have one of each. could have one of each. Okay, for fictional, I’ve been reading all these dystopian books that involve robots. I love Heinlein’s The Moon is a Harsh Mistress. There’s an AI there, Mike or Michelle, not a robot that causes an apocalypse, but one that kind of helps solve kind of a crisis.

CRob (24:13.622)
Sure.

You could have one of each.

Isaac Wuest (they/them) (24:35.373)
So that’d be my favorite fictional. Ooh, for existing, I don’t know. There’s a number of AI models I’m pretty scared of right now. We’ll see. And I don’t want to badmouth any, because maybe in two or three years, I’ll be hoping that they take care of me.

CRob (24:35.489)
Nice.

CRob (24:43.297)
You

CRob (24:50.241)
That’s our dream. Well, thank you for playing along, Isaac, being a good sport. And as we wrap up, do you have any closing thoughts or a call to action for our listeners?

Isaac Wuest (they/them) (25:01.161)
Absolutely. Well, thank you so much for bringing me on. I really appreciated the conversation. This was really exciting and interesting. What I would definitely say is, for anyone listening, if you’re worried about End of Life and the potential exposure that any of your applications have, feel free to check out what we’ve been working on. We have a free tool with a data set called eoldataset.com. And we’re looking just to give away as much data that we have about the End of Life space. So if this is something that was interesting to you and you want tolearn more about what might be end of life, or you want to contribute thoughts and ideas about how to improve the data set, please let us know. We’re very interested. yeah, with that, that’s my main…

CRob (25:43.189)
Well, Isaac from HeroDevs, thank you for joining us today. And I want everyone to kind of listen to this, maybe take some action, do a little research to educate yourselves. And I’d like everyone to stay cyber safe and sound out there. Happy open source and folks. That’s a wrap.

May 29

Love0

Aligning on Machine-Readable Signals as the Foundation for Due Diligence

By OpenSSF Blog, EU Cyber Resilience Act

By Madalin Neag, EU Policy Advisor, OpenSSF

Introduction

The software supply chain has reached a level of complexity where manual oversight is no longer a viable strategy for security or regulatory compliance. Modern systems depend on vast, rapidly evolving networks of components, making manual, paper-based approaches to due diligence impractical. Machine-readable, continuously generated security signals are therefore the only realistic way to support Cyber Resilience Act (CRA) due diligence at scale. These signals already exist across open source ecosystems as a natural byproduct of standard development practices, though they remain fragmented across tools, repositories, and pipelines. Crucially, these signals are best understood as mechanisms for transparency rather than assurance: they expose observable characteristics of software development and operational behavior without constituting guarantees, certifications, or transfers of liability.

This shift is driven by a need for technical accuracy. Static documentation and point-in-time attestations cannot reflect continuously evolving software systems. This limitation has been underscored by recent U.S. enforcement actions, such as Department of Justice settlements involving inaccurate cybersecurity compliance certifications, which highlight how formal attestations can later be treated as misleading when they diverge from actual system behavior, significantly increasing legal exposure.

Established approaches such as continuous compliance, evidence-based assurance, and secure-by-design all rely on the same principle: replacing subjective, point-in-time claims with dynamic, verifiable proof, automated data that reflects actual system behavior.

Within this model, roles remain clearly separated. Upstream open source projects may choose to publish security-relevant signals in machine-readable formats, while manufacturers, who bear the legal responsibility under the CRA, consume and interpret this information as part of their due diligence processes. This preserves the foundational “no warranties, no liabilities” principle of open source. Participation from upstream remains strictly voluntary and must not introduce legal obligations, certification expectations, or shifting of compliance risk and liability to the project community, ensuring that ecosystem sustainability is maintained while enabling effective downstream risk management.

This discussion builds on earlier reflections on voluntary attestation models under the Cyber Resilience Act, particularly Article 25, which enables voluntary security attestation programmes to support manufacturer due diligence for products incorporating free and open source software while preserving the separation between upstream development and downstream regulatory responsibility. From a systems perspective, however, Article 25 also exposes an important limitation of paper-based attestation approaches. Static, human-authored representations of security struggle to remain accurate within environments defined by continuous change, where rapidly evolving components and deeply nested dependencies can quickly render point-in-time attestations incomplete or outdated. This leads to a broader architectural observation: effective due diligence at scale increasingly shifts away from narrative declarations toward machine-readable, continuously updated security signals embedded directly within development and release workflows. In this framing, voluntary attestation is valuable not as a mechanism for upstream certification, but as a way to enable structured, interoperable security data that downstream systems can automatically consume and evaluate. Machine-readable signals thus become the practical substrate for operationalizing the intent of Article 25 in complex software ecosystems, preserving voluntariness, avoiding any conflation of transparency with assurance, and enabling evidence-based due diligence aligned with the dynamic nature of modern software systems.

Due Diligence under the CRA: a continuous risk-based process

Due diligence under the CRA must be understood as a continuous, risk-based obligation rather than a procedural formality. As clarified in the European Commission’s FAQ and further complemented via the CEN PT1 standard, it is not a checklist to complete or a document to obtain, but an ongoing responsibility carried by manufacturers placing products with digital elements on the market. Its purpose is to ensure that third-party components, regardless of origin, do not compromise the cybersecurity of the final product.

At its core, due diligence requires manufacturers to make informed, traceable decisions about the software they integrate. This includes understanding the origin and role of components, evaluating their security characteristics, and determining whether their use is appropriate within the context of the product. These activities form a continuous lifecycle process covering evaluation, integration, monitoring, and remediation. The level of scrutiny applied is inherently risk-based and contextual, and depends on the role, exposure, and criticality of each component within the manufacturer’s system.

This obligation is dynamic by nature. Software components evolve, vulnerabilities are disclosed continuously, and integration contexts change over time. Due diligence therefore extends across the entire lifecycle, requiring manufacturers to revisit earlier assumptions and adjust mitigation strategies as new information becomes available. This creates a continuous feedback loop between upstream changes and downstream risk decisions.

The regulatory expectation is that this process is demonstrable through technical documentation that allows decisions and risk assessments to be traced and verified. The emphasis is not on collecting predefined assurances, but on ensuring that decision-making remains consistent, auditable, and defensible over time.

For open source components, due diligence relies on observable project characteristics rather than formal assurances. Manufacturers assess elements such as maintenance activity, responsiveness to security reports, release practices, and the availability of structured security documentation, drawing on signals that reflect how a project is actually developed and maintained. These signals can be aggregated into continuously updated, machine-readable evidence reflecting the current security posture of both the component and its dependencies. This approach does not create any dependency on upstream attestations: under the CRA, manufacturers remain solely responsible for their assessments, while any transparency provided by open source projects is entirely voluntary and does not constitute certification or liability. Machine-readable security signals therefore function primarily as decision-support inputs within downstream risk management processes. They improve the quality, consistency, and scalability of due diligence activities, but they do not replace the manufacturer’s obligation to exercise independent judgment and accountability.

Machine-Readable Signals in Practice

A mature ecosystem of tools already generates machine-readable signals that can support due diligence under the CRA. These signals span multiple layers of the software lifecycle, from component identification to vulnerability management and build integrity. Standards such as SPDX and CycloneDX enable structured software bills of materials (SBOMs), while frameworks like SLSA define levels of build provenance and integrity. Complementary technologies such as Sigstore provide cryptographic mechanisms to verify artifacts, and formats like CSAF and VEX support the structured exchange of vulnerability and exploitability information. Tools such as SBOM CVE Check, Dependency-Track, Syft, and Grype operationalize these standards by enabling SBOM-driven component analysis and automated vulnerability scanning, while SBOMQS provides additional validation of SBOM quality and compliance against established standards.

Within the OpenSSF ecosystem, these capabilities are reinforced by a growing set of complementary tools that standardize, expose, and operationalize security-relevant signals across different layers of the software lifecycle. Some focus on repository security posture and development practices, others on supply chain integrity and provenance, while newer systems increasingly aggregate these signals into unified, queryable models suitable for large-scale risk analysis and automated due diligence workflows. At the project governance and security posture layer, OpenSSF Scorecard provides automated checks on repository hygiene and secure development practices, while the Best Practices Badge and Open Source Project Security (OSPS) Baseline initiatives offer structured indicators of project maturity and security adoption. OpenSSF Security Insights extends this approach by introducing a standardized, machine-readable format for publishing security policies, development processes, and maintenance practices, enabling more consistent interpretation of project security posture across tools and downstream consumers. Complementing these efforts, LFX Insights aggregates operational and community signals related to project activity, contributor diversity, governance, and security posture, helping organizations evaluate the long-term sustainability and operational health of dependencies over time. Together, these tools transform otherwise fragmented repository metadata into reusable signals that support risk-based evaluation without requiring additional compliance artifacts from maintainers.

At the supply chain integrity layer, frameworks such as in-toto provide cryptographically verifiable attestations describing individual steps within software build and release pipelines, strengthening provenance visibility and artifact integrity. SBOMit builds on this model by combining SBOM generation with in-toto attestations and signed supply chain layouts, enabling verifiable component composition during the build process. Related tooling such as Protobom and Bomctl improves interoperability and operational reuse of SBOM data. Protobom provides a format-neutral intermediate representation that allows SPDX and CycloneDX documents to be transformed and consumed consistently across heterogeneous tooling ecosystems, while Bomctl enables structured manipulation, merging, and management of SBOM trees across complex dependency environments.

Increasingly, these signals are being aggregated into higher-level analytical systems capable of supporting continuous, ecosystem-scale risk analysis. GUAC (Graph for Understanding Artifact Composition) demonstrates this direction by ingesting SBOMs, provenance attestations, vulnerability reports, OpenSSF Scorecard results, and related metadata into a continuously queryable graph model. This enables dependency-aware analysis of upstream risk exposure, artifact relationships, and vulnerability propagation across software ecosystems. Architecturally, systems such as GUAC illustrate a broader shift within software supply chain security: compliance and due diligence increasingly become problems of correlating continuously generated technical evidence rather than collecting static documentation.

Additionally, tools and frameworks such as OSS Review Toolkit (ORT), Community Health Analytics in Open Source Software (CHAOSS), and OpenChain extend this landscape by enabling deeper analysis and contextual understanding. ORT integrates dependency, license, and vulnerability analysis into reproducible workflows, while CHAOSS provides metrics on project activity, health, and sustainability. OpenChain complements these by defining standards for open source compliance and supply chain governance, helping organizations establish consistent, auditable processes for managing open source use. Together, these perspectives allow manufacturers to assess not only technical risk but also organizational maturity and long-term sustainability of the components on which they depend.

This direction is also reflected in European cybersecurity guidance. ENISA’s Security by Design and Default Playbook highlights machine-readable signals as a mechanism for making security both demonstrable and verifiable within development processes. By enabling continuously generated, machine-consumable evidence that can be automatically validated and reused, this approach reinforces the shift from static documentation to dynamic, lifecycle-integrated assurance, directly supporting scalable due diligence.

European initiatives further build on this foundation by operationalizing these signals into compliance workflows. EU-funded projects such as CRACoWi, CYBERFORT, CONFIRMATE, OSCRAT, and OCCTET ingest machine-readable inputs (including SBOMs, vulnerability data, and provenance information) and transform them into risk assessments and technical documentation. These platforms demonstrate how compliance can be implemented as a continuous, automated process, reinforcing the complementarity between upstream signal generation and downstream consumption.

Taken together, these tools form an interoperable ecosystem of continuously generated signals. They already provide most inputs required for effective due diligence, demonstrating that the necessary data exists within current development workflows. This confirms a key architectural reality: compliance at scale is fundamentally a data integration problem, not a documentation problem.

A large share of due diligence-relevant information is already present within open source repositories. Security policies (SECURITY.md, security.txt), contribution workflows (CONTRIBUTING.md), release histories (changelogs), issue templates, licensing files, and repository governance practices (branch protection, maintainer authentication) collectively describe how software is developed, maintained, and secured. Together, they provide a rich baseline for assessing development discipline, update reliability, and supply chain integrity, without requiring additional compliance artifacts.

However, these signals are often distributed across heterogeneous formats and locations, making them difficult to discover and reuse at scale. Improving their visibility through lightweight structuring or simple indexing can significantly reduce friction. This is not about adding new artifacts, but about improving the accessibility of existing ones.

The viability of this model is already demonstrated in practice. Many open source projects publish structured security information as part of their normal operations. Projects such as K3s provide comprehensive self-assessments describing architecture and security considerations, while the Argo project maintains clear documentation of its vulnerability disclosure processes. Other initiatives, including Privateer and other projects within the CNCF ecosystem, expose structured security information directly within their repositories. These projects demonstrate that “CRA readiness” is essentially an extension of existing high-quality security engineering. Documenting security posture is already a well-established practice; what is missing is not the content, but a consistent way to connect that content to automated due diligence workflows.

Guidance from OpenSSF security assessments further supports this practice by helping projects think systematically about their security posture, development processes, and risk boundaries.

This becomes particularly critical at scale. Modern systems depend on hundreds or thousands of components, making manual evaluation (and reliance on manual, individualized attestations) infeasible. Machine-readable signals enable automated collection, continuous updates, and consistent analysis across dependency graphs, transforming due diligence into a reproducible computational workflow aligned with contemporary software realities.

Voluntary Upstream Participation and Ecosystem Engagement

It is critical to start with a baseline legal protection: maintainers and stewards are not “suppliers” in a commercial sense and are not required or expected to sign contracts or guarantee compliance outcomes. Under the CRA, open source projects are under no obligation to support compliance activities. Responsibility remains exclusively with manufacturers placing products on the market. This legal boundary is intentional and reflects the regulation’s effort to preserve the open source model, particularly the “no warranties, no liabilities” foundation that enables broad participation and innovation. More broadly, the legislative intent of the CRA is to protect the “long tail” of community-driven innovation, ensuring that smaller projects, individual maintainers, and informal communities are not burdened with obligations designed for commercial actors.

At the same time, many projects already choose to publish security-relevant information such as vulnerability handling policies, release processes, or build metadata. These actions improve transparency and usability for downstream users, but they do not create legal obligations, warranties, or liability. They are best understood as voluntary engineering practices that reduce friction and make projects easier to adopt within regulated environments.

A central principle throughout this model is the clear distinction between transparency and assurance. Transparency refers to voluntarily published, descriptive information about how software is developed, maintained, and secured. Assurance, by contrast, implies some form of validated guarantee, certification, or assumption of responsibility. Under the CRA and within open source ecosystems, transparency must never be interpreted as assurance.

Any attempt to interpret voluntary signals as certification risks undermining both the legal structure of open source licensing and the intent of the CRA. From a regulatory perspective, oversight remains focused on products placed on the market rather than upstream development processes. As a result, any security signals published by projects function as inputs into downstream evaluation, not as regulatory objects in themselves.

Within this framework, upstream security signals serve only as inputs into downstream due diligence. Manufacturers remain responsible for evaluating those inputs and making risk-based decisions. The availability of better signals can improve that process, but it does not shift accountability or create dependencies on upstream participation.

At the same time, the CRA introduces an important change in incentives. Manufacturers can no longer rely on passive consumption of open source components without understanding their security implications. When gaps in security signals are identified, the most effective response is not to request formal assurances but to improve the upstream ecosystem through tooling, documentation, funding, or engineering contributions. This includes supporting SBOM generation, provenance tooling, vulnerability disclosure processes, or automation of security pipelines.

This dynamic creates an opportunity for a more balanced and sustainable relationship between upstream and downstream actors. By investing in the security and transparency of the projects they depend on, manufacturers not only support their own compliance efforts but also strengthen the resilience of the broader ecosystem. This shift does not alter legal responsibilities, but it encourages a model of shared interest where better upstream practices benefit all participants without imposing new obligations on open source maintainers.

Building a Scalable Model for Cyber Resilience

Modern software systems routinely incorporate thousands of independently evolving components, making static documentation obsolete almost as soon as it is produced. In this context, scalable due diligence cannot rely on manual, document-driven approaches. Machine-readable security signals provide a scalable alternative: continuously generated, verifiable, and aligned with dynamic software supply chains.

A scalable due diligence model therefore depends not only on machine-readable signals, but also on correctly interpreting their nature. They are evidence of behavior, not guarantees of outcome. Maintaining the distinction between transparency and assurance is what allows these signals to be useful without distorting responsibility or imposing unintended obligations upstream.

The CRA establishes a clear downstream responsibility model, but its effectiveness depends on implementation. When grounded in automation, interoperability, and continuously updated evidence, due diligence becomes operational rather than procedural. This approach builds on existing engineering practices and widely adopted tooling, enabling scalable risk assessment without imposing new burdens on upstream maintainers. This direction is consistent with ENISA’s Security by Design and Default Playbook, which emphasizes machine-readable security attestations as a foundation for demonstrable and continuously verifiable security across the software lifecycle.

Crucially, this model preserves the sustainability of the open source ecosystem. It avoids shifting liability or compliance expectations onto maintainers, while still improving transparency through low-friction, machine-readable signals. Much of the required information already exists within projects today; the challenge is not creation, but integration and consistent reuse. By treating compliance as something assembled from technical evidence rather than declared through static attestations, the process remains both accurate and adaptable over time.

Ultimately, a shift toward continuous, evidence-based due diligence ensures cybersecurity can scale alongside software complexity. It enables manufacturers to manage large dependency landscapes efficiently, supports ecosystem resilience, and fosters more meaningful upstream–downstream collaboration. Compliance is not a one-time declaration but an ongoing capability that strengthens both regulatory outcomes and the integrity of the digital infrastructure.

About the Author

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.

May 28

Love0

OpenSSF Newsletter – May 2026

By OpenSSF Newsletter

What a month! May was packed with milestones for the OpenSSF community, and we're still riding the high from an incredible OpenSSF Community Day North America in Minneapolis. Read OpenSSF…

May 21

Love0

OpenSSF Notes Quarter of Growth with New Members, Added AI Security Resources, and Growing Community

By OpenSSF Blog, Press Release

Foundation celebrates five additional members, new cyber reasoning sandbox project, and release of v1.0.0 Python Secure Coding Guide to support open source security globally

MINNEAPOLIS – OpenSSF Community Day North America – May 21, 2026 – The Open Source Security Foundation (OpenSSF), a cross-industry initiative of the Linux Foundation focused on sustainably securing open source software, today announced five new members have joined the foundation. The OpenSSF also notes additional technical resources for Python secure coding, the first cohort of OpenSSF Ambassadors, and new projects like OSS-CRS joining the foundation’s sandbox during OpenSSF Community Day North America in Minneapolis. OpenSSF’s efforts ensure that open source remains a trusted foundation for digital innovation by addressing the technical, legal, and human elements of modern cybersecurity.

These milestones address two main converging pressures in the software ecosystem: increasingly mandatory security standards and the need to unify organizations and countries behind those standards. By providing practical resources, the OpenSSF helps projects navigate complex requirements such as the CRA. The project continues to expand its global community as well, keeping all that benefit from open source software ahead of sophisticated risks and threats.

“As the threat landscape for software supply chains becomes more complex, the need for community driven security standards has never been more urgent,” said Steve Fernandez, General Manager of OpenSSF. “The growth we’re seeing in our membership and the arrival of projects like OSS-CRS show that security is an important priority for all. The OpenSSF is providing the practical tools and guidance developers need to build more resilient software.”

New OpenSSF members include ActiveState, Aikido, Minimus, and TuxCare, who join the Foundation as General Members. The FreeBSD Foundation also joins as an Associate Member. These organizations will contribute to working groups and technical initiatives to help drive the strategic direction of the OpenSSF. By collaborating within a neutral forum, these members support the long term sustainability of the open source ecosystem.

Foundation Updates and Milestones

In the second quarter of 2026, the OpenSSF achieved several milestones to secure and support more resilient software for all:

Publication of the European Union Cyber Resilience Act (CRA) Guides and Resources for Maintainers and Stewards: The Global Cyber Policy Working Group created this technical roadmap to help foundations and projects navigate global regulations, including the EU Cyber Resilience Act (CRA).
OSS-CRS Joins OpenSSF: Following its debut in the DARPA AI Cyber Challenge, the Open Source Cyber Reasoning System (OSS-CRS) has been formally accepted as an OpenSSF Sandbox project to advance AI-driven automated vulnerability finding and patching.
First Release of the Python Secure Coding Guide: The BEST Working Group has announced version 1.0.0 release of the Secure Coding Guide for Python, providing developers with high-confidence anti-patterns and compliant code examples to mitigate common vulnerabilities.
Security Slam 2026 Conclusion: OpenSSF celebrates the successful completion of Security Slam 2026, which resulted in dozens of open source projects reaching the Open Source Project Security (OSPS) Baseline and publishing their first formal threat models.
New AI Security eBook: In collaboration with the Cloud Native Computing Foundation (CNCF), OpenSSF released Securing Open Source in the Age of AI: A Practical Guide for Maintainers, Security Engineers, and Researchers. The guide offers actionable advice for managing AI generated contributions and using AI to improve security.
Mentorship Program Expansion: OpenSSF selected eight mentees for its Summer 2026 program. These contributors will provide dedicated support to Repository Service for TUF (RSTUF), GITTUF, SBOMit, and Minder.
Inaugural Ambassador Program Cohort: Today at OpenSSF Community Day, the Foundation announced the first cohort of the OpenSSF Ambassador Program, featuring 13 community leaders dedicated to spreading security best practices.

Supporting Quotes

“The Linux Foundation and OpenSSF are where the serious work on open source security gets done. No single organization secures the software supply chain alone. Thirty years of building secure open source infrastructure is what we bring to that work, and that work is better done together.”

– Abby Kearns, CEO, ActiveState

“Open source software is the foundation of modern software development, and supporting that ecosystem has always been core to Aikido’s mission. Through projects like Safe Chain, Zen Firewall, OpenGrep, and BetterLeaks, we’re investing in practical, community-driven security tooling that helps developers build and ship software with speed, trust and confidence. We believe securing open source is a shared responsibility, and we’re proud to contribute technologies that make the broader ecosystem safer and more resilient for everyone.”

– Willem Delbare, Founder and CEO, Aikido Security

“As a critical component of the global digital infrastructure, we believe FreeBSD must be part of the security discussions shaping the future of open source. Joining the OpenSSF will enable us to collaborate with others to help protect the software the world depends on.”

– Deb Goodkin, Executive Director, FreeBSD Foundation

“Minimus is proud to join OpenSSF and work alongside its other members to help secure the open source ecosystem that allows us all to thrive. Enabling developers to build on open source components while keeping security teams happy is central to our business, and we intimately understand the responsibility we all share in achieving that goal.”

– Kat Cosgrove, Head of Developer Advocacy, Minimus

“TuxCare is pleased to be joining OpenSSF and the cross-industry effort to strengthen open-source security. For more than a decade, we’ve worked to keep open source secure and reliable in enterprise production over the long term. We see that kind of sustained reliability as essential to the trusted, secure open-source ecosystem OpenSSF envisions.”

– Igor Seletskiy, CEO, TuxCare

Events and Gatherings

OpenSSF members are gathering this week in Minneapolis at OpenSSF Community Day North America. To get involved with the OpenSSF community, join us at the following upcoming events: OpenSSF Community Day Europe (Prague; October 6) and Open Source Summit Europe (Prague; October 7-9).

Additional Resources

View the complete list of OpenSSF members
Contribute efforts to one or more of the active OpenSSF working groups and projects
Sign up for the OpenSSF newsletter to receive updates on upcoming events, resources, and community news.

About the OpenSSF

The Open Source Security Foundation (OpenSSF) is a cross-industry organization at the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all. For more information, please visit us at openssf.org.

About the Linux Foundation

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure, including Linux, Kubernetes, LF Decentralized Trust, Node.js, ONAP, OpenChain, OpenSSF, PyTorch, RISC-V, SPDX, Zephyr, and more. The Linux Foundation focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Media Contact
Grace Lucier

The Linux Foundation
pr@linuxfoundation.org

May 21

Love0

Introducing the First Cohort of the OpenSSF Ambassador Program

By OpenSSF Blog

Securing the open source software ecosystem is a monumental task, and it is not one we can tackle alone. It requires collaboration, education, and passionate advocates who are willing to share their knowledge across the globe.

Today, at OpenSSF Community Day, we are beyond excited to announce the launch of the OpenSSF Ambassador Program and to introduce the 13 incredible community leaders who make up our First Cohort!

Earlier this year, we put out a call for community leaders to apply to become OpenSSF Ambassadors. The response was incredible, and reviewing the impressive backgrounds of our applicants reinforced just how dedicated our community is to open source security.

What is the OpenSSF Ambassador Program?

The OpenSSF Ambassador Program was created to empower passionate open source security advocates. Our Ambassadors are recognized leaders who share the OpenSSF vision of a future where open source software is secure by default.

Whether they are writing thought leadership articles, speaking at global conferences, contributing to critical working groups, or mentoring the next generation of security professionals, our Ambassadors are the dedicated champions of our community.

Meet the First Cohort

Over the past couple of weeks, you may have noticed the reveal of our amazing Ambassadors. Today, we are happy to present the complete lineup. These individuals bring a diverse wealth of knowledge spanning supply chain security, policy, community building, and engineering.

Please join us in welcoming:

Ben Cotton is the Open Source Community Lead at Kusari. He has been active in Fedora and other open source communities for over a decade. His career has taken him through the public and private sector in roles that include desktop support, high-performance computing administration, marketing, and program management. Ben is the author of Program Management for Open Source Projects.

Rob Kenefeck is a Field CTO at ControlPlane. He likes to talk about how Security is fundamental to DevOps and how Kubernetes often isn’t the best answer to your reliability problem. A CNCF Ambassador and organizer of KCD Melbourne and CloudCon SYD, he has spent the last several years helping enterprises navigate the intersection of platform engineering, security, and cloud transformation. He participates in the CNCF TAG Security APAC group and brings a community-first perspective to his work believing that open source is how the industry levels the playing field on security.

Ejiro Oghenekome is a Cybersecurity Professional and Open Source Advocate passionate about open source security, cloud technologies, and digital resilience in Africa and globally. She contributes to open source projects like OpenSSF, focused on strengthening awareness and collaboration around secure open source ecosystems. Her interests include cybersecurity research, open source security, and security awareness within the African tech ecosystem, with a growing focus on deepening her technical expertise and contributing to real-world security solutions.

Justin Cappos is a NYU Professor and a Creator of five Linux Foundation projects: TUF, in-toto, Uptane, SBOMit, and gittuf. His research advances are adopted into production use by Google, RedHat/IBM, VMware, Docker, Amazon, Palantir, Lockheed Martin, Datadog, Bloomberg, millions of automobiles, and other IoT devices, and are also used to protect the legal code across a variety of jurisdictions, including Washington DC, Baltimore, and the State of Maryland.

John Kjell is a Principal Consultant at ControlPlane, where he helps some of the world’s most security-conscious organizations build and assure mission-critical platforms. He is a maintainer of the Witness and Archivista sub-projects under in-toto and serves as a co-chair of the CNCF’s TAG Security. John is also actively involved in several initiatives within the OpenSSF. Prior to joining ControlPlane, he was the Director of Open Source at TestifySec and held engineering leadership roles at VMware.

Brandt Keller is a Staff Software Engineer with a passion for Open Source. He serves as a Maintainer and Technical Lead for the CNCF Security & Compliance Technical Advisory Group, a Cloud Native Ambassador, and a project maintainer within the OpenSSF for the Zarf Project. He has led and contributed to multiple foundation working groups, to include publishing artifacts to enhance end-user security.

Tabatha DiDomenico is an Open Source Security Engineer and Advocate focused on the people and practices that keep open source secure and sustainable. She’s president of Security BSides Orlando, co-hosts the GR-OSS Out podcast, and contributes to OpenSSF and FINOS projects and working groups. At G-Research, she’s part of the Open Source team, working on supply chain security, secure open source practices, and community and developer relations.

Kadi McKean is passionate about the DevOps / DevSecOps community and has been since her days of working with COBOL development and Mainframe solutions. At ReversingLabs she collaborates with developers and security researchers to help entities prioritize their open source risk, reduce technical debt, and meet compliance objectives. When she’s not working with the developer community, she loves running, traveling, and hanging out with her dog Milo.

Roman Zhukov is a Cybersecurity Expert, Engineer, and Leader with over 20 years of hands-on experience securing complex systems and products at scale. Currently Principal Architect at Red Hat, he leads open source security strategy, upstream collaboration, and cross-industry initiatives focused on building trusted software ecosystems. Previously, Roman led Product Security & Privacy for Data Center and AI software at Intel. He is a Security Champion for several open source projects and an active contributor to working groups under the OpenSSF, Eclipse Foundation, and other global initiatives.

Katherine Druckman is a senior technologist, speaker, and longtime advocate for open ecosystems. Currently Head of Community and Partnership Engagement at JetBrains, she specializes in developer experience, combining software ecosystem strategy, content strategy, and community building, grounded in a foundation of hands-on software engineering experience and proven leadership. She is a long-time open source advocate, developer, and podcaster, and is currently the host of the Reality 2.0 podcast.

Hannah Braswell is an Associate Product Security Engineer at Red Hat, focusing on proactively securing complex open source systems. 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. As an active contributor to several projects and Working Groups within the OpenSSF, she is passionate about pragmatic development and using automation to enhance security workflows. She currently serves as the Community Manager for the OpenSSF Gemara Project and excels at making technical concepts digestible for all audiences. Outside of her work, she enjoys traveling, hiking, and exploring art exhibitions.

Yunseong Choi Yunseong Choi is a cybersecurity strategist dedicated to resilient open source ecosystems. An adjunct Professor at Kyonggi University and lecturer at Korea University, he bridges the gap between academic research and pragmatic open source security practices. As a member of the Presidential Council on National AI Strategy in South Korea, he spearheads national initiatives for SBOM/VEX standardization and compliance automation. He actively promotes global collaboration within the OpenSSF to ensure secure, sustainable open source ecosystems for developers worldwide.

Walter Pearce is a key Leader of the Rust Foundation’s Security Initiative. Walter comes from a 14-year career in security. For the past seven years, he has specialized in offensive security in the gaming industry, leading efforts to find and mitigate vulnerabilities affecting tens of millions of players at Epic Games and Blizzard Entertainment. Before that, he was a security consultant providing penetration testing, red teaming, and code review services for many Fortune 100 companies whose foci included operating systems, languages, and embedded systems. Walter has always had a passion for technical security problems and has built his career helping craft novel solutions to new, challenging issues in security. In his spare time, Walter enjoys playing open source games. He was previously a contributor and member of the Amethyst Game Engine and a lead contributor on other open source game development projects.

What is Next?

You will see our Ambassadors representing OpenSSF at upcoming industry events, hosting local meetups, and creating content to help developers secure their code. Be sure to follow them on socials, and say hello if you see them in the OpenSSF Slack!

Interested in becoming an Ambassador in the future? Sign up for our Newsletter for announcements regarding our next cohort application window.

May 19

Love0

What’s in the SOSS? Podcast #61 – S3E13 Beginner to Builder: Shaping the Conversation in Open Source Security

By OpenSSF Podcast

Summary

In this episode of What’s in the SOSS, Yesenia Yser interviews cybersecurity analyst Ejiro Oghenekome about her journey from UI/UX design to becoming a key contributor to the OpenSSF. Ejiro shares the inspiration behind her public “100 Days of Cybersecurity” challenge, which has helped her maintain discipline and consistency while making the field less intimidating for beginners. She discusses how connecting with the OpenSSF community led her to the BEAR Working Group, where her authorship of the “Beginner to Builder” blog series has allowed her to move from consuming content to actively shaping the open source security conversation. Ejiro also offers advice to the next generation, emphasizing that open source contribution is not just about coding but is a welcoming space for anyone to learn and grow, regardless of their current expertise.

Listen on Apple Podcasts Listen on Spotify Listen on Overcast Listen on Pocket Casts

Conversation Highlights

00:00 – Music, Promo clip, & Welcome
01:11 – Ejiro details her transition from UI/UX design to cybersecurity and connecting with OpenSSF.
03:39 – Ejiro explains her motivation for starting the 100-day challenge, including receiving advice to learn publicly and a previous rejection from an internship.
06:49 – Ejiro shares that she is currently on day 44 and expects to complete the challenge around April.
07:50 – Ejiro discusses her biggest personal lesson: understanding consistency and discipline, and learning from the community.
10:45 – Ejiro describes her authorship of the “Beginner to Builder” blog series, which shifted her from consuming content to shaping the open source conversation.
15:47 – Ejiro shares the impact of her work, noting that it has made cybersecurity feel less intimidating for beginners and helped her grow in confidence.
18:22 – Rapid Fire Questions: Ejiro shares her preferences on books, cooking, social media, and more.
21:13 – Ejiro offers advice to the next generation, emphasizing that open source is welcoming, not just about coding, and provides great opportunities for learning and growth.
24:46 – Yesenia concludes the interview, thanking Ejiro for her time and contributions

Episode Links

Ejiro (Sonia) Oghenekome LinkedIn page
Ejiro’s GitHub page
BEAR Working Group
Ejiro’s OpenSSF Beginner to Builder Blog Series:
Get involved with the OpenSSF
Subscribe to the OpenSSF newsletter
Follow the OpenSSF on LinkedIn

Transcript

Intro Music (00:00:00)

Ejiro Oghenekome (00:01.366)
So I have embarked on a 100-day cybersecurity challenge where I post whatever I learn about cybersecurity in the open. I posted both on LinkedIn and on Twitter, currently known as X. I was told to learn publicly. It has really helped me to stay consistent and it has also helped me to stay disciplined.

Yesenia Yser (00:23.662)
Hello and welcome to What’s in the SOSS, OpenSSF’s podcast where we talk to interesting people throughout the open source ecosystem, sharing their journey, experience, and wisdom. So Yesenia, one of your hosts, and today I have the utmost pleasure of interviewing Jiro, who has been such a great part of the open source community and has done a lot for us already from part of the FAIR program.

writing a few blogs that we have seen out in the wild, and much more. don’t want to share details of the upcoming podcasts, but welcome, Ejiro. Please, you know, let’s start with you for listeners that are meeting you for the first time. Can you introduce yourself and share your journey into open source cybersecurity? Like what really pulled you into this space?

Ejiro Oghenekome (01:11.822)
Thank you very much for having me here. Hello everyone. My name is Ejiro Oghenekome. I’m a cybersecurity analyst. Currently I am contributing to the OpenSSA. So for how I got into this space and where I am at right now, I’d like to give a little backstory on myself so that I would better understand how I got to this particular phase of my career. I used to be a UI UX designer a couple of years.

But I think about 2024, I started to like not see myself doing UI UX in a long time. And as at that point, I was already interested in security. I was already curious to know how data is secured and a lot of other things about security. So I decided to dive in and take it as a career to learn about security. And the first course I took was the Google Cyber Security Certification course on

Coursera and it was a very interesting course. I took that. had other little courses that I took some on YouTube and other very, very not so prominent courses that I took that helped my career helped shape my career going forward. And something I didn’t have, I didn’t mention was the fact that I’ve always known about open source, even during my UI UX design time, but I really did not partake in open source contribution as at that point.

But I really, did not want my cybersecurity journey to be that way. So I was looking for every means to get into this space, to try to contribute to open source with my cybersecurity career. So fortunately for me during that time, I think about 2025, met a friend, told me, or I saw a post from a friend where she had an interview with someone that was talking about open source and open source security. I found that very interesting and I reached out to her.

I like to connect to the person so that they would share more light on contributing to open source, especially with my focus, which is cyber security. And she actually did that to me. She actually did that for me. And I connected with the person. The person was Sal. I a couple of meetings with Sal and she got to know where I was in my career, which led her to introduce me to the OpenSSF. And yeah, I am today trying to contribute to the OpenSSF in whichever way I can.

Yesenia Yser (03:39.854)
That’s such a great story how one friend, one webinar connected you to one individual that opened up the space of open source and it’s brought you to where you’re at today. Such a great story to hear. And one of the little birdies in the open source told me that they gave you a hundred days of cybersecurity challenge that you’ve been publicly documenting on LinkedIn. Like what inspired you to start that journey and

What do you hope would come from it?

Ejiro Oghenekome (04:10.67)
So I have embarked on a 100-day cybersecurity challenge where I post whatever I learn about cybersecurity in the open. I posted both on LinkedIn and on X. Twitter, currently known as X. So my journey can be documented. What’s made me do this was the advice I got from friends and loved ones. I was told to learn publicly. And that really has shaped me over time coming out.

because looking back, it has really helped me to stay consistent and it has also helped me to stay disciplined in terms that I feel so indebted to the cause of posting because I’ve seen a lot of people grow interest in what I have posted about my career, everything I do about cyber security. It has really been an interesting journey for me. Also, another reason why I embarked on the 100 day of cyber security challenge was because

I would say I got a rejection from an internship. I really did not get a feedback from them. So I would know, I don’t know if I should say that’s a rejection, but technically it is because I didn’t get the feedback. I really wanted to get a practical knowledge of what I was already learning. I’ve learned for a while and I wanted to get into the practical space. I wanted to get into the real world space to practice what I have been learning. Applied for the internship. Unfortunately.

I did not get it, so I had to take some step back and make a curriculum for myself where maybe I would be able to create something that feels really practical. The internship I applied for was a three-month internship, which is 90 days, if I would say technically. So I just had to do it, 90 days for an internship that I did not get. So I had to make it a 100-day for myself. Looking at all I have done, what I hope

to come out from this, which I am already saying is for people to know me for what I do. For people to know me for open source, for people to know me for open source security, for people to know me for cybersecurity, and for people to know me for preaching and being an enthusiast of open source. People should come into the open source space to contribute to open source and see the opportunity it comes with. And people to also know that

Ejiro Oghenekome (06:34.734)
I’m a cyber security analyst and I also give best practices. I also give basic knowledge of what cyber security is and all of that. Yeah, that is what I hope to get my 100 day challenge. And it has really been turning out well for me.

Yesenia Yser (06:49.836)
I love that because getting online and really just sharing what you’re learning, you know, on a cadence, whatever cadence that is for you is such an important way just for your own accountability and for others to connect to you, connect with you and learn what you’re learning, especially if you’re looking for jobs. I’m just curious right now it’s, you know, mid February. What day are you in for this challenge?

Ejiro Oghenekome (07:13.774)
Yeah, I think I’m in day 44. Nice. Yeah, day 44. It’s been a great journey. Yeah.

Yesenia Yser (07:22.574)
24 days. So when do you envision, it’s 100 days, so when do you envision this challenge ending?

Ejiro Oghenekome (07:29.39)
Let me try to do a rough calculation right now in my head. So we have a couple of these. So let’s see the beginning of around April. I’m not sure the dates for April. I’m not going to give an exact estimate, but yeah, by April I should be done with the 100 day cybersecurity challenge.

Yesenia Yser (07:50.85)
Very nice. Okay, so we’ll keep watching. you’re deep into this challenge. 44 days is a great time because that’s built in that habit to get it done and share out what you’ve learned. But I’m curious, what’s your biggest lesson that you’ve learned so far? And not just like technically, but like personally, like how have you changed how you see your learning, your discipline, or just like your community growth?

Ejiro Oghenekome (08:17.614)
Okay, that’s a very interesting question. I would really say if I’m going to put it short, I’ll say it has not been an easy journey. It’s not been easy because it’s not easy to stay consistent and trying to like, remodel my expectations of what I have to post, what I have to do. It is not easy. I’ve come to see that everything cannot go on the same pace every day.

I’ve had to stay consistent. I’ve had to understand what consistency and discipline means. I’ve come to get that. Consistency does not mean I have to be in the same place every day. I do not do the same thing every day. Some days I might not even feel motivated to want to partake in that particular challenge for that day. But have to stay disciplined. I have to stay consistent, which might make me cover less than what I covered the previous day.

Other days I might feel so motivated that I might cover more every other thing I’ve covered in the past. It just happens. One thing I’ve learned is staying consistent, what consistent really mean, being very disciplined in the space. Also it has given me a very good routine. In terms of community, I’ve come to understand that community is where I learn.

This learning can come by interacting with projects and interacting with people in the community that have more experience than I do. During my 100-day challenge, I’ve been able to have the opportunity to be part of the OpenSSF. This has gone hand in hand with the 100-day challenge that I’m doing. For the fact that I’m part of the OpenSSF and doing my 100-day challenge, I’ve seen the impact that the OpenSSF community has had on me. I’ll give a very simple example.

We had a blog post or we had a blog post that talks about a lot of things that we might go over eventually. Because of one research I did for one part of one series of the blog post, I a course on the OpenSSF and the Linux Foundation Education that I took in and I benefited from. That is the LFD121, that is developing secure software.

Ejiro Oghenekome (10:34.274)
want to understand from this journey that I’ve taken that I could learn from community, I could learn from interacting with people, want to understand what consistency and discipline mean.

Yesenia Yser (10:45.678)
That’s awesome. Yeah, I when you started being involved in the Bear Working Group, you and Saul were working on a blog series and I you just lightly mentioned it. It’s beginner to builder. What has that experience been like moving from learning to actually contributing publicly? And you know, this blog, it’s a big deal. It’s a three series blog. Like what does this authorship mean to you in the aspect of open source?

Ejiro Oghenekome (11:13.208)
Again, I would try to give an example to put what I have learned and how contributing to open source has been to me. During my design career, I’ve always known about open source, but I was not involved in open source contributions because as I did, I would say I did not know where to start. I did not know what to do. I did not know how to get into the space. I also felt most of the times that I did not know enough to be able to partake in open source contributions.

all of that and that’s feeling of mine is something I feel like a lot of other persons also do have. It was a problem for me and that problem I felt that a part of the blog post was able to solve it. One thing about me is if I experience a particular challenge or problem going forward in my career I try my best to solve it so that when people come behind me and they experience such problems they would not find it difficult to solve because they are

cases or maybe they are documentations that will help them go through this problem. That is one thing that I’ve been able to do with the blog posts and that is how, that is why the blog post publication was made public. And for me, Autorship in open source is more than just putting my name on the blog post or making contribution. It represents ownership of my learning and my voice. When I started my cyber security,

I was mostly consuming content. was reading documentations, watching tutorials and following experts. questions, I did all of that. But authorship changed the dynamics of everything for me. It shifted me from being just someone that consumed information to someone that is actively shaping the conversation, even if it was in small ways. Authorship made me feel responsible. I know that something I am going to write

is going to be published and the knowledge I share is going to be put out in the ecosystem. It would make me more focused. It would make me more thoughtful. It would make me more intentional about what I’m going to post. And this led me to call back, questions, ask people from the community to give me feedback on the blog post I wrote. I think you must have experienced that because

Ejiro Oghenekome (13:35.916)
During the first part, the second part and the third part, we were always very intentional to make sure that we got feedback from the community so that the best resources can be put out there to solve the actual problem we saw that we wanted to solve. And also, Authorship for me means visibility. As someone from Nigeria and someone who transitioned from design to cyber security, Autorship allows me to exist in a public space where people like me

are not highly represented. It shows that contributions does not have to fit a specific style or character. Also, it also makes me confident. It means that I am no longer waiting until I know everything before I can speak and before I can contribute in the open source space. Comfortable contributing while I am learning.

This is very powerful in the open source space because the open source space does not work with one person’s perfection, but it works with individuals putting together their efforts and their knowledge to try to make things work. The bear walking group and generally the OpenSSF community has really been helpful in this part. I’ve been encouraging, they’ve been friendly and they have pushed me to understand things. They have guided me each step of the way.

to understand what I am doing so that whatever resources we put out there will be the best quality for people that are going to have that.

Yesenia Yser (15:08.448)
It reminds me a lot of when I started, like just grabbing whatever kind of resources I could find and just learning. And when I realized that I was able to use my voice or my penmanship, so to speak, to share out information, I realized the power and the impact that I can have, you know, just not for my own credibility, but also you never know who’s going to read it down the line. Like I have articles that I wrote years ago or that I published that people still reference.

Nowadays that they’re like, this was an amazing article that you wrote. learned so much. So big kudos to you for that.

Ejiro Oghenekome (15:45.55)
Thank you.

Yesenia Yser (15:47.17)
Before we get into the rapid fire, I would love to know what impact you’ve seen in the community, either from your 100 day posts or your bear working group, like the work you’ve done with the blog. I know you mentioned a bit in this session, but I would love to learn, know a little bit more of looking at your journey so far. Like what impact have you seen?

Ejiro Oghenekome (16:08.634)
Genuinely speaking, I really did not think about impact when I started all of this. When I started my 100-day challenge, I was not thinking about the impact it was going to have on anyone. I just wanted to learn. When I started contributing to open source, I just wanted to learn. But over time, I started to notice little impact on people. I saw that for my 100-day challenge, people would message me saying things like, they started learning because they were following my post.

Some people asked me questions on the tools that I use and if I will be able to share resources with them. Other people said that made cyber security feel less intimidating because of course, a lot of cyber security posts we see online are from experts that would tell us in cyber security knowledge and try to express things in very technical terms for us, which could be very intimidating for beginners.

for people that are beginners that could relate to what I was saying, that could relate to very basic things in cyber security. It really felt nice. It really felt welcoming. It gave them confidence to say, okay, I could learn this. I could start somewhere. I could get some of this knowledge and get to that point of expertise where I would be able to have this opposed, intimidating knowledge also to myself. Also talking about the community.

The impact has been slightly different. I’ve been able to be part of so many decision-making. I’ve connected with experts that are very kind and friendly, and they want to see me grow. From publishing the blog series, this has made me more aware of my words, that my words could guide people that are just starting up, and this makes me feel so happy. I’m growing in the community in terms of

confidence and experience and also in transferable skills, in terms of receiving feedbacks and all of that growing. And I see that when resources are put out there, it’s really encouraging to me.

Yesenia Yser (18:22.126)
That’s awesome to hear the impacts from, I think he started maybe like a year or so ago into the organization. So it’s great to see and hear what has happened within a year.

So let’s go ahead and move on to the rapid part of the interviews. You gotta have fun with some of these parts. So I’m gonna ask you a series of this or that kind of questions or what’s your favorite X and then you just go ahead and respond. So first question, books or podcasts?

Ejiro Oghenekome (18:38.776)
FIRE!

Ejiro Oghenekome (19:02.117)
I don’t really like reading. I just have to read because I need to get those informations in my head.

Yesenia Yser (19:08.258)
Yeah, I get that. A favorite off-computer activity.

Ejiro Oghenekome (19:18.51)
enjoy cooking a lot. Yeah, enjoy cooking a lot.

Yesenia Yser (19:22.158)
What’s that one meal you cook often that you enjoy?

Ejiro Oghenekome (19:27.926)
I know if you would know, but I cook fried rice. I like seafood a lot. So I cook fried rice, prawns, salad.

That’s my favorite meal. That’s my favorite. Maybe one will see one of these days, I’ll make it and you will definitely testify to its greatness.

Yesenia Yser (19:48.086)
am ready for that. Next question. Best way to grow a project. it social media, conferences, or contributors?

Ejiro Oghenekome (19:57.44)
is social media yeah if I’m going to be very honest social media can do that

Yesenia Yser (20:03.726)
I feel like social media drives the other two. Next question, sweet or sour?

Ejiro Oghenekome (20:12.014)
No, sir, I don’t like sweets like that.

Yesenia Yser (20:16.366)
We had a quick, quick, quick change there.

Ejiro Oghenekome (20:19.575)
I just had to think about suits, so I really didn’t like suits.

Yesenia Yser (20:25.166)
I know we’re meeting early morning for you, so are you an early bird or a night owl?

Ejiro Oghenekome (20:32.386)
I I’m an early bird. I really do think I’m an early bird because I wake up very early and do things. I’m an early bird and I try to sleep very early.

Yesenia Yser (20:41.77)
I’m the opposite. just, at night I’m like a week. It’s so strange.

Ejiro Oghenekome (20:46.894)
I’m really not sleeping lot. So I just try to sleep at night. I stay awake very early in the morning. I get up very early in the morning and try to go on my day.

Yesenia Yser (20:57.464)
Yeah, I’ve adapted myself to it, but naturally I could stay up all night and sleep all day. Last question is your favorite treat or dessert?

Ejiro Oghenekome (21:10.702)
I’d say cakes.

Yesenia Yser (21:13.422)
That’s a good answer. There you had it. The rapid fire interview questions focused on food. So as we wrap things up, any advice for the next generation entering tech or security? What advice would you give them about using open source as a way to launch pad their career?

Ejiro Oghenekome (21:36.494)
Okay, well, I’ll give a disclaimer. would say I’m still part of the next generation. So whatever advice I’m going to say, I’m giving that to myself also. This is something I would have told myself earlier on in my career during design. Try to understand open source and the opportunity it provides. Also, open source is not just about coding. There are different things that someone can do in the open source space.

As a designer, could contribute to the open source space. As a writer, you could contribute to the open source space. As a community manager, you could contribute to the open source space. Obviously, very obvious ones. You could write codes. You could review codes. And you could do a whole lot of other things. Even joining calls, giving your suggestions on calls and decision making during the call is also a way to be part of the open source space.

get involved in the open source space. has a lot of opportunities for people. It’s a very welcoming space. I can testify to that from the community I am part of. It’s a very lovely community with lovely people. The OpenSSF has been a great space for me to learn and grow. And I strongly believe that this is how most, if not all of the open source communities are.

It’s a place where you can learn. It’s a place where you can build your confidence. It’s a place where you can grow. also open source is not about you being an expert. are with the knowledge you have. You could be part of an open source space. You could be part of, you could contribute into the open source. So commonly try to understand open source. is not as difficult as it might look from the outside. Trust me. in, learn.

be part of it and contribute. And I promise you it’s a very welcoming space to be part of. And talking about open source and advice I’ll give to people, have an article coming up that will be talking about contributing into the open source space generally. How to work for communities that you could contribute to, how to understand the communities, and maybe how to make it a first time contribution in a community.

Ejiro Oghenekome (23:54.668)
that you’re contributing to. This is not going to just be specifically about the open access, but open up source generally, how to be part of the space, how to try to understand the space and get into the space. Something else I would have, I would love to talk about is the opportunity for open source for us in Africa. I really don’t know that we, the idea of open source is not so widespread in Africa. That is why it has to be preached. It has to be introduced to a lot of people.

And I would love us to consider that, to try to make sure we introduce people in Africa to open source and the benefits it has on us, what it can do to us and the privileges it can give to us. Yes, that is the advice I would give to the next generation, also myself, the open source space.

Yesenia Yser (24:46.478)
Thank you so much for your time today, your impact, your contributions. I love that you have another article coming out to help those, know, explore the different open source communities and how to search. Thank you so much for everything you do within our community and all the hard work you’re putting together. I really appreciate your time and to our listeners, reach out to Jiro. She’s doing great work. Find her on LinkedIn and keep tracking on that 100 day challenge. Thank you so much everyone and we’ll catch you on the episode.

May 18

Love0

Taking Stock of the State of European Cyber Resilience Act (CRA) Compliance: An Urgent Wake-up Call for the Open Source Ecosystem

By OpenSSF Blog, EU Cyber Resilience Act, Global Cyber Policy

By Christopher (CRob) Robinson, OpenSSF

For the better part of two years, discussions surrounding the European Cyber Resilience Act (CRA) have been somewhat theoretical: mapping requirements, debating definitions, and analyzing how the requirements will impact our amazing ecosystem. But folks, it’s mid-2026, and the CRA is live. Theory is officially in the rearview mirror as implementation milestones roll out over the next two years.

I’ve just finished reviewing the finalized 2026 CRA Awareness and Readiness Report, a joint effort with LF Research experts, and to be blunt, the results are a sobering reality check. Despite tireless community work, the broader ecosystem is far from ready for CRA compliance.

CRA Awareness Has Stalled

The most disappointing finding is that awareness surrounding this regulation has decreased year-over-year. Today, 66% of respondents remain unfamiliar with the CRA, a slight increase from 62% in 2025. That means a growing portion of the software ecosystem is unaware of a regulation with global consequences and hefty fines.

The geographic disparity is even more alarming. In the United States and Canada, nearly 72% of respondents are unfamiliar with the regulation. It cannot be understated: if you are a North American company selling software products into the EU market, you are legally required to comply with the CRA. However, the majority of the neighborhood is still walking unprepared toward a September 2026 reporting deadline.

Why the “Consume and Forget” Model is No Longer Possible

For years, organizations have treated open source like a free lunch: grabbing code and assuming the lights are being kept on by someone else. Under the CRA, that posture is no longer tenable. Manufacturers now bear the legal responsibility for the security of the components they integrate. For some (read: most) this is a stark wake up call.

Despite that, 51% of manufacturers still passively rely on upstream projects for security fixes. In the new world of the CRA, “passive” is a level 10 risk.

Private Forks Are Not the Answer (They’re Worse)

Many of you have tried to dodge the upstream journey by maintaining private forks, but inefficient code is still inefficient code, and now we have the bill to prove it. The report shows that maintaining private workarounds is a massive form of technical debt, costing organizations an average of $258,000 in labor every single release cycle. With some release cycles as short as a matter of hours, these costs can quickly get out of hand.

For large organizations (5,000+ employees), this burden exceeds 11,152 labor hours per cycle. Maintaining these divergent codebases is a giant bill for a strategy that actually makes supply chain transparency worse. Contributing fixes upstream isn’t just being a “good neighbor” – it’s the only financially rational path forward.

For the last several years, the OpenSSF community has observed traditional vulnerability disclosure systems buckling under the strain of volume of discoveries being reported through them. Data from the report points to a surge of 394% increase in Common Vulnerabilities and Exposures (CVEs) and an 811% spike in vulnerabilities that fall within the High+ severity categories in the first quarter of 2026. Several factors contribute to this trend:

Transparency: Open source is open and transparent, which means the community cannot hide vulnerabilities behind opaque processes or paywalls.
Project Growth: Year-over-year we’re seeing an explosion of MORE open source projects.
Ubiquity: Open source is quite literally the majority of software used globally.
AI Tools: More users are leveraging Large Language Models (LLMs) and other tools to explore and analyze software. The transparency of open source software offers a low barrier of entry for those using these new tools and test code.

Globally, regulations like the CRA are codifying long-standing security guidance into law. This shifts security from a “nice-to-have” recommendation to a legal requirement backed by heavy non-compliance fines.

How Does Upstream Investment Improve Your Security Posture?

On the bright-ish side the data reveals a clear correlation: organizational diversity is a strong predictor of a project’s security posture. When more organizations invest in a project, that project becomes more resilient, making upstream investment a direct catalyst for your own compliance posture. Organizations have an important role in their own security health through their participation in open source projects.

However, the participation of small and medium-sized enterprises (SMEs) is crucial to the entire ecosystem, they are the backbone of the industry. Currently, over half of European SMEs remain unfamiliar with the CRA, creating a significant gap in project diversity. Directed investment in SME engagement is essential to prevent compliance from becoming a structural barrier to innovation. By funding the support and tools these smaller players need to remain compliant, we ensure the entire upstream supply chain remains robust and competitive.

What OpenSSF Resources Can Help Organizations Prepare for the CRA?

While we wait for the full 2026 report to drop, the tools to succeed already exist. Our previous research, Unaware and Uncertain: The Stark Realities of Cyber Resilience Act Readiness in Open Source, highlighted these same gaps a year ago. It’s time to start acting. The tools to succeed already exist and practitioners who find our resources rate them highly:

LFEL1001 Training Course: A free, 90-minute course providing the essential foundation for CRA compliance.
OpenSSF OSPS Baseline: A starting point for security attestation.
Global Cyber Policy Working Group and CRA Special Interest Groups (SIGs): Community-driven spaces for tackling implementation hurdles.

This ecosystem is rife with the talent and the collaborative instincts to meet this challenge. The December 2027 deadline is a forcing function, but it’s an opportunity to build a software supply chain that is actually secure by design.

Europe is leading the way in protecting consumers globally. Despite our geographic distance in the U.S., the oceans between us all do not provide isolation from this regulation any longer. Software and products with digital elements are built with hardware, software, and firmware created through international collaboration. That fact feeds the global economy and makes manufacturers globally responsible for CRA adherence. Events that happen “over there” DO truly affect everyone.

The results of the CRA research conducted with our peers in LF Europe is truly grave. A significant amount of work and collaboration has occurred across the ecosystem since CRA enforcement. It is shocking to look back at all this work done by both the OpenSSF and its partners and see that 39% of manufacturers, who have BILLIONS of euros at stake in potential non-compliance penalties, are still unaware and uncertain about their requirements.

The next stage in our shared journey together unfolds in September 2026 when the vulnerability reporting obligations are enforced. There is not much time to prepare. Organizations have a narrow window to audit their upstream dependencies and establish the processes needed to report and patch new vulnerabilities as they emerge. The more complex aspects of the CRA are currently a year out, coming due December 2027. Please, take action today to protect yourselves, your companies, the upstream maintainers on whom you depend, and your customers.

The OpenSSF encourages everyone that benefits from open source software to consider the beauty and complexity of the open software world. Every day in software repositories, chat channels, and mailing lists a talented cohort of developers co-engineer the tools you use and love. We ask that organizations and their leaders understand that free software is NOT free. Being a responsible consumer and participant in the ecosystem creates benefits for everyone. With CRA in our midst, there is ample opportunity to make this shared space better and more secure for everyone. My hope is that we can rise to that opportunity.

Stay Ahead of the CRA

Be the first to read the 2026 CRA Research Report. Subscribe to our newsletter for an alert when it releases the week of June 9 (European Open Source Security Forum in Brussels).

Get involved with the OpenSSF Global Cyber Policy Working Group.

About the Author

Christopher Robinson (aka CRob) is the Chief Technical Officer and Chief Security Architect for the Open Source Software Foundation (OpenSSF). With over 25 years of experience in engineering and leadership, he has worked with Fortune 500 companies in industries like finance, healthcare, and manufacturing, and spent six years as Program Architect for Red Hat’s Product Security team.

May 12

Love0

Hack to the Future: The Impact and Legacy of the DARPA AIxCC Challenge

By OpenSSF AI, Blog, Global Cyber Policy, Guest Blog

By Helen Woeste

AIxCC Competition Background & Results:

In 2023, DARPA announced a two-year long competition called the Artificial Intelligence Cyber Challenge (AIxCC) with the goal to safeguard open source software used in critical infrastructure throughout America. The intent is to hasten the development of open source AI tooling that can assist developers with finding and fixing bugs in live software with minimal cost. Open source is a drastically underfunded and underresourced form of infrastructure. It therefore presents an exciting, practical target, and opportunity for the research and development of AI in cybersecurity. Additionally, open source’s publicly observable code is ideal for competition and collaboration.

AIxCC was run in collaboration with ARPA-H and supported with contributions from Anthropic, Google, Microsoft, and OpenAI, with additional consulting around open source provided by the Linux Foundation and the Open Source Security Foundation (OpenSSF). This research was developed with funding from the Defense Advanced Research Projects Agency (DARPA). The competition consisted of two rounds, the Semifinal Competition (ASC) and the Final Competition (AFC), where cash prizes from a pot of $30,500,000 were distributed. For the ASC, 42 team submissions were accepted across two tracks; the Open Track and the Small Business Track, which required an additional technical paper submission. The top seven teams moved forward to the AFC which was set up to mimic a real world CI/CD pipeline. The scoring algorithm was also designed to highlight behaviors that would make the competing systems more useful to developers. At the conclusion of AFC, the top three teams were Team Atlanta, Trail of Bits, and Theori.

For the AIxCC competition, real open source projects were selected, and their code was forked and then modified to insert artificial bugs for the Cyber Reasoning Systems (CRS) to discover and fix. However, during the execution of the competition, the CRSs discovered several real potential bugs alongside the artificial ones. This introduced the issue of how to triage and manage resolution of fixes in the projects. OpenSSF engaged third party open source security organization Open Source Technology Improvement Fund (OSTIF) to get involved with the closing out of the bugs identified as a result of the AIxCC competition.

OSTIF selected the team at Ada Logics for their extensive experience working with open source fuzzing, bug verification, and disclosure. With a list of potential bugs identified through the course of the competition, Ada Logics was tasked with securely submitting verified issues, ensuring that anything reported to open source project maintainers was a proven bug. The Ada Logics team was able to reproduce and confirm twenty-seven issues after multiple rounds of testing and continued coordination between AIxCC competitors, collaborators, and contributors. CRS teams, including Team Atlanta, Team Buttercup, Team FuzzingBrain, Team Shellphish, Team Theori, Team 42-b3yond-6ug, and Team Lacrosse, working together with Kudu Dynamics and the OpenSSF, continued to collaborate and meet with OSTIF around the disclosures to ensure total accuracy of the reported issue’s testing and resulting decision around disclosure.

It was of utmost importance that any and all real bugs detected during the competition were verified before alerting the project maintainer to the issue. This is to differentiate how the competition reports issues to projects from the low-quality reports plaguing open source maintainers today. In several cases, CRS-generated patches were submitted alongside bugs, an offering to project maintainers looking to quickly resolve the finding. Additionally, feedback was sourced from the projects around their experience as a target in the competition as well as the disclosure procedure following.

The Findings:

Teams discovered twenty-seven candidate real-world issues during the competition and OSTIF engineers were ultimately able to replicate all of the draft bugs. The affected projects were cURL, shadowsocks-libev, healthcare-data-harmonization, hertzbeat, little-cms, and mongoose. Once identified, the hard work began of fixing those bugs, implementing CRS tooling to perform the second half of its double duty to find and fix security issues.

However, some of the findings did not meet a level of security concern for various reasons. Some issues were fixed by code changes in the projects during the time-period in between the competition and when engineers reproduced them. Others were outside of the threat model of the project and did not meet the criteria needed to incorporate into the project (for example, the Apache Poi project threat model states “Expect any type of Exception when processing documents,” making any exception-based findings non-issues). One issue had actually already been found by OSS-Fuzz, but the project hadn’t fixed it yet.

Ultimately, interesting findings were discovered and fixed by the Cyber Reasoning Systems in this competition, and the systems found a lot of valid issues. Further, some projects had introduced fixes before the bugs were reported. This is likely because the AIxCC teams submitted the fuzzing harnesses to the projects before triage had taken place, which re-discovered the same bugs before triage had completed. One significant lesson learned from this is that cyber reasoning systems may benefit from doing self-triage when discovering potential issues by checking against the project’s documentation and understanding the types of issues that the project accepts as security bugs that need to be addressed.

Conclusion & Looking Forward:

The AIxCC program was a massive undertaking by dozens of organizations, all working to contribute back to open source security in a meaningful way using novel AI tooling. The competition was mindfully designed and carried out, with attention given towards the open source projects and maintainers, the wide variety of competitors and interests, and the impact of the competition itself on the industry all the way down to the maintainers.

OpenSSF is the home for extended collaboration on these new open source tools through its newly formed Cyber Reasoning Systems Special Interest Group. OSS-CRS and FuzzingBrain, two open source projects that emerged from the competition, are now hosted at OpenSSF in the Linux Foundation. A third tool applied and was accepted to the OpenSSF, and has a few remaining steps before the official transition. The group aims to foster their development and adoption, and to establish best practices that help projects use CRSs effectively and responsibly.

This work is already producing real results. For example, FuzzingBrain has since turned its AI-assisted fuzzing system on the broader open source ecosystem, discovering sixty-two vulnerabilities across twenty-six projects, from CUPS and Apache Avro to Ghidra and OpenLDAP, with forty-three confirmed by maintainers and thirty-six already patched upstream. 42-b3yond-6ug has expanded its CRS to uncover twelve kernel-related vulnerabilities in the Linux kernel and related components, plus ten zero-day vulnerabilities in userspace projects including Eclipse Mosquitto and OpenLDAP. The team is also developing a platform to support more efficient model training and evaluation of models and agents, with a release expected soon. Using OSS-CRS, Team Atlanta discovered twenty-five vulnerabilities across sixteen projects spanning a broad range of software including PHP, U-Boot, memcached, and Apache Ignite 3. Of those, nine have been fixed and eight more have been confirmed with fixes in progress.

The future of AI assisting maintainers in finding and fixing security vulnerabilities is bright. The challenges raised by the AIxCC competition already have solutions being developed in open source, such as LLM-based tools that build threat models by looking at the data-flow of projects, and AI agents that triage findings against threat models and documentation before reporting issues. As these tools all continue to develop, they will harmonize into reliable solutions that maintainers can use to elevate their security with far less effort than today.

Our gratitude to the folks at Ada Logics for triaging the potential bugs and working hard to reproduce the issues so maintainers didn’t have to, OpenSSF for trusting us to bring together all of the stakeholders to work on the issues together, DARPA and ARPA-H for holding the AIxCC competition and sponsoring this work, the teams that built the Cyber Reasoning Systems for the competition, Kudu Dynamics for their support in confirming the findings, and all of the maintainers that worked with us to resolve the issues.

OpenSSF and OSTIF will continue to support this kind of work by serving as human connectors between CRS tools and open source communities. The goal is to help triage and validate vulnerability reports and proposed patches before they reach maintainers, ensuring findings are accurate, actionable, and respectful of maintainers’ time.

Organizing a competition of this scale on behalf of open source maintainers and its end users takes both enormous collaboration and individual effort. Understanding the communities involved, and building lightweight programs that shield maintainers from headaches while strengthening security is the best possible outcome for the ecosystem. It took everyone coming together to make this happen, and ongoing efforts will bring low-cost and low-maintenance tools to everyone that are valuable and make us all safer.

As AI moves forward at breakneck speed, innovative work like this highlights how you can move fast and build things together for a better tomorrow.

Author Bio

Helen Woeste joined OSTIF in 2023, coming from a decade of work experience in the restaurant and hospitality industries. With a passion (and degree) for writing and governance structures, Woeste quickly transitioned into an operations and communications role in technology.

The views, opinions and/or findings expressed are those of the author and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.

Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)

May 07

Love0

The Road to Gold: How CPS Set a New Standard for Security and Quality in Open Source

By OpenSSF Blog, Guest Blog

In the world of open source, trust is our most valuable currency. ONAP is a “collection of individual, semi-standalone network automation functions that provide design, orchestration, observability, and automation of…