プロジェクトを運用していると、GitHubから頻繁に届く通知があります。
その代表例が Dependabot のアラートです。
「依存関係に脆弱性があります」
「このバージョンは既に危険です」
「アップデートを推奨します」
最初のうちは真面目に見ていました。しかし次第にこう思うようになります。
・まだ悪用されていない
・今すぐ影響はなさそう
・アップデートすると壊れそう
・後でまとめてやればいい
その結果、私は Dependabot を無視し続け、最終的に実際に脆弱性を突かれました。
これはその経緯と、そこから学んだことの記録です。
何が起きたのか
ある日、サーバーの負荷が急激に上昇しました。
・CPU 使用率が常に 100% 近い
・API のレスポンスが異常に遅い
・ログに見覚えのないリクエストが増える
・一部のファイルが勝手に書き換わっている
調査の結果、原因は 依存ライブラリの既知の脆弱性を突いた攻撃 でした。
しかもその脆弱性は、Dependabot が何ヶ月も前から警告していたものだったのです。
無視していた脆弱性の正体
該当していたのは、Web フレームワークの内部で使用されている小さなライブラリでした。
・直接インストールした覚えはない
・package.json にも明示的には書いていない
・transitive dependency（間接依存）として含まれていた
しかしそのライブラリには RCE（リモートコード実行）の脆弱性があり、特定のリクエストを送ることで任意のコマンドが実行できる状態でした。
Dependabot はそれを正確に検知し、Issue も Pull Request も出してくれていました。
私はそれを見て、こう思っていました。
「間接依存だし、今は関係ないだろう」
「そのうちフレームワーク側が直すだろう」
「壊れるよりは放置のほうが安全だ」
それが完全な誤りでした。
なぜ Dependabot を無視してしまうのか
自分の行動を振り返ると、無視の理由は技術的というより心理的でした。
・アップデートが怖い
・差分を読むのが面倒
・影響範囲が分からない
・テストを書く時間がない
・今は忙しい
つまり、「やらない理由」が無限に存在します。
一方、「やる理由」は目に見えません。
問題は起きていない。だから緊急性が感じられない。
しかしセキュリティとは、起きてからでは遅いものです。
攻撃はどうやって成立したのか
攻撃者は、以下のような流れで侵入していました。
- サービスのバージョンとレスポンスヘッダを観測
- 使われているフレームワークとそのバージョンを推定
- 公開されている脆弱性データベースと照合
- 該当する脆弱性用の攻撃コードを送信
- サーバー内部でコマンド実行
つまり、特別なことは何もしていません。
公開情報だけで攻撃は成立していました。
実害
実際に起きた被害は以下の通りです。
・サーバーの不正利用（マイニング）
・ログの改ざん
・一部データの破損
・復旧のためのダウンタイム
・信用の低下
技術的な損失よりも、精神的なダメージの方が大きかったです。
「自分の怠慢で起きた事故」だったからです。
何を変えたか
この件以降、運用を次のように変えました。
・Dependabot の PR は必ずレビューする
・脆弱性は severity に関わらず必ず把握する
・依存更新用の定期メンテナンス日を設ける
・影響範囲を CI 上で確認できるようにする
・壊れたら直す前提で更新する
特に重要なのは、
「アップデートはリスク」ではなく
「アップデートしない方がリスク」
という認識への転換でした。
まとめ
Dependabot はうるさい存在に見えるかもしれません。
しかしそれは「問題が起きない世界」を維持するためのノイズです。
静かに動いているからこそ、無視してしまう。
何も起きないからこそ、価値が見えない。
ですが、無視し続けた先には「必ず起きる現実」があります。
私はそれを実際に踏みました。
だから今ははっきり言えます。
Dependabot は邪魔な通知ではなく、
未来の事故を未然に止める唯一の警報です。
無視しないでください。
面倒でも、怖くても、止まっても。
それでもアップデートした方が、安全です。