SBOM 2025 - ソフトウェアサプライチェーンの透明性革命

SBOMとは何か

SBOM（Software Bill of Materials：ソフトウェア部品表） は、ソフトウェアを構成するすべてのコンポーネント、ライブラリ、依存関係を一覧化したドキュメントです。製造業における部品表（BOM）の概念をソフトウェアに適用したものであり、「ソフトウェアの成分表示」とも呼ばれています。

SBOMに含まれる情報:
・コンポーネント名
・バージョン情報
・サプライヤー/開発者
・ライセンス情報
・依存関係の階層構造
・ハッシュ値（完全性検証用）
・パッチ/更新状況

なぜSBOMが重要なのか

2021年のLog4Shell脆弱性（CVE-2021-44228）は、SBOMの重要性を世界に知らしめました。多くの組織が「自社システムのどこにLog4jが使われているか」を把握できず、対応に数週間から数ヶ月を要しました。

Log4Shell問題が露呈した課題:
・サプライチェーンの不透明性
・間接依存の把握困難
・脆弱性対応の遅延
・ライセンスコンプライアンスリスク

SBOMがあれば、脆弱性が公表された瞬間に影響範囲を特定し、迅速な対応が可能になります。

規制動向

米国大統領令14028（2021年）

2021年5月、バイデン政権は大統領令14028「国家のサイバーセキュリティ向上」を発令しました。

大統領令14028の主な要求:
・連邦政府調達ソフトウェアへのSBOM提供義務
・NISTによるガイドライン策定
・ソフトウェア開発セキュリティ基準の確立
・サプライチェーン透明性の強化

この大統領令を受けて、2025年現在、連邦政府にソフトウェアを納入する企業はSBOMの提供が事実上必須となっています。

EU Cyber Resilience Act（CRA）

EUは2024年にCyber Resilience Act（サイバーレジリエンス法）を採択し、2027年の完全施行に向けて準備が進んでいます。

EU CRAの主要要件:
  対象:
    - デジタル要素を持つすべての製品
    - IoTデバイス
    - ソフトウェア製品
    - ハードウェア製品

  SBOM要件:
    - 製品に含まれる依存関係の文書化
    - 脆弱性開示ポリシーの策定
    - セキュリティ更新の提供義務（最低5年）
    - 既知の脆弱性なしでの出荷

  罰則:
    - 最大1,500万ユーロまたは売上高の2.5%
    - EU市場からの製品撤去

日本の動向

日本でも経済産業省を中心にSBOM活用が推進されています。

日本のSBOM関連動向（2025年）:
・経産省「ソフトウェア管理に向けたSBOMの導入に関する手引」公開
・政府調達におけるSBOM推奨
・重要インフラ分野でのSBOM導入検討
・自動車業界でのSBOM標準化（JASPAR）

SBOMフォーマット

SPDX（Software Package Data Exchange）

Linux Foundationが策定したオープン標準であり、ISO/IEC 5962:2021として国際標準化されています。

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-application",
  "documentNamespace": "https://example.com/my-app-1.0.0",
  "creationInfo": {
    "created": "2025-01-12T10:00:00Z",
    "creators": [
      "Tool: syft-1.0.0",
      "Organization: Example Corp"
    ]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "supplier": "Organization: Lodash Maintainers",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "filesAnalyzed": false,
      "licenseConcluded": "MIT",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "npm",
          "referenceLocator": "lodash@4.17.21"
        },
        {
          "referenceCategory": "SECURITY",
          "referenceType": "cpe23Type",
          "referenceLocator": "cpe:2.3:a:lodash:lodash:4.17.21:*:*:*:*:node.js:*:*"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-Package-lodash"
    }
  ]
}

CycloneDX

