ソフトウェアサプライチェーンセキュリティ入門：依存関係とSBOM活用

はじめに

近年、ソフトウェア開発の現場では、オープンソースソフトウェア（OSS）の利用が不可欠となっている。Apache Log4j の脆弱性（CVE-2021-44228）や SolarWinds へのサプライチェーン攻撃といった事例が示すように、自社が直接開発したコードだけでなく、外部から取り込む依存関係のセキュリティが製品全体の安全性を左右する。この認識から、ソフトウェアサプライチェーンセキュリティ（Software Supply Chain Security）への注目が急速に高まっている。

本稿では、依存関係管理の基本から、ソフトウェア部品表（SBOM: Software Bill of Materials）の生成・活用方法、さらに実践的なセキュリティ対策までを段階的に解説する。開発者やセキュリティエンジニアが自社のCI/CDパイプラインに即座に反映できる内容を目指す。

ソフトウェアサプライチェーンセキュリティとは何か

サプライチェーン攻撃の実態

ソフトウェアサプライチェーン攻撃とは、開発プロセスにおいて信頼されているサードパーティのコンポーネントやツールを侵害し、その結果として広範な顧客やシステムに被害を拡大させる攻撃手法である。2021年に発生した Codecov への侵入事件では、攻撃者が Codecov の CI/CD 環境に不正アクセスし、ユーザーがスクリプトから送信する環境変数や認証情報を窃取した。この攻撃は Codecov の直接的な顧客にとどまらず、その先のエンドユーザーにも影響が及んだ。

なぜ今、重要視されるのか

従来のセキュリティ対策は、自組織が管理するアプリケーションやインフラに焦点が当てられていた。しかし、現代のソフトウェアは平均で数百から数千もの依存関係を持ち、その多くが直接管理できない外部リポジトリから取得される。米国大統領令（Executive Order 14028）や欧州のサイバーレジリエンス法（CRA）などの規制も、サプライチェーンセキュリティ対策を法的に要求する方向へ動いている。これらの背景から、SBOMの生成・共有や依存関係の継続的な脆弱性スキャンが業界標準になりつつある。

依存関係管理の基本

依存関係の種類とリスク

依存関係は大きく二つに分類される。

• 直接依存（Direct Dependencies）: プロジェクトが明示的に宣言し、直接利用するライブラリやパッケージ。例：npm install express でインストールされる Express。
• 推移的依存（Transitive Dependencies）: 直接依存がさらに内部で利用しているライブラリ。これらは開発者が意識せずに取り込む場合が多く、脆弱性の盲点となる。

リスクとして、次の三つが重要だ。

1. 既知の脆弱性（Known Vulnerabilities）: 依存関係に公開済みの脆弱性が含まれている状態。CVE（Common Vulnerabilities and Exposures）で管理される。
2. 悪意のあるパッケージ（Malicious Packages）: タイポスクワッティング（typosquatting）やブランドハイジャックにより、正規パッケージに見せかけたマルウェアがインストールされるケース。
3. メンテナンス放棄（Abandonware）: 長期にわたって更新が行われていないライブラリは、新たに発見された脆弱性に対処されないため、使い続けることがリスクになる。

依存関係管理のベストプラクティス

1. ロックファイルの活用

package-lock.json（npm）、yarn.lock（Yarn）、Gemfile.lock（Ruby）、Cargo.lock（Rust）などのロックファイルは、インストールされるパッケージのバージョンを固定する。これにより、開発環境・CI・本番環境で同一の依存関係ツリーを再現できる。ロックファイルをバージョン管理システムに含め、変更差分をコードレビューの対象とすることが推奨される。

2. 定期的な依存関係の更新

依存関係は定期的にアップデートし、古いバージョンが持つ脆弱性を解消する必要がある。Dependabot（GitHub）やRenovate（Mend）などの自動更新ツールをCIに組み込むことで、Pull Request形式で更新が提案される。ただし、更新時には互換性テストと統合テストを必ず実施し、破壊的変更（Breaking Changes）を事前に検出する仕組みが必須となる。

3. 最小権限の原則に基づく利用

必要最低限の依存関係だけを導入する。開発者がすべてのパッケージを無差別にインストールするのではなく、機能要件を満たす最小限のライブラリを選択する。たとえば、HTTPクライアントライブラリだけが必要なら、フルスタックのWebフレームワークを導入する必要はない。

SBOM（ソフトウェア部品表）の基礎

SBOMとは何か

SBOMは、ソフトウェアを構成するすべてのコンポーネント、そのバージョン、ライセンス情報、依存関係の関係性を機械可読な形式で記述した文書である。SPDX（Software Package Data Exchange）やCycloneDX（Cyclone Data Exchange）が主要な標準フォーマットとして広く採用されている。

SBOMの主な用途は次のとおり。

