如何正确实现图像加固（以及容器安全防护）

虽然我可能因为自己在 Docker 公司工作而存在一定的偏见，但可以肯定地说，容器已成为当前运行应用程序的主要技术形式。同样重要的是，那些以人工智能为核心功能的下一代应用程序，早已开始在容器环境中运行了。既然整个世界都在依赖容器技术来运行各种系统，那么确保容器安全就显得至关重要了。

很遗憾地说，大多数自称提供容器安全保障的组织实际上并没有真正做到这一点。尤其令人担忧的是，那些号称能够提供高度安全容器的供应商越来越多，但他们却忽略了实现容器安全所必需的关键要素。诚然，我们对容器安全有着自己的深刻见解——我们运营着全球最大的容器托管与管理基础设施。需要明确的是，我们公司的未来命运直接取决于人们是否继续认为容器是安全的。因此，我们在这个问题上确实有着切身的利害关系。

容器安全的基本要素

话虽如此，作为 Docker 的首席安全工程师，同时也是一个在容器技术领域拥有丰富经验的人，我想阐述一下我们对容器安全的看法。其实，我们的观点非常简单：实现最高级别的容器安全以及构建更加安全的容器镜像，关键在于五个基本要素。这些要素分别是：

最小化攻击面：经过适当加固的容器镜像中仅包含绝对必要的软件组件。这意味着会移除大部分默认存在于软件发行版中的库、代理程序及模块——这些组件虽然能提供某些功能，但同时也增加了系统的复杂性，并增加了系统遭受安全漏洞攻击的风险。通过我们的加固流程，容器中的安全漏洞风险平均可被降低98%以上。

一份100%完整的软件物料清单。这被视为最低要求，必须做到信息完全准确（符合CISA的指导原则），且无需设定任何最低信息深度要求。该清单应包含精确的库存信息，涵盖直接依赖关系、间接依赖关系以及各种明确的组件关联关系。为了确保软件物料清单的真实性，必须能够通过诸如SPDX或CycloneDX这样的开放标准、PURL等标准化的组件标识符，以及对信息缺失部分的如实披露，实现对其来源的完全追溯。

可验证的构建来源追踪机制能够从源代码到最终部署的软件产品建立起完整的监管链。SLSA的第三级构建来源追踪功能能够提供关于软件的构建内容、构建地点以及构建过程的不可篡改的证明。如果你不知道软件是如何构建的、在何处构建的，也不知道是谁构建的，那么你就无法确保该软件没有被篡改过。

标准化的可利用性评估机制明确了哪些漏洞会影响特定的部署环境。OpenVEX提供了关于漏洞状态的机器可读信息，使得审计人员和合规性检测工具能够独立地处理这些评估结果，并有效地利用安全漏洞清单（SBOMs）。VEX所提供的数据透明性与互操作性使得容器安全防护成为可能，也让相关团队能够将精力集中在真正存在的安全风险上。

加密验证能够确保数据的真实性和完整性。像 Sigstore 和 Cosign 这样的现代技术实现了带有公开验证机制的签名功能，使得任何人无需依赖专有基础设施即可验证这些签名。签名信息及其生成过程必须具有透明性，并且易于被生成或查询。

实现100%的透明度，以将这些关键要素紧密联系在一起。上述五个要素都必须保持高度透明——不仅体现在它们所产生的结果上，还体现在它们生成各类证明文件、证据以及任何相关数据或声明的方式上。这意味着要使用公开来源来获取漏洞信息（例如国家漏洞数据库NVD、安全漏洞信息发布平台、语言生态系统安全预警、GitHub安全公告等），并且确保这些信息能够以透明的方式定期更新。当KEV（已知被利用的漏洞）目录中列出新的漏洞时，透明度能够确保各方在处理这些漏洞时无需进行任何协商，从而实现共识。具体来说，这意味着要将漏洞的筛选流程和标准公之于众，让用户能够了解整个筛选过程；同时，还要让SBOM（供应链安全清单）的生成过程保持透明，让用户明白这些清单是如何生成的。最终，彻底的透明度会将安全保障工作从一种基于信任的机制转变为一种可验证的过程——在这种过程中，企业可以证明自身的安全防护措施，审计人员可以验证这些措施的有效性，而客户也可以独立评估企业的安全声明是否真实可信。

