企业官网建设流程全解析

Anthropic Cybersecurity Skills 实战：基于 SBOM 的供应链漏洞分析（CycloneDX/SPDX + NVD CVE 关联）

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读：本文以 Anthropic Cybersecurity Skills 仓库中的analyzing-sbom-for-supply-chain-vulnerabilities技能为核心，系统讲解如何解析 CycloneDX 与 SPDX 两种主流 SBOM（软件物料清单）格式，通过 NVD 2.0 API 将组件与 CVE 数据库关联，构建依赖图定位传递性漏洞路径、计算风险评分并生成合规报告。读完本文，你将掌握一套从生成 SBOM 到输出漏洞分析报告的完整实战流程，可直接用于应对 EO 14028 / EU CRA 等监管要求、第三方风险评估与 CI/CD 供应链安全门禁场景。

技能定位与适用场景

该技能是仓库中 Supply Chain Security（供应链安全）领域下的 8 个技能之一，前置于 skills/analyzing-sbom-for-supply-chain-vulnerabilities/SKILL.md，以 agentskills.io 标准封装，YAML frontmatter 中的 description 明确列出了激活条件：SBOM 分析、软件成分分析（SCA）、供应链安全评估、依赖漏洞扫描、CycloneDX/SPDX 解析或 CVE 关联等请求。其完整能力描述为：

解析 CycloneDX 和 SPDX JSON 格式的 SBOM，通过 NVD 2.0 API 将组件与 NVD CVE 数据库关联来识别供应链漏洞；构建依赖图、计算风险评分、识别传递性漏洞路径并生成合规报告。

何时使用（When to Use）

技能文档定义了五类典型触发场景：

• 监管合规：新的监管要求（如美国的 EO 14028、欧盟的 EU CRA）强制要求软件交付物附带 SBOM 分析结果；
• 第三方风险：安全团队需要扫描供应商提供的 SBOM，评估第三方软件风险；
• CI/CD 自动化：流水线需要对生成的 SBOM 执行自动化漏洞检查；
• 事件响应：新披露的 CVE 出现后，需要判定其是否影响已部署的软件；
• 采购评估：采购团队需要对软件收购进行供应链风险评估。

明确的边界：该技能不适用于对在线系统的运行时漏洞扫描——那应当使用容器扫描工具（Trivy、Grype CLI）或主机级漏洞扫描器（Nessus、Qualys）。这一点在 SKILL.md 中被明确标注为 "Do not use" 场景。

框架映射

技能 frontmatter 将该工作流映射到多个行业框架，便于在统一框架下检索与引用：

仓库的 mappings/mitre-attack/coverage-summary.md 将 T1195 列为 Supply Chain Compromise 父技术，与analyzing-supply-chain-malware-artifacts、devsecops 依赖扫描等技能共同构成覆盖。

前置条件

• SBOM 文件：CycloneDX JSON（v1.4+）或 SPDX JSON（v2.3+）格式；
• Python 3.9+：安装requests、networkx、packaging三个库；
• NVD API Key（免费，可选）：在 NVD 官网申请以获得更高速率限制；
• 网络访问：能够访问 NVD API（https://services.nvd.nist.gov/rest/json/cves/2.0）；
• 可选工具：syft用于生成 SBOM，grype用于交叉验证。

七步工作流（核心章节）

Step 1：生成 SBOM（若未提供）

使用 Anchore 的syft从容器镜像或项目目录生成 SBOM：

# 从容器镜像生成 CycloneDX JSON syft alpine:latest -o cyclonedx-json > sbom-cyclonedx.json # 从项目目录生成 SPDX JSON syft dir:/path/to/project -o spdx-json > sbom-spdx.json # 从运行中的容器生成 syft docker:my-app-container -o cyclonedx-json > sbom.json

syft 支持 30+ 包生态（npm、PyPI、Maven、Go modules、apt、apk、RPM 等），生成的 SBOM 包含包名、版本、许可证、CPE 标识符和 PURL（Package URL）引用。

syft 支持的输出格式（参考 references/api-reference.md）：

syft 的 source 参数支持三种输入类型：容器镜像（alpine:latest）、目录（dir:/app）、文件归档（file:archive.tar.gz）。

Step 2：解析 SBOM 并提取组件

SKILL.md 给出了两种格式的核心 JSON 结构。CycloneDX使用components数组承载组件、dependencies数组承载依赖关系：

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

SPDX使用packages数组和relationships数组，许可证信息更丰富（licenseConcluded/licenseDeclared）：

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

源码级解析逻辑：格式自动识别与字段抽取

本技能自带可执行分析器 scripts/agent.py，其解析逻辑可作为两种格式差异的权威参考：

