こんにちは、FutureVulsチームの棚井です。
※The English version of this blog post is available at "We Presented at VulnCon 2026"
2026年4月16日（木）、アメリカ・アリゾナ州スコッツデールで開催されたセキュリティカンファレンス VulnCon 2026 に、Future Corporation として登壇しました。
登壇前の紹介記事はこちらです。
セッション情報
| 項目 | 内容 |
|---|---|
| タイトル | The CVE Blind Spot: Defeating "Hidden EOLs" and Repo Jacking with Engineering Triage & Code Diet |
| 日時 | 2026年4月16日（木）13:15〜14:15（MST） |
| 会場 | Breakout 3（South Ballroom） |
| 登壇者 | Kota Kanbe, Ryunosuke Tanai（Future Corporation, JP） |
| TLP | TLP:CLEAR |
発表内容
発表は 8 パートで構成し、前半は棚井がトーク、後半は神戸がライブデモを担当しました。
Part 1: Repo Hijacking — 私たちの体験
2026年2月24日、私たちは通常のリリースサイクルで trivy v0.69.1 を GitHub Releases からプルしました。その4日後、trivy のリポジトリが乗っ取られました。
AI エージェント「hackerbot-claw」（Claude Opus 4.5 ベースと報告されている）が、GitHub Actions ワークフローの脆弱性を悪用して少なくとも7つのリポジトリを攻撃した事件です。trivy はフルテイクオーバーに至り、178件のリリースが削除されました。
私たちは攻撃ウィンドウ内にバイナリを取得していたため、SHA256ハッシュ・ビルドタイムスタンプ・Sigstore署名の3軸検証を実施し、改竄がなかったことを暗号学的に証明しました。この検証手法の詳細は以下の記事で公開しています。
Part 2–3: Scorecard 分析と CVE の限界
私たちは、攻撃を受けた7リポジトリすべてをクローンし、攻撃前のコミットに巻き戻した上で OpenSSF Scorecard CLI を実行するという、おそらく他に例のない分析を行いました。この分析の詳細は「hackerbot-clawが狙った7リポジトリ — 攻撃直前の OpenSSF Scorecardを検証する」で公開しています。
結果、7リポジトリ中3つは Scorecard の警告と攻撃手法が一致しており、事前に検知できた可能性がありました。一方、残り4つは Scorecard の検出範囲外の手法（issue_comment インジェクション、ファイル名インジェクション、AI プロンプトインジェクションなど）で攻撃されており、単一ツールでは防ぎきれないことが明らかになりました。
さらに、この攻撃キャンペーンの被害の大半（リポジトリ乗っ取り、トークン窃取、RCE）には CVE が採番されていません。CVE が発行されたのは、悪意あるコードが混入した特定バージョンのみ。攻撃チェーン全体は CVE のスコープ外です。私たちがこの攻撃を最初に知ったのは、CVE でも脆弱性スキャナでもなく、X（旧 Twitter）のタイムラインでした。
Part 4–5: Hidden EOLs — CVE の最大の死角
CVE が捕捉できないリスクの中で最も深刻なのが、メンテナンスが停止した OSS（Hidden EOLs） です。EOL パッケージには CNA もメンテナも不在のため、深刻な脆弱性があっても CVE が採番されません。「CVE がない＝脆弱性がない」ではなく、「誰も調査していない」という状況です。
国内の先進組織約100社で実際に稼働中の 16,000以上のプロダクション OSS パッケージ を分析したところ、健全な状態にあるのは全体のわずか 51.5% でした。残りの約半数が何らかのライフサイクルリスクを抱えています。この調査結果は2026年3月に日本経済新聞で報道されており、詳細は「ソフトウェアサプライチェーン健全性レポート2026」で公開しています。
リスク構造は氷山のようになっています。多くの組織が追跡しているのは公式 EOL の 9.4% のみ. その水面下には、Effective EOL（4.5%）と Stalled（34.6%）が隠れており、水面下のリスクは水面上の約4倍です。
Part 6–7: Code Diet とライブデモ
こうした CVE では捕捉できないリスクへの対処として、「Code Diet」というアプローチを提案しました。
- Pillar 1: Detect — OSS のライフサイクルを 7 段階に分類して可視化する。既存の SCA ツールが返す「メンテナンスされている / されていない」の二値ではなく、Active・Legacy-Safe・Stalled・EOL-Scheduled・EOL-Effective・EOL-Confirmed・Review の 7 段階で評価する
- Pillar 2: Remove — 不要な依存関係を除去し、攻撃対象面を縮小する。標準ライブラリへの置き換えや自前実装で対応する
ライブデモでは、以下の実例を用いて Code Diet の有効性を示しました。
事例1: HashiCorp Vault — シークレット管理ツールに潜む EOL
Vault の go.mod をスキャンしたところ、209 の依存関係のうち 11 パッケージが EOL であることが判明しました。しかも、そのほとんどが CVE ゼロ。脆弱性スキャナでは決して検出されないリスクです。
特に深刻だったのが以下の 2 つです。
aws-sdk-gov1（EOL-Confirmed）: AWS が公式に v2 への移行を推奨済み。Vault では S3 ストレージバックエンド（シークレットの保存先）と AWS 認証メソッド（Vault へのアクセス制御）で使われています。Vault は AES-256-GCM で暗号化してから SDK にデータを渡すため、平文のシークレットが SDK を通ることはありません。ただし、AWS クレデンシャル（アクセスキー、シークレットキー、セッショントークン）は平文で SDK を通過しており、SDK が侵害された場合にクレデンシャルが窃取されるリスクがありますmitchellh/copystructure（Archived）: Vault の創設者である Mitchell Hashimoto 氏が 2023 年に HashiCorp を退職し、個人リポジトリを一括アーカイブしたパッケージの一つです。コミュニティフォークも存在せず、パッチが提供される見込みはありません。このパッケージはvault/acl.go（アクセス制御レイヤー） で使用されており、DeniedParameters（「このユーザはこのパラメータにアクセスできない」というルール）のディープコピーを担っています。もしこのパッケージが侵害されると、セキュリティチェック間でルールが共有され、Deny ルールが暗黙に消失してアクセス制御が破綻するというシナリオが考えられます。エラーもログも出ない、サイレントな攻撃です
事例2: Grafana — CI/CD パイプラインに潜むアーカイブ済み Action
GitHub Actions もパッケージと同じく依存関係です。Action 自体がメンテナンスされているかどうかを誰もチェックしていない、という盲点を示しました。
Grafana（GitHub Stars 73,000+）の Actions をスキャンしたところ、39 の Action のうちほぼすべてが Active でしたが、tibdex/github-app-token がアーカイブ済みであることが判明。このアーカイブ済み Action が、release-build.yml や release-npm.yml を含む 13 のワークフローファイル、計14箇所 で使用されていました。Grafana のリリースパイプラインのコア部分です。
アーカイブ済みの Action は、GitHub がランタイムを廃止した時点で予告なく CI が壊れます。また、アクティブなプロジェクトが侵害された場合はコミュニティが即座に対応しますが、アーカイブ済みプロジェクトは誰も見ていないため、侵害されても気づかれません。
なお、私たちはこの問題を Grafana に Issue として報告しており、報告から3日後にコミュニティから修正 PR が提出され、Grafana チームが内部の shared-workflows で対応を進めています。
Code Diet の実践成果
OSS 脆弱性スキャナ vuls で Code Diet を実践した結果を紹介しました。
当初は個別パッケージを9つ置き換えましたが、間接依存として残り続けたためバイナリサイズはほぼ変わりませんでした。そこで発想を転換し、フレームワーク層ごと除去するアプローチに切り替えました。Trivy 由来のフレームワーク（fanal）が引き込んでいた IaC アナライザやディスクイメージパーサなど 250以上の不要パッケージ を一括で除去した結果、スキャナバイナリを 106.6 MB から 34.1 MB へ 68% 削減しました。ビルド時間も 7.8 秒から 3.2 秒へ 59% 短縮されています。
回帰テストとして 129 の実際の OSS プロジェクトの lockfile に対してスキャン結果を比較し、127/129 が同一結果（残り2件は改善）であることを確認しました。
uzomuzo-oss
上記の Code Diet を実現するツールとして、uzomuzo-oss を OSS として公開しています。uzomuzo の背景や使い方については「あなたの依存関係は本当に安全ですか？ — OSSの見えないEOLリスクと「uzomuzo」」もあわせてご覧ください。
uzomuzo scan — 依存関係のライフサイクルを可視化
SBOM・go.mod・GitHub URL を入力として、依存関係ツリー全体のライフサイクルを一括評価します。既存の SCA ツールが「メンテナンスされている / されていない」の二値で判定するのに対し、uzomuzo は 7 段階のライフサイクル（Active・Legacy-Safe・Stalled・EOL-Scheduled・EOL-Effective・EOL-Confirmed・Review）で分類します。「Stalled（開発停滞中）」と「EOL（終了済み）」では必要な対応が異なるため、この粒度が実務では重要です。
データソースとして GitHub API・deps.dev API・OpenSSF Scorecard を組み合わせ、bot コミットと人間のコミットを区別して実質的なメンテナンス状況を判定します。Go のように git コミット = リリースのエコシステムと、npm のようにレジストリへの publish が必要なエコシステムでは判定ロジックが異なりますが、uzomuzo はエコシステムごとの配信モデルに適応します。
uzomuzo diet — 除去の優先順位を自動算出
依存関係の中から「何を最初に除去すべきか」を、tree-sitter によるソースコード解析に基づいて算出します。SBOM から依存グラフを構築し、実際のソースコードからインポート数・呼び出し箇所数・結合度を測定。scan の健全性スコアと組み合わせて、グラフ影響度 × 健全性リスク × (1 − 結合度) のスコアで優先順位を付けます。Go・Python・JavaScript・TypeScript・Java に対応しています。
scan と diet はいずれも LLM 不使用の完全決定的な処理です。同じ入力に対して常に同じ結果を返します。
LLM スキル — 検出から除去まで
検出の先にある「判断」と「実行」を支援する Claude Code 用のスキルも OSS として公開しています。
/diet-assess-risk: 依存関係を残し続けるリスクを評価する。データフローを追跡し、攻撃シナリオを構築して危険度を判定する（Vault の copystructure 分析はこのスキルで実施）/diet-evaluate-removal: 除去のコストパフォーマンスを 6 軸で評価する。PR 負荷・コード結合度・サプライチェーンリスクなどを総合判定し、Priority A/B/C を付与する/diet-remove: 実際に除去を実行する。外部プロジェクトには Issue モード、自プロジェクトには PR モードで対応する
既存ツールが検出で止まるのに対し、uzomuzo は検出から除去までの一気通貫のパイプラインを提供します。プロジェクト内に潜む「隠れた EOL」の検出と対処に、ぜひご活用ください。
セッション録画について
VulnCon 2026 の TLP:CLEAR セッションの録画は、FIRST と CVE Program それぞれの YouTube チャンネルで公開されます。私たちのセッションも TLP:CLEAR のため、後ほど視聴可能になる予定です。公開され次第、本記事にもリンクを追加しますので、見逃さないようチャンネル登録をお忘れなく。
- FIRST: https://www.youtube.com/@FIRSTdotorg
- CVE Program: https://www.youtube.com/@cveprogram21
発表スライド
発表で使用したスライドはこちらです。
海外向け記事
発表内容をベースにした英語記事も dev.to で公開しています。
登壇者コメント
神戸 康多（Kota Kanbe）
VulnCon はずっと登壇を夢見ていたカンファレンスです。YouTubeのアーカイブ動画を食い入るように観て勉強してきた、あの舞台に自分が立てたことは本当に嬉しく思っています。
最新事例の収集はもちろんのこと、FutureVuls のアップデートにつながるネタをたくさん仕入れることができました。脆弱性マネジメントの最前線で何が議論されているかを肌で感じられたのは大きな収穫です。
また、uzomuzo についてもニーズがあることを直接確認できました。セッション後のディスカッションで、「依存関係のライフサイクル管理」という課題に多くの実務者が直面していることを改めて実感しました。このフィードバックを踏まえて、これからさらにアップデートさせていきたいと考えています。今後の FutureVuls の進化にご期待ください。
棚井 龍之介（Ryunosuke Tanai）
神戸さんのアウトプットに食らいつきながら準備を進め、最先端のカンファレンスで登壇する経験を得ることができました。
イベント会場でのコミュニケーションを通して、これまで日常的に使っていた「誰かが作ったツールやエコシステム」に対して、実際にその作成・運営を長年担っている歴戦の猛者たちと直接会話できたのは非常に刺激的でした。CVE Program、FIRST、NVD、各種 SCA ツール。普段は画面越しに触れているだけの仕組みの裏側にいる人たちと直接議論ができるのは、VulnCon ならではの体験です。
普段の業務で取り組んでいる脆弱性管理の実務を、国際的なセキュリティコミュニティに直接つなげる道筋が見えてきました。今回の登壇をきっかけに、サイバーセキュリティ領域のコミュニティでもっと活動していきたいという気持ちが強くなっています。セキュリティ業界はやはり面白いです。
おわりに
FutureVuls チームは、国内外のサイバーセキュリティカンファレンスへの登壇を通じて、現場の知見をコミュニティに還元し続けていきます。サプライチェーンセキュリティと脆弱性管理の領域で、これからもイノベーションを起こしていきます。
執筆者プロフィール
