本文整理自匡大虎、马元元、程涛与黄竹刚在2024云栖大会的演讲
针对软件供应链的攻击事件在以每年三位数的速度激增，其中三方或开源软件已经成为攻击者关注的重要目标，其攻击方式和技术也在不断演进。通过供应链的传播，一个底层软件包的漏洞的影响范围可以波及世界。企业亟需更加标准和完善的供应链风险洞察和防护机制。本文将结合最佳实践的形式，面向容器应用完整的生命周期展示如何基于容器服务ACK/ACR/ASM助力企业构建云原生软件供应链安全。
本文分为四部分，第一部分我们会首先了解当下容器供应链安全形势和业界针对容器供应链安全发布的规范标准；第二部分我们会一起介绍如何基于ACK容器服务构建企业应用端到端供应链安全；在第三部分中会介绍如何使用ASM服务网格实现应用无感的零信任安全；最后会介绍ACR容器镜像服务在软件供应链安全相关的产品能力发布和最佳实践。
容器供应链安全形势和规范标准
可能大家对软件供应链还有些陌生，我们可以将软件供应链比作大家比较熟悉的，也和我们每个人日常生活都相关的食品供应链，在食品供应链中有几个重要的阶段：生产、仓储、分销和最终的消费阶段。为了构建可持续的食品供应链，保证最终我们消费者能够买到放心可靠的食品，国家颁布了“食品安全法”，并且建立了完善的平台监管机制，用来防范一些食品源头、加工和运输各环节可能出现的食品安全问题。因为其中任何一个环节的纰漏，都会直接影响到我们消费者的健康安全。
在典型的软件供应链中，从源代码到构建，再到包装和分发，每个环节也都存在被恶意攻击并传播的安全风险。在过去的一年多时间里，软件供应链遭受了数十起引人注目的有针对性的攻击，其影响遍及全球。
比如去年OpenAI正是攻击者利用一个Redis底层的Python异步工具代码库漏洞，导致直接泄露了ChatGPT Plus用户的详细信息，该事件甚至导致一个国家在此之后直接宣布禁用了ChatGPT。
还有今年3月爆出的威胁评分为10分满分的critical供应链漏洞XZ后门，漏洞源自一个未知的攻击者通过3年之久的长期潜伏和精心酝酿，逐步成为了一个流行的压缩工具包社区的maintainer，并通过一系列复杂的混淆和替换技术，最后成功将后门植入到主流OS系统的发行版本中，并最终通过供应链的传播影响了千行百业的软件系统。
这里我们参考一些主流云安全厂商在今年发布的统计数据，通过数据可以直观地了解当下供应链安全的严峻形势。左侧Sonatype在今年关于软件供应链攻击演化的报告中指出，自19年以来，软件供应链攻击平均每年都以742%的速度增加。
右侧新思科技在今年的开源安全风险分析报告中对17个行业一千多个商业代码库的匿名分析，在分析结果中得出，其中84%的代码库中包含安全漏洞，更有74%的代码库包含高危安全漏洞。
对于企业来说，无论您是在构建软件还是部署软件，软件供应链都是当下潜伏在企业内部最大的未解决攻击面。
为了应对严峻的软件供应链安全形势，我们需要规范化的安全标准指导企业安全运维人员实施有针对性的供应链安全加固措施。SLSA是近两年在业界被逐步认可采纳的供应链安全框架。面向软件生产者和消费者提供了安全实践和指南，帮助安全地构建和验证软件完整性。
就像食品供应链中需要成熟的食品安全法和监管准则去确保食品中每一种配料的安全可信。需要从工厂源头开始建立卫生环境标准，确保不会有污染物进入包装，到要求食品包装上的防篡改密封条，确保无人能够变更货架上的食品内容。
SLSA框架在软件供应链中也有类似的作用，它会确保软件生产过程中每个步骤都提供了安全指导，并加签了可信证明。
通过SLSA明确定义的分级标准，可以帮助软件开发的生产者提升供应链生产过程中每一步的安全性，也可以帮助企业判断部署在生产环境中的制品是否满足安全可信的基本要求。
在企业构建自身安全防护平台架构的过程中，通常都希望将安全合规测试无缝集成到内部DevSecOps流程中去，同时要求在安全和迭代效率之间取得平衡，企业安全管理员传统的人工审核卡点角色需要逐步转换为在整个供应链开发流程管道中提供自动化的安全防护机制，同时避免对开发人员设置障碍。就好像F1赛车中，只有在出现严重事故时，安全车才会出动去限制和引导车手。同样的，开发人员也希望按照自己的节奏开发和创新。
CNAPP云原生应用防护平台正是这样的架构，框架中将运行时风险的威胁分析和防护，云安全风险洞察和开发工具平台的风险可视性需求结合起来，形成了完整的CNAPP平台所需的安全集成功能。
CNAPP架构的目标是整合并拉近应用开发团队，云架构和基础设施运维团队以及安全运营团队的距离，云安全是团队人员的共同职责，而开发人员是修复已知风险的最终角色。这就要求CNAPP工具遵循左移原则，将风险可见性转移到开发阶段，深入集成开发人员的CI/CD流程中，并扩展针对云原生制品的安全扫描能力，逐步评估和构建完整的CNAPP安全能力。
基于框架的安全能力要求，阿里云容器服务在内部践行DevSecOps流程的同时，也通过ACK、ACR和ASM服务提供了涵盖容器供应链安全流程关键阶段的核心安全产品能力。我们会通过session后续的三个部分逐一介绍。
基于ACK容器服务
构建企业应用端到端供应链安全
针对容器软件供应链日益严峻的安全形势，容器服务ACK/ACR/ASM通过一系列安全产品能力，实现了“连点成线”的供应链风险分析和防御机制。今年，面向供应链安全的典型客户需求，ACR容器镜像服务支持OCI社区1.1版本的镜像和分发规范，标志着客户可以通过ACR管理和分发镜像签名和SBOM这样的非镜像OCI制品，同时结合ACK的策略治理能力，帮助企业客户实现通用的制品自动化加签和验证方案，保证部署到生产集群中的镜像是完整可信的。
同时ACK容器服务还针对授权过大和容器逃逸后的节点内横向攻击等风险，有针对性地提供了对应的加固和防护能力。
通过一系列安全产品能力的升级，帮助企业客户在统一的阿里云容器平台上，以更标准、更易用、更智能的方式构建端到端的容器供应链安全防护。
我们的客户深势科技，也是基于容器服务的策略治理能力，实现了日均万次的应用部署时刻容器镜像和配置安全风险的主动防御和安全审计。
在构建分发、部署和运行时这几个容器供应链生命周期的典型阶段，我们都布局了相应的安全产品能力并且在今年完成了相应安全能力的增强。稍后我们也将逐一介绍。
通过ACK/ACR/ASM等云服务，我们提供了一套综合的、紧密集成的主、被动安全功能，旨在确保云原生应用在整个生命周期各阶段的配置合规性和风险评估洞察能力，并提供自动化方式方便企业无缝集成到DevSecOps框架中。
在整体流程上我们希望我们的客户能够基于阿里云容器供应链主动安全能力，在供应链早期阶段及时发现风险，降低修复成本。
同时我们希望企业的应用开发人员能够基于阿里云容器供应链安全能力，从原先被动修复的方式逐步转换为一种主动识别并减低风险的自动化方式，能够让开发人员真正共担起容器应用安全风险的防护责任。
在原先的镜像签名方案中，镜像签名信息是在ACR服务侧管理，对客户是黑盒的存在。
在OCI v1.1新规范中，与镜像相关的签名、SBOM等其他元数据信息支持以manifest的形式在ACR仓库中运维管理，并且支持通过Referrers API快速检索指定镜像关联的签名信息。
为此我们推出了基于OCI v1.1规范的通用云原生制品的完整性安全防护方案，在加签环节，我们基于Notation社区的plugin规范开源了标准的阿里云插件，支持对接阿里云KMS中管理的签名密钥完成通用的制品加签流程。
在验签环节，当apiserver请求进入到admission准入阶段，会基于Gatekeeper原生的external data机制调用后端服务进行部署镜像签名的自动化验签，这里我们在ACK应用市场引入了开源组件Ratify，Ratify内置了面向通用开源签名工具Cosign或Notation的校验器，同时提供了多种CRD帮助用户配置细粒度的验签凭据或私有仓库的manifest拉取凭据。当Ratify中发现有不满足签名校验的部署时，会自动化拦截。从而完成完整的通用制品加签和验签流程。
过度授权是企业客户系统中普遍存在的问题，在今年sysdig的云原生安全使用报告中统计，只有2%的线上授权被实际使用，这些冗余权限通过不断地积累会严重影响企业线上系统的安全水位，也是攻击者利用的首选路径。
为此我们针对集群应用对线上云资源和数据面集群内的k8s资源的两种访问需求，提供了相应的凭据管理和权限收敛方案。
首先针对集群内K8s资源的访问，集群管理员可以通过ACK凭据管理功能轮转临近过期的凭据，清理离职员工的残留凭据，同时支持对风险凭据的定期巡检和主动告警能力，为了保证应用稳定性，对于正在被业务系统使用的误删凭据，还支持回收站中的一键恢复操作。
针对数据面应用对云上资源的访问，ACK集群已支持节点池维度的自定义RAM角色绑定配置，同时完全清理了节点默认绑定的RAM权限；针对多租场景，我们推荐使用RRSA方案，通过k8s原生的serviceaccount token，基于标准的OIDC协议的认证方式完成pod维度的细粒度RAM授权。最大程度遵循最小化授权原则。
集群节点的安全性是攻击者发起横向攻击的第一道屏障，今年我们针对一些超大规模镜像（AI大模型场景）对节点数据盘的容量压力问题，推出了节点闲置镜像清理能力，通过在应用市场部署image cleaner插件，以自动化方式扫描并清理节点上闲置的或不符合漏洞扫描规则约束的风险镜像，弥补节点kubelet清理能力的局限性，同时预防节点数据盘空间被占满的稳定性风险。
另外针对攻击者exec进入容器后的恶意行为，也可以在ACK组件管理中部署针对容器内行为审计的webhook插件，基于eBPF程序采集攻击者进入容器后执行的命令事件，并快速关联到指定的容器资产，最终通过SLS的日志采集和告警能力及时告知集群安全运维人员正在发生的疑似攻击行为。
使用ASM服务网格实现应用无感的零信任安全
阿里云服务网格（Service Mesh，简称ASM）提供一个全托管式的服务网格平台，兼容社区Istio开源服务网格，用于简化服务的治理，包括服务调用之间的流量路由与拆分管理、服务间通信的认证安全以及网格可观测性能力，从而极大地减轻开发与运维的工作负担。这里着重介绍如何使用服务网格ASM实现应用无感的零信任安全。
ASM整体架构如上图所示，主要由数据平面和控制平面组成：
数据平面：包括入口网关、出口网关以及和业务容器部署在同一个Pod中的Sidecar代理。Sidecar代理会透明的拦截进出业务容器的流量，并且对这些流量执行加解密以及认证鉴权操作。每一个数据面代理中都有自己的X.509证书，数据面组件之间的通信默认使用X.509证书来实现mTLS通信。和普通的TLS通信不同，在mTLS通信中，不仅需要客户端验证服务端提供的证书是否合法，服务端同样会验证客户端提供的证书，确保只有可信的客户端可以访问当前服务。在mTLS通信的基础上，数据面代理可以基于客户端的证书以及请求的L7信息实现丰富的授权能力。
控制平面：ASM控制平面由阿里云托管，主要负责为数据面代理颁发证书，下发网络配置、认证策略以及授权策略等。
从图中可以看出：一个ASM控制平面支持管理多个数据面集群。将多个数据面集群加入同一个ASM之后，这些集群中的服务可以实现全局统一的流量路由、负载均衡以及认证授权等。和集群内通信相同，跨集群通信同样会默认使用mTLS来对流量进行加密。
下面我们将从三个方面来介绍ASM提供的全链路安全能力，分别是集群入口流量、集群内东西向流量以及集群出口流量。
首先介绍入口流量的认证与鉴权。集群外客户端要访问集群内服务时，需要通过入口网关做一层转发，ASM入口网关提供了丰富的认证以及授权能力：
多种认证方式：mTLS认证（使用通信双方的X.509证书完成身份认证）；JWT和TLS结合的认证，TLS用来验证服务端身份，JWT用来验证客户端身份。
完善的授权策略：支持从mTLS、JWT等认证方式中获取客户端身份，结合L7信息进行鉴权。
灵活的扩展方式：支持对接自定义授权服务（您可以自行实现数据面代理要求的标准HTTP/gRPC接口，数据面代理会根据配置调用该服务来进行鉴权）；支持在数据面代理中运行Lua脚本；支持使用Go、Rust以及C++等语言开发WASM插件部署在数据面代理中。
硬件加速：网关要处理大量TLS/mTLS连接，ASM网关支持基于Multi-Buffer的TLS/mTLS加速，降低请求延迟。
低使用门槛：ASM网关支持完整的白屏化操作，支持多种简化的自定义资源，让您可以更快地上手网关提供的各种能力。
这部分主要介绍ASM提供的集群内东西向流量的安全能力。
首先我们介绍集群内的身份认证能力。当您的业务Pod被注入Sidecar代理之后，两个Pod之间的通信流量会被网格代理劫持，并且使用mTLS进行Pod间通信。此时您的业务容器依旧处理明文流量，但是Pod外的通信已经是加密后的流量了。为了方便您将业务逐步迁移至网格中，ASM支持严格和宽松两种认证模式，迁移过程中可以使用宽松模式，Sidecar代理可以同时接收明文和mTLS流量，切换为严格模式之后，不再接收明文流量。同时，多个集群加入同一个ASM后，网格代理会自动完成基于mTLS的跨集群身份认证。
mTLS通信中，通信双方的证书是实现安全通信的基石。ASM采用了严格的证书签发与轮转流程保障了数据面代理的证书安全。首先，网格代理的私钥一直保存在其程序内存中，不会存储在文件系统上，也不会被发往外部。ASM控制面会向数据面APIServer校验业务Pod的身份并为其签发证书，并且会定期自动轮转证书。数据面代理会使用控制面签发的证书进行mTLS通信，以此实现东西向通信的零信任。
有了mTLS通信提供的通信双方的身份，就可以实现基于X.509证书身份的授权。Sidecar代理支持使用客户端身份和请求L7信息进行鉴权，并且支持使用OPA规则引擎对客户端权限进行鉴别。和网关一样，Sidecar代理同样支持对接标准的自定义授权服务，您可以实现更加复杂的鉴权逻辑。
集群外服务的访问控制同样是全链路安全中不可忽视的一部分。ASM提供了完善的出口流量管理方案，可以实现更细粒度的出口访问控制，提升系统整体安全水位：
网络策略：使用Kubernetes提供的网络策略来限制L4访问，确保除出口网关外的Pod无法直接访问外部服务。
出口网关：创建ASM出口网关，确保只有出口网关可以访问外部服务。出口网关由网格管理员进行管理，能够更好地实现权限隔离，防止过度授权。
配置虚拟服务：ASM提供的虚拟服务配置可以用来将流量透明拦截至出口网关，业务应用无需做任何修改。
授权策略：ASM出口网关同样支持基于客户端身份和请求的L7信息进行鉴权，并且支持对接自定义授权服务等，防止未经授权的恶意访问。
配置目标规则：流量经过出口网关鉴权后，可以通过配置目标规则，以明文、TLS、mTLS等多种协议被发往真正的外部服务。
通过以上的三部分能力，您可以实现入口、东西向以及出口的全链路认证以及授权，确保业务流量的整体安全。
ACR软件供应链安全产品能力发布及实践
容器镜像服务ACR在今年软件供应链安全能力的升级分为三个方面：
可信生产：ACR提供面向镜像构建场景的智能构建诊断能力，通过深度分析构建过程，来识别敏感信息和安全风险，并提供相应的优化方案。
可信管理：生成镜像后，ACR通过漏洞扫描与内容分析来为客户产出详细的镜像漏洞报告以及镜像依赖详情，并提供依赖反查的能力快速确定漏洞的影响面。
可信分发：ACR现已支持OCI v1.1标准，这使得我们能够方便地将镜像与软件物料清单（SBOM）、镜像签名和安全扫描报告等其他OCI制品进行关联，从而更好的支持可信分发。
首先介绍一下我们ACR新推出的构建智能诊断能力。
在之前，容器镜像服务ACR为用户提供了从源代码至业务镜像的自动化持续集成能力。然而，用户编写的代码或Dockerfile中可能会包含一些敏感信息和安全隐患，从而导致生成的业务镜像存在敏感信息泄露风险以及引入了一些额外的安全漏洞，威胁线上业务的安全和稳定。
为此，容器镜像服务推出面向镜像构建的智能诊断能力，通过深度解析Dockerfile和构建日志，为每一次构建任务生成准确的诊断报告，帮助用户识别出Dockerfile中的不当内容、比如敏感信息、高危指令，潜在的外部风险依赖引入等等，并结合阿里云容器镜像服务长期积累的丰富经验和最佳实践利用通义千问大模型来生成全面的优化方案，助力用户来构建安全、稳定的业务镜像。
再来说可信管理方面，容器镜像服务最新推出了容器镜像软件物料清单生成的功能，来帮助客户去生成软件物料清单SBOM，以洞察镜像的内容成分、包括镜像的依赖组件版本和license等信息。同时ACR也会在控制台提供对镜像的依赖分析来便于用户去查看镜像的组件内容以及漏洞信息，这里图中简要展示了SBOM分析任务生成的各个层所包含的内容，比如镜像包含的应用级别的软件包名称及版本，操作系统级别的软件包名称及版本还有所使用的操作系统等等。这些内容将用于后续排查镜像的安全漏洞风险。
通过前一步生成SBOM后，可以获取到软件包和镜像层的关联关系，因此ACR提供了软件物料依赖反查的能力，当使用安全扫描扫出某个高危漏洞时，帮助客户依据漏洞所在软件包的名称及版本，通过依赖反查查询所有含有该软件包的镜像，从而快速确定漏洞影响范围，显著提高对安全威胁的响应速度和效率。
接下来是可信分发，ACR对镜像签名能力做了优化升级。在实际项目开发中，软件交付的链路往往很长，并且开发环境产生的镜像可能需要部署到全球各个地域。在此过程中，中间链路可能存在中间人攻击和使用不规范导致非预期镜像更新的风险。而用户希望在阿里云Kubernetes集群上运行的是预期内的、未被篡改的安全可信镜像。
如图所示，在开发阶段，用户提交代码变更到代码仓库，触发镜像构建。通过构建、安全扫描（SBOM分析）等阶段后，可以利用ACR的加签能力对相应镜像进行加签，确保该镜像的完整性和来源可信。
随后，利用ACR的镜像全球同步能力，可以跨账号跨地域高效安全地将镜像和签名分发到目标镜像仓库。接着在对端集群上进行部署时，通过配置验签策略使用准入控制组件对镜像验签，从而确保部署阶段镜像的内容可信。
今年，ACR已支持OCI v1.1标准规范。这使得我们能够方便地将镜像与软件物料清单（SBOM）、镜像签名和安全扫描报告等软件供应链安全产物进行关联。
镜像在多云多镜像仓库间同步时，可同时同步关联的制品，在部署阶段，用户可以基于关联的漏洞报告、镜像签名和SBOM，制定相应的准入策略。这些策略可以在后续的消费过程中，确保镜像的安全性和合规性。
得益于OCI标准规范，ACR能够与Trivy、Cosign及Harbor等多个供应链开源工具进行兼容性集成，便于镜像及其关联制品在多种工具之间的生产和消费。
最后，我们highlight了一些容器服务ACK/ACR/ASM在今年增强的一些供应链安全产品能力，希望通过阿里云容器服务的统一平台，帮助企业客户构建容器应用完整生命周期的端到端全链路的云原生软件供应链安全防护。
