软件供应链的脆弱性已经成为一个不容忽视的问题。如今，市面上涌现出越来越多的强化容器产品，这似乎成了行业应对安全危机的主要手段。
几年前，安全的容器镜像还只是少数人的关注点。如今，它们已经变得无处不在。业界普遍采取了一种“末端治理”的思路——在软件组装线的最后环节加强检查（更多的扫描、更多的检测），却很大程度上忽视了上游组件的来源、集成与验证方式是否可靠。
我参与创立的公司在四年前就开始专注于软件供应链安全领域，远早于“强化容器”成为一个热门品类。过去一年的市场变化清晰地表明，强化容器确实有其价值，但它们并非业界应当全力解决的核心问题。真正的问题在于，我们是否能够信任所使用的软件来源？为什么说直接从源代码构建开源软件，才是保护整个软件供应链的唯一可行路径？
强化容器的优势与陷阱
容器技术之所以能取得成功，关键在于它提升了开发者的效率与速度，而不是因为它让系统变得更安全。Docker 早期的流行，正是源于其决策和默认设置优先考虑了灵活性，但这恰恰与安全团队所期望的背道而驰：默认用户是 root、到处都有 shell、包管理器无处不在，而 Docker Hub 上的“官方镜像”在其存在的大部分时间里，几乎一直是个安全噩梦。安全，成了一件可以“稍后再处理”的事情，通常的做法是扫描并修补生产环境中暴露出来的问题。
这种“事后补救”的思维模式，使得对已成型的工件进行加固成为了常态。它要求团队不停地修补漏洞、剥离不必要的二进制文件、重建镜像、调整配置、运行策略检查，并周而复始地循环这个过程。这是一项繁重的工作，对许多组织而言是必要的，但它终究只是治标，未能触及根本。
一个经过加固的镜像，仍然无法回答那个最重要的问题：你真的清楚它里面包含的每一个软件组件，最初是从哪里来的吗？
当今的容器生态系统，很大程度上是由不透明的二进制文件、临时拼凑的构建流水线，以及那些从一开始就没考虑过可重现性或可审计性的 Dockerfiles 所构建的。
几年前，我在参与 Google 的 Distroless 项目时，就亲身遭遇了这个问题。该项目的目标很明确：生成最小化的、可直接用于生产的容器镜像，不包含 shell、包管理器或其他非必要的攻击面。我们很快意识到，试图通过对现有成品进行事后的“外科手术”式加固来可靠地实现这一目标，是行不通的。你必须从一开始，就能完全控制软件的构建方式。
“强化容器”市场的虚假承诺
过去一年里，越来越多的供应商涌入市场，推出了各种形式的“强化容器”产品。这客观上推动了一场迟来的行业讨论，让更多组织认识到，当前这种消费开源软件的方式是不可持续的，这本身是一件好事。然而，这些公司的宣传焦点往往单一地集中在“零 CVE（常见漏洞和暴露）”和“容器加固”上。虽然强化容器很重要，但大多数供应商选择这个切入点，是因为相比于修复整个软件供应链的根源问题，这要容易得多。
广义上，当前的“强化容器”市场主要有两种方法论：1) 事后强化 和 2) 从源代码构建。
我所推崇的路径属于后者——从源代码开始构建，其中的一些安全配置自然会产出强化容器。我们并非试图去强化一个既有的、来路不明的镜像；我们是从零开始，重新构想软件应该如何被安全地构建出来。如今，我们能够在一个完整的发行版体系下，从源代码自动化构建开源软件，并具备构建一切所需的安全保障能力。这是保护整个软件供应链唯一诚实可靠的方法。强化容器的出现，是因为客户有这方面的需求，但它们是这一安全构建过程所产生的结果，而不应成为最终目标。
目前市场上的大部分产品，仍然围绕对现有成品的“事后强化”展开。但如果不具备从源代码构建的能力和属于自己的发行版体系，就不可能真正提供拥有自主软件选择权的强化容器。有人认为，维护自己的发行版是一个缺点。但我完全不这么看——没有其他诚实的方法能做到这一点。而且，当你依赖于他人提供的、不透明的强化镜像时，你实际上已经陷入了另一种形式的锁定：不透明的二进制文件、被遗弃的旧镜像，以及无人记得如何重现的临时构建管道。
最终，仅仅将目光聚焦在“强化容器”上，会让我们忽略一个更重要的观点。甚至“强化”这个词本身就有问题：它暗示你正在处理一个本身有缺陷的东西，并试图在事后去修复它。
将焦点转向软件供应链安全
我们的客户需要强化容器，所以它们不会消失。但真正需要思考的问题是：在一个开源软件以惊人速度和规模发展的世界里，这种不受控的软件供应链模式是否还能持续？某种程度上，一个组织要么真正了解其软件的构建和维护方式，要么就不应该将其发布出去。
展望未来，我预测有几个趋势将继续塑造这个行业。当前对强化容器镜像的热捧是可以理解的应急反应。但长期、可持续的安全性，并非来自于在流程末端不断收紧管控。它源于我们是否有能力信任软件在最开始被构建出来的方式。
引用链接
[1] Hardened containers don‘t fix a broken software supply chain: https://thenewstack.io/hardened-containers-dont-fix-a-broken-software-supply-chain/
[2] 供应链安全: https://thenewstack.io/securing-the-software-supply-chain-a-2035-blueprint/
[3] 强化容器: https://thenewstack.io/hardened-containers-arent-enough-the-runtime-security-gap/
[4] Dockerfiles: https://thenewstack.io/docker-basics-how-to-use-dockerfiles/
[5] Google: https://cloud.google.com/?utm_content=inline+mention
对于DevOps和云原生领域的安全实践，你有何见解？欢迎到云栈社区的云原生/IaaS板块与其他开发者交流探讨。
发表于 1 小时前
|
查看: 1|
回复: 0