OWASPが策定したセキュリティ重視のフォーマットで、脆弱性情報との連携に強みがあります。

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.5"
     version="1"
     serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79">
  <metadata>
    <timestamp>2025-01-12T10:00:00Z</timestamp>
    <tools>
      <tool>
        <vendor>anchore</vendor>
        <name>syft</name>
        <version>1.0.0</version>
      </tool>
    </tools>
    <component type="application" bom-ref="my-application">
      <name>my-application</name>
      <version>1.0.0</version>
    </component>
  </metadata>
  <components>
    <component type="library" bom-ref="pkg:npm/lodash@4.17.21">
      <name>lodash</name>
      <version>4.17.21</version>
      <purl>pkg:npm/lodash@4.17.21</purl>
      <licenses>
        <license>
          <id>MIT</id>
        </license>
      </licenses>
      <hashes>
        <hash alg="SHA-256">
          bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81d4
        </hash>
      </hashes>
    </component>
  </components>
  <vulnerabilities>
    <vulnerability ref="pkg:npm/lodash@4.17.21">
      <id>CVE-2021-23337</id>
      <source>
        <name>NVD</name>
      </source>
      <ratings>
        <rating>
          <score>7.2</score>
          <severity>high</severity>
          <method>CVSSv3</method>
        </rating>
      </ratings>
    </vulnerability>
  </vulnerabilities>
</bom>

フォーマット比較

SBOM生成ツール

Syft（Anchore）

最も人気のあるオープンソースSBOM生成ツールです。

# インストール
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# コンテナイメージからSBOM生成
syft alpine:latest -o spdx-json > alpine-sbom.spdx.json

# ディレクトリからSBOM生成
syft dir:/path/to/project -o cyclonedx-json > project-sbom.cdx.json

# 複数フォーマットでの出力
syft packages myapp:latest \
  -o spdx-json=sbom.spdx.json \
  -o cyclonedx-json=sbom.cdx.json \
  -o table

Trivy（Aqua Security）

脆弱性スキャンとSBOM生成を統合したツールです。

# インストール
brew install trivy

# SBOM生成
trivy image --format cyclonedx --output sbom.cdx.json nginx:latest

# SBOM生成と同時に脆弱性スキャン
trivy sbom --severity HIGH,CRITICAL sbom.cdx.json

# ファイルシステムスキャン
trivy fs --format spdx-json --output sbom.spdx.json ./

その他の主要ツール

SBOM生成ツール一覧:

  オープンソース:
    - syft: 多言語対応、高速
    - trivy: 脆弱性スキャン統合
    - cdxgen: Node.js/Java特化
    - spdx-sbom-generator: SPDX公式
    - tern: コンテナ特化

  商用:
    - Snyk: 開発者フレンドリー
    - Black Duck: エンタープライズ向け
    - FOSSA: ライセンスコンプライアンス
    - Sonatype Nexus: リポジトリ統合
    - JFrog Xray: アーティファクト管理統合

  クラウドネイティブ:
    - AWS Inspector: AWS統合
    - Google Cloud Build: GCP統合
    - Azure Defender: Azure統合

CI/CDパイプライン統合

# GitHub Actions での SBOM 生成例
name: SBOM Generation

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Syft
        uses: anchore/sbom-action/download-syft@v0

      - name: Generate SBOM
        run: |
          syft dir:. -o spdx-json > sbom.spdx.json
          syft dir:. -o cyclonedx-json > sbom.cdx.json

      - name: Scan for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'sbom'
          scan-ref: 'sbom.cdx.json'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'

      - name: Upload SBOM artifacts
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.spdx.json
            sbom.cdx.json

      - name: Attest SBOM (for container images)
        uses: actions/attest-sbom@v1
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.push.outputs.digest }}
          sbom-path: 'sbom.spdx.json'

脆弱性スキャン連携

VEX（Vulnerability Exploitability eXchange）

