Guest: Dan Lorenc (LinkedIn)
Company: Chainguard 
Show: Secure By Design
Topic: Open Source

Modern infrastructure runs on open source software built by volunteers who owe enterprises nothing. When these maintainers step away from mature projects, companies are left holding production dependencies with no one answering security tickets. Most CIOs don’t have a plan for this, and new regulations like Europe’s Cyber Resilience Act (CRA) are making that gap a liability issue.

Dan Lorenc, CEO and Co-Founder of Chainguard, calls open source “a chaotic system” with no clear economic explanation for why it works. “It’s people writing code in their spare time, doing it for random reasons,” he says. Yet this volunteer-driven ecosystem powers everything from smartphones to ATMs. The problem emerges when maintainers’ motivations change and they decide to archive projects—leaving enterprises scrambling to find replacements or continue running unmaintained code.

Chainguard recently launched EmeritOSS, a program designed to bridge this gap by taking over maintenance of archived open source projects. “We’re not committing to feature work,” Lorenc explains. “We’re just going to be there in case a vulnerability shows up and we need to patch it.” The goal is to extend project lifetimes so companies can migrate on their own schedules rather than being forced into reactive firefighting mode.

The Regulatory Wake-Up Call

The CRA has intensified pressure on this issue by codifying liability for software vulnerabilities. Early drafts of the CRA incorrectly tried to place the burden on open source maintainers themselves—”the completely wrong way to look at this problem,” according to Lorenc. The responsibility has now shifted to companies using the software, which is where it should have been all along.

“Every time you grab one of these, you’re using it at your own risk,” Lorenc says. “That means you have to accept that risk, have a plan to maintain it, and have a plan to get patches if you need them.” The CRA applies to any company serving EU customers, making this a global compliance issue, not just a European one.

The Audit Problem

For CIOs, the challenge starts with visibility. “Because open source is free, nobody even puts it in a spreadsheet anymore,” Lorenc notes. Companies meticulously track every paid SaaS seat but often have no inventory of their open source dependencies. This creates a dangerous blind spot when regulators or auditors come asking questions.

The problem isn’t new, but the volume and unpredictability of open source maintenance make it uniquely challenging. “On any given day, something is going out of maintenance or reaching end of life,” Lorenc explains. “It’s hard to build predictable product roadmaps when you’re constantly forced to swap out components that are being deprecated or quietly archived in the background.”

One financial services institution Lorenc spoke with had hundreds of teams forced to change their roadmaps because a single end-of-life project affected multiple systems. In enterprises with six to nine-month release cycles and annual planning targets, these disruptions cascade quickly.

Where Liability Actually Sits

Lorenc frames the issue in stark terms: “You’re responsible for all the code you use, whether you wrote it or not.” This challenges the common enterprise assumption that they’re only liable for code their teams write. Open source licenses explicitly state the software comes with no warranties, which means liability transfers entirely to the user.

He compares current industry practices to medical malpractice. “We haven’t had that concept in software—a standard set of best practices where, if you do these things, you’re following industry best practices.” New frameworks like NIST’s Secure Software Development Framework are attempting to codify what malpractice looks like in software. Running a 17-year-old Java framework and getting breached is very different from running current versions and getting hit by a nation-state zero-day.

How EmeritOSS Works

Technically, EmeritOSS involves forking archived projects and applying Chainguard’s existing automation infrastructure. “We’re maintaining somewhere around 100,000 different projects where we have automation to bump them, patch them, and rebuild them anytime there’s a vulnerability,” Lorenc says. The program extends this capability to projects that maintainers have already decided to archive.

Chainguard isn’t promising indefinite support or new features—just security patches when vulnerabilities emerge. “We’d like to be able to work with maintainers and move earlier in this process,” Lorenc adds, ideally stepping in when maintainers are considering archiving rather than after the fact.

The team is also experimenting with generative AI (GenAI) to scale the effort. “My guess is that a team of three people, if we keep improving the automation, should be able to handle hundreds—maybe even 1,000—projects,” Lorenc estimates. The work is batchable since vulnerabilities don’t typically hit all projects simultaneously, creating natural economies of scale.

An Ecosystem-Wide Challenge

Lorenc is clear that no single company can solve this alone. “Open source is not a problem anyone can solve alone,” he says. “It’s hundreds of thousands of people all contributing to projects in different ways, for different reasons.” The entire industry shares this supply chain, which means solutions require collective effort across vendors, foundations, and enterprises.

His advice for enterprises is straightforward: treat open source like any other software dependency. “Open source is free as in puppy, not free as in beer,” he says, referencing the classic analogy. “You have to take care of it the same way you have to take care of any software.” That means having migration plans, patch strategies, and clear ownership internally—whether you build those capabilities yourself or work with partners like Chainguard to fill the gaps.