威胁行为者将如何攻击和利用容器？这是我不断思考的一个问题。我在这个领域工作了二十多年，我觉得我应该有一个答案。但我不这么认为。
相反，我有很多不同的想法，但我无法真正确定其中哪个是正确的。这种犹豫不决的部分原因是我花了很多时间在“遗留”世界中学习安全性。容器并没有真正的类似物。当然，虚拟机 (VM) 通常与容器混为一谈，但它们永远无法像容器一样扩展。它们的用途也与容器完全不同。我花了一段时间来调整我的想法并了解容器实际上适合攻击面的位置。
针对容器化环境的攻击的公开示例非常有限。这些违规行为几乎总是与加密货币挖矿相关，这是严重的攻击，但我的事件响应者发现它们令人印象深刻。另一个共同点是，它们主要是配置错误的结果，无论是在 Kubernetes 还是云帐户中。到目前为止，动机和策略的结合还不是很鼓舞人心。
旧路
远程代码执行（RCE）漏洞长期以来一直是计算机安全领域的主要关注点。仍然如此，但是这种思维方式如何应用于容器呢？人们很容易立即将 RCE 视为主要威胁，但这似乎不是处理容器的正确方法。一方面，容器的寿命通常很短—— 44% 的容器存活时间不足五分钟 ——所以入侵者必须速度快。
这种方法还假设容器暴露在互联网上。当然，有些容器是这样设置的，但它们通常非常简单，并且使用经过充分测试的技术，例如 NGINX。这些应用程序可能存在零日漏洞，但它们非常有价值且难以获得。我的经验告诉我，很多容器是在内部使用的，并不直接连接到互联网。在这种情况下，RCE 场景会变得更加困难。我应该提一下 日志4j，尽管这些类型的漏洞有可能被远程利用，即使易受攻击的系统不在边缘。
新方式
如果 RCE 不是容器面临的最大威胁，那么什么才是？容器是否受到威胁者的关注？是的，容器及其支持基础设施太重要了，不容忽视。容器编排软件使容器化工作负载能够扩展到难以想象的数量。使用趋势也在增加，因此您可以确定它们将成为目标。它们只是不能被认为是通过 RCE 漏洞获取的服务器。
相反，事实恰恰相反。容器需要从内到外受到攻击，而不是从外向内攻击。这本质上就是供应链攻击的作用。当您开始了解容器的构建方式时，供应链是针对容器的极其有效的攻击媒介。容器以定义文件开始，例如 Dockerfile，它定义了容器运行时将包含的所有内容。一旦构建，它就会变成一个映像，并且该映像可以无数次地转化为工作负载。如果该定义文件中的任何内容受到损害，那么运行的每个工作负载都会受到损害。
容器通常（但并非总是）是专门为执行某些操作并退出的应用程序而构建的。这些应用程序几乎可以是任何东西 - 重要的是要了解有多少是使用其他人编写的库（闭源或开源）构建的。 GitHub 拥有数百万个项目，而且这并不是唯一的代码存储库。正如我们在 SolarWinds 中看到的那样，闭源也容易受到供应链攻击。
供应链攻击是威胁行为者进入目标容器环境的好方法。如果损害未被注意到，他们甚至可以让客户的基础设施为他们扩大攻击规模。正如我们在 Codecov 漏洞。但由于这一切都是新事物，而且我们的思维仍然植根于过去的问题，因此很难察觉。
未来之路
与解决大多数问题一样，可见性通常是一个很好的起点。很难修复你看不到的东西。为了保护您的容器，您需要了解容器本身以及构建它们的整个管道。漏洞管理是一种必须集成到构建管道中的可见性。我还将包括其他静态分析工具，例如寻找泄露秘密的工具。由于无法真正预测供应链攻击的情况，因此运行时监控变得至关重要，以便您准确了解容器正在做什么。
