来吧，友好的 SBOM

利用软件物料清单为你保驾护航

Alice Sowerby

我本想给本文起名《我如何学会停止担忧并爱上 SBOM》（How I learned to stop worrying and love the SBOM），却发现这个美式俏皮话已在该话题上被广泛使用。于是我改用一个更具英伦风味的备选标题，灵感来自约翰·贝杰曼爵士（Sir John Betjeman）脍炙人口的诗作《斯劳》（Slough），其首句为 “来吧，友好的炸弹，落在斯劳！”。该诗于 1937 年出版，痛惜一战以后伦敦附近一座英国小镇的工业化。

诗中呼唤炸弹摧毁这座小镇，因为在贝杰曼看来，它已败落不堪、无可救药。我希望能借喻一种更乐观的愿景——邀请友好的 SBOM（软件物料清单，Software Bill of Materials）落在代码之上。不是要摧毁代码——我们手头这份伟大的代码遗产有太多值得珍视和守护之处（推倒重来恐怕不可能）——而是要支持它、改进它，让它为全世界所用时更安全。

我们先从 SBOM 所处的监管与文化背景谈起。我会聊聊我们是如何走到这一步的、为什么安全愈发重要、SBOM 如何发挥作用，然后深入分享 FreeBSD 在这方面的工作。

我们故事的切入点是欧盟出台的一项软件安全法规，名为 《网络弹性法案》（CRA）。听起来或许不那么激动人心，但它对软件供应商影响深远，将重塑整个软件行业（包括开源）的格局。

CRA 规定，凡是将 “含数字元素的产品” 投放欧盟市场的主体，都要对这些产品的安全负责。实际操作上，这意味着制造商必须以安全方式设计产品，留存相关证据，并在欧洲市场监督机构要求时提供这些证据。制造商还必须以尽可能安全的状态向消费者交付产品，一旦产品出现被实际利用的漏洞或安全事件，必须遵守严格的报告和补救时限。

报告要求自 2026 年 9 月 11 日起强制合规，“安全设计”（secure by design）和 “安全默认”（secure by default）要求自 2027 年 12 月 11 日起强制合规。

违规罚款数额相当惊人。最高一档罚款针对违反核心要求的情况，金额为 1500 万欧元或全球年营业总额的 2.5%，取两者中较高者。

我们来看看这件事为何现在如此重要，又为何与不起眼的开源开发者扯上了关系。

好消息是，开源项目终于有了监管层面的支持，要求下游制造商负责任地构建和维护软件。该法规强制使用 SBOM，要求制造商对其代码库中每个组件（无论自研还是来自第三方）的安全状况进行尽职调查。

欧盟网络安全局（ENISA） 也在制定关于何谓 “安全设计” 和 “安全默认” 的指南，而市场监督机构负责评估制造商的合规情况。

如果你正感到不祥的预感，担心这最终会落到我们这些小角色头上，那还是有理由抱有希望的。多亏过去几年开源社区出色的协作，欧盟委员会（EC） 对开源软件开发的本性及其在软件行业中的角色有了更深入的认识和理解。在 CRA 制定过程中，开源社区的若干个人和组织与 EC 持续沟通。CRA 现已包含针对开源软件的专门豁免和保护条款。甚至还有一些为开源项目创收的机会。具体而言，目前有一项 “自愿安全认证”（voluntary security attestations）框架的提案。若按当前设想落地（细节仍在制定中），该框架将允许开源项目就安全认证向制造商收费。

开源项目及其开发者不受 CRA 约束，开源基金会虽可能承担部分报告义务，但不会因违规而被罚款。

监管负担与相应的处罚——也就是大棒——主要瞄准商业制造商。

这些工作最重要的成果，或许是 EC 如今在机构层面认识到开源的价值，并投入维护其在欧洲科技创新与技术主权中的角色。随着 EC 继续完善 CRA 指南，推进诸如自愿安全认证等举措，我们可以确信，他们将开源视为一等利益相关方。

注：你可能还记得美国曾发布过类似的指令：2021 年 5 月 12 日第 14028 号美国行政令《改进国家网络安全》（2021）。该行政令后于 2026 年 1 月 29 日部分撤回，相关规范转为可选项。

从某种角度看，软件安全竟花了这么久才迎来这种方式的监管，着实令人意外。要弄清原因，我们不妨简短回顾一下历史（建议手边备一杯热饮？）。

