脆弱性管理

依存ライブラリ管理いぞんらいぶらりかんり

サプライチェーン攻撃パッケージマネージャーSBOM脆弱性スキャンオープンソースライセンス管理

依存ライブラリ管理について教えて

簡単に言うとこんな感じ！

システムやアプリは「他の人が作った部品（ライブラリ）」を組み合わせて動いてるんだ。その部品に穴（脆弱性）があると自分のシステムも危険になるから、どの部品を使っているか把握して、古くなったら更新する管理のことだよ！

依存ライブラリ管理とは

現代のソフトウェア開発では、アプリケーションの機能すべてをゼロから作ることはほとんどありません。認証処理、暗号化、データ変換など、よく使われる機能は**オープンソースのライブラリ（部品）として公開されており、それらを組み込んで開発するのが一般的です。こうした「自分のコードが頼っている外部の部品」を依存ライブラリ（依存関係 / dependency）**と呼びます。

依存ライブラリ管理とは、アプリケーションが使用しているすべての外部ライブラリを把握し、バージョンを記録・固定し、脆弱性が発見されたときに迅速に更新できる状態を保つ一連の取り組みです。1つのアプリが直接使うライブラリ（直接依存）だけでなく、そのライブラリがさらに使うライブラリ（推移的依存・間接依存）まで含めると、数百〜数千の部品が関与することも珍しくありません。

発注者・管理者の視点では、「作ったシステムがどんな部品で構成されているか」を把握していないことが大きなリスクになります。2021年に話題になったLog4Shell（Javaのログライブラリに潜んでいた深刻な脆弱性）は、自社サービスに使われていることすら気づいていなかった企業が続出し、大きな混乱を招きました。依存ライブラリ管理は、こうした事態に備える「部品の棚卸し」とも言える活動です。

依存ライブラリの構造と管理の仕組み

ライブラリの依存関係の種類

種類	説明	例
直接依存	自分のコードが直接 `import` / `require` しているライブラリ	`axios`（HTTP通信ライブラリ）を使う
間接依存（推移的依存）	直接依存のライブラリがさらに使っているライブラリ	`axios` が内部で使う `follow-redirects`
開発依存	開発・テスト時のみ使い、本番環境には含まないライブラリ	テストフレームワーク `jest` など
ピア依存	「一緒に使う前提」として宣言される依存関係	Reactのプラグインが `react` 本体を前提とする

主なパッケージマネージャーと管理ファイル

パッケージマネージャーとは、ライブラリのインストール・バージョン管理を自動化するツールです。

言語	パッケージマネージャー	依存定義ファイル	バージョン固定ファイル
JavaScript / Node.js	npm / yarn / pnpm	`package.json`	`package-lock.json` / `yarn.lock`
Python	pip / Poetry	`requirements.txt` / `pyproject.toml`	`poetry.lock`
Java	Maven / Gradle	`pom.xml` / `build.gradle`	— （リポジトリキャッシュ）
Ruby	Bundler	`Gemfile`	`Gemfile.lock`
Go	Go Modules	`go.mod`	`go.sum`
PHP	Composer	`composer.json`	`composer.lock`

ロックファイルが重要な理由

「package.json には ^1.2.0（1.2.0以上）と書いてあるだけ」という状況では、インストールするタイミングによって入るバージョンが変わってしまいます。ロックファイル（package-lock.json など）は「このときは 1.2.3 を使った」という事実を記録し、どの環境・どのタイミングでも同じバージョンが入ることを保証します。ロックファイルをバージョン管理（Git）に含めることがセキュリティ上の基本です。

歴史と背景

2000年代前半：オープンソースの普及とともに、外部ライブラリの活用が一般化。当初は手動でDLして組み込む方式が主流
2009年：Node.jsのパッケージマネージャー npm が登場。ライブラリの自動インストール・依存解決の概念を普及させる
2013年頃：MavenやBundlerなど各言語でのパッケージエコシステムが成熟。依存地獄（dependency hell）が問題視され始める
2014年：Heartbleed（OpenSSLの脆弱性）が発覚。広く使われるライブラリの脆弱性が世界規模で影響することが明確になる
2016年：left-pad事件。npmの小さなライブラリが削除されただけで多くのサービスがビルド不能になり、依存管理の脆弱性を改めて認識
2021年：Log4Shell（CVE-2021-44228）が発覚。Java製ロギングライブラリLog4jの脆弱性が数千のサービスに波及し、依存ライブラリ管理の重要性が経営課題として認識される
2021年〜：米国大統領令（EO 14028）でソフトウェアの部品表（SBOM）作成が義務付けられ、国際的なトレンドになる
2023年〜：GitHub Dependabot・Snyk・OWASP Dependency-Checkなどの自動脆弱性スキャンツールが普及し、CI/CDへの組み込みが標準化

脆弱性管理との関係・SBOM

依存ライブラリ管理は単なる「バージョン管理」にとどまらず、セキュリティ・サプライチェーン管理の核心です。

SBOMとは

SBOM（Software Bill of Materials / ソフトウェア部品表）とは、システムを構成するすべてのソフトウェア部品をリスト化した文書です。食品の「原材料表示」にあたるイメージで、「このシステムはどの部品で作られているか」を明示します。

項目	内容
記載内容	部品名・バージョン・ライセンス・供給元・ハッシュ値
主なフォーマット	SPDX（ISO/IEC 5962）、CycloneDX
活用場面	脆弱性対応・ライセンス監査・調達審査
義務化動向	米国政府調達・EU CRAなどで要求が拡大中

脆弱性スキャンの流れ

ライセンス管理も忘れずに

依存ライブラリにはOSS（オープンソース）ライセンスが付いており、ライセンスの種類によっては商用利用の制限やソースコード公開義務が発生します。脆弱性管理と並行してライセンス監査も実施することが重要です。

ライセンス種別	代表例	商用利用	ソース公開義務
許容的ライセンス	MIT / Apache 2.0 / BSD	○	なし
コピーレフト（弱）	LGPL	△	部分的
コピーレフト（強）	GPL	△	あり（注意）
商用ライセンス	—	要契約	—

規格・番号	内容
ISO/IEC 5962:2021	SPDX（Software Package Data Exchange）形式のSBOM標準
NIST SP 800-161r1	ソフトウェアサプライチェーンリスク管理のガイドライン