Why Your EOL Open Source Stack Is a Compliance Liability, Not Tech Debt

Welcome & Housekeeping

Erin Hannaford: Hello, and welcome to our webinar, "Why Your End-of-Life Open Source Stack Is a Compliance Liability, Not Just Tech Debt." My name is Erin Hannaford, and I'll be facilitating today's webinar.

‍

Before we dive in, I'd like to cover a couple of housekeeping items. Today's webinar is being recorded, and after the session is completed we will be sharing both the recording and an accompanying white paper via email — so be on the lookout for that in your inbox.

‍

We have saved plenty of time for questions at the end. Feel free to use the comments functionality to enter questions or comments throughout the webinar, and we'll get to as many as we can live. Anything we can't handle live, we will follow up on directly with you after the webinar.

‍

Now I'd like to introduce today's speaker, HeroDevs COO, Rob Nalen. Rob, take it away.

‍

Rob Nalen: Thanks, Erin. Great to see everybody here — really excited to talk about this topic.

‍

For some background, as you all know, I am the COO here at HeroDevs. Our goal is to enable enterprises to meet their internal and external compliance requirements, including the EU CRA, which we'll talk about here. We do this by providing continuous CVE remediation and support for end-of-life open source software. As part of offering this to enterprises, we strategically partner with open source communities like the OpenJS Foundation, the Linux Foundation, and the Commonest Foundation, as well as working directly with many open source projects like Bootstrap, Vue, .NET, and many others.

‍

My goal for this webinar is to provide details not only on what the EU CRA is and how companies can ensure compliance, but also to give some background into why this requirement came into play, as well as other requirements that will launch globally based on the advancements in AI and open source. We'll talk about how organizations should think about compliance with respect to end-of-life open source software. Lastly, we'll go into a Q&A, where I look forward to getting into questions and topics — it's always fun to have a bit of interactive discussion.

‍

History Repeats Itself: Lessons from Personal Data

With this in mind, let's jump into a quick review of how history repeats itself and how we can learn from it moving forward.

‍

Before we talk about the Cyber Resilience Act, I want to zoom out, because none of this is entirely new. What we're living through with software and AI right now follows a similar pattern to what we saw with the collection and use of personal data.

‍

So let's start with the pattern. About fifteen years ago, enterprises figured out they could consume personal data at a scale no one had imagined. This value for companies came with risk, and primarily that risk landed on the people who never really agreed to have their data consumed or used. For the first few years, the model for personal data protection was best effort, without much accountability behind it and certainly no definitive legislation or compliance standards driving behavior.

‍

In short, failures started piling up and people's personal data was compromised at scale, which resulted in the law catching up. In Europe, it was GDPR. In the United States, it was the Gramm-Leach-Bliley Act, HIPAA, and later CCPA.

‍

For those of you in compliance, you'll remember the rollout of these standards wasn't straightforward. Some may remember the Schrems I decision, perhaps not so fondly. In 2015, the European Court of Justice struck down the US-EU Safe Harbor framework overnight, ruling that it didn't adequately protect Europeans' data. Thousands of companies that thought they were compliant suddenly weren't. That case, along with a few other similar cases and developments, is what drove GDPR. Best-effort protection became a mandated, ongoing, enforceable obligation — with real penalties if you failed.

‍

What we see now is a swap of personal data for AI and open source, and the same story plays out. Enterprises consume open source at a massive scale, and AI is multiplying how fast we ship it. The risk spreads through the code and onto everyone who depends on it. These factors have a distinct impact on infrastructure and application security, which has given rise to a lot of security incidents — some of which we'll talk about a little later.

‍

The key part is that the response has been identical in form: legislation and compliance standards are being put in place to make sure security is no longer a best-effort possibility, but instead must be evidenced and fully supported. This legislation takes the form of things like the EU CRA, NIS2, and DORA, and in the United States there's a myriad of requirements as well.

The Scale of Open Source and AI-Driven Risk

To help paint a picture of open source adoption and the changes caused by AI, there are some helpful data points provided by Black Duck, Sonatype, and others in the industry.

‍

For open source, I don't think there's any confusion about how pervasive the adoption has been — enterprises, and fundamentally the world and the internet, are completely dependent on open source. For context:

‍

• About 10 trillion open source downloads are requested annually.
• There are over 150 million developers on GitHub alone.
• 70% of all code is now open source.
• Enterprise applications average over 900 open source dependencies per application.

‍

This may be surprising to those who aren't close to developer organizations, but this isn't just about a large quantity of usage — it's also that major components enterprises rely on are created and distributed by open source communities. With so much open source in play, staying on current versions may be nearly impossible, especially given product lifecycle requirements that may require enterprises to keep certain versions available for their own customers. We'll talk about that a bit later.

