依存関係管理

現代のソフトウェアは大量のサードパーティライブラリに依存しており、依存パッケージのセキュリティはアプリケーション自体のセキュリティと同様に重要である。サプライチェーン攻撃とは、悪意あるコードを依存パッケージに混入させてダウンストリームの利用者を標的にする攻撃手法であり、2020年のSolarWinds事件・2021年のua-parser-js事件などが代表的な実例となっている。Typosquatting（lodashの代わりにl0dashのような誤字ドメインのパッケージ公開）や依存関係ハイジャック（所有者が変わったパッケージへの悪意あるコード挿入）が主な攻撃手法である。

npm audit・Snyk・GitHub Dependabotなどのツールは、既知の脆弱性（CVE）を持つ依存パッケージを検出し、修正バージョンへのアップグレードを推奨する。これらをCI/CDパイプラインに組み込むことで、脆弱性のある依存関係を持つコードのマージを自動的にブロックできる。SBOM（Software Bill of Materials）は、アプリケーションが依存するすべてのコンポーネントのリストであり、特定の脆弱性が公開された際に影響範囲を素早く特定するために活用される。

ロックファイル（package-lock.json・yarn.lock・pnpm-lock.yaml）は、依存パッケージの正確なバージョンとチェックサムを記録することで、異なる環境での同一ビルドを保証し、依存関係のバージョンドリフトを防ぐ。ロックファイルをgitignoreに追加して無視する設定は、再現性とセキュリティの両面で誤りである。依存パッケージの最小化も重要であり、使用していないパッケージが残り続けると攻撃面が広がる。

コードレビューで着目するポイント

ロックファイル（package-lock.json等）がgitリポジトリに含まれており、コミットされているか
新しく追加される依存パッケージが信頼できるソースから取得されており、インストール数・メンテナンス状況・オーナーが確認されているか
npm audit / snyk testがCIパイプラインに組み込まれており、高・致命的な脆弱性がブロック対象になっているか
使われていない依存パッケージがpackage.jsonに残っていないか
依存パッケージのバージョンが^によるマイナーバージョン自動更新で固定されているか（パッチ・マイナーの範囲が意図的か）
本番依存（dependencies）と開発依存（devDependencies）が正しく分類されているか
内部パッケージの配布にプライベートレジストリが使われており、パブリックレジストリから同名パッケージを引っ張れない設定になっているか

典型的なアンチパターン

ロックファイルをgitignoreに追加: package-lock.jsonを.gitignoreに追加し、npm installのたびに解決バージョンが変わる状態にする設定。CI環境と開発環境でパッケージバージョンが異なり、再現性がなくなると同時に悪意あるバージョンへの意図しないアップグレードが発生しうる。

脆弱性スキャンなしの依存関係更新: npm updateやdependabotの自動更新PRを内容確認なしに機械的にマージする運用。パッケージのマイナーアップデートに行動変更が含まれることがあり、自動マージは最低限CIパイプラインでのテスト通過を確認してから行うべき。

本番コードへの不必要な依存: 左パッド（left-pad）事件のように、1行で代替できる処理のために外部パッケージに依存する設計。依存数が多いほど攻撃面が広がるため、標準ライブラリで代替できる場合は外部依存を避けることを検討する。

参考リソース

npm audit — Node.jsプロジェクトの脆弱性スキャン組み込みコマンド
Snyk (https://snyk.io/) — 依存関係・コンテナ・IaCの脆弱性スキャンとモニタリングサービス
GitHub Dependabot — GitHubリポジトリの依存関係自動更新・セキュリティアラート機能
CycloneDX SBOM標準 (https://cyclonedx.org/) — ソフトウェア部品表（SBOM）の業界標準フォーマット
CNCF Supply Chain Security White Paper — クラウドネイティブ環境でのサプライチェーンセキュリティのベストプラクティス