近两年，软件供应链有非常多安全事件，包括软件供应链的各个阶段开发、构建、交付、使用等每个环节都有很多的软件供应链的安全事件发生。在
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上线啦，欢迎移步龙蜥公众号2024年3月5日相同推送查看。
技术 PPT ：关注龙蜥公众号【OpenAnolis 龙蜥】，回复“龙蜥课件”获取。
—— 完 ——
