在容器中运行的易受攻击的东西仍然是易受攻击的东西

有人说——而且不仅仅是我说的——加密的恶意代码仍然是恶意代码。 加密并不能改变这一点，除了可能使安全性和应用程序基础设施对网络传输产生盲目影响。

在容器中运行的应用程序和平台也是如此。 如果应用程序存在漏洞，那么无论它是在操作系统、虚拟机还是容器中运行，它都存在漏洞。 如果应用程序在数据中心存在漏洞，那么它在云端也会存在漏洞。 反之亦然。

容器并不是为了神奇地保护应用而设计的。 它们在网络层提供一些基本的安全性，但网络不是应用。 应用有其攻击面，包括其代码和接口（API）以及协议（HTTP，TCP）和所需的应用程序堆栈。 通过在 IP 表中添加条目或以其他方式限制来自入口到容器化环境的入站请求，这些都不会发生改变。

我提出这个问题的原因要感谢Sonatype 的 2017 年 DevSecOps 调查。 其中，超过 2200 名受访者中，88% 的人认为容器安全很重要，但只有 53% 的人利用安全产品来识别容器中存在漏洞的应用/操作系统/配置。

该统计数据的前两个部分——应用和操作系统——引起了我的注意，因为它们是完全实现的应用程序堆栈的两个组成部分，不一定根据位置或操作模型（云、容器、虚拟化等）而改变。 具有 SQLi 或 XSS 漏洞的应用程序或 API 在模型之间移动时并不会神奇地受到保护。 这个漏洞存在于代码中。 对于平台来说也是如此，它无疑是应用程序安全堆栈的一部分。 如果将应用程序从传统的基于操作系统的模型转移到容器化模型，那么在 Linux 上运行时 Apache 中 HTTP 标头的处理漏洞仍然存在。

重要的是 - 甚至是必须的 -无论应用程序在何处或以何种形式部署，我们都要继续识别整个应用程序堆栈中的漏洞。

当迁移到容器时，保留对传统应用程序已经采用的应用程序保护也同样重要。 Web应用防火墙对于部署在容器中的应用程序、部署在云中的应用程序以及部署在传统环境中的应用程序同样有益。

调查发现受访者还使用了其他安全工具，例如静态和实时扫描解决方案（ SAST、DAST、IAST 和 RASP ）。 虽然 Web应用防火墙 (WAF) 的使用超过其他工具，但 SAST 和 SCA（源代码分析）也很常见。 SCA 是一种在交付前根除问题的静态方法。 我会指出日期，并指出像lint这样的工具属于 SCA 工具类别，虽然这些工具不会实时暴露由代码（以及与用户）交互而导致的漏洞，但它们可以发现开发人员犯下的一些更常见的错误，这些错误会导致内存泄漏、崩溃或臭名昭著的缓冲区溢出。

我知道你在想什么。 你在想，“Lori，我刚刚阅读了Stack Overflow 的 2017 年开发者调查结果，JavaScript 是迄今为止开发者首选的语言。 而且 JavaScript 是解释型的，所以所有这些缓冲区溢出和内存泄漏问题都只是你用 C/C++ 编码时的不愉快回忆。”

除了 JavaScript 和其他现代解释型语言之外，最终还是以更接近电路板的语言来实现，比如 C/C++。 正如过去所表明的那样，如果一个人足够聪明，他就可以利用这一事实来利用系统漏洞。

即使这不是一个问题，任何基于所使用的库或滥用的系统调用的代码中都存在许多其他漏洞，这些漏洞会破坏服务器端的安全性。 目前的调查表明，80%的应用程序是由开源组件组成的。 Sonatype 的调查进一步指出，从 2014 年到 2017 年，与开源组件相关的已证实或疑似违规行为增加了 50%。 其中许多都是用容易出现更多错误的语言编写的，这既因为它们的控制较差，也因为精通这些语言的开发人员越来越少。 

关键在于任何代码都容易存在漏洞。 由于代码是应用程序的构建块，而应用程序是当今业务的门面，因此无论它们在何处或如何部署，对其进行扫描和保护都非常重要。

容器或云。 传统的或虚拟的。 应该扫描所有应用的漏洞并防止平台和协议漏洞。 时期。

应用程序应该在开发过程中进行彻底的扫描和测试，然后在生产中再次测试。 两者都是必要的，因为分解谬误告诉我们引入新组件会改变基线。 新的互动可能会使之前未被发现的弱点凸显出来。

为了保护应用程序，请考虑以下几点：

• 在开发中使用代码和应用程序分析工具。 如果可能的话，将它们构建到 CI/CD 管道中。
• 在生产中再次测试，以防与其他组件/应用程序的交互出现问题。
• 留意协议和平台漏洞，以及你可能使用的第三方库中发现的漏洞
• 将 Web 应用防火墙集成到您的架构中。 即使您不在阻止模式下使用它，在发现协议/平台零日漏洞或库漏洞时它也是无价的资源。

注意安全！