ライブラリ更新の放置はセキュリティの穴。Dependabotで無料監視

アプリやWebサイトは、ライブラリ（既製品のプログラム）を数多く組み合わせて動いています。ライブラリは日々更新され、機能の追加や改善のほか、脆弱性（セキュリティ上の弱点）の修正が行われます。

ライブラリ更新を放置すると、脆弱性が残ったままになり、攻撃の入口になってしまうのです。

この記事では、無料のDependabotアラートを使った脆弱性監視の体制を解説します。

さらに、脆弱性の深刻度で更新の速さを変える弊社の運用と、設定をAIに任せる方法も紹介します。

※この記事はGitの前提が必要です。Gitに詳しくない方は非エンジニアのためのGit入門を参考にしてください

動画で見たい方はこちら。

ライブラリの脆弱性は、早めに更新しないと攻撃の入口になる

脆弱性とは、ライブラリを作った時には気づかなかった不具合やセキュリティの穴が後から見つかり、攻撃の入口になるものです。

脆弱性が見つかると、ライブラリの開発者はすぐに修正版をリリースします。ですが、修正版が出ても利用者側が更新しなければ、アプリの中に脆弱性は残ったままです。

残った脆弱性を攻撃され、ウイルス感染や情報漏洩といったセキュリティ事故につながるのが、よくあるパターンです。

実際、Sonatypeの2024年の調査では、脆弱なバージョンのダウンロードの95%は、その時点で修正済みのバージョンが存在していました。穴の大半は「直せたのに直していない」のです。

攻撃側の動きも速く、Google Cloudの分析によると、2023年に修正公開後に悪用された脆弱性41件のうち、12%は公開1日以内、56%は1か月以内に悪用されました。

なので、使っているライブラリに脆弱性が見つかったら、なるべく早く更新しなければなりません。

数十個のライブラリを手動で更新するのは非現実的

でも普通、アプリやWebサイトで使っているライブラリは数十個にもなります。手動でバージョンアップ情報をすべてチェックし、更新していくのは現実的ではありません。

弊社のサイトでも、直接指定しているライブラリだけで43個あります。ライブラリが内部で使うライブラリまで含めると667個です。

無料のDependabotアラートで脆弱性に即気づく

そこで役立つのが、GitHubのDependabotアラートです。プロジェクト内のライブラリを常に監視し、既知の脆弱性が見つかったらGitHub上でアラートを出してくれます。

費用はGitHubの全プランで無料です。

アラートが出るのは、次の2つのタイミングです。

• GitHubの脆弱性データベース（GitHub Advisory Database）に、新しい脆弱性が登録されたとき
• 使っているライブラリやバージョンが変わったとき

アラートには深刻度が表示されます。脆弱性の評価規格CVSS（共通脆弱性評価システム）に基づく、Critical・High・Moderate・Lowの4段階です。

設定はボタン1つで、次の手順で有効にできます。

1. GitHubでリポジトリを開き、「Settings」をクリック
2. 左のメニュー「Security and quality」の「Advanced Security」をクリック
3. 「Dependabot alerts」の右の「Enable」をクリック

アラートが出たら、そのリンクをCodexやClaude CodeなどのAIエージェントに渡せば、適切に対応してくれます。

Dependabotセキュリティ更新の機能で、脆弱性の修正PRを自動で作ることもできます。PRの内容は、アラートが出たライブラリを脆弱性修正後の最小バージョンへ上げるというもの。

最新版を即更新するのも危険。乗っ取り版が紛れ込む

一方で、ライブラリに新しいバージョンが出たら即座に更新するのも、実は危険な運用です。ライブラリの運営元が乗っ取られていて、新しいバージョンにウイルスや脆弱性が仕込まれているパターンがあるからです。

2025年9月8日には、chalkやdebugなど、合計で週20億回以上ダウンロードされる18個のライブラリが乗っ取られました。検知から開発者が対応を始めるまでに、約2時間かかっています。

同じ月の14日には、自己増殖するワームShai-Huludがnpmから広がり、GitHubは500件以上のライブラリを削除しました。

対策は公開後24時間待つこと。ツールに標準搭載

ただ、乗っ取りはたいてい素早く発見され、悪意あるバージョンは1時間以内に配布サイトから削除されると、ライブラリ管理ツールpnpmの開発元は説明しています。

なのでぼくは、ライブラリに新しいバージョンが出ても、公開後24時間以上たってから更新しています。24時間あれば、運営が乗っ取りの事実を公表したり、対策を講じる時間があるからです。

このすぐに更新しない考え方は、ツールの標準機能にもなっています。

• pnpm：minimumReleaseAgeに分単位で待ち時間を設定でき、v11からは既定で1日（1440分）待つ
• Dependabotのバージョン更新：設定しなくても公開後3日のクールダウンが既定で適用され、この期間は新バージョンを更新対象にしない

弊社の運用：通常は24時間後、Criticalと悪用確認済みは即更新

ここで矛盾が起きます。脆弱性の修正版まで24時間待つと、その間は穴が開いたままです。逆にすべてを即日更新すれば、乗っ取り版に弱くなります。

そこで弊社は、更新の速さを脆弱性の深刻度で変えています。

• Critical：当日中に確認し、原則24時間以内に修正
• High：翌営業日までに確認し、原則7日以内に修正
• Moderate・Low：週1回の定期更新で対応

「公開後24時間待つ」ルールを飛ばせるのは、Criticalか、すでに悪用が確認されている脆弱性の修正だけです。

悪用が確認された脆弱性は、米国のCISAがKEVカタログとして公開しています。Dependabotアラートの一覧にも、今後30日以内に悪用される確率（EPSS）が表示され、絞り込みに使えます。

Dependabotアラートの設定と運用ルールはAIに頼める

ここまでの運用は、Claude CodeやCodexに頼めば適切に設定してくれます。

このリポジトリでDependabotアラートを有効にして。
ライブラリの通常更新は、公開後24時間以上たったバージョンだけを対象にして。
ただし、Dependabotアラートの深刻度がCriticalの脆弱性と、悪用が確認されている脆弱性の修正は、待たずに即更新する設定にして

まとめの前に、お知らせを。

無料メルマガで実務で使えるAI活用を毎日配信中。1分で登録できます。

超実践AI論Substacktaichiaiworker.substack.com

ながら聞きで、AIを仕事に活かす方法がわかるポッドキャストをSpotifyでも配信しています。

超実践AI論Spotifyopen.spotify.com

まとめ：ライブラリを適切に更新してセキュリティの穴をふさぐ

この記事の要点は次の4つです。

• ライブラリの脆弱性は、修正版が出ても自分が更新しなければ残る。放置は攻撃の入口になる
• Dependabotアラートは無料で、脆弱性が見つかったらすぐ知らせてくれる
• 最新版の即更新は乗っ取り版を入れる危険があるため、公開後24時間は待つ
• Criticalと、すでに悪用されている脆弱性だけは、待たずに即更新する

まずは、自分のアプリやWebサイトのDependabotアラートをオンにしましょう。アラート対応に慣れてきたら、24時間ルールと即時更新の運用にもチャレンジしてみてください。