Dependabotのアラートに、脆弱な関数を呼んでいるかどうかの判定が付いた

GitHubでJavaScript・TypeScriptのリポジトリを運用していると、Dependabotからの脆弱性アラートが毎日のように積み上がる。重大度の高いものから手を付けようにも、依存パッケージに脆弱性が見つかっただけでは、自分のコードがその危ない部分を実際に呼んでいるのかまでは分からない。

GitHubは2026年10月28日、Dependabotアラートに「到達可能性(リーチャビリティ)分析」を追加したと発表した。公式Changelogによると、自分のコードから脆弱な関数までの呼び出し経路を探し、見つかれば証拠つきでアラートに表示する。対象は今のところJavaScript・TypeScriptのリポジトリで、Public Preview(一般提供前の試験提供)として無料公開されている。

気になるのは、何を手がかりに「使っているかどうか」まで分かるのかだ。そこが分かれば、判定をどう読めばいいかも、今すぐ自分のリポジトリで試せるのかも見えてくる。

なぜ使っているか分かるのか

重大度だけでは分からないこと

Dependabotはこれまでも、依存パッケージの脆弱性を重大度やEPSSスコア(悪用される可能性を予測する指標)と合わせて教えてくれていた。だが、これらはどれも「このパッケージに脆弱性がある」という情報であって、「自分のアプリがそれを使っているか」は別の話だ。巨大なユーティリティライブラリの中に危ない関数が1つあっても、自分のコードがそのライブラリの別の安全な関数しか呼んでいなければ、実害はない。

コードの構造を読んで経路を探す

到達可能性分析が見ているのは、まさにこの「自分のコードから、その危ない関数まで実際に繋がっているか」という経路だ。GitHub Docsの説明によると、GitHubのコード解析エンジンCodeQLによる静的解析と、どの関数が影響を受けるかをあらかじめ整理したデータを組み合わせ、リポジトリのソースコードから脆弱な関数への呼び出しパスを探す。コードを実行せずに、コードの構造だけを読んで経路の有無を調べる仕組みになる。

公式Changelog記事に載っている例がわかりやすい。server.jsというファイルが、日付処理ライブラリmomentパッケージを経由して脆弱な関数を呼び出している、という呼び出し経路がスクリーンショットで示されている。同じmomentパッケージを使っていても、呼んでいるのが別の、脆弱ではない関数だけなら、経路はそこで途切れる。

上段のserver.jsからmomentパッケージの関数を経て脆弱な関数まで届く経路は、公式Changelog記事のスクリーンショットにある例そのものだ。下段のreport.jsは、対比のためにここで用意した説明用の例で、momentの中のどの関数が該当するかまで公式記事が示しているわけではない。同じパッケージを使っていても、自分のコードが呼んでいる関数次第で、経路が脆弱な関数まで届くかどうかが変わる。GitHubはこの経路の有無を、次の4種類の判定としてアラートに表示する。

判定ごとに何をすればいいか

到達可能性分析の判定は、「直す・直さない」を機械が決めるものではない。あくまで、数あるアラートのうちどれを先に見るかを判断するための材料だ。実際、GitHub Docsは「判定だけを理由にアラートを閉じたり無視したりしてはいけない」と明記している。

Reachableが出ても、それが「今すぐ悪用される」という意味ではない。経路が存在することが分かっただけで、実際に悪用できるかどうかは別の確認が要る。逆にUnreachableも、「このアラートは安全」という保証ではない。解析時点のコードで経路が見つからなかった、という事実を示しているにすぎない。

Potentially reachableには、ひとつ注意がいる。複数のディレクトリにマニフェストファイル(依存関係の定義ファイル)があるリポジトリでは、あるマニフェストのディレクトリの外側でだけ見つかった呼び出しも、この判定に含まれる。解析の対象範囲がマニフェストのディレクトリで区切られているための仕様で、Reachableより弱い確信度というだけではない点は覚えておきたい。

つまり4つの判定は、優先して見るアラートを絞り込むための目安であって、実際に直すかどうかまで決めてくれるわけではない。

次に気になるのは、これを自分のリポジトリで今すぐ試せるかどうかだ。

今すぐ使えるのか

対象はJavaScript・TypeScriptのリポジトリに限られる。npm、pnpm、Yarnのいずれかのロックファイル(依存関係のバージョンを固定したファイル)が必要で、対象となる脆弱性情報もGitHub Advisory Databaseでレビュー済みのnpmアドバイザリに限られる。

• 分析はGitHubホステッドランナーで実行され、自分で用意したセルフホステッドランナーには対応していない
• モノレポなど、複数ディレクトリにマニフェストがあるリポジトリは、Preview期間中はサポートされない場合がある
• 分析が3時間を超えると、一部の結果が「Reachability unavailable」になることがある
• コードをpushしても即座には反映されない。オープンなアラートがあるリポジトリは24時間ごとに再スキャンされる仕組みで、直したつもりの修正が判定に反映されるまで時間差が生じる

料金については、GitHubの高度なセキュリティ機能の多くが有料ライセンス(GitHub Advanced Security)を前提にしてきた中で、ここは意外だった。公式Changelog記事は、到達可能性分析にGitHub Advanced Securityのライセンスは不要で、分析に使うGitHub Actionsの実行時間も課金対象にならないと明記している。追加費用なしで試せる機能だ。

ただし、利用には「GitHub Enterprise Cloud」プラン(データレジデンシー利用を含む)の契約が前提になる、とも書かれている。個人で使っているGitHub Free・Pro・Teamのアカウントでは、今のところ対象外ということになる。無料で使える機能だが、無料で使えるプランの機能ではない、という組織向けの位置づけだ。

使い始めるには

GitHub Enterprise Cloudの組織に所属していて、対象のJavaScript・TypeScriptリポジトリがあるなら、設定はそれほど複雑ではない。公式Changelog記事による手順は次のとおりだ。

1. リポジトリまたは組織でDependabotアラートを有効にする(判定を見るための前提条件)
2. 到達可能性分析は既定でオフになっている。単一のリポジトリなら「Settings」内の「Advanced Security」のDependabotセクションで、複数のリポジトリをまとめて設定する場合はエンタープライズまたは組織のカスタムセキュリティ構成で、それぞれオンにする
3. オンにすると、オープンなDependabotアラートに対する初回スキャンがすぐに始まる。数分で終わることもあれば、数時間かかることもある
4. 以降は、オープンなアラートがあるリポジトリに対して24時間ごとに再スキャンされる

判定が付いたあとは、リポジトリや組織のアラート画面で判定によるフィルタや並べ替えができるほか、Dependabot alerts REST APIからも取得できるので、自前のツールに判定を取り込むことも可能だ。

まとめ

GitHub Dependabotの到達可能性分析は、依存パッケージの脆弱性に対して、自分のコードが実際にその脆弱な関数を呼んでいるかを、コードの構造を読む静的解析で判定する機能だ。Reachable・Potentially reachable・Unreachable・Reachability unavailableの4種類の判定は、どれも最終的な安全確認ではなく、数あるアラートの中からどれを先に見るかを決めるための目印にすぎない。

JavaScript・TypeScriptのリポジトリに対象が限られ、利用にはGitHub Enterprise Cloudの契約が要るという制約はあるが、分析自体に追加ライセンスや課金は発生しない。該当する環境を持つ開発者は、Settingsから到達可能性分析をオンにするだけで、今日からDependabotのアラートの見え方を変えられる。