AI Doesn't Know Your Framework Is End of Life. That's a Security Problem.

AI coding tools have changed how engineers write software. They've also introduced a new category of vulnerability risk that most security programs aren't designed to catch.

The problem isn't that AI tools are malicious or even particularly careless. It's that they're trained on historical code, and historical code includes a lot of end-of-life software that was extremely popular before it was abandoned. When a model recommends a dependency based on what appears most frequently in its training data, it's optimizing for prevalence — not for whether the package is currently supported, actively patched, or even still maintained.

The 2026 State of the Software Supply Chain Report documents this directly: EOL packages often appear "popular" in public code corpora, making them more likely to be suggested and adopted as defaults in AI-generated manifests. Once introduced, those patterns replicate across services through reuse, reinforcing dependence on software that has no viable long-term remediation path.

This is not a theoretical concern. It's a structural feature of how these tools work — and understanding it is the first step to building governance around it.

How AI Dependency Selection Actually Works

When an AI coding assistant suggests a dependency, it's drawing on patterns from its training data. That training data is largely composed of public GitHub repositories, Stack Overflow threads, documentation pages, blog posts, and other places where engineers have written about or used specific packages.

The packages that appear most frequently in this corpus are, almost by definition, the ones that were most popular at some point in the past. Popularity in software does not correlate cleanly with current maintenance status. A package can become extremely common in the wild, then slowly lose maintainer activity, then reach end of life — all while its presence in the public codebase remains vast because historical code doesn't disappear.

The result: AI tools recommend packages that look normal based on usage patterns, even when those packages are no longer supported. The model has no reliable mechanism to distinguish between "this package is widely used" and "this package is widely used and actively maintained and currently patching CVEs." Those are different things, but from the model's perspective they can look identical.

The SSCR found a high recommended dependency upgrade hallucination rate in leading LLMs tested — suggesting that models frequently recommend versions that don't exist, versions that are outdated, or upgrade paths that are incorrect. This is a data quality problem that compounds directly with EOL risk: if the model's knowledge of what versions exist and what versions are safe is unreliable, it will steer teams toward EOL software with false confidence.

EOL Risk Is Self-Replicating in AI Workflows

The particular danger of AI-introduced EOL dependencies isn't just the initial bad recommendation. It's how that recommendation propagates.

When an AI tool generates a manifest that includes an EOL component, that manifest becomes a template. Engineers copy it, adapt it, and reuse it across other projects. Code review processes that might catch a security vulnerability in application logic often don't have the context to flag an EOL dependency that "looks fine" — because it is fine, functionally, right up until a CVE drops and there's no patch available.

This is what the SSCR means by "self-replicating" EOL risk: AI reuses prior code patterns, and if those patterns include EOL dependencies, those dependencies get deeper into the organization's infrastructure with every project that copies them. The further a dependency travels from the initial AI-generated manifest, the harder it becomes to unwind.

This pattern is particularly pronounced in large engineering organizations where AI tools are used extensively across many teams simultaneously. A single EOL recommendation that makes it through code review can propagate across dozens of services before anyone realizes the dependency is unsupported.

The Gap Between Training Data and Current Reality

There's a timing problem built into how language models work that makes EOL risk particularly hard to manage in AI-assisted workflows.

Models are trained on data up to a cutoff date. After that cutoff, the model's knowledge of the software ecosystem is frozen in time. New EOL events — packages crossing their support end date, maintainers stepping down, projects being formally deprecated — happen continuously. But the model's recommendations don't update to reflect these events. A package that was actively maintained when the model was trained may be fully EOL by the time an engineer uses the tool to select it.

This gap grows over time. An AI coding tool trained 18 months ago has an 18-month blind spot for EOL events that occurred after its cutoff. Given that EOL events happen across thousands of packages annually, that's a significant accumulation of outdated information baked into the recommendations the tool is making today.

The SSCR notes that AI tools can only make recommendations that are as up-to-date as their training data. For dependency selection, that means teams cannot rely on AI tools to surface EOL status — they need independent, continuously updated EOL detection to catch what the AI doesn't know.

AI Doesn't Help With Old Software — Even When You Need It To

There's another dimension to the AI-EOL problem that security programs often miss: AI tools are also not well-equipped to help organizations that are actively trying to migrate away from EOL software.

Modern AI coding assistants are trained on modern code. They understand current frameworks, current APIs, current dependency ecosystems. They are optimized to generate and assist with code that uses contemporary software stacks.

