Register for Open Source SecurityCon North America 2026

Tag

Software Supply Chain

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 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.

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
Love1

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

By 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 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 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:

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.