Anthropic Cybersecurity Skills 实战基于 SBOM 的供应链漏洞分析CycloneDX/SPDX NVD CVE 关联【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 将该工作流映射到多个行业框架便于在统一框架下检索与引用框架映射 IDMITRE ATTCKT1195.001篡改开发工具、T1195.002篡改开发环境/供应链、T1554编译后组件篡改、T1190面向公网应用利用NIST CSF 2.0GV.SC-01、GV.SC-03、GV.SC-06、GV.SC-07供应链风险治理NIST AI RMFGOVERN-5.2、MAP-1.6、MANAGE-2.2、GOVERN-1.1、GOVERN-4.2MITRE ATLASAML.T0010供应链投毒仓库的 mappings/mitre-attack/coverage-summary.md 将 T1195 列为 Supply Chain Compromise 父技术与analyzing-supply-chain-malware-artifacts、devsecops 依赖扫描等技能共同构成覆盖。前置条件SBOM 文件CycloneDX JSONv1.4或 SPDX JSONv2.3格式Python 3.9安装requests、networkx、packaging三个库NVD API Key免费可选在 NVD 官网申请以获得更高速率限制网络访问能够访问 NVD APIhttps://services.nvd.nist.gov/rest/json/cves/2.0可选工具syft用于生成 SBOMgrype用于交叉验证。七步工作流核心章节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.jsonsyft 支持 30 包生态npm、PyPI、Maven、Go modules、apt、apk、RPM 等生成的 SBOM 包含包名、版本、许可证、CPE 标识符和 PURLPackage URL引用。syft 支持的输出格式参考 references/api-reference.md格式命令CycloneDX JSONsyft source -o cyclonedx-jsonCycloneDX XMLsyft source -o cyclonedx-xmlSPDX JSONsyft source -o spdx-jsonSPDX Tag-Valuesyft source -o spdx-tag-valuesyft 原生 JSONsyft source -o json默认表格syft source -o tablesyft 的 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/lodash4.17.20, cpe: cpe:2.3:a:lodash:lodash:4.17.20:*:*:*:*:*:*:*, licenses: [{license: {id: MIT}}] } ], dependencies: [ {ref: pkg:npm/express4.18.2, dependsOn: [pkg:npm/lodash4.17.20]} ] }SPDX使用packages数组和relationships数组许可证信息更丰富licenseConcluded/licenseDeclared{ spdxVersion: SPDX-2.3, packages: [ { name: lodash, versionInfo: 4.17.20, externalRefs: [ {referenceType: purl, referenceLocator: pkg:npm/lodash4.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三种结果未知格式直接抛出ValueErrorCPE 多位置提取parse_cyclonedx()除了读取顶层cpe字段还会遍历properties中的syft:cpe23等键名含 cpe 的属性作为兜底——这正是 syft 生成 SBOM 时 CPE 的实际存放位置SPDX ID 到 PURL 的映射parse_spdx()先为每个包建立SPDXID - purl映射随后将relationships中DEPENDS_ON类型的边解析为依赖关系父/子引用会统一归一化为 PURL 或nameversion形式。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_keyNone): params {cpeName: cpe_name, resultsPerPage: 50} headers {apiKey: api_key} if api_key else {} resp requests.get(NVD_API, paramsparams, headersheaders, timeout30) resp.raise_for_status() return resp.json().get(vulnerabilities, []) def search_cves_by_keyword(keyword, versionNone, api_keyNone): params {keywordSearch: keyword, resultsPerPage: 50} headers {apiKey: api_key} if api_key else {} resp requests.get(NVD_API, paramsparams, headersheaders, timeout30) 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 URLhttps://services.nvd.nist.gov/rest/json/cves/2.0认证请求头apiKey: your-api-key按 CPE 搜索GET /rest/json/cves/2.0?cpeNamecpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*按关键词搜索GET /rest/json/cves/2.0?keywordSearchlodashprototypepollution按 CVE ID 搜索GET /rest/json/cves/2.0?cveIdCVE-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_THRESHOLDSCRITICAL≥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], namecomp[name], versioncomp[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 补充了三个实用 APInx.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 criticalgrype 的漏洞数据源覆盖 NVD、GitHub Security AdvisoriesGHSA、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. lodash4.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-core2.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-util1.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的组件——这些正是商业分发与开源合规审计的常见问题点。关键概念速查术语定义SBOM软件物料清单软件产品中所有组件、库和依赖的正式清单CycloneDXOWASP 维护的 SBOM 标准支持 JSON/XML/protobuf 格式含依赖图与漏洞数据SPDXLinux Foundation 的 SBOM 标准侧重许可证合规支持包/文件/片段级细节PURL包统一资源定位符跨生态标识软件包的标准方案如pkg:npm/lodash4.17.21CPE通用平台枚举NIST 用于 IT 产品命名的方案用于与 NVD CVE 数据关联NVD美国国家漏洞数据库按 CVE 标识符索引的漏洞数据仓库Transitive Dependency未被直接声明、但经由直接依赖的依赖链被引入的依赖CISA KEVCISA 已知被利用漏洞目录确认在野外被积极利用的 CVE工具与系统syftAnchore开源 SBOM 生成器支持 30 包生态输出 CycloneDX/SPDX 格式grypeAnchore接受 SBOM 作为输入的漏洞扫描器关联多个公告数据库cyclonedx-python-lib用于编程方式创建、解析和验证 CycloneDX SBOM 的 Python 库lib4sbom可同时解析 SPDX 和 CycloneDX 格式 SBOM 的 Python 库nvdlibNVD 2.0 API 的 Python 封装支持 CVE/CPE 查询与速率限制管理。用法示例references/api-reference.mdimport nvdlib # 按 CPE 搜索 CVE results nvdlib.searchCVE(cpeNamecpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*) for cve in results: print(f{cve.id}: CVSS {cve.score[1]}) # 按关键词搜索 results nvdlib.searchCVE(keywordSearchlodash prototype pollution)OWASP Dependency-Track面向持续 SBOM 分析、漏洞追踪与策略执行的平台。实战场景Log4Shell 披露后的供应商软件评估背景CVE-2021-44228Log4Shell披露后安全团队需要判定哪些供应商交付的应用包含存在漏洞的 log4j 版本。多家供应商已按合同要求提供了 SBOM。执行路径SKILL.md 定义的 7 步收集所有供应商 SBOMCycloneDX 或 SPDX JSON 格式逐一解析 SBOM搜索版本 2.17.1 的 log4j-core 组件向 NVD API 查询具体 CVECVE-2021-44228、CVE-2021-45046、CVE-2021-45105构建依赖图识别哪些应用组件依赖 log4j计算爆炸半径暴露的服务与端点有多少按暴露程度与业务关键性排序生成优先级修复报告使用 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 ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考