依存ライブラリの脆弱性更新、研究が示す実態

研究・論文
2026.06.20

【更新 2026-08-04】本記事を見直し、修正しました。主な修正点：①元論文（arXiv:2403.17382 v4）が指標の計算から推移的（間接）依存を明示的に除外していることを確認し、「推移的依存のほうが更新が遅れる」という研究由来の記述を論文の実際の記述に訂正。②「依存ツリーが大きいほど遅い」「エコシステムごとに傾向が異なる」も論文の分析結果（依存数と更新の速さの相関は弱く、エコシステム間の差は小さい）に合わせて訂正。③参考リンクの「SBOM導入・運用の手引き」がIPA自身の著作物ではなく、IPA産業サイバーセキュリティセンター 中核人材育成プログラムの卒業プロジェクト成果物であることを本文・出典の両方に明記。

自社開発のシステムやアプリが使うOSS（オープンソースソフトウェア）の依存ライブラリに脆弱性が見つかったとき、その更新はどれくらいの速さで進むのでしょうか。「更新を促せばすぐ直る」という前提は、現実には成り立っていないかもしれません。npm・PyPI・Cargoの約16万パッケージを分析した査読前の研究が、依存関係の更新がどれくらいの速さで進んでいるのかを定量的に示しています。論文の結論は「大多数のパッケージは比較的速く更新している。ただし、更新が長期間止まったままのパッケージも一定数あり、分布は長い尾を引く」というものです。本記事は、この研究を情シス（情報システム部門のセキュリティ担当者）の視点で噛み砕きます。

この記事でわかること

  • 開発チームによる「脆弱な依存ライブラリ」の更新が、なぜ思うように進まないのか
  • 更新の速さを測る新しい指標「MTTU」「MTTR」と、その違い
  • この研究が測っているのは「直接依存」だけで、推移的（間接）依存は指標の対象外だという前提
  • 自社のソフトウェア部品表（SBOM）管理や脆弱性対応に、この知見をどう活かすか

これはどんな研究なのか

ひとことで言えば、「OSSの依存ライブラリに脆弱性が出てから、それが更新・解消されるまでの実態を、大規模データで定量化した研究」です。論文タイトルは How Quickly Do Development Teams Update Their Vulnerable Dependencies?（Imranur Rahman, Ranindya Paramitha, Nusrat Zahan, William Enck, Laurie Williams ら）。arXivで公開されており（arXiv:2403.17382、2026年6月のv4時点で査読中）、査読前のプレプリントである点にはご注意ください。結果は今後の改訂で変わりうるため、本記事も断定は避けて要点を紹介します。

なぜ情シスが気にすべきテーマなのか

近年のインシデントの多くは、自社が直接書いたコードではなく、その下に積み重なった第三者ライブラリの脆弱性を起点にしています。しかも依存関係は、自分が直接呼ぶ「直接依存」だけでなく、その依存がさらに引き込む「推移的（間接）依存」まで含めると、数百〜数千に膨らむことも珍しくありません。「自社製品のどこに、どの脆弱なバージョンが含まれているか」を把握しきれない——この見えにくさこそ、サプライチェーン・リスクの本質です。

更新の速さをどう測るのか：MTTUとMTTR

この研究の核は、更新スピードを測る2つの指標を整理し直した点にあります。従来の測り方は、バージョンを固定せず最新を取り込む「フローティング指定」や、古い更新と最近の更新を同列に扱ってしまう問題を抱えていました。そこを補正したのが次の2つです。

指標 意味 何を表すか
MTTU（Mean Time To Update） 依存ライブラリを新しいバージョンへ更新するまでの平均的な時間 その開発チームの「更新習慣」の速さ全般
MTTR（Mean Time To Remediate） 脆弱な依存を、脆弱でないバージョンへ解消するまでの平均的な時間 セキュリティ上の「修正」の速さ

分析対象は3つの主要エコシステムにまたがる合計16万3,207パッケージ（npm 11万7,129、PyPI 4万2,777、Cargo 3,301）という大規模なものです。エコシステム間の差は小さく、更新の傾向はおおむね共通していたと報告されています（MTTUの四分位範囲はCargo 1〜39日、npm 4〜45日、PyPI 11〜54日）。

MTTUが速ければ、脆弱性対応も速いと言えるのか

結論から言えば、必ずしもそうとは限りません。研究は、MTTU（更新習慣の速さ）をMTTR（脆弱性解消の速さ）の代わりに使うのは、注意が必要だと指摘します。脆弱性データが限られる場面で「普段からよく更新しているから安全だろう」と推測するのは、部分的にしか当てになりません。普段の更新が速いことと、いざ脆弱性が出たときに素早く直せることは、別の問題だということです。