‍

For AI: everyone's aware of the updates coming out seemingly every day and week. Personally, I hear something almost daily that I didn't think AI could or would do. There are a lot of open questions about what AI can and will do in the future — but we do know what it's good at right now, and right now AI is extremely good at finding vulnerabilities. This is causing a massive influx of CVEs.

‍

HeroDevs has seen some really clear examples of this. Take Spring Framework: in 2025, Spring Framework had 17 CVEs disclosed. For 2026, as of the day of this webinar, there are over 200.

‍

This doesn't only impact enterprises — it also impacts the communities and projects that have to review these incoming security issues. They're now facing thousands of requests a week that must be reviewed in order to find and remediate vulnerabilities before they're exploited. Projects like Anthropic's Glasswing initiative have rapidly increased CVE identification, and the number of open source packages containing malicious code is growing as well.

‍

These two elements — the scale of open source usage and the acceleration of vulnerability discovery — impact enterprises the most, because organizations are using a much larger amount of open source and their ability to keep up with that product lifecycle is really, really tough. And once you fall behind, enterprises can't rely on upstream patches and CVE fixes, since the community is no longer providing them.

A Timeline of Breaches Driving Regulation

I'll touch on the history of personal data regulation, but I won't get too far into it since many of you may have some scars from it. The current compliance standards we've seen, if you look through the timeline, arose from some big events. For me, understanding the history of these requirements is helpful for two reasons: first, I find things easier to approach when I understand where the problem originated; second, it helps us understand what future expectations will look like.

‍

Looking at the Snowden whistleblower disclosures and the TalkTalk breach, you'll see that GDPR's adoption and enforcement followed closely on the heels of some very large breaches and disclosures of personal data.

‍

When we look at the EU CRA, we see a similar trend. Consider the Equifax breach in 2017, where millions of people's personal data was disclosed and Equifax was subject to a fine of over $500 million from the FTC. We also see the Log4Shell incident, which we'll talk about a little later. There's a similar timeline: critical security breaches followed by a rise in standards.

‍

What's important to note here is that — regardless of whether it's the personal-data angle or the newer infrastructure-security angle — both are impacted directly by the use of end-of-life open source software, whether under Article 32 of GDPR or Article 13(8) of the EU CRA.

‍

And this isn't just a European story — it's global. Canada has Bill C-26. The US has a myriad of recently published executive orders, FedRAMP, CMMC 2.0, and PCI requirements, plus a proposed revision and security overhaul for HIPAA. Across the globe you see similar requirements rising, including in APAC, where Australia has the Cybersecurity Act as well as CPS-A.

‍

These requirements will impact organizations as well as the enterprises that supply software and services to the companies affected. At a high level, these compliance standards require the same core elements:

‍

1. Know what you're running and using.
2. Have a process and the ability to fix vulnerabilities.
3. Have a process and the ability to report serious incidents that may impact personal or general information.
4. Have audit-ready documentation to show any governing body.

‍

Introducing the EU Cyber Resilience Act (CRA)

Now that we've gone through the history, let's cover the EU CRA specifically — some of it is already in effect, and it will have a widespread impact.

‍

First, let's ground what the EU CRA is: it's the first horizontal cybersecurity law. "Horizontal" means it's the first legislation that applies across every product category, not just one sector. For comparison, many of you may be familiar with the Digital Operational Resilience Act (DORA), which went into effect in January 2025 — but that applies specifically to financial entities and organizations providing certain services to them, making it a sector- or vertical-specific regulation.

‍

The EU CRA was proposed by the European Commission and adopted by the European Parliament and the Council of the EU. Its formal name is Regulation (EU) CRA — not that anyone's going to use that, but just so you know. Its main purpose is to create a mandatory lifecycle obligation for any product with digital elements.

The Four Pillars of the EU CRA

The mandatory lifecycle obligations are built around four main elements:

‍

1. Secure by design. Companies providing or using software products with digital elements must build cybersecurity features directly into the software — not as a bolt-on afterthought. These features have to be maintained through the entire support period.
2. Vulnerability handling. This is an ongoing obligation to identify, document, fix, and report security flaws as necessary. This includes timely, securely distributed patches and a Coordinated Vulnerability Disclosure (CVD) policy that lets security researchers and customers report issues.
3. Incident reporting. In the event a vulnerability is discovered, there must be clear documentation and processes for notifications in line with deadlines.
4. SBOM requirement. A Software Bill of Materials — a machine-readable inventory of all software components, libraries, and dependencies inside the digital product.