SBOMだけでは「この脆弱性が実際に影響するか」がわかりません。VEXはその判断情報を提供します。

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2025-001",
  "author": "Example Corp Security Team",
  "timestamp": "2025-01-12T10:00:00Z",
  "statements": [
    {
      "vulnerability": {
        "@id": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228",
        "name": "CVE-2021-44228",
        "description": "Log4j RCE vulnerability"
      },
      "products": [
        {
          "@id": "pkg:npm/my-application@1.0.0",
          "identifiers": {
            "purl": "pkg:npm/my-application@1.0.0"
          }
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "Log4j is included as a transitive dependency but the vulnerable JNDI lookup feature is never invoked in our application."
    }
  ]
}

脆弱性データベース連携

# Python での SBOM 脆弱性スキャン例
import json
import requests
from packageurl import PackageURL

class SBOMVulnerabilityScanner:
    def __init__(self, osv_api="https://api.osv.dev/v1"):
        self.osv_api = osv_api

    def scan_cyclonedx(self, sbom_path: str) -> list:
        """CycloneDX SBOMから脆弱性をスキャン"""
        with open(sbom_path) as f:
            sbom = json.load(f)

        vulnerabilities = []

        for component in sbom.get("components", []):
            purl = component.get("purl")
            if not purl:
                continue

            vulns = self.query_osv(purl)
            if vulns:
                vulnerabilities.append({
                    "component": component["name"],
                    "version": component["version"],
                    "purl": purl,
                    "vulnerabilities": vulns
                })

        return vulnerabilities

    def query_osv(self, purl: str) -> list:
        """OSV APIで脆弱性を照会"""
        parsed = PackageURL.from_string(purl)

        response = requests.post(
            f"{self.osv_api}/query",
            json={
                "package": {
                    "purl": purl
                }
            }
        )

        if response.status_code == 200:
            data = response.json()
            return data.get("vulns", [])

        return []

    def generate_report(self, vulnerabilities: list) -> str:
        """脆弱性レポート生成"""
        report = []
        critical = 0
        high = 0

        for item in vulnerabilities:
            for vuln in item["vulnerabilities"]:
                severity = self.get_severity(vuln)
                if severity == "CRITICAL":
                    critical += 1
                elif severity == "HIGH":
                    high += 1

                report.append(
                    f"- {item['component']}@{item['version']}: "
                    f"{vuln['id']} ({severity})"
                )

        summary = f"Critical: {critical}, High: {high}"
        return f"{summary}\n" + "\n".join(report)

継続的モニタリング

# SBOM継続監視アーキテクチャ
sbom_monitoring_pipeline:

  ingestion:
    sources:
      - ci_cd_pipeline
      - container_registry
      - artifact_repository
    storage:
      type: s3
      bucket: sbom-archive
      retention: 7_years

  vulnerability_correlation:
    feeds:
      - nvd: "https://nvd.nist.gov/"
      - osv: "https://osv.dev/"
      - github_advisory: "https://github.com/advisories"
      - vendor_advisories: custom

    schedule: every_6_hours

    actions:
      on_new_cve:
        - scan_all_sboms
        - identify_affected_products
        - create_tickets
        - notify_owners

  reporting:
    dashboards:
      - vulnerability_overview
      - license_compliance
      - dependency_freshness
      - sbom_coverage

    alerts:
      critical_cve:
        - slack: "#security-alerts"
        - pagerduty: on_call_team

2025年の義務化状況

グローバル規制マップ

flowchart TB
    subgraph title["2025年 SBOM義務化状況"]
        subgraph usa["米国"]
            usa1["連邦政府調達: 必須（EO 14028）"]
            usa2["医療機器: 必須（FDA要件）"]
            usa3["重要インフラ: 推奨→段階的義務化"]
            usa4["金融: 規制当局からの強い推奨"]
        end
        subgraph eu["EU"]
            eu1["CRA: 2027年完全施行に向け準備"]
            eu2["NIS2: 重要事業者にSBOM推奨"]
            eu3["医療機器規則: SBOM要件検討中"]
        end
        subgraph japan["日本"]
            jp1["政府調達: 推奨（ガイドライン策定中）"]
            jp2["自動車: JASPAR標準策定"]
            jp3["重要インフラ: サイバーセキュリティ経営ガイドライン"]
        end
        subgraph others["その他"]
            ot1["英国: 医療機器、政府調達で検討"]
            ot2["オーストラリア: 重要インフラ法で言及"]
            ot3["シンガポール: サイバーセキュリティ法改正検討"]
        end
    end

業界別要件

業界別SBOM要件（2025年）:

  医療機器:
    規制: FDA Cybersecurity Guidance
    要件:
      - 製品出荷時のSBOM提供
      - 脆弱性監視計画
      - セキュリティアップデート手順
    期限: 即時適用

  自動車:
    規制: UN R155/R156
    要件:
      - 車両ソフトウェアの構成管理
      - サイバーセキュリティ管理システム
      - OTAアップデート管理
    期限: 新型車2024年7月〜

  金融:
    規制: FFIEC、PCI DSS 4.0
    要件:
      - サードパーティリスク管理
      - ソフトウェアサプライチェーン可視化
      - 脆弱性管理プロセス
    期限: 段階的導入

  防衛:
    規制: NIST SP 800-171、CMMC
    要件:
      - 調達ソフトウェアのSBOM
      - サプライチェーン完全性
      - 継続的モニタリング
    期限: 契約更新時

SBOM導入のベストプラクティス

段階的導入アプローチ

flowchart TB
    subgraph phase1["Phase 1: 基盤整備（1-3ヶ月）"]
        p1a["ツール選定・導入"]
        p1b["フォーマット決定（SPDX/CycloneDX）"]
        p1c["パイロットプロジェクト選定"]
        p1d["チーム教育"]
    end
    subgraph phase2["Phase 2: 自動化（3-6ヶ月）"]
        p2a["CI/CDパイプライン統合"]
        p2b["コンテナイメージスキャン"]
        p2c["アーティファクト署名"]
        p2d["脆弱性スキャン連携"]
    end
    subgraph phase3["Phase 3: 運用化（6-12ヶ月）"]
        p3a["全プロジェクトへの展開"]
        p3b["継続的モニタリング"]
        p3c["VEX運用開始"]
        p3d["サプライヤー要件化"]
    end
    subgraph phase4["Phase 4: 成熟（12ヶ月〜）"]
        p4a["サプライチェーン全体可視化"]
        p4b["リスクスコアリング"]
        p4c["自動修復ワークフロー"]
        p4d["規制対応レポート自動化"]
    end
    phase1 --> phase2 --> phase3 --> phase4

よくある課題と解決策

課題と解決策:

  ツールの精度:
    問題: SBOM生成ツールによって結果が異なる
    解決:
      - 複数ツールでの相互検証
      - マニフェストファイルの正確な管理
      - 定期的なツール評価

  大規模環境:
    問題: 数千のマイクロサービスのSBOM管理
    解決:
      - 中央集権的なSBOMリポジトリ
      - 自動化されたインジェスト
      - 階層的な集約

  サードパーティ依存:
    問題: OSS以外のサプライヤーからSBOM取得困難
    解決:
      - 契約時にSBOM要件を明記
      - 段階的な要件強化
      - 自社でのリバースエンジニアリング

  運用負荷:
    問題: 脆弱性アラートの対応が追いつかない
    解決:
      - VEXによる影響判定自動化
      - リスクベースの優先順位付け
      - 自動パッチ適用ワークフロー

将来展望

SBOM 3.0時代へ

flowchart LR
    subgraph future["2025年以降の進化"]
        subgraph ai["1. AI/MLモデルのSBOM"]
            ai1["学習データの透明性"]
            ai2["モデル依存関係の追跡"]
            ai3["バイアス/公平性情報"]
        end
        subgraph saas["2. SaaSBOM（サービスのSBOM）"]
            saas1["クラウドサービス構成の可視化"]
            saas2["API依存関係の追跡"]
            saas3["マルチクラウド対応"]
        end
        subgraph realtime["3. リアルタイムSBOM"]
            rt1["ランタイム依存の検出"]
            rt2["動的ロードの追跡"]
            rt3["コンテナオーケストレーション統合"]
        end
        subgraph zerotrust["4. ゼロトラストとの統合"]
            zt1["SBOM署名の検証"]
            zt2["ポリシーベースのデプロイ制御"]
            zt3["サプライチェーン攻撃の検出"]
        end
    end

まとめ

2025年、SBOMは「あれば良いもの」から「必須のもの」へと変化しました。米国大統領令、EU CRAなどの規制により、ソフトウェアサプライチェーンの透明性は法的要件となりつつあります。

SBOM導入の価値:
・脆弱性対応時間: 数日→数時間
・ライセンス違反リスク: 大幅削減
・規制コンプライアンス: 対応可能
・サプライチェーンリスク: 可視化・管理

Syft、Trivyなどのツールを活用し、CI/CDパイプラインに組み込むことで、SBOMの自動生成と脆弱性スキャンを実現できます。SPDX、CycloneDXの両フォーマットを理解し、組織のニーズに合った選択をすることが重要です。

参考資料:

• NTIA SBOM Documents
• CISA SBOM Resources
• Linux Foundation SPDX
• OWASP CycloneDX
• 経済産業省 SBOMの手引き

SBOMは単なる文書ではなく、ソフトウェアサプライチェーン全体の信頼を構築するための基盤です。今こそ、組織全体でSBOM戦略を策定し、セキュアなソフトウェア開発・運用体制を確立すべき時です。