どこで更新が遅れるのか

研究が浮かび上がらせた傾向のうち、現場感覚と特につながるのは次の点です（いずれも査読前の知見として、傾向の紹介にとどめます）。

  • この研究が測っているのは「直接依存」だけである。 論文は「開発者が直接コントロールできるのは直接依存のバージョンだけだ」として、推移的（間接）依存を指標の計算から除外し、その取り込みを今後の課題（future work）としています。したがって「推移的依存のほうが更新が遅い」という比較は、この研究からは導けません。
  • リリース回数が多いパッケージほど更新が速い。 調べた9つの特性のうち、更新の速さとはっきり関係していたのはバージョンのリリース回数だけでした（MTTUとの相関 -0.55、MTTRとの相関 -0.41）。
  • コントリビュータ数・被依存数・依存数・スター数・フォーク数は、更新の速さとほとんど関係がない。 論文は「スターやフォークが多いことが更新の速さに直結するわけではない」「被依存数が数千あるパッケージでも、自身の依存が適時に更新される保証はない」と述べています。回帰分析では「古いパッケージほどMTTUが長い」「品質・人気の総合指標であるSourceRankが高いほどMTTUが短い」という関係も出ていますが、モデルの説明力は低く（決定係数 R²＝3.9%）、論文自身が「ここで測っていない要因のほうが大きく影響している」としています。

現場目線の所感

この研究を読んで率直に感じるのは、「自社が悪い・遅いという話だけではない」という点です。たとえ自社の開発チームが脆弱性情報を受けてすぐ動こうとしても、修正版を出すのは上流のOSSメンテナーであり、そこが止まっていれば末端ではどうにもなりません。推移的依存に至っては、そもそも「自分が使っている」という自覚すら持ちにくい。限られた人員で、見えない依存の奥まで目を届かせるのは、正直なところ容易ではありません。

だからこそ、「気合いで全部追う」のではなく、直接依存を優先的に監視し、自動化で取りこぼしを減らすという割り切りが現実的だと感じます。この研究が測っているのも「開発者が直接コントロールできる直接依存」だけで、推移的依存は指標の外に置かれています。裏を返せば、推移的依存の遅れは研究の側でもまだ定量化されていない領域だ、ということです。まず見える範囲（直接依存）を確実に、そのうえで推移的依存を可視化する仕組み（SBOM）へ広げていく、という順番です。

情シスは何をすべきか

個別の対策チェックリストを長々と並べるより、まずは依存関係の「見える化」と、公的機関が整理した指針に沿って体制を組むのが近道です。

  • SBOM（ソフトウェア部品表）で依存を棚卸しする。 推移的依存まで含めて「何を使っているか」を一覧化しなければ、更新の遅れ以前に対象が特定できません。「SBOM導入・運用の手引き」（IPA産業サイバーセキュリティセンター 中核人材育成プログラム 卒業プロジェクト第7期生の成果物。IPAは掲載元で、IPA自身の著作物・公式見解ではありません）などを出発点にすると整理しやすいでしょう。
  • 脆弱性情報を継続的に取得する。 自社が使うライブラリに関わる注意喚起は、JPCERT/CCやJVNなどの一次情報で押さえます。
  • 更新運用の優先度を決める。 すべてを同時には直せません。脆弱性管理・パッチ適用の進め方は、IPA「中小企業の情報セキュリティ対策ガイドライン」などの考え方を土台にすると、経営層への説明もしやすくなります。

あわせて、開発・運用に関わるメンバーへの地道な啓発も欠かせません。「依存ライブラリの更新はコードを書くことと同じくらい重要なメンテナンス作業だ」という認識を共有できているかどうかで、いざというときの動きが変わります。

まとめ

  • npm・PyPI・Cargoの16万超パッケージを分析した査読前研究によれば、大多数のパッケージは比較的速く依存を更新している。一方で、更新が長期間止まったままのパッケージも一定数あり、エコシステム間の差は小さい。
  • 普段の更新の速さ（MTTU）は、脆弱性解消の速さ（MTTR）の代わりには使いきれない（部分的な代用にとどまる）。またこの研究は直接依存だけを対象としており、推移的（間接）依存の遅れは測られていない。
  • 情シスはまずSBOMで依存を可視化し、直接依存を優先監視しつつ、JPCERT/CC・JVN等の一次情報とIPAの公的指針に沿って更新運用の優先度を整えるのが現実的。

出典

タイトルとURLをコピーしました