简单、透明、安全、高度集成!龙蜥可信 SBOM 能力探索与实践

简介: 从攻击面管理的角度解决软件供应链SBOM复杂体系的安全可信问题。

近两年,软件供应链有非常多安全事件,包括软件供应链的各个阶段开发、构建、交付、使用等每个环节都有很多的软件供应链的安全事件发生。在 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 龙蜥】,回复“龙蜥课件”获取。

相关实践学习
通过workbench远程登录ECS,快速搭建Docker环境
本教程指导用户体验通过workbench远程登录ECS,完成搭建Docker环境的快速搭建,并使用Docker部署一个Nginx服务。
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
1天前
|
敏捷开发 运维 监控
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第17天】 在现代软件开发过程中,"持续集成"(Continuous Integration, CI)和"持续部署"(Continuous Deployment, CD)已经成为提高开发效率、确保代码质量和加速产品上市速度的关键策略。本文将深入探讨CI/CD在软件测试中的应用,包括它们的定义、目的、实施策略以及面临的挑战。通过对自动化测试、版本控制、构建流程和反馈循环的详细分析,我们将揭示如何利用CI/CD实践来优化测试流程,减少错误,并确保高质量的软件交付。
|
2天前
|
Java 数据库连接 Spring
K8S+Docker理论与实践深度集成java面试jvm原理
K8S+Docker理论与实践深度集成java面试jvm原理
|
3天前
|
运维 监控 Kubernetes
构建高效自动化运维体系:基于容器技术的持续集成与持续部署(CI/CD)实践
【5月更文挑战第15天】 随着云计算和微服务架构的普及,传统的IT运维模式面临转型压力。为提高软件交付效率并降低运维成本,本文探讨了利用容器技术实现自动化运维的有效策略。重点分析了在持续集成(CI)和持续部署(CD)流程中,容器如何发挥作用,以及它们如何帮助组织实现敏捷性和弹性。通过具体案例研究,文章展示了容器化技术在自动化测试、部署及扩展中的应用,并讨论了其对系统稳定性和安全性的影响。
|
3天前
|
运维 监控 安全
构建高效自动化运维系统:基于容器技术的持续集成与持续部署(CI/CD)实践
【5月更文挑战第14天】 随着DevOps文化的深入人心,持续集成与持续部署(CI/CD)已成为现代软件工程不可或缺的组成部分。本文将探讨如何利用容器技术,尤其是Docker和Kubernetes,构建一个高效、可扩展的自动化运维系统。通过深入分析CI/CD流程的关键组件,我们将讨论如何整合这些组件以实现代码从提交到生产环境的快速、无缝过渡。文章还将涉及监控、日志管理以及安全性策略等运维考量,为读者提供一个全面的自动化运维解决方案蓝图。
|
3天前
|
运维 Kubernetes 持续交付
构建高效自动化运维体系:基于容器技术的持续集成与部署实践
【5月更文挑战第13天】 在现代软件开发周期中,持续集成(CI)和持续部署(CD)已成为提升开发效率、保障产品质量的关键环节。随着云计算和微服务架构的普及,容器技术如Docker和Kubernetes为运维领域带来了革命性的变革。本文旨在探讨如何利用容器技术构建一个高效、可靠的自动化运维体系,实现从代码提交到产品发布的全过程自动化管理。通过深入分析容器化技术的核心原理,结合实际案例,我们将阐述如何优化持续集成流程、确保自动化测试的覆盖率、以及实现无缝的持续部署。
25 2
|
3天前
|
敏捷开发 监控 Devops
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第13天】 在现代软件开发的快节奏和复杂性中,持续集成(Continuous Integration,CI)与持续部署(Continuous Deployment,CD)成为确保软件质量和加速交付的关键策略。本文将深入探讨CI/CD在软件测试中的应用,解析其核心概念、流程以及面临的挑战,并分享实际案例分析以揭示如何在不断变化的开发环境中维持高效和可靠的软件发布周期。
|
3天前
|
NoSQL Java MongoDB
【MongoDB 专栏】MongoDB 与 Spring Boot 的集成实践
【5月更文挑战第11天】本文介绍了如何将非关系型数据库MongoDB与Spring Boot框架集成,以实现高效灵活的数据管理。Spring Boot简化了Spring应用的构建和部署,MongoDB则以其对灵活数据结构的处理能力受到青睐。集成步骤包括:添加MongoDB依赖、配置连接信息、创建数据访问对象(DAO)以及进行数据操作。通过这种方式,开发者可以充分利用两者优势,应对各种数据需求。在实际应用中,结合微服务架构等技术,可以构建高性能、可扩展的系统。掌握MongoDB与Spring Boot集成对于提升开发效率和项目质量至关重要,未来有望在更多领域得到广泛应用。
【MongoDB 专栏】MongoDB 与 Spring Boot 的集成实践
|
3天前
|
机器学习/深度学习 敏捷开发 监控
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第10天】 在现代软件开发周期中,"持续集成"(CI)与"持续部署"(CD)是提升效率、确保质量的重要环节。本文将详细探讨CI/CD在软件测试中的应用,包括其基本概念、实施策略、工具应用及面临的挑战。不同于一般性概述,本文将重点分析如何优化测试流程以适应CI/CD环境,并提出针对性的改进措施。通过实际案例分析,揭示成功实施CI/CD的最佳实践,并讨论如何在不断变化的技术环境中保持测试策略的前瞻性和灵活性。
|
3天前
|
运维 测试技术 持续交付
持续集成与持续部署(CI/CD):提高软件开发效率的关键实践
【5月更文挑战第8天】CI/CD是提升软件开发效率的关键实践,包括持续集成和持续部署。CI通过频繁集成代码并自动化构建、测试,早发现错误;CD则自动将通过测试的App部署到生产环境,缩短交付周期。自动化流程能降低人为错误,保障软件质量,减少运维成本。Jenkins、Travis CI、GitLab CI/CD和Docker是常见的CI/CD工具。通过这些工具和实践,可优化开发流程,推动项目成功。
|
3天前
|
敏捷开发 运维 测试技术
构建高效自动化运维体系:基于容器技术的持续集成与持续部署实践
【4月更文挑战第30天】在数字化转型的浪潮中,企业对软件交付速度和质量的要求日益提高。自动化运维作为提升效率、确保稳定性的关键手段,其重要性不言而喻。本文将探讨如何利用容器技术构建一个高效的自动化运维体系,实现从代码提交到产品上线的持续集成(CI)与持续部署(CD)。通过分析现代容器技术与传统虚拟化的差异,阐述容器化带来的轻量化、快速部署及易于管理的优势,并结合实例讲解如何在实际环境中搭建起一套完善的CI/CD流程。

热门文章

最新文章