analyzing-sbom-for-supply-chain-vulnerabilities

サプライチェーンの脆弱性に関する SBOM の分析

使用する場面

• 新たな規制要件（EO 14028、EU CRA）により、ソフトウェアの納品時に SBOM の分析が義務付けられている場合
• セキュリティチームが、ベンダーから提供された SBOM をスキャンしてサードパーティのリスクを評価する必要がある場合
• CI/CD パイプラインで、生成された SBOM に対する脆弱性チェックを自動化する必要がある場合
• インシデント対応で、新たに公開された CVE がデプロイ済みソフトウェアに影響するかどうかを特定する必要がある場合
• 調達チームが、ソフトウェアの購入にあたってサプライチェーンリスクの評価を必要とする場合

使用しないでください。稼働中のシステムを対象とするランタイム脆弱性スキャンには使用しないでください。代わりに、コンテナスキャンツール（Trivy、Grype CLI）またはホストベースの脆弱性スキャナー（Nessus、Qualys）を使用してください。

前提条件

• CycloneDX JSON（v1.4 以降）または SPDX JSON（v2.3 以降）形式の SBOM ファイル
• requests、networkx、packaging ライブラリをインストールした Python 3.9+
• レート制限の緩和に必要な NVD API キー（https://nvd.nist.gov/developers/request-an-api-key から無料で取得できます）
• NVD API（https://services.nvd.nist.gov/rest/json/cves/2.0）へのネットワークアクセス
• 任意：SBOM の生成に使用する syft、相互検証に使用する grype

ワークフロー

ステップ 1：SBOM を生成する（提供されていない場合）

syft を使用して、コンテナイメージまたはプロジェクトディレクトリから SBOM を作成します。

# Generate CycloneDX JSON from a container image
syft alpine:latest -o cyclonedx-json > sbom-cyclonedx.json

# Generate SPDX JSON from a project directory
syft dir:/path/to/project -o spdx-json > sbom-spdx.json

# Generate from a running container
syft docker:my-app-container -o cyclonedx-json > sbom.json

Syft は、npm、PyPI、Maven、Go モジュール、apt、apk、RPM など、30 以上のパッケージエコシステムに対応しています。生成される SBOM には、パッケージ名、バージョン、ライセンス、CPE 識別子、PURL（Package URL）参照が含まれます。

ステップ 2：SBOM を解析してコンポーネントを抽出する

SBOM を解析して、識別子とともにすべてのソフトウェアコンポーネントを抽出します。

CycloneDX JSON の構造：

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.20",
      "purl": "pkg:npm/[email protected]",
      "cpe": "cpe:2.3:a:lodash:lodash:4.17.20:*:*:*:*:*:*:*",
      "licenses": [{"license": {"id": "MIT"}}]
    }
  ],
  "dependencies": [
    {"ref": "pkg:npm/[email protected]", "dependsOn": ["pkg:npm/[email protected]"]}
  ]
}

SPDX JSON の構造：

{
  "spdxVersion": "SPDX-2.3",
  "packages": [
    {
      "name": "lodash",
      "versionInfo": "4.17.20",
      "externalRefs": [
        {"referenceType": "purl", "referenceLocator": "pkg:npm/[email protected]"},
        {"referenceType": "cpe23Type", "referenceLocator": "cpe:2.3:a:lodash:lodash:4.17.20:*:*:*:*:*:*:*"}
      ],
      "licenseConcluded": "MIT"
    }
  ],
  "relationships": [
    {"spdxElementId": "SPDXRef-express", "relatedSpdxElement": "SPDXRef-lodash",
     "relationshipType": "DEPENDS_ON"}
  ]
}

ステップ 3：コンポーネントを NVD の CVE データベースと照合する

NVD 2.0 API にクエリを送信し、各コンポーネントに関する既知の脆弱性を検索します。

import requests

NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0"

def search_cves_by_cpe(cpe_name, api_key=None):
    params = {"cpeName": cpe_name, "resultsPerPage": 50}
    headers = {"apiKey": api_key} if api_key else {}
    resp = requests.get(NVD_API, params=params, headers=headers, timeout=30)
    resp.raise_for_status()
    return resp.json().get("vulnerabilities", [])