20 世纪中叶，约莫我祖父在 English Electric Computers 造计算机那会儿，计算机还是个小众领域。计算机昂贵、稀缺，通常由政府、大学和大公司等可信机构运行，安全靠物理隔离和限制已知用户访问来实现。让这些系统正常运转起来、保证可靠性和性能，远比防御恶意行为者更迫在眉睫。

20 世纪后期，随着个人计算日益普及，我父亲刚入行做软件工程师时，业界主流是构建网络、开发开放且可互操作的协议，而非安全的协议，往往假设参与者是可信的。连接性和采用率被视为主要挑战。与此同时，商业软件开发也激励着不断交付新功能——客户容易评估这些功能并为之付费，而安全薄弱的代价直到出事之前都难以衡量。

到了互联网时代，我开始在软件安全公司 Sophos 工作时，普通大众开始上网。随着首批著名恶意软件攻击事件登上头条，公众对 “病毒” 的认识大幅提升。安全常常被当作一门单独的学科，通过防病毒软件、防火墙、安全设备和渗透测试等多层防护来应对，而非在软件设计之初就纳入考量。

2010 年代带来了云计算和移动计算，以及由 DevOps 支撑的持续交付模式。既有的 “外挂式” 安全做法已不适应持续部署的时代——软件一天可更新多次，并即时部署到联网环境中。靠定期渗透测试来保障安全已不再合适，DevSecOps 正是对这一挑战的回应，也是催生 DevOps 的 “左移” 原则的自然延伸。

如今，软件安全已超越代码缺陷的范畴，涵盖供应链、开源依赖、云基础设施、身份管理以及 AI 驱动的系统。多起高调事件表明，复杂生态系统中的任何环节都可能出现漏洞。

可以看到，软件安全实践随着软件构建与使用方式的变化而演进。然而它常常是滞后的话题，因为驱动软件开发的激励——功能、易用性、连接性和交付速度——往往被置于应对相关安全风险之上。再加上恶意行为者的创造力和相反的动机，许多教训只能用惨痛的方式习得。

近年来，全球各国政府日益聚焦于软件安全监管。政府所用的软件、作为关键行业基础设施的软件、嵌入消费产品的软件，其安全已成为国家安全的关键——民族国家行为者和其他恶意组织已注意到并企图利用软件无处不在所带来的机会。国家及其所代表个体的安全，都依赖于社会各层所用软件的安全。

前文提到，CRA 要求制造商采用 “安全设计” 的做法。此外，还明确要求他们采用一种称作软件物料清单（SBOM）的产物。

SBOM 是代码库中每个第三方组件的清单。清单包含元数据，如包名、许可证和版本号。该清单以机器可读文件提供，支持工具交叉检查已报告的可利用漏洞、未打补丁的包以及许可证冲突。

SBOM 出现已有一段时间，如今正逐步走向标准化和广泛采用，相关工具也在成熟。

SBOM 正成为围绕软件代码库和软件供应链管理的诸多元活动的基础。掌握软件中所有组件的关键元数据，你就能做很多事——比如将自己持有的包版本号与已知的最新包进行比对，检查代码库中是否有未打补丁的依赖。你还可以将 SBOM 与已知漏洞列表比对，从而快速判断产品是否会受其影响。

SBOM 最初也旨在支持许可证管理，也就是弄清你是否可以按预期方式使用开源组件。即便你主要是出于安全原因需要 SBOM，它在这方面依然有用。

可以想见，SBOM 可包含递归元素，让你能看透供应链的多个层级。这对理解和管理产品风险水平至关重要。

学习并掌握 SBOM 的使用，对任何开发者来说不仅是一项有市场价值的技能，也是提升安全意识、培养更安全开发实践的好途径。

对开源项目而言，提供 SBOM 并非必需，因为下游制造商可以用第三方工具扫描代码，从而生成 SBOM。

不过，这种方式并不算理想。如此生成的 SBOM 可能存在多种不准确之处，尤其因为它对构建环境一无所知。

因此，尽管开源项目并不一定要在其项目中提供 SBOM 或 SBOM 工具，但若能提供，对各方都大有裨益。对下游用户而言，这意味着可以按需生成准确的 SBOM；对项目自身而言，践行 SBOM 思维与实践将提升项目的整体安全。开源项目自行创建 SBOM 后，便能主动做些 “内务整理”，比如给依赖打补丁、修复可利用的漏洞。

拥有一份自己的 SBOM

看来我们在这篇文章里可以全程引用文学作品。这次的典故出自英国作家弗吉尼亚·伍尔夫的长篇随笔《一间自己的房间》（A Room of One’s Own）。她在书中写道：“女人如果要写小说，就必须有钱和一间自己的房间”，借此点出经济独立在为艺术创作创造条件方面所起的作用。

