The CVE Blind Spot: Defeating "Hidden EOLs" and Repo Jacking with Engineering Triage & Code Diet

The CVE Blind Spot: Defeating "Hidden EOLs" and Repo Jacking with Engineering Triage & Code Diet

Speakers: Kota Kanbe (Future Corporation); Ryunosuke Tanai (Security Engineer, Future Corporation)

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=qiTQGY9vxks

Overview

In an era of increasing software supply chain attacks, traditional vulnerability management approaches often fall short. This talk, delivered by Ryunosuke Tanai and Kota Kanbe of Future Corporation, Japan, exposes a critical "CVE blind spot" that leaves organizations vulnerable to sophisticated attacks and undetected risks. They present a compelling case, rooted in their firsthand experience with a significant repository hijacking incident, demonstrating that the current CVE system and many security scanners are ill-equipped to identify threats arising from misconfigurations, attack tactics, and especially, unmaintained or End-of-Life (EOL) software dependencies.

The core of their presentation introduces Code Diet, a complementary strategy designed to close this blind spot. Code Diet combines lifecycle governance—implemented through their open-source tool Uzumuzo—with a proactive approach to eliminating unnecessary dependencies, thereby shrinking the attack surface and improving overall code health. Kanbe, creator of the widely recognized binary scanner Virus and the newly introduced Uzumuzo, along with Tanai, a security engineer specializing in supply chain security, argue that security must evolve beyond merely patching known CVEs to embrace "preventive medicine" through diligent dependency management and aggressive code reduction.

This talk is crucial for security professionals, developers, and architects grappling with the complexities of modern software supply chains. It highlights that a clean CVE record can be a deceptive indicator of security, particularly for abandoned or EOL components. By offering a practical, reproducible methodology and open-source tools, Tanai and Kanbe empower the community to identify and mitigate risks that current industry standards overlook, fostering a more resilient and secure software ecosystem.

Background

▶ Watch: Our repository was hijacked: the incident story (2:00)

The impetus for this talk stemmed from a harrowing incident that directly impacted Future Corporation. On February 24th, 2026, during a routine release of their binary management platform, a GitHub repository they depended on was hijacked. Four days later, a self-described autonomous AI agent named Hacka Bot Kuro, reportedly powered by Claude Opus 4.5, scanned over 47,000 GitHub stars, identifying and exploiting vulnerable GitHub Actions workflows. This resulted in at least seven compromised targets, with severe outcomes including full repository takeovers, deletion of 178 releases, and the loss of 24,000 GitHub stars within 90 minutes of initial compromise. The vulnerable workflow had been exposed for over three months, with a security scanner having previously flagged it in November 2025.

Despite downloading their binary during the attack window, Future Corporation's system remained cryptographically untampered, thanks to rigorous verification processes including binary hash comparison, build timestamps, and Sigstore signature verification. However, the story didn't end there; three weeks later, a second wave of attacks hit due to incomplete credential rotation, demonstrating the cascading effects of such compromises. This experience prompted two critical questions: could these attacks have been prevented, and could the CVE system track the damage?

To address the first question, the speakers undertook a unique analysis: they cloned all seven targeted repositories, checked out the commits just before the attacks, and ran OpenSSF Scorecard locally. The results revealed glaring issues: all seven repositories scored zero out of ten for "token permissions" due to over-privileged tokens. For three out of seven targets (Trivy, Awesome Go, and Rust Python), Scorecard flagged "dangerous workflow" issues, with specific warnings like "untrusted code checkout" aligning directly with the attacker's exploit vectors. This suggested that the signal for prevention was present, at least for some targets. However, for the remaining four targets (Argie, AI Discovery Agent, Delock ISC Scanner), Scorecard gave a perfect "10 out of 10" for dangerous workflows, yet these repositories were still compromised. The attacker employed techniques outside Scorecard's scope, such as issue command script injection and AI prompt injection, highlighting the limitations of any single security tool and emphasizing the need for defense in depth.

More alarmingly, the second question revealed a profound systemic failure: the CVE system proved incapable of tracking the damage. Repository takeovers, token theft, and remote code execution (RCE) in CI/CD pipelines—the most destructive outcomes—received no CVEs. The few CVEs assigned were for specific malicious code versions, not for the overarching chain attacks. This is because workflow misconfigurations, repository hijacking, and CI/CD RCE do not fit the definition of a CVE vulnerability, which is designed for software flaws, not infrastructure attacks or attack tactics. The speakers learned about this "most significant supply chain attack in 2026" not through industry-standard vulnerability management tools, but through social media platform X. This underscored the existence of a CVE blind spot: a vast domain of destructive outcomes that fall entirely outside the CVE system's scope.