def search_cves_by_keyword(keyword, version=None, api_key=None):
    params = {"keywordSearch": keyword, "resultsPerPage": 50}
    headers = {"apiKey": api_key} if api_key else {}
    resp = requests.get(NVD_API, params=params, headers=headers, timeout=30)
    resp.raise_for_status()
    return resp.json().get("vulnerabilities", [])

NVD API では、CPE 名（最も正確）、キーワード、CVE ID、日付範囲を指定して検索できます。レート制限は、API キーなしの場合は 30 秒あたり 5 リクエスト、API キーありの場合は 30 秒あたり 50 リクエストです。

ステップ 4：依存関係グラフを作成して、推移的なリスクを特定する

依存関係の伝播を追跡するため、有向グラフを構築します。

import networkx as nx

def build_dependency_graph(sbom):
    G = nx.DiGraph()
    # Add nodes for each component
    for comp in sbom["components"]:
        G.add_node(comp["purl"], name=comp["name"], version=comp["version"])
    # Add edges from dependency relationships
    for dep in sbom.get("dependencies", []):
        for child in dep.get("dependsOn", []):
            G.add_edge(dep["ref"], child)
    return G

推移的依存関係の分析では、直接含まれてはいないものの、依存関係の連鎖を通じて取り込まれるコンポーネントを特定します。深くネストされた推移的依存関係（例：4 階層目）の脆弱性もリスクとなりますが、修正が難しい場合があります。

リスク評価で重要となるグラフの指標：

• 入次数：このコンポーネントに依存するコンポーネントの数（入次数が高いほど、影響範囲が広くなります）
• ルートまでの最短経路：アプリケーションのエントリーポイントからの距離（近いほど、悪用される可能性が高くなります）
• 媒介中心性：多くの依存関係経路上にあるコンポーネント（ボトルネックとなるリスク）

ステップ 5：リスクスコアを計算する

脆弱性データを集約し、コンポーネントごと、および全体のリスクスコアを算出します。

Risk Score Calculation:
━━━━━━━━━━━━━━━━━━━━━━
Component Risk = max(CVSS scores of all CVEs affecting the component)

Weighted Risk = Component Risk * Dependency Factor
  where Dependency Factor = 1.0 + (0.1 * in_degree)
  (more dependents = higher organizational impact)

Overall SBOM Risk = weighted average of all component risks
  weighted by dependency centrality

Risk Levels:
  CRITICAL: CVSS >= 9.0 or known exploited (CISA KEV)
  HIGH:     CVSS >= 7.0
  MEDIUM:   CVSS >= 4.0
  LOW:      CVSS < 4.0

ステップ 6：Grype で相互検証する

grype を使用して SBOM を独立してスキャンし、検出結果を比較します。

# Scan CycloneDX SBOM with grype
grype sbom:sbom-cyclonedx.json -o json > grype-results.json

# Scan SPDX SBOM
grype sbom:sbom-spdx.json -o table

# Filter by severity
grype sbom:sbom-cyclonedx.json --only-fixed --fail-on critical

Grype は、NVD、GitHub Security Advisories、Alpine SecDB、Red Hat、Debian、Ubuntu、Amazon Linux、Oracle のセキュリティデータベースから脆弱性データを取得するため、NVD のみによるスキャンより広範囲をカバーできます。

ステップ 7：コンプライアンスレポートを作成する

規制への準拠に適した形式のレポートを作成します。

SBOM VULNERABILITY ANALYSIS REPORT
====================================
SBOM File:         app-sbom-cyclonedx.json
Format:            CycloneDX v1.5
Analysis Date:     2026-03-19
Total Components:  247
Total Dependencies: 1,842 (direct: 34, transitive: 213)

VULNERABILITY SUMMARY
  Critical:  3 components / 5 CVEs
  High:      11 components / 18 CVEs
  Medium:    27 components / 41 CVEs
  Low:       8 components / 12 CVEs

CRITICAL FINDINGS
1. [email protected]
   CVE-2021-23337 (CVSS 7.2) - Command Injection via template
   CVE-2020-28500 (CVSS 5.3) - ReDoS in trimEnd
   Dependents: 14 components (high blast radius)
   Fix: Upgrade to 4.17.21+

2. [email protected]
   CVE-2021-44228 (CVSS 10.0) - Log4Shell RCE [CISA KEV]
   CVE-2021-45046 (CVSS 9.0) - Incomplete fix bypass
   Dependents: 8 components
   Fix: Upgrade to 2.17.1+

