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 支持 30 多种软件包生态系统，包括 npm、PyPI、Maven、Go modules、apt、apk 和 RPM。生成的 SBOM 包含软件包名称、版本、许可证、CPE 标识符和 PURL（软件包 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 次请求；使用密钥时每 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	包 URL；用于跨生态系统识别软件包的标准化方案（例如，pkg:npm/[email protected]）
CPE	通用平台枚举；NIST 为 IT 产品制定的命名方案，用于与 NVD CVE 数据关联
NVD	国家漏洞数据库；美国政府的漏洞数据存储库，按 CVE 标识符索引
传递依赖项	未直接声明，但通过直接依赖项的依赖链引入的依赖项
CISA KEV	CISA 已知遭利用漏洞目录；已确认正在现实环境中遭利用的 CVE

工具与系统

• syft（Anchore）：开源 SBOM 生成器，支持 30 多种软件包生态系统，并可输出 CycloneDX/SPDX 格式
• grype（Anchore）：漏洞扫描器，可将 SBOM 作为输入，并与多个安全公告数据库进行关联
• cyclonedx-python-lib：用于以编程方式创建、解析和验证 CycloneDX SBOM 的 Python 库
• lib4sbom：用于解析 SPDX 和 CycloneDX 格式 SBOM 的 Python 库
• nvdlib：NVD 2.0 API 的 Python 封装，支持 CVE 和 CPE 查询，并管理速率限制
• OWASP Dependency-Track：用于持续分析 SBOM、跟踪漏洞和执行策略的平台

常见场景

场景：Log4Shell 漏洞披露后评估供应商软件

背景：Log4Shell（CVE-2021-44228）漏洞披露后，安全团队需要确定哪些供应商提供的应用程序包含易受攻击版本的 log4j。根据合同要求，多个供应商已提供 SBOM。

方法：

1. 收集所有供应商的 SBOM（CycloneDX 或 SPDX JSON 格式）
2. 解析每个 SBOM，并搜索版本低于 2.17.1 的 log4j-core 组件
3. 查询 NVD API，获取特定 CVE（CVE-2021-44228、CVE-2021-45046、CVE-2021-45105）的信息
4. 构建依赖关系图，确定哪些应用程序组件依赖 log4j
5. 计算影响范围：有多少服务和端点暴露在风险中
6. 按暴露程度和业务关键性排序，生成优先级修复报告
7. 使用 grype 扫描相同的 SBOM，并交叉验证结果

注意事项：

• 供应商的 SBOM 可能不完整，遗漏嵌入 log4j 的 shaded/bundled JAR 文件
• SPDX 和 CycloneDX 的版本差异可能会影响解析器兼容性
• 如果在没有 API 密钥的情况下扫描数百个组件，NVD API 的速率限制可能会拖慢分析
• SBOM 中的 CPE 名称可能与 NVD 条目并不完全匹配，因此需要进行模糊匹配
• 即使 log4j 不是直接依赖项，传递依赖项中也可能包含它