聚焦源代码安全，网罗国内外最新资讯！

编译：代码卫士

专栏·供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

美国总统在2021年5月份发布第14028号行政令，要求美国商务部在60天内协同美国国家通信和信息管理局 (NTIA) 发布软件物料清单 (SBOM) 的“最小元素”。如下是对美国商务部所发布报告的编译（中）。

自动化支持

自动化支持（包括自动化生成和机器可读性）可使SBOM的能力扩展至软件生态系统，尤其是组织边界。使用SBOM数据要求具有工具，它是可预测实现和数据格式所必需的。例如，某些机构可能希望将该能力集成到现有的漏洞管理实践中；有些机构可能要求实时审计安全策略的合规性。自动化是这两者的关键点，因此也要求具有常见的、机器可读的数据格式。

虽然单一标准意味着简约有效，但生态系统中存在多种数据格式而且它们被用于生成并使用SBOM。通过开放流程和国际力量，已形成这样一些数据格式细则。除了机器可读外，这些数据格式也是人类可读的，能更好地支持故障排除和创新。更重要的是，这些标准对于核心数据字段而言具有互操作性，而且使用常见的数据句法表示。

用于生成并使用 SBOMs 的数据格式为：

• 软件包数据交换（Software Package Data eXchange (SPDX)）

• CycloneDX

• 软件识别 (Software Identification (SWID)) 标记

SBOM 必须以其中一种可互操作格式在组织边界中传达。如果出现新的可与其它数据格式兼容的标准细则，那么就应当在SBOM最小元素上下文，把这些标准细则归到自动化支持中。同样，如果广泛认为某种数据格式不再交叉兼容，或者不再得到主动维护并支持SBOM用例，那么就应当将这种数据格式从SBOM最小元素自动化要求中删除。使用专有数据格式的标准也不应当包含在内。这样就能实现基于现有工具实现易于采用、支持未来演变以及可扩展性的要求。

实践和流程

SBOM 不止结构性数据集；将其集成到安全开发生命周期中，组织机构应当遵循某些专注于SBOM使用机制的实践和流程。在任何要求提供或提供 SBOMs 的策略、合同或约定中，都应当明确提出多个元素。其中某些元素（如频率）的要求很直接；在一些情况下（如访问），存在多种实践且正在开发更多实践，因此某些约定具有最小元素要求。

频率。如果软件组件以新版本或发布的形式更新，那么必须创建新的 SBOM 来体现该软件的新版本。其中包括集成已更新组件或依赖的软件版本。同样，如果供应商获悉关于底层组件的新详情，或者希望修正已有SBOM数据中的错误，那么供应商应当发布新的经过修订的SBOM。

深度。SBOM 应当包含所有主要（顶层）组件，并列出其中包括的所有传递依赖。至少，必须列出所有顶层依赖的足够多的详情，以便以递归的方式查找传递依赖。

随着组织机构开始建立SBOM，由于子组件供应商的现有要求，可能无法轻易获取除主要组件以外的深度。对SBOM流程的最终采用将能够在子组件层面通过更深的透明度层级进行更深度的访问。应当注意的是，某些用例要求完整的或基本完整的表。如 “举反证“，证明某既定组件不存在于某机构网络中。

SBOM 消费者可通过传递步骤的数量来指定深度要求。或者也可通过运营术语的方式指定深度要求。可以包括软件属性，如“所有非开源软件“，或者某个功能的所有组件或者复杂程度。组织机构还可以向那些提供并缓解SBOM所列组件中漏洞的一方做出不同要求，鼓励报告深度和完整性。这类标准细则不在最小元素范围内。

已知的未知。对于在SBOM 中未列举出完整依赖表的实例，SBOM 作者必须明确识别出“已知的未知“。即，依赖数据清晰地区分出不含其它依赖的组件和所含依赖不明及不完整的组件。该数据必须集成到自动化数据中。为了避免错误假设，数据的默认解释应为：数据是不完整的；SBOM 数据的作者应当肯定地说明何时已完全枚举组件的直接依赖，或何时组件不含其它依赖。当前，这一信息在依赖关系数据字段中实现。

