近两年，软件供应链有非常多安全事件，包括软件供应链的各个阶段开发、构建、交付、使用等每个环节都有很多的软件供应链的安全事件发生。在 2023 龙蜥操作系统大会全面建设安全生态分论坛上，阿里云技术专家郑耿、周彭晨分享了龙蜥社区在构建 SBOM 基础能力方面所做的努力，也深入探讨了龙蜥社区在建立健全 SBOM 能力所必须开展的相关工作，并基于软件供应链各个阶段出现的签名服务短板，提出了专门服务于软件供应链的统一签名服务。以下为分享原文：
***01 ***软件物料清单（SBOM）
提到 SBOM 就不得不提一下软件供应链的概念，上图是引用 CNCF 软件供应链白皮书。软件供应链和传统供应链是一个非常好的类比，如从原件的生产到工厂的制造，运输到用户侧，商店销售，触达到终端用户。从软件的维度，软件源码的引入、开发、构建，通过网络发布到最终的制品仓，触达下游用户的整个流程，即为软件供应链的定义。
近两年的情况可以看到非常多的软件供应链的安全事件，包括软件供应链的开发、构建、交付、使用等各个环节都有很多安全事件发生，软件供应链问题急需解决。截止到 2023 年 4 月份的 12 个月之内，外企有至少 60% 的公司受到软件供应链攻击的影响。
这就引出了软件物料清单的概念。软件物料清单可以理解为对软件制品的一种描述，它包括了一些软件的原信息、软件的基本信息、软件的依赖、开源证书等信息，可以做软件供应链管理、安全漏洞管理、应急响应、软件合规管理等用途。gartner 预测，到 2026 年至少有 60% 的采购方将在关键设施的采购中交付软件物料清单。
龙蜥社区在逐步构建整个 SBOM 的基础数据能力。目前在龙蜥软件信息中心上已经实现了针对软件的软件包、ISO 镜像、容器镜像的全制品覆盖。目前，初步是实现国际主流的 SPDX 的格式的软件物料清单，后续根据需求，也会逐步支持其他的 CycloneDX、SWID 等更多 SBOM 格式的支持。
***02 ***可信 SBOM
什么是可信 SBOM？这里引用一句话：Simply producing an SBOM is not sufficient，instead we must ensure that such SBOMS are trustworthy，意思是做一个 SBOM 的交付是不够的，保证 SBOM 交付给下游的用户的 SBOM，它是可信的，什么是可信？从四个维度定义可信，一个是交付给用户的 SBOM 内容的准确性，比如软件制品包含了哪些成分，成分是否是真的，用机器学习的评价指标就是里面的假阳率有多少。二是可验证性，怎么保证交付给用户的 SBOM，用户可以验证交付的 SBOM 是真实的。三是完整性，比如 SBOM 可能包含了 99 个依赖成分，但可能它实际依赖了 120 个成分，完整性上的缺失导致 SBOM 内容不准确。四是 SBOM 的来源可信，是否是来源于一个可信的组织机构，比如龙蜥，而不是不可信的第三方，这就是机构可信背书的问题。
目前开源社区在可信 SBOM 上的实践：上图是 Redhat 的 sbom 仓库。Redhat 在官方制品的仓库已经发布了一个 beta 版本的、基于 spdx 的 sbom 数据。可以看到每个制品的 SBOM 对应了三条数据，第一条是压缩后的 SBOM 文件；第二条是 SBOM 文件的签名信息；第三条是 SBOM 的哈希值。利用签名和哈希值，从完整性和来源可信两个维度保证 SBOM 的可信。
上图是一个比较典型的容器镜像场景，也是 SBOM 目前的生态和整个工具集支撑的比较好的场景。目前社区主流的方案是: 首先通过 SBOM 的一些生成工具，比如 syft 工具生成容器镜像的 SBOM。cosign 是 Linux Fundation 在社区上支持的签名项目，然后利用cosign 对 SBOM 基于 in-toto 的 Attestation 格式生成 SBOM Attestation。通过这种方式可以把 SBOM 和容器镜像关联。最终下游用户可以通过工具对 SBOM 进行验证。图上我们对远程证明做验证，可以看到 SBOM 整个的制品签名信息。签名是一个非常好的验证来源可信的手段。供应链的整个生产流程还有非常多的点可以用签名做可信校验。
***03 ***龙蜥统一签名服务
为什么在软件供应链 SBOM 场景下提到统一签名服务？它其实是推导后的结果。接下来介绍怎么演绎推导出需要的统一的签名服务？
软件供应链 SBOM 有一个非常明显的特征，所有的数据来源、问题都是碎片化散落在整个软件供应链 SBOM 体系下面的，比如生产阶段、设计阶段、发布阶段。要解决软件供应链 SBOM 的可信问题，需要一个非常好的方法论指导，而龙蜥从攻击面管理的角度解决软件供应链 SBOM 复杂体系的可信问题。
在安全问题的设计过程中，首先为软件供应链 SBOM 建立一个可信模型。为了全面覆盖软件供应链 SBOM 整个过程，把它分为大概三部分：
- 源码阶段是编码 Code Review。
- 构建阶段是编译、发布。
- 部署阶段是发布、上线、运行。
除了以上三部分之外还会涉及到依赖，如构建依赖、编译依赖等，这是构建、发布时非常重要的 SBOM 概念。在此过程中，源码阶段会发现有一个攻击方式，比如有一些人编写的不安全代码，这是一种比较多的攻击方式。源码入侵的场景下，可以把源码仓库都破坏掉，对源码完整性形成了一个非常坏的结果。在构建阶段还有非常多的供应链投毒，把发布制品篡改成用于攻击的制品。
总结下来整个软件供应链 SBOM 有四种需要做安全保护：源码完整性、构建完整性、系统完整性、元数据的完整性。在此过程中，提到完整性大家会有一个非常直观的概念，就是完整性的保护可以通过签名解决。软件供应链 SBOM 绝大多数场景有完整性的需求，通过统一签名解决这样的问题。因此，龙蜥从软件供应链 SBOM 安全威胁模型，推导出了需要有统一的签名服务消解可信问题。
当前签名技术比较成熟标准化，在 SBOM 的体系下有用签名。那当前的签名服务在Anolis OS 还有没有，有哪些需要解决的问题。从整个Anolis OS 的软件生命周期看，把它分为七个阶段，需求、设计、研发、构建、测试、发布、运行。需求阶段有一个很重要的问题，即所谓的需求完整性，例如产品需求方提的需求最后有没有完全被覆盖到，在软件供应链体系下它其实没有被覆盖的。签名依赖很多签名工具，比如构建系统、三方的工具等，龙蜥 OS 用的是 koji 的打包平台。底层用到的密管服务，阿里云的 KMS 或者本地的 PKI，从签名服务的复杂性来说有很多的对接。
我们对 Anolis OS 的场景做了一个总结，有些功能有但可能会承担安全风险，如 OS 的 rpm 包有一个非常严重的问题，有可能会本地落盘，所有的软件生命周期当中的签名都是分散，缺乏管控的。另外一个问题是标红的东西很多，不同的标准，不同的签名工具，不同的 KMS 都没有统一支持或集成，导致了整个软件供应链 SBOM 签名是碎片化的。
针对以上问题，社区做了龙蜥统一签名服务的设计，龙蜥的统一签名服务特点是简单的、透明的、安全的、高度集成的。所谓的简单从用户的视角来看，希望统一签名服务是易用的，对用户来说非常简单，可以用各种方式把服务用起来。透明是后续把统一签名服务开源出去，来搭建它真正的安全性。另一个最重要的点是高度集成，签名服务是弹性的、可扩展，可以支持多种 KMS、服务、数据库等。
统一签名服务架构上可以东西向和南北向扩展。南北向的可扩展是后台支撑的服务有多种 KMS、数据库、三方服务可以借用。东西向的可扩展希望有多实例的能力，LB 或者 Gateway的方式能够提升服务的吞吐能力，还有一个最重要的是缺失的标准的 JWT 统一的权限管控。以上就是龙蜥统一签名服务的整体架构介绍。
精彩视频回放、课件获取：
2023 龙蜥操作系统大会直播回放及技术 PPT上线啦，欢迎点击下方链接观看~
回放链接：https://openanolis.cn/openanolisconference
技术 PPT ：关注龙蜥公众号【OpenAnolis 龙蜥】，回复“龙蜥课件”获取。
—— 完 ——
版权归原作者 OpenAnolis小助手 所有， 如有侵权，请联系我们删除。