我们或许能注意到，开源项目同样需要资源才能创建属于自己的 SBOM——这类工作惠及众人，却难以找到商业赞助或志愿贡献者来着手。

所幸，过去几年间 FreeBSD 基金会已争取到若干投资来源，用于支持 FreeBSD 的若干 SBOM 相关项目。

了解 FreeBSD 的依赖

2025-26 年间，基金会运作了名为 “海滩清理”（Beach Cleaning）的项目，由 Alpha Omega 项目（隶属 OpenSSF）赞助。该项目旨在提升我们对 FreeBSD 开源依赖及其相关风险的认识。FreeBSD 基本系统中的各组件经过人工风险分析，并制定了与上游项目协作以缓解这些风险的行动计划。

我们基于这些数据和其他组件元数据，构建了一个数据库，整理各组件的维护者和依赖信息，还包含安全审查注释以及在发现风险时降低风险的计划。创建 SBOM 所需的数据正好与数据库中收录的内容相吻合。

我们还开发了工具，可按需生成关于基本系统组件的报告。每种报告类型聚焦组件群体中某一特定信息领域，便于纵览 FreeBSD 依赖的全貌、风险分析结果以及缓解计划的当前进展。该工具还能按 GitHub 要求的标准生成 CODEOWNERS 文件。这套工具现已可长期使用，帮助维护者更轻松地持续管理 FreeBSD 依赖中的风险。

SBOM 基础

基金会管理的另一个项目，是德国政府 主权技术机构（STA） 出资委托 FreeBSD 开发 SBOM 基础能力。STA 关注 “改进和维护支撑软件创建的基础数字技术”，以此作为通向国家数字主权的路径，确保开源方案足以替代国际供应商的商业产品。

该项目由 FreeBSD 关键利益相关方提出，旨在探索为 FreeBSD 生成 SBOM 的可选方案，提出解决方案，并在可用时间内尽可能落实。

注：该项目由 STA 委托，原定于 2025 年 4 月至 12 月执行。基金会后续追加资助，将项目延期至 2026 年 10 月底。

SBOM 解决方案的需求如下：

• SBOM 必须采用被广泛使用且可持续的格式。

• SBOM 必须基于源代码，而非编译后的二进制文件。

• 必须能够按需为正在构建的镜像生成 SBOM。

• FreeBSD 官方发布的二进制镜像必须随附 SBOM。

• 解决方案必须有完善文档，便于社区使用。

项目自 2025 年 4 月启动，首先评估了现有的 SBOM 标准。最受欢迎的两种开源方案是 CycloneDX 和 SPDX。我们最终选择 SPDX，理由在于其流行度、ISO 标准地位以及工具生态。SPDX 在许可证信息处理上也更细致，这对 FreeBSD 这样的开源项目很有利——尽管项目偏好 2 条款 BSD 许可证，但源代码树中包含多种不同许可证下的代码。为提升 SBOM 解决方案的实用性和兼容性，我们还探索了未来将 CycloneDX 格式作为辅助输出予以支持的方式，让终端用户可自行选择使用哪种格式。

随后，我们着手建立一套可行的方案，为 FreeBSD 基本系统创建 SBOM。

我们来看看 SBOM 里都有什么。SBOM 是一种数据文件，包含代码库中每个包的关键元数据。

SBOM 包含一份包摘要清单，内容包括：

• Name：提供包的人类可读名称。

• Version：包的版本。

• Requires、Conflicts：指定依赖关系，在 FreeBSD SBOM 中用于生成依赖树。（FreeBSD SBOM 解决方案目前不使用 Conflicts。）

• Copyright：应用程序的版权信息。

• License：应用程序的许可证，以对应的 SPDX 短标识符表示（如 BSD-4-Clause AND BSD-3-Clause）。许可证信息通过 scancode-toolkit 以及源文件或头文件中的 SPDX-License-Identifier 标签（若存在）收集。

• Source：获取源代码的位置。

• URL：应用程序主页。若无其他可用来源，则使用 man 手册页，尤其是非第三方应用程序。

有了这些数据，便可以实现一些有力的洞察与能力。

借助 Name 和 Version，可以通过与公开的通用漏洞披露（CVE）数据库交叉比对，判断代码库中是否存在已知漏洞。借助 Requires、Conflicts 信息，还可选择性地将这一检查扩展到依赖关系上。