‍

Those are the four table-stakes elements within the EU CRA.

What Counts as a "Digital Element"?

The EU CRA applies to products with, quote, "digital elements" — which is as broad as it sounds. Digital elements can include operating systems, desktop and mobile apps, firmware, and libraries. It includes embedded open source. Basically, anything that connects a device to or with a network.

‍

There are a few carve-outs handled by other regulatory requirements — for example, pure SaaS is covered under NIS2, and certain sectors like automotive, aviation, and medical are covered by their own standards. Still, the definition of "digital element" is very broad on purpose.

‍

One carve-out worth clarifying is non-commercial open source. Non-commercial open source means software that is built and provided completely free, without a commercial model or path to monetization — no intent to profit from distribution. Realistically, this exemption applies to upstream projects and communities. To be clear: any manufacturer that bundles open source software — including non-commercial open source — into their products is subject to the EU CRA.

‍

And just like GDPR, the EU CRA is extraterritorial. If you're not located in the EU but you sell products into the EU, this is in scope for you, regardless of where you're incorporated or where you do business.

The Log4Shell Backstory

It's worth noting that the European Commission's proposal for the EU CRA specifically referenced the Log4Shell vulnerability. A small Java library known as Apache Log4j was sitting inside millions of applications. Overnight, a security flaw put much of the internet at risk: the CVE allowed attackers to run malicious code on a target computer or server from anywhere on the internet. Someone exploiting it could gain full control, steal data, install ransomware, or launch full-scale network attacks.

‍

This exposed a hard truth the European Commission was aiming to solve: no one was accountable for the security of Log4j across all these deployments. The EU CRA assigns that accountability to whoever places the product on the market.

‍

Key EU CRA Deadlines and Articles

Let's go through a quick timeline and cover some key elements of the EU CRA in more detail.

‍

• The EU CRA was proposed by the European Commission in 2022.
• It entered into force in December 2024, which is when people started paying more attention to it.
• September 11, 2026 — vulnerability reporting obligations now apply. (This is last week as of this webinar.)
• December 11, 2027 — full requirements take effect.

‍

So as of today, the reporting clock is effectively running. If a vulnerability in your product is being actively exploited, you have to report it — through the EU Agency for Cybersecurity (ENISA), via the Single Reporting Platform (SRP). This gets picked up and reviewed by the National Computer Security Incident Response Team (CSIRT). You have to love acronyms if you want to get into the EU CRA — it's a requirement.

‍

The clock is aggressive:

‍

• 24 hours — early warning requirement
• 72 hours — full notification
• 14 days — final report, after a fix is made available

‍

Importantly: if you shipped a product prior to September and it's already in the field, you're still on the hook for these obligations now. The EU CRA's wide definition of applicability isn't tied to a single sector or to organizations that operate primarily in the EU — if you're doing business in the EU, this will very likely have an impact on you.

Three Requirements That Matter Most Right Now

Article 13(8) — the support period. Manufacturers providing a product with digital elements must declare a support period of at least five years. During those five years, they must handle vulnerabilities in every component, including embedded open source. Updates also have to stay available for ten years — this prevents manufacturers from using licensing terms to pull fixes back after the fact. Regulators want to give those dependent on the software time to migrate, so manufacturers can't ship a fix and then immediately withdraw it.

‍

Article 14 — vulnerability reporting. This covers the 24-hour/72-hour/14-day reporting clock described above. Key actions enterprises should take today:

‍

• If you're providing a product with digital elements, identify an assigned representative — the person who will log into the ENISA SRP if a vulnerability is discovered.
• Have that representative create an EU login (an account with the European Commission) ahead of time — but note the European Commission specifically advises against pre-registering directly on the SRP itself.
• Establish a clear internal process for who's responsible for what during an SRP report.

‍

Annex I — SBOM requirements, commencing in December. Four main elements:

‍

1. Generate machine-readable SBOMs for every distinct version of a software product, included as part of the technical documentation, so regulators (surveillance authorities) can review it.
2. Update the SBOM continuously — it can't be a stale snapshot from twelve months ago; it needs to reflect current components, patches, and updates.
3. Integrate vulnerability handling — the SBOM should tie into continuous vulnerability matching and tracking tools to support compliance and fast reporting.

Penalties

The goal is for every organization to meet these requirements and stay in compliance — but there is real teeth behind the EU CRA. Penalties can reach into the tens of millions of euros or a percentage of global annual turnover, whichever is higher. For serious breaches, products can be pulled from the EU market entirely, which could have severe consequences.

What to Do Now