This blind spot encompasses three structural categories: attack techniques (tactics like repo takeover, credential theft, CI abuse), configuration issues (site-specific misconfigurations enabling attacks), and critically, unmaintained software or End-of-Life (EOL) packages. While the ecosystem is beginning to respond to visible problems like misconfigurations with immutable releases and workflow hardening, the invisible threat of unmaintained software remains largely unaddressed. These "hidden EOLs" are packages that have reached end-of-life but persist in production without awareness. They manifest as dead-end EOL (maintainer vanished), lazy EOL (no releases in years but still widely used), transitive EOL (abandoned code deep in the dependency tree), stranded EOL (orphaned in a niche ecosystem), and hollow EOL (code exists but no one is watching). The critical insight here is that "no CVE doesn't mean no vulnerability"; for EOL packages, a clean CVE record reflects a lack of ongoing security research and maintenance, not an absence of exploitable flaws. Their research, analyzing 60,000 OSS packages in production across 100 organizations in Japan, found that only 51.5% were in a healthy state, with the remaining half carrying lifecycle risks that no CVE would ever capture—a finding consistent with Black Duck's 2026 OSS audit report, which noted 93% of codebases contained components with no development activity in over two years. This "iceberg" of hidden risk necessitates a complementary approach beyond CVEs.

Key Findings

▶ Watch: "Hidden EOLs": no CVE doesn't mean no vulnerability (14:00)

The presentation by Tanai and Kanbe illuminates several critical findings that challenge conventional wisdom in software supply chain security:

• The CVE System's Inherent Blind Spot: The most significant discovery is the existence of a fundamental "CVE blind spot." The current CVE framework is designed to track specific software flaws, rendering it incapable of addressing entire classes of modern supply chain attacks, such as repository takeovers, token theft, CI/CD Remote Code Execution (RCE), and workflow misconfigurations. These are not merely delays in CVE assignment but fundamental scope limitations, leading to critical incidents being communicated via social media rather than established vulnerability channels.
• Widespread Undetected Lifecycle Risk in Production OSS: A substantial portion of open-source software running in production environments carries significant lifecycle risks that are completely missed by traditional CVE-based scanners. Their study of 60,000 OSS packages in Japan revealed that only 51.5% were "healthy," with the rest exhibiting hidden EOLs (End-of-Life) or abandoned status. This aligns with broader industry reports, indicating that "no CVE doesn't mean no vulnerability"; a clean CVE record for an EOL package often signifies a lack of active maintenance and security scrutiny, not an absence of exploitable flaws.
• Limitations of Current Security Tools: While valuable, existing security tools like OpenSSF Scorecard are not a panacea. The Hacka Bot Kuro incident demonstrated that Scorecard could flag some vulnerabilities (e.g., over-privileged tokens, dangerous workflows related to untrusted code checkout) but entirely missed others, particularly sophisticated attack vectors like issue command script injection or AI prompt injection. This underscores the necessity for a defense-in-depth strategy rather than reliance on any single tool.
• The "Code Diet" as a Complementary Solution: The talk introduces Code Diet as an effective and necessary complement to traditional vulnerability management. This approach has two pillars: lifecycle governance (detecting EOL/abandoned dependencies using Uzumuzo) and dependency removal (eliminating unnecessary code). This strategy not only shrinks the attack surface and reduces maintenance costs but also demonstrably improves code quality, as evidenced by their own binary scanner's size reduction from 100MB to 34MB with improved correctness.
• Proactive Prevention vs. Reactive Patching: The speakers advocate for a paradigm shift from reactive vulnerability management ("treating the disease") to proactive OSS health management ("preventive medicine"). By systematically identifying and removing hidden EOLs and unused dependencies, organizations can reduce their attack surface before incidents occur, rather than solely relying on patching after a CVE has been identified.

Technical Deep Dive

▶ Watch: Introducing Code Diet: detect lifecycle risk, remove dependencies (18:00)

The technical core of the presentation revolves around addressing the CVE blind spot through two primary mechanisms: Uzumuzo for lifecycle governance and the Code Diet strategy for dependency reduction, supported by the Uzumuzo Diet tool.

Uzumuzo: Lifecycle Governance for Hidden EOLs

Uzumuzo is an open-source tool designed to detect and classify the lifecycle status of software dependencies, going beyond traditional SCA tools that primarily focus on known CVEs. It tackles the fundamental question: "Is this package still maintained?"