• 格式自动识别：detect_sbom_format()按优先级检查bomFormat == "CycloneDX"、是否含spdxVersion键、components中是否有purl字段、是否存在packages键，返回cyclonedx/spdx/unknown三种结果，未知格式直接抛出ValueError；
• CPE 多位置提取：parse_cyclonedx()除了读取顶层cpe字段，还会遍历properties中的syft:cpe23等键名含 "cpe" 的属性作为兜底——这正是 syft 生成 SBOM 时 CPE 的实际存放位置；
• SPDX ID 到 PURL 的映射：parse_spdx()先为每个包建立SPDXID -> purl映射，随后将relationships中DEPENDS_ON类型的边解析为依赖关系，父/子引用会统一归一化为 PURL 或name@version形式。

Step 3：组件与 NVD CVE 数据库关联

使用 NVD 2.0 API 查询每个组件的已知漏洞，SKILL.md 提供了两个核心查询函数：

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 Key 时 5 次请求/30 秒，携带 Key 时 50 次请求/30 秒。

NVD 2.0 API 速查

参考 references/api-reference.md 的详细说明：

• Base URL：https://services.nvd.nist.gov/rest/json/cves/2.0
• 认证：请求头apiKey: <your-api-key>
• 按 CPE 搜索：GET /rest/json/cves/2.0?cpeName=cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*
• 按关键词搜索：GET /rest/json/cves/2.0?keywordSearch=lodash+prototype+pollution
• 按 CVE ID 搜索：GET /rest/json/cves/2.0?cveId=CVE-2021-44228
• 响应结构：vulnerabilities[]数组中每个条目含cve.id、published、descriptions（按lang区分语言的描述）、metrics.cvssMetricV31[0].cvssData（含baseScore与baseSeverity）、references等字段

agent.py中extract_cve_info()的字段解析顺序值得注意：CVSS 评分按cvssMetricV31 → cvssMetricV30 → cvssMetricV2的优先级降级取用；严重级别按SEVERITY_THRESHOLDS（CRITICAL≥9.0、HIGH≥7.0、MEDIUM≥4.0、LOW≥0.1）判定；并会扫描references中是否出现cisa.gov域名以标记CISA KEV（已知被利用漏洞）状态。correlate_cves()对每个组件优先按 CPE 精确查询，无结果时回退为组件名+版本号的关键词搜索；无 API Key 时请求间隔为 6.0 秒，携带 Key 时为 0.6 秒，命中 403 还会自动退避重试。

Step 4：构建依赖图，识别传递性风险

用networkx将有向图组织依赖关系，追踪漏洞传播路径：

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 层深的传递性依赖漏洞同样构成风险，但修复成本往往更高。

风险评估的关键图指标（SKILL.md 定义）：

• 入度（In-degree）：有多少组件依赖该组件（入度高 = 爆炸半径大）；
• 到根节点的最短路径：距离应用入口的距离（越近越可被利用）；
• 介数中心性（Betweenness centrality）：位于多条依赖路径上的组件（瓶颈风险）。

agent.py的analyze_dependency_graph()提供了更完整的图分析实现：统计节点/边数量、判定是否为有向无环图（is_directed_acyclic_graph）、提取入度 Top 10 的"被依赖最多"组件、计算dag_longest_path得到最深依赖链长度、标记"高 CVSS + 入度>0"的高风险枢纽组件，并通过betweenness_centrality输出 Top 5 瓶颈组件。此外 references/api-reference.md 补充了三个实用 API：nx.all_simple_paths(G, "app", "vulnerable-lib")枚举到脆弱组件的全部路径、nx.betweenness_centrality(G)计算瓶颈、nx.dag_longest_path(G)求最长依赖链。

Step 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

核心思想是：组件风险取该组件所有 CVE 的最高 CVSS 分，再乘以上依赖因子（1.0 + 0.1×入度），被更多组件依赖的脆弱组件会产生更高的组织级影响。agent.py中correlate_cves()对每个组件计算max_cvss并据此分配CRITICAL/HIGH/MEDIUM/LOW风险等级，是这套公式的落地实现。

Step 6：使用 Grype 交叉验证

用 grype 独立扫描 SBOM 并比对结果，降低单一数据源的漏报风险：

# 扫描 CycloneDX SBOM grype sbom:sbom-cyclonedx.json -o json > grype-results.json # 扫描 SPDX SBOM grype sbom:sbom-spdx.json -o table # 仅显示有修复方案的漏洞，并以 critical 为失败门限 grype sbom:sbom-cyclonedx.json --only-fixed --fail-on critical

