供应信息和文章都能优化的采集软件(软件供应链攻击面-2019-5736，容器服务服务ACR)

　　供应信息和文章都能优化的采集软件(软件供应链攻击面-2019-5736，容器服务服务ACR)

　　“没有容器，就没有全球化。”在软件行业，Docker和Kubernetes也扮演着类似的角色，加速了软件行业的社会分工和交付运维效率。 2013年，Docker公司提出了容器应用打包规范Docker Image，帮助开发者将应用和依赖打包成可移植的镜像。 2015 年，Google 将 Kubernetes 捐赠给 CNCF，进一步普及了*敏*感*词*容器编排的标准。

　　Kubernetes 使用声明式容器编排和管理系统来屏蔽底层基础架构的差异，并使软件交付越来越标准化。随着以K8s为代表的云原生技术的*敏*感*词*应用，越来越多的容器化应用分布到IDC、公有云、边缘等全球。

　　2019年ACR容器镜像服务ACR月镜像下载量突破3亿次。同年10月，阿里云市场容器镜像品类发布，越来越多的企业将软件上架，以容器的形式销售。 11月，天猫双11所有核心系统100%上云。除了支持双11内部镜像托管，容器镜像服务ACR也在云端展示了内部能力，支持更多双11生态企业。

　　接下来我们来看看如何保证容器和Kubernetes下的软件供应链的安全，熟悉软件供应链常见的攻击场景。

　　软件供应链攻击面及典型攻击场景

　　软件供应链通常包括三个阶段：

　　不同阶段的攻击面如下：

　　历史上著名的APPLE Xcode IDE工具攻击是发生在软件开发阶段的攻击。攻击者在 Xcode 中注入了一个恶意后门，并在非官方的 网站 上提供了下载。所有使用此 Xcode 的开发人员都编译了它。 APP会感染后门。同样著名的还有美国的 Prismgate 事件，大量软件被植入后门程序，执行数据采集等恶意操作。

　　Kubernetes 中软件供应链的攻击面也收录在上述范围内。以软件使用阶段为例。今年的 RunC 漏洞 CVE-2019-5736。该漏洞本身与RunC的运行设计原理有关，在Container之外是动态的。运行时会触发编译Runc，它会引用Conainer内部的动态库，导致RunC本身被恶意注入运行恶意程序。攻击者只需将恶意动态库和恶意程序放入Container镜像中，即可诱导攻击者进行恶意下载。运行混淆攻击。一旦被攻击的容器环境满足攻击条件，就可以完成攻击。

　　同样的攻击面仍然存在于 Kubernetes 自己的服务组件中。前段时间爆发的HTTP2 CVE-2019-9512、CVE-2019-9514漏洞就是一个非常好的软件开发阶段漏洞例子。该漏洞存在于GO语言的基本LIB库中。任何依赖于 GO 版本的东西 (

　　与传统的软件供应链不同，镜像作为统一的交付标准，在容器场景中被大量使用，因此关注镜像的生命周期可以帮助攻击者更好地设计攻击路径。

　　攻击者可以在镜像生命周期的任何阶段污染镜像，包括篡改构建文件、植入构建平台后门、在传输过程中劫持替换和修改、攻击镜像仓库等。劫持攻击替换镜像文件、在镜像上运行下载和升级等。

　　整个攻击过程可以利用与云场景相关的各种依赖，例如Kubernetes组件漏洞、仓库漏洞，甚至底层基础设施漏洞。对于防御者来说，镜像整个生命周期的安全是容器场景下防攻击的重中之重。

　　云原生时代应用交付标准的演进（从Image到Artifacts）

　　在云原生时代之前，应用交付方式多样化，如脚本、RPM等。云原生时代，为了屏蔽异构环境的差异，提供统一的部署抽象，大家也迫切需要统一应用交付标准。

　　头盔

　　Helm 是 Kubernetes 的包管理工具。提出了Chart的概念。

　　CNAB

　　CNAB 是 Docker 和微软于 2018 年底联合推出的独立于平台的 Cloud Native Application Bundle 规范。与 Helm 相比，还有几个额外的定义：

　　CNAB 的这些功能支持跨平台（包括云和本地 PC）应用程序打包和在受信任的软件分销商和消费者之间分发。

　　OCIArtifacts

　　2019 年 9 月，在 OCI 分发标准之上，开放容器标准组织 (OCI) 启动了 OCIArtifacts 项目来定义 Cloud Native Artifacts 的规范，以支持更多的分发格式。我们可以通过扩展media-type定义一个新的Artifacts规范，并通过标准的镜像仓库统一管理。

　　Kubernetes 时代的安全软件供应链

　　如前几章所述，相比传统的软件安全软件供应链管理，容器和Kubernetes的引入使得：

　　在传统的软件安全和安全指南之上，我们可以结合一些最佳实践来沉淀一个新的端到端安全软件供应链：

　　让我们来看看一些与安全软件供应链相关的社区技术发展：

　　格拉菲斯

　　2017 年 10 月，谷歌联合 JFrog、IBM 等公司推出了 Grafeas。 Grafeas（希腊语中的“scribe”）旨在定义一种统一的方式来审查和管理现代软件供应链，并为云原生产品提供元数据管理功能。您可以使用 Grafeas API 来存储、查询和检索有关各种软件组件的全面元数据，包括合规性和风险状态。

　　全面

　　In-toto 提供了一个框架或策略引擎来保护软件供应链的完整性。

　　这是通过验证链中的每项任务都按计划执行（仅限授权人员）并且产品在运输过程中没有被篡改来完成的。 In-toto 需要项目所有者创建布局。该布局列出了软件供应链中的步骤顺序以及授权执行这些步骤的员工。当工作人员执行跨步操作时，有关使用的命令和相关文件的信息将被采集并存储在链接（Link）元数据文件中。通过定义完整供应链中的每个步骤并验证步骤，可以完全集成整个供应链的安全性。

　　克里蒂斯

　　为了加强 Kubernetes 的安全性，Google 引入了 Binary Authorization，以确保用户只能将受信任的任务部署到 Kubernetes。二进制授权可以基于Kubernetes Admission Controller插入部署准入检测，只有经过授权的镜像才能在环境中运行。

　　下图是一个策略示例：

　　同时，对于在安全软件供应链中占比较大的第三方软件，需要有完善的基线机制和fuzzing安全测试机制，保障分发过程中的安全风险并避免以已知漏洞启动。阿里云正在积极回馈社区，帮助进化一些开源工具链。

　　在基础图片优化、安全扫描、数字签名等领域也有很多工具和开源产品，这里就不一一介绍了。

　　云中安全软件供应链的最佳安全实践

　　在阿里云上，我们可以轻松构建基于容器服务ACK、容器镜像服务ACR、云安全中心的完整安全软件供应链。

<p>安全软件供应链的整个环节始于云原生应用托管，止于云原生应用分发。整个环节可观察、可追溯，并可独立设置。可帮助对安全要求高、业务规模大、业务部署多的企业级客户在全球范围内实现一次性应用变更和多场景自动交付，大幅提升云原生应用交付的效率和安全性。