研究表明，“先构建，后付款”的方式来缓解容器中的 CVE 会让公司每年损失数千小时。
译自 Cloud Native Companies Are Overspending on CVE Management，作者 John Speed Meyers。
要求云原生开发者“立即构建”意味着将云原生供应链中的漏洞（CVE)推迟到“以后”。新的 CVE Zero 运动正在重新思考如何处理容器安全债务。
现代公司沉迷于快速交付新功能。这就是为什么在现代软件团队中交付软件通常感觉像是在给一群疯狂的鲨鱼喂鱼。这也是为什么软件团队很容易接受所有类型的技术债务。为什么不今天就喂饱鲨鱼？他们今天就想要，并且愿意为此付出代价。
云原生公司往往会特别敏锐地感受到这种权衡。软件开发者选择基础容器镜像和其他第三方镜像，并在其上添加自定义代码和配置。这些第三方容器镜像中可能潜伏着问题，但测试通过且客户满意。
只有在稍后，当云原生软件团队在为其创收应用程序提供支持的容器群中发现数万个已知的独特 CVE 时，问题才会出现。
人们越来越接受这样一个事实：最流行的容器（云原生应用程序的基本构建块）都布满了 CVE。行业分析表明，即使是最新的流行容器版本也存在数百个 CVE。来自 Ponemon 研究所和其他组织的研究正在深入研究团队如何使用新兴的 DevSecOps 模式来管理和解决漏洞。
但所有这些伟大的研究都没有回答一个基本问题：将容器漏洞作为一种安全债务接受的“稍后支付”方法的成本是多少？识别、分类和修复 CVE 的实际损失是什么？
为了让安全社区更深入地了解 CVE 的成本，Chainguard Labs对软件专业人士进行了深入访谈，这些专业人士在云原生软件公司负责漏洞管理，这是他们日常职责的一部分。我们的调查深入研究了与 CVE 管理相关的所有任务和工作流，以估算 CVE 管理的年度时间成本。
这些调查结果令人担忧，尤其是对于需要保持功能速度以保持竞争力的软件领导者而言。
我们了解到，大多数云原生软件公司每年都在漏洞管理上花费数千小时。对于某些公司来说，每年是 10,000 小时，甚至更多。这是一个完整的工程团队，除了识别、分类和修复漏洞之外，什么都不做。
下表揭示了这一严峻的现实。虽然平均水平似乎每年约为 1,000 小时，但有些组织的支出却高出 10 倍。这意味着整个软件和安全工程师团队都在管理 CVE，而不是交付新软件。
按行业估算的 CVE 管理直接员工工时年总量
团队以不同的方式合理化推迟支付 CVE 债务。
一个主要因素是软件消费者贪得无厌，要求快速构建新功能。这意味着时间紧迫的软件工程师不情愿地接受云原生默认设置——带有 CVE 的容器。如果功能有效，那么扫描 CVE（更不用说修复它们）就是事后才想到的。
另一个关键因素是通常选择容器镜像（通常通过对 Dockerfile 进行一些编辑）的软件应用程序开发者通常不是承担漏洞管理下游成本的人。
最后，创建易于更新的软件很困难。虽然这是 DevOps 理念的核心，但实践起来却很难。更改软件（即使是为了修复 CVE）通常会带来产品停机和客户不满的风险。因此，许多软件组织发现即使对软件进行微小的更改也令人痛苦。这意味着修复 CVE 可能被认为不值得冒这个险。
每个组织都面临着不同的时间表，决定其 CVE 驱动的安全债务何时需要偿还。
对于一些组织来说，必须出于合规性原因偿还债务。例如，寻求开拓联邦市场的云原生公司经常会遇到合规框架，当容器中存在 CVE 时，这些框架需要大量的文书工作（想想 FedRAMP）。
对于特别不幸的公司来说，由于黑客利用 CVE 访问系统，债务会一次性到期。这种成本可能是数百万美元的声誉损失、诉讼和勒索软件。Apache Struts 中的一个漏洞 CVE-2017-5638 允许通过 HTTP 标头执行远程代码。它造成了 历史上最大的数据泄露事件之一，影响了近 1.5 亿美国公民和 1500 万英国公民。
CVE-2021-44228，更广为人知的名字是 Log4Shell，是另一个需要一次性偿还安全债务的 CVE 的示例。作为所有 CVE 中无可争议的重量级选手，Log4j 仍然 如此普遍，以至于几乎所有大型组织都在运行它，许多组织仍在努力查找所有实例。
微服务和容器改写了开发人员获取软件组件的规则。自上而下的方法已经一去不复返了，在自上而下的方法中，技术领导层决定 Linux 发行版、操作系统、应用程序基础设施和安全服务级别协议 (SLA)。如今，开发人员在 Dockerfile 和 GitHub Actions 中完成所有这些工作。
但在发行版和软件包之间存在巨大的信任差距。存在完全不在发行版之外且不会被安全扫描器发现的漏洞类别。同时，大多数发行版和软件包都附带许多已知的 CVE，这些 CVE 会从安全扫描器中产生大量“误报”噪音。稍后偿还 CVE 安全债务的后果是，很难清楚地了解哪些 CVE 可以解决你的环境。在估计分类单个 CVE 所需的时间时，也涉及大量无用功，因为从简单的批处理版本升级到将代码库迁移到依赖项的主要新版本之间存在许多变量。
无论何时到期，偿还漏洞驱动的安全债务都是一场工程管理噩梦——工作量大且不可预测。
CVE Zero 旨在控制二进制文件，即容器映像本身。它旨在将软件构建块转变为零漏洞方法。它旨在从基础映像中清除不必要的组件，以便安全扫描器的信号变得更加可靠。