grype 的漏洞数据源覆盖 NVD、GitHub Security Advisories（GHSA）、Alpine SecDB、Red Hat、Debian、Ubuntu、Amazon Linux、Oracle、Wolfi SecDB 等多个数据库，覆盖面比仅用 NVD 更广（references/api-reference.md 列出了完整数据源清单）。--only-fixed过滤出已有修复版本可用的漏洞，--fail-on可用于 CI 门禁判断。

Step 7：生成合规报告

产出适合监管合规的结构化报告，SKILL.md 给出了报告模板的核心结构：

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. lodash@4.17.20 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. log4j-core@2.14.1 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: core-util@1.2.3 (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

报告包含四大部分：漏洞汇总（按严重级别统计组件数与 CVE 数）、高危发现明细（列出 CVE、CVSS、依赖者数量与修复建议，CISA KEV 标记）、依赖图风险（被依赖最多组件、最深依赖链、瓶颈组件）以及License 合规（copyleft 许可证检查，用于商业分发评估）。

CLI 实战：一键运行完整分析

agent.py提供了四个子命令（references/api-reference.md 中的 CLI 用法）：

# 完整 SBOM 分析（NVD 关联 + 依赖图 + 风险评分 + 报告） python agent.py analyze sbom-cyclonedx.json --api-key YOUR_KEY -o report.json # 离线分析（跳过 NVD 查询） python agent.py analyze sbom.json --skip-nvd -o report.json # 对比两个 SBOM 的组件增删与版本变化 python agent.py diff old-sbom.json new-sbom.json # 仅解析并列组件 python agent.py parse sbom.json -o components.json # 检查许可证合规 python agent.py licenses sbom.json

--api-key也可以通过环境变量NVD_API_KEY提供（main()中的回退逻辑）。diff子命令输出 Added/Removed/Version Changes 三类变更，可用来追踪两次发布之间的供应链漂移；licenses子命令调用check_license_compliance()，其 copyleft 许可证集覆盖 GPL-2.0/3.0、AGPL-3.0、LGPL-2.1/3.0、MPL-2.0、EUPL-1.2、CPAL-1.0、OSL-3.0 等，并统计未声明许可证（NOASSERTION）的组件——这些正是商业分发与开源合规审计的常见问题点。

关键概念速查

工具与系统

• 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 查询与速率限制管理。用法示例（references/api-reference.md）：

import nvdlib # 按 CPE 搜索 CVE results = nvdlib.searchCVE(cpeName="cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*") for cve in results: print(f"{cve.id}: CVSS {cve.score[1]}") # 按关键词搜索 results = nvdlib.searchCVE(keywordSearch="lodash prototype pollution")

• OWASP Dependency-Track：面向持续 SBOM 分析、漏洞追踪与策略执行的平台。

实战场景：Log4Shell 披露后的供应商软件评估

背景：CVE-2021-44228（Log4Shell）披露后，安全团队需要判定哪些供应商交付的应用包含存在漏洞的 log4j 版本。多家供应商已按合同要求提供了 SBOM。

执行路径（SKILL.md 定义的 7 步）：

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 可能不完整：遗漏了内嵌/打包（shaded/bundled）的 JAR 文件，而这些 JAR 里可能嵌着 log4j；
• 格式版本差异：SPDX 与 CycloneDX 的版本差异可能影响解析器兼容性；
• NVD API 速率限制：无 API Key 扫描数百个组件时，分析会被明显拖慢；
• CPE 名称不精确匹配：SBOM 中的 CPE 与 NVD 条目可能不完全一致，需要模糊匹配；
• 传递性依赖：即使 log4j 不是直接依赖，也可能经由依赖链被引入。

技能目录结构参考

本技能遵循仓库统一的技能目录规范（见 README.md 的 Skill anatomy 章节）：

skills/analyzing-sbom-for-supply-chain-vulnerabilities/ ├── SKILL.md ← 技能定义（YAML frontmatter + Markdown 主体） ├── references/ │ └── api-reference.md ← NVD API、格式规范、CLI 用法深度参考 ├── scripts/ │ └── agent.py ← 可执行的 SBOM 分析代理（parse/analyze/diff/licenses） └── LICENSE

其中 SKILL.md 是可被 AI Agent 逐步执行的决策型工作流，references/api-reference.md 提供 NVD 2.0 API、两种 SBOM 格式与 syft/grype/nvdlib 的深度参考，scripts/agent.py 则把上述全部工作流固化为可直接运行的 Python CLI——三者构成"快速决策 + 深度参考 + 可执行代码"的完整技能形态，这也是本仓库所有技能的统一架构模式。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills