10.7 手动工作量与自动化和准确性

供应商必须考虑的一个关键点是自动化的作用与提供给消费者的信息准确性的需求形成鲜明对比。对于大型软件公司来说，进行软件保障成为一种可扩展性的练习，尤其是那些在数百甚至数千个软件产品中部署计划非常快的公司。在某些情况下，自动化可能无法识别关键软件组件。例如，在运行时动态加载组件或不在 Dockerfile 中包含组件的 Docker 映像可能需要手动识别该组件。但是，确定什么是“足够好”的，以便对SBOM进行初始捕获可能会有所帮助。

如果供应商可以生产出超过一定置信度（例如80%）的SBOM或其他人工制品，那么对于该人工制品的消费者来说，这是否足够？总会有一些出错的可能性，当自动化流程时，这个余量可能会增加。如果不是 80%，您的预期置信度是多少？谁是你的客户？你有没有和他们谈过现实的期望？您是否有一个流程来更新和纠正先前错误的供应链工件？要通知您的客户？要根据这些新信息更新任何分析？如果工件是正确的，但发现了新的分析见解（例如新的 CVE），该怎么办？不仅要您生成的工件必须正确，而且从分析中获得的见解也必须正确。

我们常见的一个问题，特别是针对逆向工程生成的SBOM（软件物料清单），是无法理解所分析的内容。有多种技术可以识别组件，但有些技术并不比在文件中进行字符串匹配复杂。例如，一个注释中写着“cve_x在component_version_1.2.3中被修补”，可能会被解读为安装的组件是1.2.3版本，而实际上是2.0版本。对每个版本进行详尽的逆向工程是不现实的，那么在这些情况下你的信心水平是多少？可能不到80%。根据作者的经验，这通常更接近60%。因此，了解工件创建的方法也可能会成为考虑因素。

SBOM生成的阶段是否重要？设计、构建和部署阶段可能会为同一个应用程序生成截然不同的SBOM。早期阶段的SBOM对最终消费者可能没有帮助，而尝试获得完美自动化的构建SBOM可能是一种徒劳的尝试。也许这对供应商的内部软件保证实践已经足够了，完美可以保留给最终交付给客户的产品。这将大量的手动工作移到了作为质量保证过程的最后阶段，并提供了纠正任何检测到的偏差的机会。