• 脆弱性管理: SBOMに記載されたコンポーネントと既知の脆弱性データベース（NVD、Exploit-DBなど）を突き合わせることで、影響を受けるコンポーネントを特定できる。
• ライセンス管理: 各コンポーネントのライセンス情報を一元管理し、法的リスクを評価する。
• インシデント対応: Log4jのような重大脆弱性が公表された際、自社のどの製品が該当するかを迅速に判別する。

SBOMの生成方法

SBOMはビルド時に自動生成することが望ましい。主要なツールとその特徴を以下に示す。

• Syft（Anchore）: コンテナイメージやファイルシステムからSBOMを生成するCLIツール。CycloneDXおよびSPDX形式に対応。出力はJSONまたはテキスト形式。
• CycloneDX Generator: npm、Maven、NuGet、Go modulesなど主要なパッケージマネージャ向けのプラグインが提供されている。各言語のビルドツールに組み込んで、ビルドのたびにSBOMを生成できる。
• SPDX Tools: SPDX標準準拠のSBOMを生成・検証するためのツール群。JavaベースのツールやPythonラッパーが存在する。

SBOMの生成はCI/CDパイプラインの一部として自動化すべきである。下記はGitHub Actionsを用いたSyftによるSBOM生成の例を示す。

name: Generate SBOM
on:
 push:
 branches: [ main ]
jobs:
 sbom:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - name: Generate SBOM with Syft
 uses: anchore/sbom-action@v0
 with:
 path: ./
 format: cyclonedx-json
 output-file: sbom.cdx.json
 - name: Upload SBOM as artifact
 uses: actions/upload-artifact@v3
 with:
 name: sbom
 path: sbom.cdx.json

このワークフローでは、プッシュごとにSBOMが生成され、アーティファクトとして保存される。生成されたSBOMは脆弱性スキャンや社内ポリシー準拠のチェックに利用できる。

SBOMの活用方法

脆弱性の継続的スキャン

SBOMを基にした脆弱性スキャンは、依存関係のセキュリティ管理の核心である。Grype（Anchore）、Trivy（Aqua Security）、Snyk CLIなどが代表的なツールだ。これらはSBOMファイルを入力として、含まれるコンポーネントを既知の脆弱性データベースと照合し、影響範囲を報告する。

CI/CDパイプラインにスキャンを組み込むことで、脆弱性を含むコードが本番環境にデプロイされる前にブロックできる。また、定期的なスキャン（例：毎晩のジョブ）により、新たに公開された脆弱性が既存の稼働システムに影響を与えないか監視する。

ポリシーによるガバナンス

SBOMとポリシーエンジンを組み合わせることで、許可されていないコンポーネントや脆弱性の高いバージョンの利用を自動的に禁止できる。たとえば、次のようなポリシーを設定可能である。

• 重大度Criticalの脆弱性を持つコンポーネントを含むビルドは失敗させる。
• GPLライセンスのコンポーネントをプロジェクトで許可しない。
• 特定のパッケージ（例：古いバージョンのlog4j）が含まれている場合にアラートを発する。

このようなポリシーはOpen Policy Agent（OPA）やKyvernoなどの汎用的なポリシーエンジンで実装できる。一方、専用のセキュリティプラットフォーム（Snyk、Dependency-Track、Mend）では、GUI上でポリシーを定義し、CIとの連携も容易である。

インシデント対応の迅速化

あるコンポーネントに重大な脆弱性が発見された場合、SBOMがあれば自社製品への影響範囲を即座に特定できる。たとえば、Log4jの脆弱性が公表された際、SBOMを持たない組織は手動で全プロジェクトを調査する必要があった。SBOMを持つ組織は「SBOMデータベースに対してLog4jのバージョンをクエリする」だけで、該当する全製品とバージョンをリストアップできる。

SBOMの管理は単なる生成だけでは不十分であり、生成したSBOMを検索可能なデータストアに格納し、製品リリースと紐付けてバージョン管理すべきである。Dependency-TrackはこのようなSBOM管理に特化したオープンソースプラットフォームであり、SBOMのアップロード、脆弱性分析、ポリシー適用を一元管理できる。

実践的なセキュリティ対策の全体像

サプライチェーン対策の段階的アプローチ

以下のフレームワークに従って、対策を段階的に実施することが推奨される。

1. 発見（Discover）: 全プロジェクトの依存関係を可視化する。アーカイブされたレガシープロジェクトも含め、すべてのソフトウェア資産をスキャンする。
2. 評価（Assess）: 依存関係ごとに脆弱性・ライセンス・メンテナンス状況を評価する。優先度を設定し、リスクの高いものから対処する。
3. 修正（Remediate）: 脆弱性のあるパッケージをアップデートする。直接依存だけでなく推移的依存も含め、パッチの適用が難しい場合は代替ライブラリへの乗り換えやワークアラウンドを検討する。
4. 監視（Monitor）: CI/CDパイプラインと本番環境で継続的にスキャンし、新たな脆弱性や変更を検出する。SBOMを定期的に再生成し、過去のバージョンとの差分を追跡する。

