AI Is Exposing The Open Source Ecosystem’s Remediation Gap

Frontier AI models are identifying vulnerabilities in open source software faster than human researchers, but remediation is not keeping pace, creating a widening gap that now affects 82% of organizations, up from 74% the previous year, according to recent findings. The pressure is prompting some companies, such as scheduling platform Cal.com, to abandon open-source licenses for proprietary ones, citing AI's ease in finding vulnerabilities in public code. The article argues that visibility tools like SBOMs are insufficient without accountable maintainers and support structures to deliver fixes.

AI Is Exposing The Open Source Ecosystem’s Remediation Gap Frontier AI models are identifying vulnerabilities exponentially faster than human researchers. But this process only improves security if maintainers and organizations can keep pace with remediation. These pressures are beginning to surface in decisions about how software is licensed and shared. Earlier this year, scheduling platform Cal.com announced https://www.zdnet.com/article/ai-security-worries-force-company-to-abandon-open-source/ that it would move its flagship commercial product from an open-source license to a proprietary one, citing how easily modern AI tools can be used to identify vulnerabilities in publicly available code and its responsibility to protect sensitive customer data. For organizations that already depend on thousands of open source components, the issue is not simply whether AI can find more vulnerabilities. It is whether the software ecosystem has the resources, accountability, and support structures to address them before it’s too late. When Discovery Outpaces Remediation Identifying vulnerabilities once required significant expertise and time. Now, the process is increasingly assisted by AI systems capable of analyzing large codebases and surfacing potential security issues. However, remediation is not a single engineering task. A vulnerability must be validated, mapped to affected versions, assessed for reachability and business impact, fixed upstream or backported, regression-tested against the organization’s environment, deployed and documented. AI can accelerate parts of that process, but it cannot create an accountable maintainer or supported release where none exists. This fuels a growing imbalance across the software ecosystem. AI is also accelerating software development and increasing the pace at which new open source components enter production. At the same time, many of the communities responsible for maintaining those dependencies continue to operate through governance models, contributor networks, and support structures built for a much slower era. The result is a widening gap between the rate at which vulnerabilities can be discovered and potentially exploited and when they can be remediated. For enterprises, the concern is operational. Every discovered vulnerability creates additional remediation work across security, engineering, compliance, and open source program teams. As findings accumulate faster than teams can address them, organizations face mounting backlogs, longer remediation cycles, and increasing difficulty prioritizing risk across complex software environments. This growing backlog is contributing to widespread security debt, which recent findings https://1ea35387.streak-link.com/DBVMJogZWclgIXt2fgEp4vXM/https%3A%2F%2Fwww.veracode.com%2Fblog%2F2026-state-of-software-security-report-risky-security-debt indicate now affects 82% of organizations, up from 74% the previous year. AI Is Exposing an Accountability Gap Vulnerability discovery is becoming easier, faster, and more accessible. The real question is who remains responsible for remediation once a vulnerability is discovered, and whether a sustainable support model exists to deliver it. For years, software supply chain security has focused on visibility through inventories, SBOMs, scanners, and vulnerability management programs. Those capabilities remain essential, but visibility alone does not reduce risk—vulnerabilities must be remediated. This becomes especially difficult when open source software reaches end of life. Vulnerabilities do not stop emerging when community support ends, but responsibility for addressing them often becomes unclear. As regulators, auditors, customers, and boards place greater scrutiny on software supply chain risk, frameworks such as PCI DSS, DORA, and the EU Cyber Resilience Act are raising expectations around software governance and ownership. The industry is beginning to recognize that discovery alone is not enough. New vulnerability research initiatives may improve visibility, but they do not answer who will validate findings, develop fixes, and maintain affected software over time. Organizations need confidence that the critical software they rely on will continue to be supported and secured. Open Source Has Become Critical Infrastructure Modern enterprises depend on open source software at nearly every layer of the technology stack, with 98% of commercial codebases https://www.blackduck.com/blog/open-source-trends-ossra-report.html containing open source components, Critical business applications often rely on hundreds of open source frameworks, libraries, and dependencies that support customer experiences, internal operations, and revenue-generating systems. As that dependence has grown, expectations around security, compliance, and operational resilience have grown as well. Organizations are no longer evaluating open source solely on functionality or performance. They are increasingly evaluating whether the software they depend on can be supported, secured, and maintained over time. Yet most organizations consume open source very differently than they consume commercial software. When enterprises purchase commercial technology, they expect support contracts, service-level agreements, escalation paths, and clearly defined accountability. Open source has historically operated under a different model, relying on communities and maintainers to provide support, governance, and security updates. For years, that distinction mattered less. Open source communities delivered innovation and maintenance at extraordinary scale. But AI is increasing the volume and pace of security demands on an ecosystem that was not built to provide enterprise-level support at scale. Building a Reliable Path to Remediation None of this means open source is disappearing. Open source remains one of the most important drivers of innovation in modern software. Organizations do, however, need to become more intentional about how they govern, secure, and support the software running within their environments. - Ensure current compliance with internal, regulatory and industry requirements. - This is done by identifying unsupported and end-of-life open source dependencies. Enterprises can do this by generating real-time build SBOMs and mapping dependency data from package manifests; Use scanners that flag unmaintained and deprecated packages directly, such as this completely free EOLDS scanner https://www.herodevs.com/eol-dataset/overview? gl=1 1jmupnz up MQ.. gs MQ.. ga NzM5NjgyNDg2LjE3NTkxNjU1Njc. ga Q36QRB8QK0 czE3ODc4NjM2NzMkbzMxOSRnMCR0MTc4Nzg2MzY3MyRqNjAkbDAkaDA.&gclid=CjwKCAjwwL UBhAjEiwAEhuT5Mv Ovvm-2PTZtfH8Yw5DLPyhF4EAiQfSIxUmDm4LI0 XLwEcFwbBhoCxosQAvD BwE&gbraid=0AAAAAp2iF1512FuaxxYLqWP-SxKiz lM4 . - In cases where unsupported open-source software is discovered, enterprises should either migrate to a supported version to continue receiving CVE fixes from the community or, if migration is not feasible, seek support from a reputable third-party vendor that is engaged with the open-source community, - - Use and deploy open source with a clear path for ongoing support and CVE remediation. - This can be done by tracking and monitoring open-source software life-cycles and EOL dates. This enables teams to set themselves up for a modernization plan that scales over time. - If a “gap” between the end of open-source community support and an organization’s ability to migrate is expected, identify stakeholders to provide support during that period—whether in-house or third-party maintainers. - Software supply chain security depends on more than visibility. It requires clear ownership and a reliable path to remediation, including for end-of-life software that cannot be replaced overnight. As discovery accelerates, the industry’s greatest challenge may not be finding more vulnerabilities, but ensuring organizations can address them while modernizing on a timeline that works for their business. SD Times Q&A How does AI-accelerated vulnerability discovery create a remediation backlog in open source? AI models can scan large codebases and surface potential vulnerabilities far faster than human researchers, generating findings at a rate that maintainer communities and enterprise security teams cannot match. Because remediation requires validation, patch development, regression testing, and deployment, the discovery-to-fix cycle is significantly longer than the discovery cycle itself. The result is a growing backlog of unaddressed CVEs, particularly in projects with limited maintainer resources. What happens to open source vulnerability remediation when a project reaches end of life? When an open source project reaches end of life, the community stops issuing CVE fixes and security patches, but new vulnerabilities in that codebase continue to be discovered. Responsibility for remediation becomes unclear: the original maintainers are no longer obligated to act, and consuming organizations must either migrate to a supported version, apply fixes internally, or engage a third-party vendor that provides extended support for EOL software. What is an SBOM and how does it help manage open source security risk? A Software Bill of Materials SBOM is a machine-readable inventory of all open source and third-party components in a software build, including version and dependency data. Generating real-time build SBOMs lets security and engineering teams map which components are unmaintained, deprecated, or past end-of-life, and prioritize remediation or migration efforts. Regulatory frameworks including the EU Cyber Resilience Act and U.S. executive guidance increasingly expect organizations to maintain SBOM data. Which compliance frameworks require organizations to govern open source software supply chain risk? PCI DSS, the EU Cyber Resilience Act CRA , and DORA Digital Operational Resilience Act all place explicit or implicit obligations on organizations to understand, govern, and remediate vulnerabilities in their software dependencies, including open source. The CRA in particular extends compliance expectations to software components, requiring manufacturers to track and address known vulnerabilities in the products they ship. What options does an enterprise have when it cannot migrate away from an unsupported open source dependency? When migration is not immediately feasible, enterprises have three main options: apply internal engineering resources to backport security fixes, engage a commercial third-party vendor that provides extended lifecycle support for the EOL project, or accept and formally document the residual risk while accelerating a modernization timeline. Third-party extended support vendors typically maintain patch compatibility with the original open source codebase and participate in the upstream community.