容器镜像强化：为何应像安全带一样免费且默认？

容器镜像的强化措施，理应像汽车安全带一样，成为免费且默认提供的标配。我们可以借鉴 HTTPS 和 TLS 的普及历程：通过免费化和简化操作，来提升整个软件供应链的安全水平，供应商则可以通过增值服务实现盈利。

译自：Let's Make Hardened Images the Seatbelts of Software
作者：Michael Donovan

没有哪家汽车制造商会要求你为安全带额外付费。安全带的成本早已计入每辆车的价格中，因为它以可接受的边际成本有效防止了伤害。这甚至不再是一个需要讨论的话题——你的车当然配有安全带。

强化容器镜像 也应该遵循同样的逻辑。它们应该让哪怕是两人的初创公司，从第一天起就能负担得起，默认普及，并被视作提升所有人安全水平的公共利益。这意味着采用最小化的基础镜像、以非 root 用户执行、只读文件系统、固定并验证的依赖项、签名溯源，以及在每个通用漏洞披露（CVE）出现时自动重建。

这些应该是标准配置，而不是需要额外付费的增值功能或选配项。供应商完全可以通过其他方式盈利。开源项目也将受益，因为它们能为那些希望从最小攻击面和官方镜像起步的用户，提供一个基础的强化选项。

我们以前在 HTTPS 和 TLS 方面也这样做过

大约十年前，HTTPS 对大多数网站来说还是可选的。证书需要花钱购买，配置过程繁琐复杂。许多网站直接跳过了这一步，导致用户暴露在窃听和中间人攻击的风险之下。

随后，Let’s Encrypt 在 2015 年诞生，它提供了免费且自动化的证书服务。浏览器厂商也开始将 HTTP 网站标记为“不安全”。短短几年内，HTTPS 就从“锦上添花”变成了不可或缺的基本条件。

如今，超过 95% 的网络流量都已加密。这并非政府强制命令的结果，而是一个非营利组织让证书变得免费且易于获取，浏览器施加了社会压力，最终推动了默认设置的改变。

TLS 的普及故事如出一辙。多年以来，在电子邮件服务器、数据库和内部服务上启用 TLS 被视为一项可选的强化措施，只有那些注重安全且拥有时间和专业知识的团队才会去实施。

后来，云服务提供商和平台开始默认启用 TLS。Amazon Web Services、Microsoft Azure 和 Google Cloud Platform (GCP) 让加密连接成了阻力最小的路径。云原生计算基金会 (CNCF) 也将 TLS 列为 Kubernetes 安全 的核心要求。一旦默认设置改变，运行未加密的内部流量反而成了需要特别解释的例外情况。

最近，开源社区及其合作的供应商们围绕 Docker Hub 上的 Docker 官方镜像 (DOI) 集结行动。DOI 是一种确保容器用户只从官方项目源拉取镜像的机制。它作为一种干净、官方的开源镜像真实来源，已经获得了广泛认可。

当你让安全选项变得免费、简便且默认时，普及就会自然而然地发生，无需强制。更重要的是，提高安全基准是所有供应商都愿意支持的事情，因为长远来看，这能为他们省去大量麻烦，并提升客户体验。这对所有人来说都是双赢。

安全外部性是每个人的问题

软件开发正以前所未有的速度向前狂奔。AI 辅助编程进一步加快了开发节奏。公司们将更多代码更快地推向基于共享基础设施的生产环境。这给本就紧张的补丁管理带来了更大压力，加速了安全的“跑步机”，也增加了所有人的风险。

组织们面临着 CVE 的浪潮，即便是经验丰富的安全团队也难以完全应对。针对广泛使用软件包的供应链攻击，让数百万台服务器暴露在风险之中。同样关键的是，现代软件栈本身变得极其复杂且快速演变。一个组织可能部署了成千上万个软件组件，而现代开发者引入新开源组件的速度，远超过强化工作能跟上的步伐。