When an engineering team is working with a legacy application built on a framework that reached end of life several years ago — the kind of application that appears most frequently in HeroDevs' customer base — AI tools are significantly less useful. The documentation that the tools were trained on is sparse or absent for EOL frameworks. The code patterns they know don't apply to the older APIs. Migration guides that once existed on the internet have been replaced with content about newer versions, leaving the model without reliable training signal for the specific migration a team needs help with.

This matters for EOL security planning because it means organizations can't lean on AI tooling to accelerate their way out of the EOL problem. The very applications that most urgently need migration assistance are the ones where AI tools provide the least help. Teams are largely on their own when working with genuinely old software — which is part of why migrations are slower than anyone would like, and why EOL exposure persists longer than security programs expect.

What Governance Looks Like in Practice

Managing AI-introduced EOL risk is not primarily a technology problem — it's a governance problem. The fix isn't to stop using AI tools. It's to build processes that account for the ways AI tools fail when it comes to dependency selection.

Approved catalogs and allowlists. Rather than letting AI tools select from the full universe of available packages, constrain their recommendations to packages on an approved list that is actively maintained for current support status. This doesn't eliminate AI-generated manifests — it ensures they draw from a vetted set of options.

Continuous EOL monitoring in CI/CD. EOL detection needs to run continuously in the build pipeline, not just at the point of initial dependency selection. Because AI tools can introduce EOL dependencies that pass initial review, catch them before they reach production.

EOL status as a first-class signal in code review. Train reviewers to flag EOL dependencies with the same urgency as security vulnerabilities. A dependency that is end-of-life today is a vulnerability that can never be patched tomorrow.

AI output audits for dependency patterns. Periodically review AI-generated code across your organization for EOL patterns — not to catch individual instances, but to identify if AI tooling is systematically steering teams toward categories of unsupported software.

Get Visibility Before AI Makes It Worse

HeroDevs' EOL Detection Suite provides continuous, portfolio-wide monitoring of end-of-life dependencies — including the ones that AI tools introduced without anyone realizing they were already EOL. When a package in your dependency graph reaches end of life or a CVE drops for an unsupported version, you know immediately.

For the EOL components already in your stack — whether they arrived through AI tools, legacy decisions, or transitive dependencies — Never-Ending Support provides security patches and CVE remediation while your team builds and executes a migration plan on a realistic timeline.

Don't let AI compound your EOL exposure. See what's already there: eoldataset.com

Frequently Asked Questions

Do AI coding tools introduce end-of-life dependencies? Yes. AI coding tools are trained on historical code, which includes many packages that were popular before reaching end of life. Because AI tools optimize for prevalence in training data rather than current support status, they frequently recommend EOL dependencies without flagging them as such. The 2026 State of the Software Supply Chain Report explicitly identifies this as a mechanism by which EOL risk is introduced and amplified in AI-assisted development workflows.

Why can't AI tools tell me if a package is end of life? AI language models have a training data cutoff — their knowledge of the software ecosystem is frozen at a point in time. EOL events happen continuously after that cutoff, so a package that was actively maintained when the model was trained may be EOL by the time an engineer receives the recommendation. The gap between training data and current reality grows over time and creates a persistent blind spot for EOL status.

How does EOL risk replicate in AI-generated code? When an AI tool generates a manifest or suggests dependencies that include EOL packages, those recommendations become templates that engineers copy and adapt across other projects. Code review processes often don't catch EOL dependencies because they look functionally correct. The initial AI-generated dependency propagates across services and teams faster than traditional dependency drift, creating broad exposure from a single recommendation.

What is AI dependency selection hallucination? In the context of open source dependencies, AI dependency selection hallucination refers to AI tools recommending package versions that don't exist, recommending upgrade paths that are incorrect, or suggesting packages without accurate information about their current support status. The 2026 SSCR documented a high hallucination rate for dependency upgrade recommendations in leading LLMs, indicating that AI tools cannot be relied upon as authoritative sources of dependency health information.

How should security teams govern AI dependency selection? Effective governance of AI dependency selection typically includes: restricting AI tool recommendations to packages on an actively maintained approved list; running continuous EOL detection in CI/CD pipelines to catch AI-introduced EOL dependencies before production; flagging EOL status in code review with the same urgency as security vulnerabilities; and periodically auditing AI-generated code for systematic EOL patterns across the organization.