ツールチェーンの構築例

具体的なツールチェーンの一例を示す。

• SBOM生成: Syft（ビルド時に自動生成）
• 脆弱性スキャン: Grype（SBOMを入力としてCIで実行）
• SBOM管理・ポリシー適用: Dependency-Track（生成したSBOMをアップロード）
• 依存関係更新: Renovate（定期的にPR作成）
• コンテナイメージスキャン: Trivy（コンテナイメージ全体をスキャン）

これらのツールを組み合わせることで、開発プロセスの各段階でセキュリティチェックが行われる。ただし、ツールを導入するだけでは不十分であり、開発チームが結果を理解し、適切に対応できるワークフローを設計することが肝要である。

サプライチェーンセキュリティの今後の展望

規制と標準化の動き

米国大統領令14028は、連邦政府に販売するソフトウェアに対してSBOMの提供を事実上義務付けた。欧州のサイバーレジリエンス法（CRA）は、ハードウェア・ソフトウェア製品にセキュリティ要件を課し、SBOMの維持・開示を求める内容を含んでいる。日本国内でも、内閣サイバーセキュリティセンター（NISC）がソフトウェアサプライチェーンセキュリティに関するガイドラインを策定中である。これらの規制は、将来的にグローバルなソフトウェア市場におけるデファクトスタンダードとなる可能性が高い。

Sigstoreとコード署名の進化

依存関係の真正性を保証する仕組みとして、Sigstore（Red Hat・Google・Purdue大学などが推進）が注目されている。Sigstoreは、ソフトウェアアーティファクトの署名・検証を無料で行える公開鍵基盤（PKI）である。開発者がビルド時に署名し、利用側が署名を検証することで、サプライチェーン上の改ざんを検出できる。GitHub ActionsやCosign（SigstoreのCLI）との連携も整備されつつある。

編集部の見解

比較時の評価軸

ソフトウェアサプライチェーンセキュリティ対策において、編集部は以下の三つの軸を重視する。第一に「自動化の深度」である。人手による依存関係管理は現実的ではなく、CI/CDパイプラインへの完全な組み込みが必須と見る。第二に「可視性の範囲」で、直接依存のみならず推移的依存までカバーできるツールが望ましい。第三に「コミュニティの活発さとサポート体制」だ。OSSツールの場合、脆弱性データベースの更新頻度やバグ修正の迅速さが実運用に直結する。

現場での落とし穴

多くの組織がSBOMの生成だけを行い、その後の管理・活用を怠る傾向がある。SBOMは「点」ではなく「線」として運用すべきであり、生成後の脆弱性スキャンやポリシー適用、定期的な再生成が不可欠である。また、ロックファイルが存在しないレガシープロジェクトでは、正確な依存関係ツリーの再現が困難なため、最初のスキャン時に大量の警告が発生する。このようなプロジェクトに対しては、優先順位を設定し、徐々に改善していく戦略が現実的だ。さらに、SBOMのフォーマット（SPDX vs. CycloneDX）の選択で長期ロックインを懸念する声もあるが、現在は両方のフォーマットに対応したツールが充実しており、変換ツールも提供されているため、過度に心配する必要はない。

今後の方向性

今後1〜3年の間に、ソフトウェアサプライチェーンセキュリティは以下の方向に進むと予測する。第一に、SBOM生成がビルドプロセスの標準機能として定着する。各言語のパッケージマネージャやビルドツールがネイティブでSBOMを出力するようになるだろう。第二に、AIを活用した異常検知が普及する。依存関係の変更パターンから、悪意のあるパッケージや攻撃の兆候を自動検知する技術が研究段階から実用段階へ移行すると考えられる。第三に、規制遵守が企業の最低条件となり、サプライチェーンセキュリティ投資がコストではなく競争力の源泉として認識される。これらの変化に備え、今のうちからSBOMの生成・管理プロセスを確立しておくことが重要と編集部は評価する。

参考

• National Institute of Standards and Technology (NIST). “Software Supply Chain Security Guidance.” https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security
• SPDX. “SPDX Specification.” https://spdx.dev/specifications/
• OWASP. “Software Supply Chain Security.” https://owasp.org/www-project-software-supply-chain-security/
• Anchore. “Syft – Generate SBOM.” https://github.com/anchore/syft
• Aqua Security. “Trivy – Vulnerability Scanner.” https://github.com/aquasecurity/trivy
• Dependency-Track. “Dependency-Track Project.” https://dependencytrack.org/
• Sigstore. “Sigstore – Software Signing for Everybody.” https://www.sigstore.dev/