Webアプリの主要セキュリティリスク一覧で触れた「依存ライブラリの脆弱性」を掘り下げます。
自分で書いた部分は、全体のごく一部
エージェントに「ログイン機能を作って」と頼むと、たいていnpm installのようなコマンドで外部のライブラリ（パッケージ）が何個もインストールされます。実際に自分の目的のために書かれたコードは全体のごく一部で、残りは他人が書いた、大量のライブラリです。さらに、そのライブラリ自身が別のライブラリに依存している、という連鎖も珍しくありません。
これは便利さの裏返しでもあります。認証・画像処理・日付計算のような、車輪の再発明をせずに済むのがライブラリのありがたさです。ただし、自分では1行も読んでいないコードが、アプリの大部分を占めているという事実は覚えておく必要があります。
2つの問題
大きく分けて2種類の問題があります。
- 既知の脆弱性：ライブラリ自体に、あとから欠陥が見つかることがあります。多くの場合は修正版がすぐに公開されますが、古いバージョンのまま使い続けていると、公開されている欠陥情報がそのまま自分のアプリの弱点になります
- サプライチェーン攻撃（supply chain attack）：ライブラリの配布経路そのものを狙う攻撃です。人気パッケージと紛らわしい名前の偽パッケージを登録する手口（タイポスクワッティング。
raectのように、よくある打ち間違いの名前を先回りして登録しておく）や、正規のパッケージのメンテナー権限が乗っ取られて、更新の中に悪意あるコードが混ぜ込まれる手口が知られています
対策の具体策
- 定期的に更新する。 使っているライブラリは、時間が経つほど既知の脆弱性が見つかる可能性が上がります。放置せず、定期的に最新版へ上げる
- 既知の脆弱性を機械的にチェックする。
npm auditというコマンドで、インストール済みのパッケージに知られている脆弱性がないか確認できます。GitHubにはDependabotという、脆弱性を検知すると自動で修正案のプルリクエストを作ってくれる仕組みもあります - 使っていないライブラリを減らす。 使っていないコードは、それだけ攻撃を受ける面積（アタックサーフェス）を増やしているだけです。「念のため追加した」ものは、あとで見直す価値があります
- インストール前に、素性を軽く確認する。 ダウンロード数が極端に少ない、最終更新が何年も前で止まっている、というパッケージは注意が必要です。似た名前の有名パッケージがないかも確認しておくと安心です
- lockファイルをコミットしておく。
package-lock.jsonのようなファイルは、実際にインストールされる正確なバージョンを固定します。これがないと、同じコードでも実行環境によって微妙に違うバージョンのライブラリがインストールされることがあります
エージェントへの頼み方
「npm auditを実行して、見つかった脆弱性を教えて。深刻度が高いものから対応方針を教えて」のように頼めば、既知の脆弱性の洗い出しから直せます。「使われていないパッケージがあれば教えて」も、アタックサーフェスを減らす作業として有効です。GitHubにリポジトリを置いているなら、Dependabotを有効にしておくと、以降は自動で気づけるようになります。
まとめ
- Webアプリの大部分は、自分では書いていない外部ライブラリでできている
- 問題は2種類。あとから見つかる既知の脆弱性と、配布経路そのものを狙うサプライチェーン攻撃
- 対策の基本は、定期的な更新と、
npm auditやDependabotのような機械的なチェックを回すこと - 使っていないライブラリを減らすことも、地味だが有効な対策
自分の書いたコードだけを見直しても、これは防げません。「自分が書いていない部分」にも目を向ける、という発想の転換が要る対策です。