如何分析SBOM（CycloneDX/SPDX）识别供应链漏…

当你拿到一份 CycloneDX 或 SPDX 格式的 SBOM，需要关联 NVD CVE 数据库、构建依赖图、评估传递性风险并输出合规报告时使用。

适用场景

解决思路

1. 若尚未有 SBOM，用 syft 生成：`syft alpine:latest -o cyclonedx-json > sbom-cyclonedx.json`（从容器镜像生成 CycloneDX JSON）、`syft dir:/path/to/project -o spdx-json > sbom-spdx.json`（从项目目录生成 SPDX JSON）、`syft docker:my-app-container -o cyclonedx-json > sbom.json`（从运行中容器生成）；syft 支持 npm、PyPI、Maven、Go modules、apt、apk、RPM 等 30+ 生态，输出包含包名、版本、许可证、CPE 和 PURL。
2. 解析 SBOM 提取组件：CycloneDX JSON 从 `components` 数组读取 type/name/version/purl/cpe/licenses，从 `dependencies` 数组读取 ref 与 dependsOn 关系；SPDX JSON 从 `packages` 数组读取 name/versionInfo/externalRefs（purl、cpe23Type）/licenseConcluded，从 `relationships` 数组读取 DEPENDS_ON 关系。
3. 通过 NVD 2.0 API 关联 CVE：用 `search_cves_by_cpe(cpe_name, api_key)` 按 CPE 名精确查询（参数 `cpeName`、`resultsPerPage`），或用 `search_cves_by_keyword(keyword, version, api_key)` 按关键字查询（参数 `keywordSearch`）；请求头带 `apiKey`，超时 30 秒，从返回 JSON 的 `vulnerabilities` 字段取结果；NVD 限速为无 key 每 30 秒 5 次、有 key 每 30 秒 50 次。
4. 构建依赖有向图识别传递性风险：用 networkx 的 `DiGraph`，为每个组件按 purl 添加节点（附带 name、version 属性），遍历 `dependencies` 的 dependsOn 添加边；据此识别非直接引入的传递依赖（即使嵌套 4 层仍有风险）。
5. 计算图指标用于风险评估：入度（in-degree，多少组件依赖它，越高爆炸半径越大）、到根的最短路径（越近越易被利用）、介数中心性（betweenness centrality，位于大量依赖路径上的瓶颈组件）。
6. 计算风险分：组件风险 = 该组件所有 CVE 的 CVSS 最大值；加权风险 = 组件风险 × 依赖因子，其中依赖因子 = 1.0 + (0.1 × 入度)；整体 SBOM 风险 = 按依赖中心性加权的所有组件风险加权平均；风险等级：CRITICAL 为 CVSS ≥ 9.0 或列入 CISA KEV，HIGH 为 CVSS ≥ 7.0，MEDIUM 为 CVSS ≥ 4.0，LOW 为 CVSS < 4.0。
7. 用 grype 交叉验证：`grype sbom:sbom-cyclonedx.json -o json > grype-results.json`、`grype sbom:sbom-spdx.json -o table`、`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 更全面。
8. 生成合规报告：包含 SBOM 文件名、格式与版本、分析日期、组件总数、依赖总数（直接/传递）、按严重级别汇总的漏洞统计、关键发现（组件名+版本、CVE 编号+CVSS+描述、依赖者数量、修复版本）、依赖图风险（被依赖最多的组件、最深依赖链、瓶颈组件）、许可证合规（发现的 copyleft 许可证如 GPL-3.0/AGPL-3.0 及商业分发审查提示）。
9. 处理 Log4Shell 类事件场景：收集所有厂商 SBOM → 解析并查找版本 < 2.17.1 的 log4j-core → 查询 NVD 获取 CVE-2021-44228/45046/45105 → 构建依赖图确定哪些应用组件依赖 log4j → 计算爆炸半径（受影响服务与端点）→ 按暴露度和业务重要性生成优先级修复报告 → 用 grype 扫描同一 SBOM 交叉验证。

适用边界 · 注意事项

• 不要用于对运行中系统的实时漏洞扫描；应改用容器扫描工具（Trivy、Grype CLI）或主机漏洞扫描器（Nessus、Qualys）。
• 厂商提供的 SBOM 可能不完整，会遗漏 shaded/bundled JAR 中嵌入的组件（如 log4j），需注意覆盖盲区。
• SPDX 与 CycloneDX 的版本差异可能影响解析器兼容性；SBOM 中的 CPE 名可能与 NVD 条目不精确匹配，需要模糊匹配。