软件供应链问题日益突出，强化容器虽有价值，但仅治标不治本。真正核心在于信任软件来源，需从源头构建开源软件以确保整个供应链安全，而非依赖事后强化。
译自：Hardened containers don't fix a broken software supply chain
作者：Dan Lorenc
软件供应链已崩溃，而近期激增的强化容器产品是业界的应对之策。
几年前，安全容器镜像还是一个小众关注点。如今，它们无处不在。业界通过在组装线末端加强检查（更多的检查、更多的扫描）来应对，却在很大程度上忽视了上游部件的采购、组装和验证方式。
我共同创立的公司在四年前就开始致力于软件供应链安全，远在强化容器成为一个类别之前。过去一年清楚地表明，强化容器很有价值，但它们并非业界应该努力解决的问题。真正的问题在于信任软件的来源，以及为什么直接从源代码构建开源软件是保护整个软件供应链的唯一途径。
强化容器的优势与陷阱
容器之所以成功，是因为它们提高了开发人员的速度，而不是因为它们使系统更安全。Docker之所以流行，是因为它早期的决策和默认设置优先考虑灵活性，但这与你从安全角度所希望的恰恰相反：默认用户是root，shell无处不在，包管理器无处不在，而Docker Hub的“官方镜像”在其整个存在期间几乎一直是安全噩梦。安全成了你后来才处理的事情，通常是通过扫描和修补生产环境中出现的任何东西。
这种“我们稍后再修复”的心态使得事后强化成为常态。它要求团队修补漏洞、剥离二进制文件、重建镜像、更改配置、运行策略镜像，并一遍又一遍地重复这些步骤。这是一项艰巨的工作，对许多组织而言是必要的。但它治标不治本。
强化镜像并不能回答最重要的问题：你真的知道它里面的软件来自哪里吗？
当今的容器生态系统大部分是由不透明的二进制文件、临时构建管道以及从未设计成可重现或可审计的Dockerfiles构建的。
几年前，我在从事 Google 的Distroless项目时亲身遇到了这个问题。那里的目标很简单：生成最小的、可用于生产的容器镜像，不包含shell、包管理器或不必要的攻击面。我们很快了解到，你无法通过事后强化工件来可靠地实现这一目标。你必须从一开始就控制软件的构建方式。
“强化容器”市场的虚假承诺
过去一年里，越来越多的供应商进入市场，提供了某种形式的“强化容器”。这有助于推动一场迟迟未到的对话。现在，更多的组织认识到，消费开源软件的现状是不可持续的，这是一件好事。然而，所有这些公司都以零常见漏洞和暴露（CVEs）以及强化容器为单一焦点。虽然强化容器很重要，但大多数供应商之所以关注它们，是因为这比修复软件供应链更容易。
广义上讲，“强化容器”市场有两种方法：1) 事后强化 和 2) 从源代码构建。
我们的方法是从源代码构建，其中一些配置会生成强化容器。我们并非一开始就尝试强化现有镜像；我们是从头开始重新构想软件的构建方式。如今，我们在一个完整的发行版中从源代码构建开源软件，并具备安全构建一切所需的自动化功能。这是保护整个供应链的唯一诚实方式，而强化容器之所以出现，是因为客户需要它们。但它们是结果，而非目标。
目前市场上的大部分仍围绕事后强化工件展开。但如果没有从源代码构建和自己的发行版，就不可能提供具有真正软件选择的强化容器。人们说，缺点是你需要自己的发行版。我根本不认为那是一个缺点。没有其他诚实的方法可以做到。而且，通过使用强化镜像，你已经陷入了锁定——不透明的二进制文件、被遗弃的镜像和无人记得如何重现的临时构建管道。
最终，仅仅关注强化容器会忽略更重要的观点。甚至这个名称本身也是错误的：它暗示你正在处理一些不完善的东西，并试图事后修复它。
将焦点转向软件供应链安全
我们的客户依赖强化容器，所以它们不会消失。但真正的问题是，在一个开源软件以如此速度和规模发展的世界里，非受控的软件供应链是否可持续。在某种程度上，组织要么了解其软件的构建和维护方式，要么就不应该发布它。
展望明年，我预测有几个趋势将塑造这个行业：
当前强化容器镜像的热潮是可以理解的。但长期的安全性并非来自在流程末端收紧控制。它来自于能够信任软件最初的构建方式。