License 字段意味着你可以核查自己是否在许可证条款范围内使用每个包。若你希望规避许可证限制更严格的组件，这就是关键信息。Copyright 字段则支持许多许可证都有的要求——保留版权声明。

URL 和 Source 字段有助于追溯包的确切来源。在可用时，我们会引用每个包的 PURL（包 URL，Package URL），因为这是一种日益被采用的格式，用于为包标识符提供可预测的 URL 结构。

所有这些信息都有助于在 FreeBSD 之上构建的任何人更深入地了解其中包含的内容，并能更彻底、更高效地管理风险、合规与安全。

下一步是为 FreeBSD 选择正确的 SBOM 构建方式。虽然现有不少优秀的工具可以检查二进制文件并生成 SBOM，但金标准是在构建时生成 SBOM。这样能提供最准确的 SBOM，因此成为我们的目标。我们必须寻找合适的工具来实现这一点。

FreeBSD 项目主要由 C 语言编写，能用于构建 SBOM 工具链的工具不如其他语言那么多。不过我们了解到 pkgconf 的新能力——这是一种可以读取和解析 pkg-config 文件（.pc 文件）的工具。它与 pkg-config 相关，但支持 .pc 文件中用于创建 SBOM 的额外标签。要让 pkgconf 担当此任，我们还需克服几个障碍。首先，pkgconf 并不在基本系统中。虽然它在 FreeBSD Ports 集合中可用，但若要在构建时于基本系统中使用，就必须将其纳入基本系统。其次，pkgconf 虽可通过 bomtool 设施输出 SPDX 2.0，但我们希望使用更新的 SPDX Lite 3.0 标准。第三，基本系统中没有任何组件具备合适的 .pc 文件。（少数第三方 contrib 软件包包含 .pc 文件，但并未集成到构建系统中。）

因此我们的任务清单是：

1. 将 pkgconf 加入基本系统；

2. 为 pkgconf 增加名为 spdxtool 的功能，输出 RDF JSON-LD 格式的 SPDX Lite 3.0.1 SBOM（并将改动提交至上游）；

3. 在基本系统中补充缺失的 .pc 文件（并将其提交至尚无该文件的第三方组件上游）；

4. 将 SBOM 生成集成到基本系统构建流程中。

截至撰稿时，第一项已完成，遵循标准的 vendor import 流程。第二项已在上游完成——新的 spdxtool 工具刚刚随 pkgconf 2.9.90 发布。第三项和第四项正在评审中——我们用 scancode-toolkit 自动审查代码库，提取许可证和版权信息，然后审查提取出的数据，对边缘案例手工修正或判定信息。接下来需要剔除数据中不必要的字段，并放入 .pc 文件中，这些文件位于 share/sbom/pkgconfig。我们用 Lua 编写了相应工具来完成这一工作。

目前 lib、bin、sbin、usr/bin 和 usr/sbin 中的软件已可提供 SBOM 信息。

等 SBOM 生成完全集成进基本系统后，便可在常规构建过程中按需创建 SBOM，比如用 make buildworld 命令。生成的文件预计会安装到 /usr/share/sbom/spdx/，扩展名为 .spdx（对应 2.2 版本），同时也会安装到 /usr/share/sbom/jsonld，扩展名为 .jsonld（对应 3.0.1 Lite 版本）。

现代化 FreeBSD 的漏洞数据格式

另一个项目是把 FreeBSD 的 Ports 和软件包漏洞数据从自有格式迁移到行业标准格式。该项目同样由 STA 委托，与 SBOM 项目并行开展。

与许多开源项目一样，FreeBSD 习惯上将漏洞数据保存在机器可读格式中——这里用的是 VuXML。VuXML 于 2005 年引入，是一种用于描述影响软件系统安全问题的文档格式。VuXML 从未在 FreeBSD 及其衍生项目之外的生态中获得采用。

随着安全形势演进，这一状况难以为继。2021 年，开源漏洞（OSV）项目应运而生。它专门为满足开源软件社区的需求而开发，采用 OpenSSF OSV 格式提供轻量、高保真的 JSON 输出，使用 git 哈希或包管理器版本来描述漏洞。

OSV 项目旨在解决开源使用者在将 CVE 条目映射到所用包版本时所面临的难题。其解决方案由一个分布式数据库和一套通用 schema 组成。没有通用标准，这项工作既耗时又易出错——而你想确认代码库中是否存在可利用漏洞时，最不希望看到的就是这种结果。

