1：容器图片中的电子邮件地址

我们中的许多人将联系电子邮件信息放入了我们的容器图像中，也自然会认为用户会发现联系图像作者会有所帮助，如果您在一家大型公司工作，或者曾经在安全部门工作过，那么对您来说完全不应该公开单个公司的电子邮件地址，无法在公共容器中找到它们图片。但这不是我想到的。在开源世界中，我们将自己的名字（或至少是我们的在线身份）标记在我们所做的工作上，这样做似乎很自然。

如果我们从事开源项目，我们仍然很容易遭受鱼叉式钓鱼攻击，但是在安全性，信任和声誉之间需要折衷。如果用户能够看到某个项目背后的个人开发人员，他们就会对该项目有更大的信任，而个人则通过将自己的名字公开发表在他们编写的代码上来建立自己的声誉。这些担忧可能超过安全风险。相比之下，巨人公司的品牌声誉激发了对客户的信任，并在员工的简历上表现出色，因此没有必要在代码或容器图像上贴上个人名字。

2：图像扫描的功能远不止这些

有很多产品会扫描您的容器映像，以告知您它们是否包含已知漏洞，他们正在扫描图像，寻找数据库中记录的已知漏洞，事实证明，在容器映像中检测漏洞的方式有很多微妙之处，它是一个容器映像这一事实与这种误报没有区别，但是当我们考虑容器层时也存在类似的问题，因此我们知道它很容易受到攻击，如果扫描程序仅逐层报告漏洞，当部署的代码中存在漏洞时，可能会发生第三种误报，但只有在与另一个组件进行交互时才会起作用。如果您不使用该组件，则该漏洞实际上不会影响您的部署，考虑通过网络访问利用的漏洞，如果容器没有任何网络接口，则存在此漏洞无关紧要。

这些误报不仅使人烦恼，还使人们难以理解生产中的代码是否确实存在问题，习惯于忽略误报的人越多，当出现明显的真实肯定时，他们注意到和做出反应的可能性就越小，

3：检测与预防

根据定义，零日漏洞的引入与检测之间存在时间间隔。在这个空白中，虽然漏洞未知，但是图像扫描无法帮助您避免部署该漏洞，我们控制了已知的未知数，但这是我们真正需要担心的未知数，有，即使采用严格的策略，您也会将一个漏洞部署到生产中，因为无法阻止您不知道的问题的部署。如果利用了该漏洞，它将以某种方式更改代码的行为-可能写入异常文件，或发送意外的网络流量。

弄清楚什么构成“正常”行为可能并非易事，但是容器化微服务体系结构实际上在这里有所帮助

容器中的功能量越少，就越容易定义应做的事情的限制-这为我们提供了增强安全性的机会，例如，在容器内运行的微服务通常仅使用很少的端口就只能与少量其他服务进行通信。如果您开始发现相同的代码也试图在完全不同的端口上发送请求，您可能会认为这是可疑的，需要停止并进行调查，同样，通常，您可以预测微服务应访问的文件或可执行文件集，别的就是抽烟的枪，检测异常行为意味着您可以发现问题存在，并且可以采取进一步措施来禁止意外行为的发生。