强迫技术团队去修改复杂的配置，或者允许他们随意调整所谓的“黄金镜像”，往往为人为错误敞开了大门，进而导致安全漏洞和其他问题。指望他们跟上所有新技术的最新安全要求，实在有些强人所难。

与此同时，我们正在步入一个由人工智能驱动漏洞发现和利用的时代。攻击者同样在使用 AI，并且会越来越擅长。

在这种环境下，一个团队未打补丁的基础镜像，或者一个易受攻击的开源组件，很快就能演变成波及每个人的安全事故。任何未经验证溯源就部署的组件都可能招致入侵，无论是通过 拼写错误抢注式 Node.js 软件包，还是利用 依赖混淆攻击 欺骗构建系统拉取恶意工件，亦或是 CI/CD 流水线被攻破后，在代码审查完毕后悄无声息地替换掉可信的二进制文件或容器镜像。

即使是最聪明的团队也可能遭遇这种命运，因为人难免会犯错，而且与安全补丁赛跑是一场注定无法完胜的游戏。在这种情况下，供应链的弱点会横向渗透到不同的平台、云环境和客户之间。

而当非 root 用户执行、只读文件系统、最小权限默认值和签名溯源成为基本条件时，整类常规攻击在开始之前就会宣告失败。公共领域中的“软目标”越少，僵尸网络、加密矿工和机会主义蠕虫赖以生存的“氧气”也就越少。

这就是“安全带”论点的核心——它在广泛的技术生态系统中保护着每一个人。就像 HTTPS 一样，技术层面的群体免疫，只有当安全默认设置以免费且简便的极低成本向所有人开放时，才能真正实现。

规模化安全功能成本低廉

你可能会问：构建所有这些东西，钱从哪来？毫无疑问，打造一个一流的强化流水线确实需要真金白银的投入。你需要进行内容策展、实现策略即代码、达到 SLSA 级别的证明、建立自动化重建机制，当然还有 AI 护栏来检查工作成果。然而，一旦这套基础设施搭建完毕，每个新增镜像的边际成本就会急剧下降。大部分持续性的工作将是自动化和内容分发。

Let’s Encrypt 正是这样运作的。建立和运行一个证书颁发机构需要资金，但颁发一张单独的证书几乎不产生成本。基础设施的投资被分摊到数亿张证书上，这是规模经济的经典案例。

强化镜像遵循同样的经济规律。一个专注于强化技术的组织可以承担起基础设施的固定成本，然后以近乎边际成本的价格分发强化后的镜像。就像安全带被直接嵌入到每辆汽车里一样。

商业模式已经存在

汽车制造商不会为安全带额外收费。他们通过装饰包、高级功能和各种服务来赚取利润。安全带是微不足道且默认包含的，因为没有哪家制造商愿意成为那个销售不带安全带的汽车的公司。

同样的模式完全可以适用于容器安全。每个人都应该获得免费的基线安全保障：最小化、可复现的基础镜像，不包含 shell 或不必要的工具，通过删除权限和 seccomp 配置文件实现非 root 用户执行，只读文件系统和锁定的网络默认设置，附带 软件物料清单 (SBOM) 和 漏洞可利用性交换 (VEX) 的固定且已验证的依赖项，针对 CVE 和已知已利用漏洞目录 (KEV) 信号的持续重建，以及带有机器可验证证明的加密签名。

企业则为高级服务付费：例如经过 FIPS（联邦信息处理标准）验证的密码学、带有严格服务水平协议的扩展长期支持分支、面向监管机构的特定证明和合规文档、专用镜像、气隙更新、区域特定分发、迁移协助、紧急访问支持、定制策略包，以及远超标准生命周期终止日期的长期支持。

一旦镜像强化成为基本条件，供应商就会有动力在新的方向上创新，超越基础安全，去改进他们的产品和用户体验。回顾汽车行业，最初对三点式安全带的强制要求，催生了一系列补充性创新，如安全带预紧器、安全气囊和碰撞吸能区。通过将安全问题“标准化”，汽车制造商得以将重心和资源转移到其他更能提升吸引力的创新上，例如更佳的车载娱乐系统和符合人体工程学的座椅控制。