• Understand your scope of applicability to the EU CRA — read through the definitions. If you're providing digital elements into the EU, you're impacted.
• Identify your assigned representative.
• Start evaluating vendors who can help generate machine-readable SBOMs.
• Put a DevSecOps platform in place so you can monitor risk in real time.
• With your assigned representative, practice the 24-hour/72-hour/14-day reporting workflow.
• Keep evidence — an audit trail, DevSecOps records, and SBOMs will be essential.

‍

December 2027 may seem far away, but it will come up quickly — and it hits hardest for organizations relying on end-of-life open source software.

‍

What "End-of-Life Open Source" Actually Means

We've covered the history and reasoning behind the CRA and what it requires. Now let's focus on where the risk is most prominent for organizations today.

‍

"End-of-life open source software" can mean a couple of things:

‍

• Completely abandoned by the community. Example: AngularJS. Google no longer wanted to maintain it, so users had to migrate to React or modern Angular. If you're still relying on AngularJS, the community isn't reviewing it for security issues or providing CVE fixes.
• A version that falls out of community support, even if the project itself is active. Example: Spring Framework, used for building enterprise-level Java applications. The community has a release cadence where legacy versions stop receiving CVE fixes — so if you're on Spring Boot 2.5, that version is end-of-life, and the community won't provide fixes for it even as security issues grow exponentially due to AI.

‍

It's tempting to assume organizations aren't relying on unsupported software with known critical or high CVEs, but the reality is:

‍

• Between 5% and 15% of enterprise components are already end-of-life.
• Over 81,000 packages have known CVEs with no known fixes, because the community has moved on.
• This risk isn't limited to major dependencies or frameworks that are top of mind — 93% of these CVEs are actually in transitive dependencies that many organizations never explicitly chose. They're just native to the deployed solution.

‍

The problem isn't slowing down. Between April and July alone, there were major end-of-life events for MySQL, Node.js, Django, Angular, and Spring Boot — all within 90 days. Organizations using these tools were on a full sprint to modernize and stay on supported versions, often at the expense of other projects and value-building work.

Real Compliance Risk Examples

This isn't a hypothetical problem. Two current examples tie directly back to the EU CRA:

‍

• Spring Security has a critical CVE that silently prevents HTTP security headers from being applied. The application continues to run and pass all status checks, but the browser-side protection — which is vital — disappears completely, without logging any errors or warnings.
• Angular had a high-severity CVE: a cross-site scripting hole that let attackers run harmful JavaScript on a user's web page, hiding malicious code inside translated text files within the Angular application.

‍

In both cases, under the EU CRA — or even DORA — an organization would face potential noncompliance in two ways: first, a breach under Article 13(8) for running an unsupported version of software in a product with digital elements, and second, if the organization failed to report within the Article 14 reporting deadlines.

‍

End-of-life open source usage is pervasive, and that usage can cause noncompliance with the EU CRA, GDPR, and other standards.

‍

Two Paths Forward

So what do you do about it? There are two options.

‍

Option 1: Move to a supported version. This sounds intuitive, but as many technical folks here can attest, migration can be extremely difficult — especially across dependencies in an ecosystem. Migrating Spring, for example, may also require migrating away from Java 8, pushing your migration timeline past twelve months. During that time, you're spending resources to modernize without gaining much new functionality — and, worse, you're still out of compliance in the meantime. This path requires enterprises to be extremely thoughtful about what open source they deploy and to keep a constant eye out for end-of-life events, which is tough given the sheer volume of adoption.

‍

Option 2: Find a vendor who can support the end-of-life software. This is where HeroDevs comes in — we provide a drop-in replacement for end-of-life open source software. As part of our subscription services, you receive CVE remediation and support throughout the entire period, giving enterprises the ability to control their own modernization timeline while staying compliant along the way.

The Remediation Market Boom — and How to Vet a Vendor

With all the discussion around AI and the rise in CVEs, there's what I'd affectionately call a "remediation market boom." SCA tools and similar solutions have gotten good at identifying CVEs in end-of-life open source software. But the real question now is: what do you do once it's identified?

‍

With 48,000 CVEs disclosed in 2025 — up over 250% year-over-year — there's a major push by vendors claiming they can remediate open source software, including versions no longer receiving community support. I've personally seen organizations claim AI alone can do it. But recent research, including from 1Password, found that only one in four solely AI-created patches actually remediated the underlying bug or CVE.

‍

From our end, HeroDevs did some research and found a prominent vendor boasting about CVE fixes for Spring. When we looked at the documentation, we found that out of 258 Spring CVEs this vendor claimed to have patched, nearly two out of three had no working fix behind the claim.

‍

