自分は書いていないコードの脆弱性

レン

自分のコードは注意して書いてる。だから大丈夫だよね？

プロクラ

それがね、今のアプリって、実際に動いているコードの大半が自分の書いたものじゃないんだ。ライブラリを入れると、そのライブラリがまた別のライブラリに依存していて…と、数百単位になることも珍しくない。

レン

数百！？そんなに入ってるの！

ウィルスン

…そこがワタシの狙い目だ。キミのコードに穴を探すより、キミが使っているライブラリの、既に公表されている穴を突くほうが早い。しかもその穴は、同じライブラリを使う全員に共通している。1つ見つければ、大量の標的に使えるのだよ。

把握する方法

プロクラ

幸い、既知の脆弱性は公開データベースにまとまっていて、それと照合するツールが標準で用意されていることが多いよ。npmなら監査コマンドが、GitHubなら自動で警告してくれる仕組みがある。

• 定期的に脆弱性チェックのコマンドを実行する習慣をつける
• リポジトリの自動警告機能を有効にしておく
• 警告が出たら、深刻度と「その機能を実際に使っているか」を見て優先度を決める
• 使っていないライブラリは消す（依存が減れば、それだけ穴も減る）

更新するときの現実的な注意

プロクラ

更新すれば動かなくなるリスクもあるよね。だから「全部を最新にし続ける」より、まずセキュリティ修正を含む更新を優先しよう。テストがあれば更新は怖くなくなるので、そこに投資する価値もある。

レン

放置するとどうなる？

プロクラ

時間が経つほど直しづらくなるよ。何年も放置したものを一気に更新しようとすると、変更が大きすぎて手が付けられなくなる。少しずつ、こまめにやるのが結局いちばん楽なんだ。

警告が出たときの判断

プロクラ

警告が出ても、全部が今すぐ危険というわけではないよ。慌てて全部更新すると、動かなくなって別の問題が起きる。この順で考えよう。

• その弱点は、自分が実際に使っている機能に関わるか
• 外部から届く入力が、そこへ到達しうるか
• 開発時だけ使うもので、本番では動いていないか
• 深刻度と、更新に伴う影響の大きさを見比べる

プロクラ

「使っていない経路の弱点だから今は見送る」という判断もあっていい。ただし、そう決めた理由を記録しておくこと。後から見返せないと、放置と区別がつかなくなるからね。

こまめに続けるための工夫

• 自動で警告してくれる仕組みを有効にする
• 月に一度など、見る日を決めてしまう
• テストがあると更新が怖くなくなる。少しずつでも増やす
• 使わなくなったライブラリを消す。減らすのが一番効く

レン

全部を最新にするんじゃなくて、判断して、記録して、こまめに。