OSSとサプライチェーン攻撃の関係
OSS（オープンソースソフトウェア）は、現代のソフトウェア開発に不可欠な存在です。Synopsys社の調査によると、商用ソフトウェアの96%以上がOSSコンポーネントを含んでいるとされています。しかし、その普及度の高さは同時にサプライチェーン攻撃の格好の標的となることを意味します。
OSS利用が普及した結果、ソフトウェアの依存関係は非常に複雑になりました。一般的なWebアプリケーションでは、直接利用するパッケージに加え、それらが内部で依存するパッケージ（推移的依存）まで含めると、数百から数千のOSSコンポーネントに依存していることも珍しくありません。
- 攻撃者がOSSを狙う理由
- 1つの人気パッケージを侵害すれば、それに依存する無数のプロジェクトに影響を与えられる。効率的に多くの標的を攻撃できる「1対多」の構造がある。
- OSS特有のリスク
- メンテナーの身元確認が困難、放棄されたパッケージの乗っ取り、悪意あるコードの混入検知が困難、などの課題がある。
| OSS関連のサプライチェーン攻撃事例 | 年 | 影響 |
|---|---|---|
| event-stream事件 | 2018年 | 200万回以上ダウンロード、ビットコインウォレット標的 |
| ua-parser-js事件 | 2021年 | 週間800万ダウンロードのパッケージにマルウェア混入 |
| Log4Shell脆弱性 | 2021年 | 世界中の組織に影響、CVSS 10.0の深刻な脆弱性 |
| node-ipc事件 | 2022年 | ロシア・ベラルーシのIPを標的にファイル上書き |
OSS利用のメリット（開発効率の向上、コスト削減、コミュニティの知見活用）を否定する必要はありません。重要なのは、リスクを理解した上で適切に管理することです。マルウェア感染や情報漏洩を防ぐため、OSS利用時のセキュリティ対策を体系的に実施しましょう。
依存パッケージの管理
OSS利用時のリスク管理において、依存パッケージの適切な管理は最も基本的かつ重要な対策です。
直接依存と間接依存
依存パッケージには、開発者が明示的に利用を宣言した直接依存と、それらが内部で利用している間接依存（推移的依存）があります。
- 直接依存
- package.json、pom.xml、requirements.txtなどに明示的に記載されたパッケージ。開発者が意識的に選択したもの。
- 間接依存（推移的依存）
- 直接依存するパッケージが内部で利用しているパッケージ。さらにそれらが依存するパッケージも含まれ、依存関係ツリーは深くなる。開発者が意識していないことが多い。
間接依存は、直接依存の10倍以上になることも珍しくありません。例えば、10個のパッケージを直接利用している場合、間接依存を含めると100個以上のパッケージに依存している可能性があります。
— 出典：Snyk社「State of Open Source Security Report」
問題は、間接依存のリスクが見落とされやすいことです。event-stream事件では、flatmap-streamという間接依存パッケージに悪意あるコードが混入されました。直接依存していたevent-streamは正常に見えたため、発見が遅れました。
依存関係の可視化
依存パッケージを適切に管理するには、まず依存関係を可視化する必要があります。SBOM（ソフトウェア部品表）の作成が有効です。
- 依存関係ツリーをコマンドで出力（npm ls、pip show、mvn dependency:tree等）
- SBOM生成ツール（Syft、Trivy）による自動生成
- OWASP Dependency-Trackでの一元管理
- GitHub Dependency Graphでの可視化
バージョン管理とロックファイル
依存パッケージのバージョン管理には、ロックファイルの活用が不可欠です。
- セマンティックバージョニング
- MAJOR.MINOR.PATCH形式（例：2.3.1）でバージョンを管理。^2.3.1や~2.3.1のような範囲指定では、ビルドごとに異なるバージョンがインストールされる可能性がある。
- ロックファイル
- package-lock.json（npm）、yarn.lock（Yarn）、Pipfile.lock（Pipenv）、poetry.lock（Poetry）など。特定時点の依存関係とバージョンを固定する。
- ロックファイルをリポジトリにコミットする
- CI/CD環境でもロックファイルを使用してインストール（npm ci等）
- 定期的に依存関係を更新し、テストを実行後にロックファイルを更新
ロックファイルがない場合、ビルドのたびに異なるバージョンのパッケージがインストールされ、再現性のないビルドとなります。これはCI/CDセキュリティの観点からも問題です。
供給元（メンテナー）の評価
OSSのセキュリティは、供給元（メンテナー）の信頼性に大きく依存します。しかし、OSSの世界では誰がメンテナーになれるかの制限が少なく、評価が困難な場合があります。
プロジェクトの健全性指標
OSSプロジェクトを採用する際は、以下の指標で健全性を評価しましょう。
| 評価指標 | 確認ポイント | リスクの兆候 |
|---|---|---|
| コミット頻度 | 最近のコミット履歴 | 数年間更新なし |
| コントリビューター数 | 複数人が関与 | 単一メンテナーのみ |
| イシュー対応 | セキュリティイシューの対応速度 | 未対応のイシューが放置 |
| リリース頻度 | 定期的なリリース | 長期間リリースなし |
| ドキュメント | README、セキュリティポリシー | ドキュメントが貧弱 |
OpenSSF Scorecardは、OSSプロジェクトのセキュリティ健全性を自動評価するツールです。ブランチ保護、コードレビュー、CI/CDの有無などをスコア化します。
メンテナーの信頼性
OSSの課題の一つは、メンテナーの身元確認が困難なことです。
- 単一メンテナーのリスク
- プロジェクトが1人のメンテナーに依存している場合、その人が「燃え尽き」たり、悪意を持ったり、アカウントを乗っ取られたりすると、プロジェクト全体がリスクにさらされる。
- メンテナー乗っ取り
- event-stream事件では、元のメンテナーが疲弊し、見知らぬ人物にメンテナー権限を譲渡。その人物が悪意あるコードを混入した。ソーシャルエンジニアリングの一種。
- 放棄されたパッケージ
- メンテナンスが放棄されたパッケージは、攻撃者が「新しいメンテナー」として引き継ぐことで乗っ取られる可能性がある。
ライセンスの確認
セキュリティだけでなく、ライセンスコンプライアンスも重要です。
- GPL系ライセンスは派生物にも同じライセンスを求める（コピーレフト）
- MIT、Apache-2.0、BSDは比較的自由に利用可能
- 予期しないライセンス変更が発生する可能性（例：Terraformの件）
- 間接依存のライセンスも確認が必要
脆弱性情報の収集と対応
OSSを安全に利用するには、脆弱性情報の継続的な収集と迅速な対応が不可欠です。
脆弱性データベースの活用
- CVE（Common Vulnerabilities and Exposures）
- MITRE社が管理する脆弱性の共通識別子。CVE-2021-44228のように一意のIDが付与される。脆弱性の「名前」として参照される。
- NVD（National Vulnerability Database）
- 米国NISTが運営する脆弱性データベース。CVEに詳細情報（CVSSスコア、影響を受けるバージョン等）を付加して提供。
- JVN（Japan Vulnerability Notes）
- IPAとJPCERT/CCが共同運営する日本の脆弱性情報データベース。日本語での情報提供と、国内製品固有の脆弱性も収録。
- GitHub Advisory Database
- GitHubが運営する脆弱性データベース。npm、Pip、Maven、RubyGems等の脆弱性情報を収録。Dependabotと連携。
自動スキャンの導入
脆弱性情報を手動で追跡するのは現実的ではありません。自動スキャンツールを導入しましょう。
| ツール | 機能 | 特徴 |
|---|---|---|
| Dependabot | 依存関係の脆弱性検知、自動更新PR | GitHub標準機能、無料 |
| Snyk | 脆弱性スキャン、修正提案 | 多言語対応、豊富な脆弱性DB |
| Trivy | 脆弱性スキャン、SBOM生成 | OSS、高速、コンテナ対応 |
| OWASP Dependency-Check | 依存関係の脆弱性検知 | OSS、CI/CD統合容易 |
これらのツールをCI/CDパイプラインに組み込むことで、ビルドごとに脆弱性チェックを自動実行できます。
脆弱性対応のプロセス
脆弱性が発見された場合の対応プロセスを事前に定めておきましょう。
- 優先順位付け：CVSSスコア、悪用可能性（Exploitability）、影響範囲を考慮して優先順位を決定
- 影響調査：SBOMを活用して、影響を受けるシステムを特定
- 対応方法の選択：パッチ適用、バージョンアップ、ワークアラウンド、代替パッケージへの移行
- テストと展開：修正後のテストを実施し、本番環境に展開
- 記録と報告：対応履歴を記録し、必要に応じてインシデント報告
ランサムウェア攻撃者は、脆弱性情報の公開から数時間で攻撃を開始することがあります。迅速な対応が被害を防ぐ鍵となります。
OSS選定のベストプラクティス
新たにOSSを採用する際は、以下の評価基準に基づいて選定しましょう。
- 活発なメンテナンス
- 最近のコミット履歴、イシューへの対応状況を確認。数年間更新がないプロジェクトはリスクが高い。長期間メンテナンスされているプロジェクト（例：10年以上の歴史）は信頼性が高い傾向。
- 十分なコミュニティサポート
- 複数のコントリビューターが関与しているか確認。単一メンテナーのプロジェクトは乗っ取りリスクがある。活発なフォーラム、Stack Overflowでの質問と回答があるか。
- セキュリティへの取り組み
- SECURITY.mdファイル（脆弱性報告ポリシー）の有無。過去の脆弱性への対応履歴。セキュリティ監査の実施有無。OpenSSF Scorecardのスコア。
- ライセンスの明確さ
- LICENSEファイルが存在し、ライセンスが明確であること。プロジェクトの方針として、ライセンス変更の可能性が低いこと。
- 代替パッケージの存在
- 同等の機能を持つ代替パッケージがあるか確認。特定のパッケージに依存しすぎないアーキテクチャ設計。将来的な移行の容易さ。
- ドキュメントの充実
- インストール、設定、使用方法のドキュメントが整備されていること。APIリファレンスがあること。
フィッシング詐欺でメンテナーのアカウントが乗っ取られるケースもあるため、2FA（二要素認証）が有効になっているかも確認ポイントです。
OSSセキュリティツールの活用
依存パッケージの脆弱性管理に役立つツールを紹介します。
| ツール名 | 機能 | 特徴 |
|---|---|---|
| Dependabot | 脆弱性検知、自動更新PR作成 | GitHub標準、無料、npm/Pip/Maven等対応 |
| Snyk | 脆弱性スキャン、修正提案、ライセンススキャン | 多言語対応、独自DBで高精度、IDE統合 |
| OWASP Dependency-Check | 依存関係の脆弱性検知 | OSS、CI/CD統合、NVD連携 |
| Trivy | 脆弱性スキャン、SBOM生成、設定ミス検出 | OSS、高速、コンテナ/IaC対応 |
| Socket | サプライチェーン攻撃検出 | npm/PyPI対応、振る舞い分析 |
「既知の脆弱性」だけでなく、「悪意ある振る舞い」を検出するツールも重要です。Socketは、パッケージのインストールスクリプトが環境変数を読み取る、ネットワーク通信を行うなどの不審な振る舞いを検出します。
— 出典：Socket社「Supply Chain Security」
依存関係の脆弱性への対策として、これらのツールをCI/CDパイプラインに組み込み、継続的にスキャンを実行することが推奨されます。
関連する攻撃手法
OSS利用に関連する攻撃手法は多岐にわたります。以下の攻撃手法を理解し、対策を講じましょう。
| 攻撃手法 | 概要 |
|---|---|
| タイポスクワッティング | 人気パッケージに似た名前の悪意あるパッケージを公開 |
| 依存関係混乱（Dependency Confusion） | 内部パッケージ名と同名の悪意あるパッケージを公開レジストリに登録 |
| 依存関係の脆弱性 | OSSの既知の脆弱性を悪用 |
| ソフトウェアサプライチェーン攻撃 | 正規パッケージへの悪意あるコード混入 |
| ゼロデイ攻撃 | 未公開の脆弱性を悪用 |
| Nデイ攻撃 | パッチ未適用の既知脆弱性を悪用 |
| 標的型攻撃（APT） | 特定組織を標的にOSS経由で侵入 |
npmセキュリティでは、npmエコシステム特有の攻撃手法と対策を詳しく解説しています。
よくある質問
- Q: OSSを使うのは危険ですか？
- A: OSSの利用自体が危険なわけではありません。むしろ、OSSは多くの開発者の目によるレビューを受けており、クローズドソースよりも脆弱性が発見されやすい面もあります。重要なのは、リスクを理解した上で適切に管理することです。依存パッケージの可視化、定期的な脆弱性スキャン、信頼できるパッケージの選定を行えば、OSSを安全に活用できます。
- Q: 依存パッケージはどのくらいの頻度で更新すべきですか？
- A: セキュリティ更新（脆弱性修正）は発見次第、できるだけ早く適用すべきです。CVSSスコアが高い脆弱性、特に「Critical」や「High」は優先的に対応してください。機能更新については、月次や四半期ごとなど、定期的なサイクルを設けて計画的に更新することをお勧めします。ただし、更新前には十分なテストを実施してください。
- Q: プライベートリポジトリでミラーリングすべきですか？
- A: 大規模な組織や、可用性要件が高いシステムでは、プライベートリポジトリ（Nexus、Artifactory等）でのミラーリングが有効です。メリットとして、外部レジストリの障害時も影響を受けない、パッケージの検証後にのみ利用許可できる、ネットワーク帯域の節約などがあります。一方、運用コストも発生するため、組織の規模とリスク許容度に応じて判断してください。
- Q: メンテナーが放棄したOSSはどうすべきですか？
- A: 放棄されたOSSは、脆弱性が発見されても修正されないリスクがあります。対応方法としては、代替パッケージへの移行を検討、フォークして自社でメンテナンス、利用を中止してコードを自前実装、などがあります。放棄されたパッケージは攻撃者に乗っ取られるリスクもあるため、継続利用には注意が必要です。
- Q: Log4Shellのような事態に備えるには？
- A: Log4Shell（CVE-2021-44228）のような深刻な脆弱性に迅速に対応するには、SBOMによる依存関係の可視化、脆弱性スキャンの自動化、緊急対応プロセスの整備が重要です。「自社のどのシステムにLog4jが含まれているか」をSBOMで即座に検索できれば、影響調査の時間を大幅に短縮できます。詳しくはSBOM解説ページをご参照ください。
まとめ
本記事では、OSS時代のサプライチェーン攻撃対策について解説しました。主なポイントは以下の通りです。
- OSS利用は現代のソフトウェア開発に不可欠だが、サプライチェーン攻撃のリスクも伴う
- 依存パッケージは直接依存だけでなく間接依存（推移的依存）も含めて管理が必要
- ロックファイルを活用してバージョンを固定し、再現性のあるビルドを実現
- 供給元（メンテナー）の評価では、プロジェクトの健全性、メンテナーの信頼性を確認
- 脆弱性管理ではDependabot、Snyk、Trivy等のツールで自動スキャンを実施
- OSS選定では活発なメンテナンス、コミュニティサポート、セキュリティへの取り組みを評価
- タイポスクワッティング、依存関係混乱など関連する攻撃手法への理解も重要
次のステップとして、npmエコシステム特有のリスクと対策を解説したサプライチェーン攻撃とnpm｜タイポスクワッティング・依存パッケージ対策をご参照ください。
技術者向けカテゴリの全体像については、サプライチェーン攻撃の技術対策｜SBOM・CI/CD・OSS・EDIをご覧ください。
サプライチェーン攻撃の総合的な理解には、サプライチェーン攻撃とは｜仕組み・事例・対策を初心者にもわかりやすく解説もあわせてご参照ください。
重要なお知らせ
- 本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。
- 実際にサイバー攻撃の被害に遭われた場合は、警察（#9110）やIPA（03-5978-7509）などの公的機関にご相談ください。
- 法的な対応が必要な場合は、弁護士などの専門家にご相談ください。
- 記載内容は作成時点の情報であり、攻撃手法は日々進化している可能性があります。
サプライチェーン攻撃 完全ガイド ナビゲーション
総合ガイド
目的別に探す
役職・立場別に探す
技術対策（技術者向け）
- SBOM
- CI/CD・SLSA
- OSSセキュリティ（現在のページ）
- npmセキュリティ
- EDIセキュリティ
- 脅威モデリング
業種別に探す
人気のページ
更新履歴
- 初稿公開