• Input and Data Sources: Uzumuzo accepts various inputs, including an S-bomb (Software Bill of Materials), go.mod files (for Go projects), or a GitHub URL. It then queries multiple data sources: GitHub for repository status and commit history, deps.dev for dependency graph information, OpenSSF Scorecard for security health metrics, and package registries (e.g., npm, Go package index) for release frequency and publication data.
• Seven-Stage Classification: Unlike simple archived flags or maintenance scores, Uzumuzo employs a sophisticated seven-stage classification system for dependencies:

1. Active: Actively maintained with recent development.
2. Legacy Safe: Quiet but stable, no immediate action needed.
3. Stalled: Activity is slowing down; this is an early warning signal for potential future issues.
4. Effective EOL: Effectively End-of-Life due to lack of activity, even without an official announcement.
5. Official EOL: Officially declared End-of-Life by maintainers.
6. Archived: Repository has been archived, indicating no further development.
7. Removed: Package has been removed from its ecosystem.

This granular classification allows for differentiated actions: "Stalled" requires monitoring, while "EOL" mandates removal.

• Ecosystem-Aware Judgment: Uzumuzo's judgment is tailored to specific ecosystems. For instance, in Go, a package might be considered active if it's available via go get, whereas in NPM, active maintenance requires publishing to a registry. This prevents misclassifications due to differing ecosystem norms.
• Signal Combination and Noise Reduction: The tool combines multiple signals for its classification, including commit history, release frequency, and Scorecard metrics. Crucially, it filters out "bot noise," meaning automated activities like Dependabot pull requests are not counted as genuine human development activity, ensuring a more accurate assessment of maintenance status.

Code Diet: Shrinking the Attack Surface

Code Diet is a proactive strategy to reduce the number and depth of dependencies, thereby shrinking the attack surface and improving code quality. It's about "dieting what you can't patch" – eliminating risks that CVEs will never cover.

• Pillars:

1. Detect (Uzumuzo): Identifying EOL and abandoned dependencies.
2. Remove (Code Diet): Eliminating unnecessary dependencies through standard library replacement or self-implementations.

• Iterative Approach: The speakers initially tried a per-package removal approach (e.g., replacing go-home-dir with a standard library equivalent). While effective for direct dependencies, it had minimal impact on overall binary size due to persistent indirect dependencies. The revised and more effective approach focused on identifying and replacing large, monolithic libraries that pulled in hundreds of unnecessary transitive dependencies. By replacing these with direct calls or smaller, purpose-built components, a significant reduction in binary size and dependency count could be achieved.
• Impact on Code Quality: Beyond security, Code Diet leads to cleaner, more maintainable code. The speakers demonstrated this by reducing their Virus scanner's binary size from 100MB to 34MB (-68%). Rigorous testing, including LLM-generated tests and running the scanner against 129 real projects, confirmed that the new, leaner code was not only functional but often more correct than the original.

Uzumuzo Diet: Prioritizing Removal

To make the Code Diet practical, the Uzumuzo Diet tool helps prioritize which dependencies to remove first.

• Four-Step Process:

1. S-bomb Build: Generates a comprehensive dependency graph.
2. Source Code Reading: Analyzes the project's source code to understand how dependencies are used (number of files importing, number of calls).
3. Health Signals: Incorporates health signals from Uzumuzo scans (e.g., EOL status, stalled activity).
4. Final Score: Calculates a priority score based on impact, risk, and ease of removal.

• Prioritization Logic: The tool prioritizes dependencies with a "big impact, big risk, easy to remove" profile at the top of the list. It also identifies packages present in the S-bomb but with no corresponding imports in the source code, indicating unused dependencies that can be immediately deleted.
• LLM for Attack Scenario Generation: For critical, deep-seated dependencies like the copy-structure example in HashiCorp Vault, automated scores are insufficient. The speakers highlighted the use of Large Language Models (LLMs) to analyze data flow, build specific attack scenarios (e.g., silent ACL bypass due to shared data in the access control layer), and even generate small, self-implemented code snippets to replace vulnerable components. This bridges the gap between detection and removal for complex cases.

In essence, the technical framework presented provides a complete pipeline from detecting hidden lifecycle risks to systematically reducing the attack surface, moving beyond mere vulnerability scanning to a holistic approach to OSS health.

Demo / Proof of Concept

▶ Watch: Code Diet in action: 68% binary size reduction (30:00)

The talk effectively demonstrated the practical application of Uzumuzo and the Code Diet strategy through several real-world examples:

1. Uzumuzo Identifying Hidden EOLs in HashiCorp Vault:

Kota Kanbe showcased Uzumuzo's ability to scan a widely used project like HashiCorp Vault. The tool immediately revealed 11 End-of-Life (EOL) packages with zero reported CVEs. These EOL packages would go undetected by conventional SCA tools. Kanbe zoomed in on one particularly critical example: the copy-structure package.

• The Problem: copy-structure was archived and unmaintained, with its creator having publicly stated they were no longer actively working on Go. Despite being abandoned, it was used in Vault's access control layer.
• The Risk: If compromised, this package could lead to a silent ACL bypass scenario. Normally, each access check would get its own copy of data. However, if copy-structure were tampered with, all checks could share the same data, causing deny rules to silently disappear without errors or logs.
• Detection Method: Uzumuzo identified the EOL status, and a subsequent LLM-assisted code review (LRM) checked the code for specific vulnerabilities, demonstrating how Uzumuzo plus LRM could find such deep-seated issues in minutes, a task that would otherwise take weeks manually.

2. Uzumuzo Detecting Archived Actions in Grafana's CI/CD:

The demo extended to CI/CD pipelines, illustrating that the problem isn't limited to application dependencies.

• The Problem: A scan of Grafana's GitHub Actions revealed an archived action, tivuteks/github-app-token, being used in 14 places within their release pipeline. This action is critical for building the binaries users download.
• The Risk: An archived action means no one is watching or maintaining it. If this action were compromised, malicious code could be injected into every release build without detection or a fix from the original owner. This highlights that pinning actions by SHA is insufficient if the underlying action's maintainer has disappeared.

3. Code Diet on the Virus Scanner:

Kanbe then demonstrated the tangible benefits of the Code Diet strategy on their own open-source binary scanner, Virus.

• Initial Approach: They first attempted to remove individual packages, such as replacing go-home-dir with a standard library equivalent. While successful, this had almost no impact on the overall binary size.
• Revised Approach (Big Library Removal): They shifted focus to identifying and removing a large, monolithic library that was indirectly pulling in hundreds of other unnecessary packages. By replacing this large dependency with direct calls, the results were dramatic:
• Binary size reduced from 100MB to 34MB – a 68% reduction.
• Validation: To ensure correctness, they used LLMs to write tests and then ran the dieted Virus scanner against 129 real projects. The outcome: 127 out of 129 projects passed regression tests, and the two changes observed were actually improvements in correctness over the original code. This demonstrated that a Code Diet not only makes code smaller but also makes it better.

4. Uzumuzo Diet for Prioritization:

Finally, Kanbe showed the Uzumuzo Diet tool in action, applied to HashiCorp Terraform.

• Functionality: The tool analyzes an S-bomb, reads source code, incorporates health signals from Uzumuzo, and assigns a score to each dependency.
• Output: It generates a prioritized list, identifying "easy fixes" with high impact at the top (e.g., a package in the S-bomb with no imports in the source code, implying it can be deleted immediately). Conversely, deep, complex dependencies with low impact or high removal difficulty are placed at the bottom, advising against starting there. This provides a clear roadmap for implementing a Code Diet effectively.

The cumulative effect of these demonstrations was a compelling argument for the necessity and efficacy of Uzumuzo and Code Diet in addressing the critical gaps left by traditional security tools.

Defensive Implications

▶ Watch: Uzumuzo Diet tool: prioritize removal, LLM for attack scenarios (33:00)

The insights from "The CVE Blind Spot" present a clear call to action for defenders, urging a shift in strategy to encompass a more comprehensive approach to software supply chain security.

1. Expand Beyond CVE-Centric Vulnerability Management: Organizations must acknowledge that CVEs provide an incomplete picture of risk. Defensive strategies can no longer solely rely on patching known CVEs. Instead, they must integrate tools and processes that address the "CVE blind spot," including repository misconfigurations, supply chain attack tactics, and especially the lifecycle health of all dependencies. This means moving beyond reactive "disease treatment" to proactive "preventive medicine."

1. Implement Continuous Lifecycle Governance: Adopt tools like Uzumuzo to continuously monitor the maintenance status of all software dependencies, both direct and transitive. This involves identifying packages that are stalled, unmaintained, or End-of-Life (EOL), even if they have zero reported CVEs. Integrate this lifecycle assessment into CI/CD pipelines to catch issues early. A regular, automated lifecycle scan should be as standard as a vulnerability scan.

1. Embrace a "Code Diet" Strategy: Proactively reduce the dependency graph of your applications. This means going beyond simply updating dependencies to actively removing them where possible. Prioritize replacing large, monolithic libraries that pull in numerous indirect dependencies with smaller, purpose-built components or, ideally, standard library implementations. A smaller attack surface inherently reduces the number of potential entry points for attackers and lessens the burden of future maintenance.