分发和交付。应当及时地向所需方提供SBOMs，而且必须设置恰当的访问权限和角色。SBOM数据可搭配每个软件实例，或者只能访问并直接映射到所指软件的某个特定版本（例如，通过特定版本的URL）。在软件供应链中共享 SBOM 数据可分为两个部分：如何获悉SBOM的存在和可用性（广告或发现），以及SBOM是如何被具有适当权限（访问）的人员检索或传递给他们。和软件保证的其它领域一样，并不存在一劳永逸的方法。虽然提供SBOM的任何人必须以某种方式提供SBOM并提供理解支持，但可根据现有机制确定。SBOM 交付也可反映软件的性质：位于端点上的可执行文件可通过编译代码的方式将SBOM数据存储在磁盘上，而嵌入式系统或在线服务则拥有在线存储的SBOM数据的指针。

访问控制。很多供应商，包括开源维护人员和广泛可获得软件的供应商，可能认为将SBOM数据公开最符合自身利益。不过其它一些组织机构，尤其刚开始，可能希望SBOM 数据保密且只有特定的客户或用户才能访问。如果需要访问控制，则必须指定相关术语，包括将SBOM数据集成到用户安全工具中的费用和空间。这类标准细则可通过许可、合约或其它现有机制来约束软件本身的使用和权益。鉴于软件许可和合约不尽相同，该标准细则的性质不在本文档讨论范围内。

容错空间。最后的实践是容错空间，它应当内置于SBOM的初始实现阶段，允许遗漏和错误。如很多评论人员注意到的那样，虽然内部管理供应链数据可能是一种最佳实践，但它仍在发展过程中。拜登政府将SBOM列为推动软件保证和供应链风险管理的优先任务，因此马上就做比等待完美更好。鉴于还不完美，因此SBOM客户应当明确容忍偶然的无心之过。这样做有助于不断改进工具：供应商发现之前SBOM中的问题时应当提供更新版数据，客户应当接受好意的附件和修订而不是实施处罚，以此鼓励SBOM数据更新。如之前在“频率”部分提到的那样，当获悉新数据时，应当发布更新版SBOM数据。值得注意的是，有意混淆或无知不应得到容忍。

（未完待续）

推荐阅读

在线阅读版：《2021中国软件供应链安全分析报告》全文

SolarWinds 攻击者再次发动供应链攻击

美国“加强软件供应链安全实践的指南” (SSDF V1.1草案) 解读来了

软件供应链安全现状分析与对策建议

“木马源”攻击影响多数编程语言的编译器，将在软件供应链攻击中发挥巨大作用

GitHub 在 “tar” 和 npm CLI 中发现7个高危的代码执行漏洞

流行的 NPM 包依赖关系中存在远程代码执行缺陷

速修复！热门npm 库 netmask 被曝严重的软件供应链漏洞，已存在9年

Npm 恶意包试图窃取 Discord 敏感信息和浏览器文件

微软“照片”应用Raw 格式图像编码器漏洞 (CVE-2021-24091)的技术分析

速修复！热门npm 库 netmask 被曝严重的软件供应链漏洞，已存在9年

SolarWinds 供应链事件后，美国考虑实施软件安全评级和标准机制

找到软件供应链的薄弱链条

GitHub谈软件供应链安全及其重要性

揭秘新的供应链攻击：一研究员靠它成功入侵微软、苹果等 35 家科技公司

开源软件漏洞安全风险分析

开源OS FreeBSD 中 ftpd chroot 本地提权漏洞 (CVE-2020-7468) 的技术分析

集结30+漏洞 exploit，Gitpaste-12 蠕虫影响 Linux 和开源组件等

限时赠书|《软件供应链安全—源代码缺陷实例剖析》新书上市

热门开源CI/CD解决方案 GoCD 中曝极严重漏洞，可被用于接管服务器并执行任意代码

GitKraken漏洞可用于盗取源代码，四大代码托管平台撤销SSH密钥

因服务器配置不当，热门直播平台 Twitch 的125GB 数据和源代码被泄露

彪马PUMA源代码被盗，称客户数据不受影响

原文链接

https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf

题图：Pixabay License

本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

 觉得不错，就点个 “在看” 或 "赞” 吧~