当然，容器安全措施也延伸到了容器运行时环境中，以确保容器在运行过程中遵循最高的安全标准。同时，这些安全措施还实现了对整个容器生命周期的持续监控，并确保组织政策得到有效执行。关于 Docker 在这一领域的具体举措，我会在后续的文章中详细阐述。

为什么你需要核实所有供应商关于“加固镜像”的说法

对于那些希望提升容器安全性的企业来说，我想明确指出：任何无法满足这些安全要求的“加固版”容器镜像，其实都只是虚假宣传罢了。遗憾的是，目前有不少提供加固版容器镜像的供应商根本无法满足这些安全标准。以下是我们用户和客户向我们反映的、关于这些竞争对手所提供的加固版容器镜像存在的一些问题：

那些经不 起仔细推敲的供应链成分清单：一个不包含任何 npm 包的 Node 服务器，实在是个自相矛盾的现象。然而，事实确实如此。他们难道真的重新编写了Node.js，从而彻底消除了对 npm 的依赖吗？我认为并非如此。这意味着他们在生成的供应链成分清单中遗漏了关键信息。
SBOM中缺少传递性依赖关系：CISA的指导原则非常明确——每个SBOM都必须包含所有依赖关系。如果不将这些依赖关系包含在内，虽然可以省去处理这些依赖关系安全性的麻烦，但这种做法是错误的。
专有且不透明的CVE编号体系：供应商无权自行决定某个CVE是否具有实际意义，也无权自行设定其严重等级。公开、透明的CVE信息库正是为了解决这类问题而存在的。任何拒绝公开自己用于CVE评估的具体方法或流程，并且拒绝在他人要求时提供这些信息的供应商，其实都在隐瞒某些重要信息。

关于 SLSA 构建等级的错误说法：SLSA 构建等级 3 是一个二进制判断结果——要么符合要求，要么不符合要求。将某个构建版本称为“过渡性版本”，其实就等于在评估表中勾选了“不符合要求”这一选项。

为什么我们要彻底改变对容器安全的认知方式（并重新设定相关预期）

供应链攻击对开源生态系统的危害已经变得难以控制，这早已不是什么新鲜事了。全球最顶尖的黑客们正利用最先进的恶意软件技术，专门针对供应链发起攻击——因为这些攻击方式是破坏整个生态系统最有效的手段之一。供应链攻击可能会让大量组织面临严重安全风险，导致数据泄露、勒索软件攻击、敲诈勒索以及间谍活动。由于我们在容器生态系统中处于核心位置，因此每当容器供应链遭到破坏时，我们也会受到牵连。

这就是我写这篇文章的原因。Docker专门设计了这些加固后的容器镜像，旨在同时满足上述五个核心要求，并确保整个运行过程、输入数据以及输出结果都具备100%的透明度。我希望让任何平台、团队、安全团队、首席信息安全官，甚至是首席执行官或企业领导者都能轻松地提出恰当的问题，从而判断他们的容器安全措施是否有效，以及他们购买的加固镜像是否真的能够兑现其承诺。顺便提一下，容器安全的重要性不言而喻；因此我们认为，这些加固镜像应该对所有人来说都是可负担的。正因如此，我们现在以极其合理的价格提供这些镜像，让即便是只有两名员工的初创企业也能使用它们。

容器安全其实并不复杂，也不需要高深的科技手段。容器安全的本质在于追求彻底的透明度、诚信，以及为用户提供最优质的服务。在理想的世界中，每个人都能够以正确的方式来保障容器安全；每个组织都能轻松获得那些默认就具备强大安全防护功能、且完全透明的容器产品。

在这个理想的世界里，Docker公司会变得更强大，用户会得到更多好处，企业也会受益匪浅，整个世界也会因此变得更加美好。坦率地说，我们的竞争对手也会因此受益，他们的产品也会变得更优秀。这其实是一件好事。这不仅仅是一篇推销文案，也不只是一篇技术性的长篇大论；我想，你可以把这称为我们的使命吧。让技术世界变得更加安全，这一点至关重要，而这正是我们追求的目标。

原文出处： https://www.docker.com/blog/100-transparency-and-five-pillars/

联系人：	王春生
Email：	chunsheng@cnezsoft.com