1. Harden CI/CD Pipelines Beyond Configuration: While OpenSSF Scorecard and similar tools are valuable for checking CI/CD configurations, defenders must also scrutinize the maintenance status of the actions and components within those pipelines. Even if a GitHub Action is pinned by a full SHA, if its maintainer has abandoned it (e.g., an archived repository), it poses a significant risk. Regularly scan CI/CD components for hidden EOLs and unmaintained status, just as you would application dependencies.

1. Prioritize Dependency Removal Strategically: Utilize tools like Uzumuzo Diet to make informed decisions about which dependencies to remove first. Prioritize based on a combination of factors: the severity of the lifecycle risk, the impact of the dependency, and the estimated effort for removal. Start with high-risk, easy-to-remove components to build momentum and demonstrate value.

1. Leverage Advanced Analysis for Deep-Seated Risks: For critical, deeply embedded dependencies where automated analysis might fall short, employ more sophisticated techniques. This includes using Large Language Models (LLMs) to analyze data flow, identify complex attack scenarios (e.g., silent ACL bypasses), and even assist in generating secure, self-implemented replacements for vulnerable components. This bridges the gap between automated detection and complex mitigation.

1. Foster a Culture of Dependency Awareness: Educate development teams on the risks associated with unmaintained software and the benefits of a "Code Diet." Encourage developers to consider the lifecycle health of new dependencies before introducing them and to actively participate in the ongoing effort to reduce the project's attack surface.

1. Share Information on Non-CVE Incidents: Just as the speakers learned about the Hacka Bot Kuro attack via X, the security community needs better mechanisms to share information about supply chain incidents that fall outside the CVE scope. Participating in information-sharing initiatives and advocating for broader definitions of vulnerability reporting can help close this communication gap.

By adopting these defensive strategies, organizations can move beyond a reactive posture, building more resilient software supply chains that are less susceptible to the hidden threats of unmaintained code and novel attack vectors.

Key Takeaways

• The CVE system has a critical "blind spot": It fails to cover a vast range of supply chain risks, including repository takeovers, token theft, CI/CD RCE, and misconfigurations. These are scope issues, not delays, meaning many significant attacks will never receive a CVE.
• Hidden EOLs are a pervasive, undetected risk: Nearly half of all production open-source software carries lifecycle risks (e.g., stalled, abandoned, or End-of-Life packages) that traditional CVE-based scanners completely miss. A clean CVE record for an unmaintained package reflects a lack of security scrutiny, not an absence of vulnerability.
• "Diet what you can't patch": Proactively reducing your dependency graph through a "Code Diet" strategy significantly shrinks the attack surface, lowers maintenance costs, and improves code quality. This was demonstrated by reducing the Virus scanner binary size by 68% while improving correctness.
• Uzumuzo provides essential lifecycle governance: This open-source tool goes beyond CVEs to classify dependencies into seven lifecycle stages, filtering bot noise and offering ecosystem-aware judgment to identify stalled or EOL packages before they become incidents.
• Strategic dependency removal is key: Tools like Uzumuzo Diet help prioritize which dependencies to remove based on risk, impact, and ease of removal, making the Code Diet practical. LLMs can assist in understanding complex data flows and generating secure replacements for critical, deep-seated risks.
• Shift to preventive security: Move beyond reactive vulnerability management (treating the disease) to proactive OSS health management (preventive medicine) by continuously scanning for lifecycle risks and systematically reducing your attack surface.

About the Speaker(s)

Kota Kanbe is a prominent figure in the open-source security community, recognized for his significant contributions. He is the creator of Virus, a widely acclaimed open-source binary scanner that boasts over 10,000 GitHub stars. Kanbe is also the visionary behind Uzumuzo, the lifecycle governance tool demonstrated in this talk, designed to tackle the "CVE blind spot" by identifying hidden EOLs and unmaintained dependencies. His expertise and impact were formally acknowledged when he received the prestigious Google OSS Peer Award in 2022.

Ryunosuke Tanai is a Security Engineer at Future Corporation, specializing in binary management and supply chain security. His work forms a crucial part of the practical application of the concepts discussed in the talk. Earlier this year, Tanai published a verification report on a Ruby supply chain attack, an experience that directly informed and initiated the research leading to this presentation. Together, Tanai and Kanbe collaborate on operating a cloud-based binary management platform that leverages the Virus scanner, bringing real-world experience and robust engineering solutions to the forefront of supply chain security challenges.