容器脆弱性风险：工具和优秀实践

容器正在迅速成为云原生生态系统中计算和工作负载部署的实际形式。

云原生计算基金会(CNCF)最近发布的云原生报道显示：96%的组织不是在积极地使用容器和Kubernetes，就是在对容器和Kubernetes进行评估。容器的优点是众所周知的，比如可移植性、一致性和高效性。但同时，容器也隐含着一些安全问题。

容器安全是一个复杂的事情，它类似于是网络安全的一个拓展。容器安全要求人员、流程以及技术的结合，其中人员是最重要的部分。因此，那些期望广泛应用容器的组织应该帮助现有的职工提高技术水平，并引进一些具有必要技能的新员工，从而确保一个安全的云原生操作模式。其中，容器是该模式的关键组成部分。

目前，最大的政府机构和技术方面的权威对软件供应链安全的关注正不断升温，这需要达到一定的严格度和成熟度，然而大多数组织都达不到该水平。在密切关注行业最佳实践和指导的基础上，通过实施下述的实践和工具，我们就可以更加接近安全容器使用预期的最终状态。

容器，云安全中相互交织的部分

首先，了解容器在云环境中的角色以及容器之间的交互是非常重要的。云原生生态系统通常具有云安全的四个C：云(cloud)、集群(cluster)、容器(container)以及代码(code)。云的脆弱性、Kubernetes 集群以及应用程序，其本身就具有一些安全问题，但这些超出了这里所要讨论的范围。

容器安全并非微不足道的小事。特别是由于容器存在的状态，例如映像或者运行时的容器，以及容器中的层和代码。CNCF发布的白皮书《Cloud-Native Security》在推动更好地了解云原生应用、容器及其生命周期方面，起了个好头。

注意容器可移植性的危险

容器的可移植性是它最为显著的优点之一。但这既是优点，也是缺陷。由于容器通常是在多租户架构上运行的，所以如果向一个容器中引入脆弱性，然后进行分发，那么实际上就是把该脆弱性发送给了使用该映像的所有人。并且还可能将它运行的环境置于风险之中。这意味着容器映像的可移植性以及分布式等特性可以被广泛地利用和共享。这使得容器与其他问题联系在一起，例如：开源代码、基础设施即代码(laC)。这些都是本身就带有脆弱性的。

容器通常是由外部的开发人员构建，然后分发给企业的。这意味着诸如安全编码实践和容器安全最佳实践等是一个很好的起点，但后者意味着什么呢?

在容器投入生产之前，对其进行扫描以检测脆弱性

已经出现的一些基本的最佳实践包括：通过扫描(CI/CD)管道中的容器来防止脆弱性被引入到运行时的生产环境。Anchore和Trivvy 等开源代码，以及Snyk等行业领导者都是很好的选择。

在管道部署活动期间扫描容器，更为广泛地推动了安全的左移。在管道中捕捉容器的脆弱性，可以防止脆弱性被引入到生产环境中，同时也可以预防不法分子趁虚而入。这比直接在生产环境中修补脆弱性，更加的高效，同时也降低了风险和成本。

因为许多容器是开发人员用来部署应用而创建的，所以这些工具可以帮助他们解决问题。这比创建一个可能会人手不够，且负担过重的安全团队来进行反复沟通，更加的有效。从而也避免了价值交付瓶颈期的产生。

尽管如此，在管道中扫描容器映像并不是一个万全之策。容器映像通常情况下被存储在存储库中，一旦部署到生产环境，就将以运行状态存在。所以关键点是：在两种环境中都要扫描它们。新漏洞是不断出现的。因此，简单地从存储库中提取以前扫描过的映像，并在不进行新扫描的情况下部署它，就可能会忽略掉一些自上次扫描以来发现的新漏洞。

同样的道理也适用于生产运行中的脆弱性。由于潜在的访问控制不良情况的发生，运行状态下的的容器可能已经遭到了篡改。我们可以通过识别运行时容器中的脆弱性，并利用工具通知相关工作人员来进行相应的调查以及潜在的干预。

使用容器映像签名

映像签名是保护容器工作负载的另一个关键活动。我们都知道：网络安全的CIA三要素：保密性、完整性以及可用性。容器映像签名就类似于一种确保容器映像完整性的工具。它能够确保你正在使用的容器映像是没有被篡改，并且可信任的。这部分的操作可以集成到DevOps工作流中，也可以在注册表中完成。

对于容器映像签名，有若干选项可供选择。最值得关注的其中一个是Cosign，它支持映像签名以及验证和存储。同时，它还支持一些其他选项，比如硬件、密钥管理服务(KMS)、以及自带的公钥基础设施等。

另一方面，无钥签名正逐渐崭露头角，并且受到了像Chainguard等创新团队的支持。无钥签名的本质是支持“短期”密钥，这种“短期”密钥与身份绑定，并且仅在进行签名活动的这段时间内存在。

为容器映像构建软件物料清单

即使是容器，同样也无法避免软件供应链中的一些安全问题的。企业正在设法利用工具来为其容器映像生成软件物料清单 (SBOMs)。其中最著名的一个例子是Anchore的Syft 工具。Syft 可以为容器映像创建SBOM，并把此部分操作集成到CI/CD工作流程中。同时，Syft还可以使企业对其在容器生态环境中运行的软件有更深入的了解，并在其他Log4类型场景发生时更好地做出响应。

这种程度的可视化在传统上是难以捉摸的。但在白宫和相关联邦机构(如网络安全行政令EO)命令的指导下，各组织开始越来越关注软件供应链安全。NIST等组织发布了更新的安全软件开发框架(SSDF)，该架构要求将SBOM应用到归档和软件发布保护等活动中。随着SSDF的发布，对于安全开发实践的关注度将会越来越高。

基于容器映像的SBOM需求是在推动认证的发展。这一点是TestifySec以及NIST在其软件供应链安全指南中所倡导的。NIST要求对SSDF进行认证，而SSDF则要求使用SBOM。还有一些创新的选项可以进一步加强SBOM，例如Syft，它可以支持 in-toto 规范的SBOM认证。这种认证方式帮助签名者证明：SBOM正是容器映像内容的准确表示。