采用业界公认的格式大有裨益，它简化了外部各方获取和利用 FreeBSD 漏洞数据的方式，也让我们能借助更丰富的既有上游工具管理数据，减少自定义开发。

以标准格式提供漏洞数据，让更广泛的安全工具和服务能无缝获取这些数据，从而加速所有 FreeBSD 及衍生版用户对威胁的检测与缓解，提升 FreeBSD 生态的安全性。

经与 FreeBSD 安全团队和更广泛的 FreeBSD 社区协商，我们考虑了采用 OSV 格式的益处。我们也评估了其他标准，但因其在满足预期需求方面存在局限而未予采用。

该项目主要聚焦于建立处理新格式数据的结构。将既有数据迁移到新格式，则需通过持续采用该格式逐步完成，这一任务由 Ports 安全团队负责。

全世界都是 SBOM

“全世界都是舞台”（All the world’s a stage）这句话出自莎士比亚戏剧《皆大欢喜》（As You Like It），位于一段描述人生七阶段的独白开头。或许我们可以设想，SBOM 正处于第二阶段——“接着是哼哼唧唧的学童，背着书包 / 闪烁着晨光的脸庞，像蜗牛般 / 不情愿地向学校爬去”。显然，构建 SBOM 工具生态系统的艰辛工作仍在大力推进之中，通往精通的希望还在前方。

现在正是环顾 SBOM 工具生态的好时机。让我们看看有哪些工具能帮你搭建所需的、基于 SBOM 的流程。

要理解 SBOM 相关工具的使用方式，不妨参考美国国家电信与信息管理局制定的 SBOM 工具分类法（SBOM Tool Classification Taxonomy）。

该分类法按照工具的使用方式对 SBOM 相关工具进行分类。我从备受好评的 awesome-sbom 仓库收录的精选列表中，补充了一些示例工具。

类别	类型	描述	工具
Produce（生产）	Build（构建）	SBOM 作为构建软件制品的一部分自动生成，并包含构建相关信息。	Syft Microsoft SBOM Tool CycloneDX Maven Plugin spdx-sbom-generator cdxgen
Analyse（分析）		通过检查制品及任何相关源代码，分析源文件或二进制文件以生成 SBOM。	Syft Trivy Tern cdxgen
Edit（编辑）		辅助人员手工录入或编辑 SBOM 数据的工具。	SBOM-Manager
Consume（消费）	View（查看）	能以人类可读形式（如图片、图表、表格、文本等）理解内容。用于支持决策和业务流程。	SBOM-Manager SBOM Viewer OSS Review Toolkit Interlynk Platform —— 支持导入、管理、查询和导出 SBOM。
Diff（差异）		能够比较多个 SBOM 并清晰看出差异（例如比较某软件的两个版本）。	AIsbom CycloneDX CLI SBOMDiff
Import（导入）		能够发现、检索并将 SBOM 导入系统以便进一步处理和分析。	SBOM-Manager
Transform（转换）	Translate（翻译）	在保留相同信息的前提下，从一种文件类型转换为另一种文件类型。	CycloneDX CLI SBOM2doc SBOM2dot Interlynk SBOM Move
Merge（合并）		可将来自多个来源的 SBOM 和其他数据合并，用于分析和审计。	CycloneDX CLI OSV-Scanner sbomasm Interlynk SBOM Assembler OSS Review Toolkit
Tool support（工具支持）		通过 API、对象模型、库、传输或其他参考来源支持在其他工具中使用。	Snyk Interlynk（GraphQL API、上传/下载 SBOM API） OSS Review Toolkit（ORT） CycloneDX Microsoft SBOM Tool

本文就写到这里。希望你觉得了解 CRA、SBOM 以及如何利用它们为自己保驾护航是有趣且有用的。

你可以在 FreeBSD 基金会的 GitHub 仓库跟进基金会在为 FreeBSD 项目开发 SBOM 工具链方面的进展，那里有一个名为 “CRA Readiness” 的项目文件夹，其中包含每月的进展更新。

---

Alice Sowerby 自 2024 年中起以合约服务提供者的身份为 FreeBSD 基金会提供支持。她是一位多面手的程序经理和开源领导者，在云原生、AI/ML 和 DevOps 领域的技术岗位上有逾 15 年经验。她目前活跃于 FreeBSD 基金会、CHAOSS 和 TODO Group，专长于程序管理和战略领导。Alice 曾任 Equinix 程序总监，其他经验涵盖产品管理、UX 和开发者关系。她以协作精神和对有影响力、社区驱动倡议的投入而闻名。