DEPENDENCY GRAPH RISKS
  Most depended-on: [email protected] (47 dependents)
  Deepest chain: app -> framework -> adapter -> codec -> zlib (5 levels)
  Bottleneck components: 3 components on >50% of dependency paths

LICENSE COMPLIANCE
  Copyleft licenses found: 2 (GPL-3.0 in libxml2, AGPL-3.0 in mongodb-driver)
  Review required for commercial distribution

主要な概念

用語	定義
SBOM	ソフトウェア部品表。ソフトウェア製品に含まれるすべてのコンポーネント、ライブラリ、依存関係を正式に一覧化したものです
CycloneDX	OWASP が保守する SBOM 標準です。依存関係グラフと脆弱性データを含み、JSON、XML、protobuf 形式をサポートします
SPDX	Linux Foundation の SBOM 標準です。ライセンスコンプライアンスに重点を置き、パッケージ、ファイル、コードスニペット単位の詳細に対応しています
PURL	Package URL。エコシステムをまたいでソフトウェアパッケージを識別するための標準化された方式です（例：pkg:npm/[email protected]）
CPE	Common Platform Enumeration。NVD の CVE データとの関連付けに使用される、IT 製品の NIST 命名方式です
NVD	National Vulnerability Database。CVE 識別子で索引付けされた脆弱性データを収録する米国政府のリポジトリです
推移的依存関係	直接宣言されていないものの、直接依存関係の依存関係チェーンを通じて取り込まれる依存関係です
CISA KEV	CISA Known Exploited Vulnerabilities カタログ。実環境で積極的に悪用されていることが確認された CVE を掲載しています

ツールとシステム

• syft（Anchore）：30 以上のパッケージエコシステムと CycloneDX／SPDX 出力に対応したオープンソースの SBOM 生成ツールです
• grype（Anchore）：SBOM を入力として受け取り、複数のアドバイザリデータベースと照合する脆弱性スキャナーです
• cyclonedx-python-lib：CycloneDX SBOM をプログラムで作成、解析、検証するための Python ライブラリです
• lib4sbom：SPDX と CycloneDX の両形式の SBOM を解析するための Python ライブラリです
• nvdlib：レート制限管理に対応し、CVE および CPE のクエリをサポートする NVD 2.0 API 用の Python ラッパーです
• OWASP Dependency-Track：継続的な SBOM 分析、脆弱性追跡、ポリシー適用のためのプラットフォームです

よくあるシナリオ

シナリオ：Log4Shell 公開後のベンダーソフトウェアの評価

背景：Log4Shell（CVE-2021-44228）の公開後、セキュリティチームは、ベンダー提供のどのアプリケーションに脆弱なバージョンの log4j が含まれているかを特定する必要があります。複数のベンダーから、契約上の要件に基づいて SBOM が提供されています。

アプローチ：

1. すべてのベンダーの SBOM を収集します（CycloneDX または SPDX の JSON 形式）
2. 各 SBOM を解析し、バージョンが 2.17.1 未満の log4j-core コンポーネントを検索します
3. 特定の CVE（CVE-2021-44228、CVE-2021-45046、CVE-2021-45105）について NVD API に問い合わせます
4. 依存関係グラフを作成し、どのアプリケーションコンポーネントが log4j に依存しているかを特定します
5. 影響範囲を算出します。影響を受けるサービスとエンドポイントの数を確認します
6. 露出度とビジネス上の重要度に基づいて優先順位を付けた修復レポートを生成します
7. 同じ SBOM を grype でスキャンし、調査結果を相互検証します

注意点：

• ベンダーの SBOM は不完全な場合があり、log4j を内包するシェーディング済み／バンドル済みの JAR ファイルが欠落していることがあります
• SPDX と CycloneDX のバージョンの違いが、パーサーとの互換性に影響する場合があります
• API キーを使わずに数百のコンポーネントをスキャンすると、NVD API のレート制限によって分析が遅くなることがあります
• SBOM 内の CPE 名が NVD のエントリーと完全には一致しない場合があり、あいまい一致が必要になることがあります
• 直接依存関係ではない場合でも、推移的依存関係に log4j が含まれていることがあります