Hi, I'm Ryunosuke Tanai from the FutureVuls team.
※本ブログの日本語バージョンは「VulnCon 2026に登壇しました」で公開しています
On April 16, 2026 (Thursday), we presented at VulnCon 2026, a security conference held in Scottsdale, Arizona, USA, on behalf of Future Corporation.
Here is the pre-event announcement:
- VulnCon 2026にFuture Corporationとして登壇します (Japanese)
Session Info
| Item | Details |
|---|---|
| Title | The CVE Blind Spot: Defeating "Hidden EOLs" and Repo Jacking with Engineering Triage & Code Diet |
| Date & Time | April 16, 2026 (Thu) 13:15–14:15 (MST) |
| Venue | Breakout 3 (South Ballroom) |
| Speakers | Kota Kanbe, Ryunosuke Tanai (Future Corporation, JP) |
| TLP | TLP:CLEAR |
Presentation Content
The talk consisted of 8 parts. Tanai handled the talk in the first half, and Kanbe ran the live demo in the second half.
Part 1: Repo Hijacking — Our Story
On February 24, 2026, we pulled trivy v0.69.1 from GitHub Releases as part of our routine release cycle. Four days later, the trivy repository was hijacked.
An AI agent called "hackerbot-claw" (reportedly based on Claude Opus 4.5) exploited vulnerabilities in GitHub Actions workflows and attacked at least 7 repositories. Trivy suffered a full takeover, with 178 releases deleted.
Since we had obtained the binary during the attack window, we performed a three-axis verification using SHA256 hash, build timestamp, and Sigstore signature, cryptographically proving that our binary had not been tampered with. The details of this verification are available in the following articles:
- Trivy Supply Chain Attack: FutureVuls Binary Safety Verification Report (Japanese)
- How We Verified "No Tampering" with Sigstore and cosign (Japanese)
Parts 2–3: Scorecard Analysis and the Limits of CVE
We cloned all 7 targeted repositories, checked out the pre-attack commit, and ran OpenSSF Scorecard CLI — an analysis that, to our knowledge, no one else had performed. The full details are available in "Verifying OpenSSF Scorecard on the 7 Repositories Targeted by hackerbot-claw" (Japanese).
The results showed that 3 out of 7 repositories had Scorecard warnings that aligned with the attack vectors, suggesting the attacks could have been detected in advance. However, the remaining 4 were attacked using techniques outside Scorecard's detection scope (issue_comment injection, filename injection, AI prompt injection, etc.), making it clear that no single tool is sufficient.
Furthermore, the majority of the damage from this attack campaign (repository takeover, token theft, RCE) has no CVE assigned. CVEs were only issued for specific versions containing malicious code. The entire attack chain is outside CVE's scope. We first learned about this attack not through CVE or a vulnerability scanner, but through our X (formerly Twitter) timeline.
Parts 4–5: Hidden EOLs — The Largest CVE Blind Spot
The most critical risk that CVE cannot capture is unmaintained OSS (Hidden EOLs). EOL packages have no CNA and no maintainer, so even severe vulnerabilities go without a CVE. "No CVE" doesn't mean "no vulnerability" — it means "no one is looking."
We analyzed over 16,000 production OSS packages actively running across approximately 100 organizations in Japan. Only 51.5% were in a healthy state. The remaining half carried some form of lifecycle risk. This research was reported by Nikkei (Japan's leading financial newspaper) in March 2026, and the full details are available in the "Software Supply Chain Health Report 2026" (Japanese).
The risk structure resembles an iceberg. Most organizations only track the 9.4% with an official EOL announcement. Below the waterline, Effective EOL (4.5%) and Stalled (34.6%) remain hidden — roughly 4 times more risk than what's visible above the surface.
Parts 6–7: Code Diet and Live Demo
We proposed an approach called "Code Diet" to address risks that CVE cannot capture.
- Pillar 1: Detect — Classify OSS lifecycle into 7 stages. Rather than the binary "maintained / not maintained" returned by existing SCA tools, evaluate using 7 stages: Active, Legacy-Safe, Stalled, EOL-Scheduled, EOL-Effective, EOL-Confirmed, and Review.
- Pillar 2: Remove — Eliminate unnecessary dependencies to reduce the attack surface through standard library replacements and self-implementations.
The live demo demonstrated Code Diet's effectiveness using real-world examples.
Case Study 1: HashiCorp Vault — EOL Lurking in a Secrets Management Tool
Scanning Vault's go.mod revealed that 11 out of 209 dependencies were EOL. Most of them had zero CVEs — risk that vulnerability scanners would never detect.
The two most critical findings were:
aws-sdk-gov1 (EOL-Confirmed): AWS officially recommends migrating to v2. In Vault, it's used in the S3 storage backend (where secrets are stored) and the AWS auth method (access control for Vault). Vault encrypts with AES-256-GCM before passing data to the SDK, so plaintext secrets never pass through. However, AWS credentials (access key, secret key, session token) pass through the SDK in plaintext, creating a credential theft risk if the SDK were compromised.mitchellh/copystructure(Archived): Mitchell Hashimoto, Vault's creator, left HashiCorp in 2023 and bulk-archived his personal repositories — this was one of them. No community fork exists, and no patches will ever come. This package is used invault/acl.go(the access control layer), handling deep copies of DeniedParameters (rules that say "this user cannot access this parameter"). If this package were compromised, security checks would share rules instead of having independent copies, causing Deny rules to silently disappear and access control to break — with no errors and no log entries.
Case Study 2: Grafana — An Archived Action Hiding in the CI/CD Pipeline
GitHub Actions are dependencies just like packages. We demonstrated the blind spot that no one checks whether an Action itself is still maintained.
Scanning Grafana's (73,000+ GitHub Stars) Actions revealed that almost all 39 Actions were Active, except tibdex/github-app-token, which was archived. This archived Action was used in 13 workflow files across 14 locations, including release-build.yml and release-npm.yml — the core of Grafana's release pipeline.
An archived Action will break CI without warning when GitHub retires its runtime. And while compromised active projects get immediate community response, archived projects have no one watching — a compromise would go unnoticed.
We reported this issue to Grafana, and within 3 days a community member submitted a fix PR. The Grafana team is addressing it through their internal shared-workflows.
Code Diet in Practice
We shared the results of applying Code Diet to the OSS vulnerability scanner vuls.
Initially, we replaced 9 individual packages, but the binary size barely changed because they persisted as indirect dependencies. We then shifted our approach to removing the entire framework layer. By eliminating over 250 unnecessary packages pulled in by a Trivy-derived framework (fanal) — including IaC analyzers and disk image parsers — we reduced the scanner binary from 106.6 MB to 34.1 MB (68% reduction). Build time also dropped from 7.8 seconds to 3.2 seconds (59% faster).
For regression testing, we compared scan results against 129 real OSS project lockfiles — 127 out of 129 produced identical results (the 2 differences were improvements).
uzomuzo-oss
We've open-sourced uzomuzo-oss as the tool that enables Code Diet. For background and usage, see also "Are Your Dependencies Really Safe? — The Hidden EOL Risks of OSS and uzomuzo" (Japanese).
uzomuzo scan — Visualize Dependency Lifecycle
Takes SBOM, go.mod, or GitHub URL as input and evaluates the lifecycle of the entire dependency tree at once. While existing SCA tools give a binary "maintained / not maintained" verdict, uzomuzo classifies into 7 lifecycle stages (Active, Legacy-Safe, Stalled, EOL-Scheduled, EOL-Effective, EOL-Confirmed, Review). Since "Stalled" and "EOL" require different responses, this granularity is essential in practice.
It combines GitHub API, deps.dev API, and OpenSSF Scorecard as data sources, and distinguishes bot commits from human commits to assess actual maintenance status. The judgment logic adapts to each ecosystem's delivery model — Git commits equal releases in Go, while npm requires registry publication.
uzomuzo diet — Automated Removal Prioritization
Determines what to remove first based on source code analysis using tree-sitter. It builds a dependency graph from your SBOM, measures import counts, call sites, and coupling from actual source code, then combines this with scan's health scores to rank by Graph Impact × Health Risk × (1 − Coupling Effort). Supports Go, Python, JavaScript, TypeScript, and Java.
Both scan and diet are fully deterministic with no LLM usage. Same input always produces the same output.
LLM Skills — From Detection to Removal
We also open-source Claude Code skills that support the "judgment" and "execution" steps beyond detection:
/diet-assess-risk: Evaluates the risk of keeping a dependency. Traces data flow, constructs attack scenarios, and determines severity (the Vault copystructure analysis was done with this skill)./diet-evaluate-removal: Evaluates removal cost-effectiveness across 6 axes — PR load, code coupling, supply chain risk, and more — assigning Priority A/B/C./diet-remove: Executes the actual removal. Issue mode for external projects, PR mode for your own.
While existing tools stop at detection, uzomuzo provides an end-to-end pipeline from detection to removal. Try it on your project to uncover hidden EOL dependencies.
Session Recording
TLP:CLEAR session recordings from VulnCon 2026 will be published on the FIRST and CVE Program YouTube channels. Since our session is also TLP:CLEAR, it will become available for viewing. We'll add the link to this article once published — don't forget to subscribe so you don't miss it.
- FIRST: https://www.youtube.com/@FIRSTdotorg
- CVE Program: https://www.youtube.com/@cveprogram21
Presentation Slides
Related Article
We've also published a separate English article based on this presentation on dev.to:
Speaker Comments
Kota Kanbe
VulnCon has always been a conference I dreamed of presenting at. I studied by watching YouTube archive videos intently, and I'm truly grateful to have stood on that stage myself.
Beyond collecting the latest case studies, I was able to gather a wealth of ideas that will feed into FutureVuls updates. Experiencing firsthand what's being discussed at the forefront of vulnerability management was a major takeaway.
I was also able to directly confirm that there is real demand for uzomuzo. Through post-session discussions, I reaffirmed that many practitioners face the challenge of "dependency lifecycle management." With this feedback in mind, I plan to keep pushing updates. Stay tuned for the evolution of FutureVuls.
Ryunosuke Tanai
I prepared by keeping pace with Kanbe-san's output and gained the experience of presenting at a cutting-edge conference.
Through conversations at the event venue, I was able to speak directly with the people who have built and maintained the tools and ecosystems I'd been using daily — and that was incredibly stimulating. CVE Program, FIRST, NVD, various SCA tools. Being able to discuss directly with the people behind the systems you normally only interact with through a screen is an experience unique to VulnCon.
I can now see a path connecting the vulnerability management work I do in my day job directly to the international security community. This presentation has strengthened my desire to become more active in the cybersecurity community. The security industry really is fascinating.
Closing
The FutureVuls team will continue sharing our field knowledge through presentations at cybersecurity conferences worldwide. We will keep driving innovation in supply chain security and vulnerability management.
執筆者プロフィール