你需要为高级赛车安全带、四点式安全带或老式汽车的维护计划额外付费。但普通的安全带是标准配置。然而，这个标准最好能结合软件特有的属性来运作。

如果免费的强化镜像足够简单，让每个人都能轻松应用到自己的应用程序中，那么它们将对所有人都有益。这意味着，在强化镜像广泛普及之前设计和部署的每个应用程序，都可以被轻松地改造升级。

而且，如果用户选择更换其技术栈，强化镜像也应该能轻松适应，只需最小的工作量。它给人的感觉应该更像是更换雨刮器，而不是进行一次大手术——这是任何业余爱好者、学生、小型企业、初创公司或企业平台团队都能轻松完成的基本任务。

克服价格和复杂性对普及的阻碍

对于那些投身关键开源项目的业余爱好者、学生和独立维护者来说，为强化镜像付费从来都不是一个可选项。对于初创公司和小型企业而言，为强化镜像付费需要与无数其他预算优先项竞争。结果就是，许多人根本不付费，他们只是简单地运行在搜索中第一个出现的基础镜像。

但即便是那些拥有充足安全预算的组织，也常常在运行臃肿且未打补丁的镜像。问题并不总是钱，而是专业知识和启动所需的精力。构建一个强化流水线，需要许多团队并不具备的特定专业知识。

这就是为什么仅仅免费是不够的。它必须既免费又简单。Let’s Encrypt 不仅仅消除了证书的成本，它还自动化了整个颁发和续订流程。你不需要理解复杂的 公钥基础设施 原理，只需运行一个命令，就能获得 HTTPS。

强化镜像需要采用同样的方法。用户只需拉取镜像，就能立刻获得安全默认设置。无需自己构建流水线，无需编写复杂的策略，也无需维护一套证明基础设施。所有的复杂性都由提供商来承担。

将“Let’s Encrypt”模式应用于容器安全

这并非一个抽象的、呼吁“行业”做得更好的口号。容器基础设施以及基于此构建的供应商们，正处于一个绝佳的位置来推动这件事成为现实。

我们已经可以预见这样一个世界：强化镜像作为任何人都能访问的免费基线而存在，只需一个功能开关即可启用。一家初创公司在成立第一天就能获得与企业相同的基本安全性。当然，他们不会获得服务水平协议、FIPS 验证或专属支持。但他们获得了“安全带”，这让他们自身及其所处的环境都变得更加安全。

当每个主流镜像都默认经过强化时，运行未强化的基础镜像就会成为需要特别解释的例外。默认设置就此改变，就像 HTTPS 一样。最终结果是整个生态系统变得更加安全。目前已有厂商 免费提供强化镜像。我们希望所有“销售”强化镜像的公司都能效仿。这是在默认状态下实现更安全软件供应链的最佳途径。

在外保持安全

让强化镜像像安全带一样普及和经济。让它们变得标准、平凡且无处不在。供应商们仍然可以赚钱，只是不再通过限制基本安全功能来赚钱。我们有 HTTPS 和 TLS 的成功先例可循。经济学上是完全可行的，因为规模化之后，边际成本会大幅下降。

容器是实现的机制。现在，是时候改变默认设置，系好软件世界的安全带了。

在云栈社区，我们持续关注并分享容器安全与软件供应链防护的前沿实践与思考。

引用链接

[1] Let's Make Hardened Images the Seatbelts of Software
[2] 强化容器镜像
[3] HTTPS
[4] TLS
[5] Amazon Web Services
[6] Microsoft
[7] 云原生计算基金会 (CNCF)
[8] Docker 官方镜像 (DOI)
[9] 拼写错误抢注式 Node.js 软件包
[10] 依赖混淆攻击
[11] SLSA
[12] 软件物料清单 (SBOM)
[13] 漏洞可利用性交换 (VEX)
[14] 公钥基础设施
[15] 免费提供强化镜像