IT 行业在应该致力于最佳实践的时候却在 SBOM 上拖延

抵制监管是人类的天性：即使我们知道某件事是最好的，我们也不喜欢它被强加给我们。

美国政府对软件物料清单 (SBOM) 实施了监管，并制定了软件“配方”。 从本质上讲，这是创建更智能的方法来识别潜在安全问题的关键要素。 人们对这个组织有负面反应和感受，这并不奇怪。

技术领域的重量级人物 ITI 理事会的回应称 SBOM“尚未准备好”，整个对话需要更加“成熟”，然后 IT 行业才能考虑创建和维护这些记录的额外负担 –特别是规则没有规定将使用的标准。

这是一个非常值得怀疑的方法。 IT行业不应该抵制这项规定，而应该欢迎它，领导它的实施，并围绕它进行成熟的辩论，而不是仅仅等待它发生。

SBOM 的状态
物料清单并不是一个新想法。 它们也称为成分列表或产品配方，在制造业中很常见 – 一个有组织的、标准化的列表，列出了制造产品所需的一切。

在制造业中，这些元素对于规划采购操作至关重要，也是出现错误或其他问题时的第一联系点。 如果某种成分被证明有缺陷，很容易确定哪个产品使用了该成分并启动召回或其他适当的行动。

SBOM 是软件中包含的所有开源和第三方组件的列表，但它还不止于此：它包含每个组件的版本号、许可证和补丁状态。 与制造业一样，当出现问题时，这将成为关键的参考材料。 如果出现问题，使用开源软件的公司可以立即识别漏洞所在。

这很重要，因为无论多么专业的开源，它都是建立在社区基础上的，并且应该始终牢记爱好者。 因此，虽然技术领域的知名人士可能会开发具有开源原则的工具并将其托管在开源平台上，但他们依赖的代码可能是作为副项目放在一起的，并且不像其他代码那样积极维护。

Log4Shell 漏洞就是一个完美的例子。 Log4j，顾名思义，用于记录错误和事件并将其报告给管理员。 如果有人访问网站并收到 404 错误，Log4j 可能会记录该错误 – 如果出现多个此类错误，则表明存在问题。 它的实用性使其无处不在，但反过来说，这也让它变得有些晦涩——一个无人真正思考过的、随处使用的虚拟软件。 当Log4j可用于注入代码被揭露时，这意味着数百万台服务器可能会受到攻击并被接管。 NIST 漏洞数据库给 Log4Shell 的 CVSS（通用漏洞评分系统）评级为 10，这是可能的最高评级。

相反，Log4j 的普遍存在意味着很容易知道是否需要补丁，因为几乎每台服务器都需要升级。 未来的漏洞可能不会那么普遍，但它们仍然很常见，这使得 SBOM 非常有价值。

需要引导而不是抵抗
对 SBOM 监管的反对大多是出于实用性而非原则。 “当前可用的行业工具生成的 SBOM 具有不同程度的复杂性、质量和完整性。多种、有时不一致甚至矛盾的工作的存在表明 SBOM 缺乏成熟度，”ITI 理事会的回应称。

确实，生成 SBOM 的方法有多种，因此目前还没有每个公司和组织都可以遵守的单一标准。 但这才是科技巨头应该引领的方向，而不是搁置。 它不应该只是嘲笑并说这是不可能的，而应该决定并接受最好的标准是什么，并在必要时寻找弥合这些不同标准之间差距的方法。

如果这一推动失败，最糟糕的情况是 SBOM 是在没有标准的情况下强制执行的，这意味着每个需要创建它们的人只需选择一种方法并使用它来满足法规的要求。 正如往常一样，标准化最终会到来，因为一种工具被大多数行业采用，并通过更受欢迎而获胜。 然而，这需要时间，也许几年，并且对于需要改变系统的公司来说成本高昂。

当这种情况发生时，我们可能会看到另一个 Log4Shell 范围的漏洞。 如果发生这种情况，美国政府将能够指出其监管并称其迫使该行业发生这种变化。 如果已经实施的 SBOM 协议不能胜任任务并且不支持必要的响应，那么行业将面临或多或少不可避免的问题。

SBOM 将是解决下一个重大漏洞的关键，并且在减轻较小漏洞影响的战斗中非常有用。 当今采用 SBOM 的问题不应被视为障碍； 相反，IT 行业应该制定一个时间表并共同努力解决这些问题，而不是放弃任何立法尝试。 施压工作应该集中于这如何发生，而不是它是否会发生。