Given this, I strongly recommend that anyone evaluating a vendor get real proof, rather than taking any vendor's word (including ours) at face value. Specifically:

‍

1. Ask for release notes that tie specific CVEs to specific releases.
2. Ask for VEX statements that highlight the remediated CVEs.
3. Check the vendor's expertise level. AI alone is not a magic cure — look for vendors that are registered CNAs and that have a track record of actually finding CVEs themselves, not just relying on upstream patches.
4. Run a proof-of-concept scan. Confirm the fix doesn't break your application, and — importantly — confirm it doesn't just clear the negative finding via a version bump while the underlying CVE is still present.

‍

Not having proper support isn't just a risk to you — it's a risk to your ability to comply with these regulations, which in turn makes it a risk to your customers.

‍

Closing Takeaways

History repeats itself, and we've seen this trend before. The EU CRA won't be the last requirement of its kind — use the practices you build for EU CRA compliance to prepare for what comes next. Open source adoption is through the roof, and AI is making it easier and faster to find vulnerabilities. That's why it's crucial to have a plan for supporting end-of-life open source software and for meeting your EU CRA requirements.

‍

EU CRA mandates have already begun — this isn't something that "all lands in December." Real requirements are already in effect. So:

‍

• Identify your assigned representatives.
• Get your EU login set up.
• Make sure you have an SBOM accessible and are scanning for vulnerabilities so you can report on time.
• Recognize that end-of-life open source software is a direct compliance issue that must be dealt with — choose a vendor with the expertise and experience to help.

‍

Q&A

Erin Hannaford: Thanks so much, Rob. We've got a couple of questions that have come in, so I'll start at the top.

‍

Attendee question: You talked a little bit about machine-readable SBOMs. Can you elaborate on what a machine-readable SBOM gives you that the repo's dependency manifest doesn't already have?

‍

Rob Nalen: Good question. Your package.json or pom.xml tells you what your developers directly chose to add. But — and this is where the EU CRA's Annex I obligation comes in — it doesn't give you the full list of dependencies, and it doesn't provide the audit trail that assessors want to see. That audit trail needs to include the transitive components that, more likely than not, nobody on your team explicitly selected — which is where that 93% figure I mentioned earlier comes in.

‍

That's why an SBOM matters. A format like CycloneDX or SPDX is structured to be machine-parsed, and it diffs release over release. So when the next vulnerability arises — similar to Log4Shell — you can determine whether you're affected much faster. Ideally, you get the full picture instead of a narrow one.

‍

Erin Hannaford: Great, thank you. Ralph is asking how we can verify that a vendor's fix actually resolves the issue instead of just suppressing it — he's seen a lot of resolved tickets that just move the problem somewhere a scanner can't see it.

‍

Rob Nalen: Good question. I'd point back to the four questions I mentioned. First, work with the vendor to get a sense of what they're actually providing before you commit to an engagement — this could be a simple proof of concept looking at a single framework or even a single fix.

‍

Get the release notes — they should tie a specific CVE to a specific release. You can't just rely on a marketing page that says "yes, you're supported." Next, and maybe most important, are VEX statements — these are machine-readable, and you can upload them into your SCA or DevSecOps platform to check whether they match your own vulnerability tracking.

‍

Beyond that, dig into the vendor itself: are they a registered CNA through MITRE? For CVEs that HeroDevs remediates, we're specifically identified as the organization that found and remediated the CVE — meaning we're not simply relying on upstream patches to come in; we're actively going out and looking for these issues ourselves.

‍

Lastly, when you're doing your proof of concept, run the actual code and confirm it's not just a version bump — again, this ties back to the VEX statement and whether the CVE is genuinely remediated. Doing these things will help you identify whether a vendor has the expertise needed.

‍

Erin Hannaford: Great, and I think we have time for one final question. Richard asks: if we already have a multi-year plan to get off legacy frameworks, does that not cover us under the CRA?

‍

Rob Nalen: Good question — unfortunately, the answer is no. Under some other regulations, you could file an exception saying something is "under development" to limit exposure. Under the EU CRA, that doesn't stop your organization's obligation to comply. Article 14's reporting obligations have been live since September 11, 2026, and they apply to every product on the market — so having a modernization path in progress isn't sufficient on its own.

‍

What I'd recommend: organizations should be working through their SCA scanners right now, identifying where end-of-life open source software exists, migrating to current versions as quickly as possible where they can, and — where they can't — engaging vendors like HeroDevs to get the support they need and ensure compliance starting today.

‍

Erin Hannaford: Thank you, Rob, and thank you everyone for joining us. That concludes today's webinar. Be on the lookout for the webinar recording and the accompanying white paper. Thank you.

‍