供应链安全中的投资回报最大化：聚焦有限时间实现最大收益
编者注：以下文章是为DZone的2025趋势报告《软件供应链安全：增强软件开发生命周期中的信任和韧性》撰写并发表的。
DevOps和DevSecOps（以及未来可能出现的任何缩写）的目标是打破壁垒，但在实践中，这通常意味着开发人员承担了更重的负担。现在，开发人员不仅需要按时交付令人满意的产品，还要负责产品的运营和安全。这引发了一个问题：开发人员能否完成所有这些任务？答案是肯定的，但前提是我们必须明智地利用时间。
在本文中，我们将深入探讨构建和增长自动化安全流程的实际步骤，以减轻保护软件供应链的许多负担，这些负担可能会在紧张的时间表和不断积压的工作中拖累我们。
供应链安全的影响
供应链安全（SCS）和DevSecOps的出现意味着我们的开发工作范围显著扩大。我们现在负责：
- 了解产品中的每一个依赖项，包括多级传递依赖
- 阅读和理解通用漏洞披露（CVE）报告
- 理解不同许可证的法律影响
- 为法律和安全团队提供建议并解决这些团队提出的问题
- 在这些流程出现问题时进行修复
在许多团队中，工作已经多于人手，那么我们如何在承担这一额外负担的同时完成现有任务？答案是理解实际需求并实现自动化。
自动化
对于任何合理规模的产品，手动检查每次提交的供应链是不可能的。每个看似无害的库都可能包含未来的关键漏洞或不允许的嵌套许可证。我们必须始终保持警惕并最小化依赖，但我们会达到一个点，手动跟踪所有依赖变得不可行。解决方案在于自动化我们的安全流程，而第一步是理解我们的安全流程需要实现什么。
理解安全流程
与持续集成/持续交付（CI/CD）一样，没有一刀切的方法。虽然模式可能出现，但我们的安全流程的具体细节会有所不同。第一步是理解我们的安全流程以及一般的CI/CD流程应该实现什么：
- 我们的流程需要交付哪些工件？
- 哪些报告应该伴随我们的工件？
- 必须包含哪些安全措施（如工件签名和构建流程验证）？
- 我们期望的安全阈值是什么？
- 缓解不同漏洞的时间表是什么？
- 哪些漏洞是阻碍发布的？
- 哪些漏洞可以在下一个版本中缓解？
- 哪些许可是允许的？
- 需要什么级别的可追溯性或证明？
这些问题的答案因产品而异——军事产品的要求与位于DMZ后的内部产品不同。重要的收获是理解我们产品的要求，创建一个有意义的起点，并在此基础上构建，直到满足所有要求。
从基础开始
自动化这个过程最初可能看起来令人望而生畏，但如果我们专注于从小处着手并逐步增长，就不会如此。今天改进流程20%远胜于未来某个虚无缥缈的时间改进100%。首先从生成软件物料清单（SBOM）开始。这份单一文档描述了供应链中的所有依赖项，并提供了对我们产品所依赖内容的可见性。
我们必须确保生成的SBOM是：
- 全面的：必须涵盖整个依赖图，包括传递依赖、用于创建工件的构建依赖（如编译器）以及容器镜像中的依赖。
- 可读的：SBOM应以工具可解析且开发人员可读的格式生成，如JSON或YAML。人类可读性对于更容易故障排除和理解哪些依赖项是问题至关重要（或者可以使用合适的工具可视化依赖图）。
拥有全面且可读的SBOM看似基础，但对于保护我们的供应链至关重要。如果我们不知道产品中包含什么，就无法审计或保护供应链。
注意：SBOM可能为恶意行为者提供有关我们产品攻击面的信息。我们应根据安全要求仔细考虑是否随产品交付SBOM。
左移安全
生成SBOM是良好的第一步，但并非终点。拥有安全流程应防止漏洞或危害性工件（如不允许的许可证）进入我们的产品。下一步是分析我们的SBOM，并在依赖项不符合我们的标准时自动使构建失败。这些标准包括：
- 没有超过我们安全阈值的漏洞
- 没有不兼容的许可证
- 没有已弃用或未维护的依赖项
当任何这些标准未满足时，我们应该中断构建。保证供应链安全的唯一方法是确保从一开始就不引入不合格的依赖项。然而，在实践中，我们可能从一个已经存在不合格依赖项的产品开始，并试图剔除它们。我们不能一口吃成胖子，所以必须一步一步来。
一些务实的方法是：
- 明智选择战斗：我们应该诚实面对什么是阻碍发布的，什么不是。拥有一个没有已知漏洞的已弃用依赖项可能不是阻碍发布的，但拥有不兼容的许可证很可能是。首先从对最重要的标准中断构建开始，然后逐渐添加值得中断的标准。
- 随时间提高安全阈值：起初，仅对关键或高严重性漏洞中断构建。一旦这些漏洞得到缓解，继续提高阈值，直到达到我们期望的安全阈值。
这些方法需要纪律：标准应随时间提高，而不是无限期保持宽松。在整个过程中，目标应始终是从小处着手并改进。今天的逐步改进胜于永远不会到来的完美解决方案。
其他考虑
有了坚实的自动化SCS流程，我们还可以添加以下内容：
- 静态代码分析
- 对执行产品的动态分析
- 有助于缓解的第三方工具，如为已知漏洞建议缓解措施的工具——甚至自动为缓解漏洞创建拉取请求（PR）
其中一些工具可能甚至不使用我们的SBOM，因此它们可以进一步左移到交付流程中。例如，一些工具扫描仓库中的代码或每次提交的代码，以确保它不会引入任何漏洞。目标是尽可能早地使构建失败，因此如果工具允许我们检查代码或提交——甚至在我们构建之前——总是倾向于尽可能左移。
审计和改进
实施SCS不是一劳永逸的事情。这是一个必须持续审计和改进的过程。随着时间的推移，需求会变化，安全约束可能收紧，问题会出现。我们的自动化流程应始终与当前需求保持一致。一些持续改进安全流程的方法包括：
- 关注手动任务：寻找不断出现的手动任务。例如，法律团队是否一直在捕捉我们产品中不允许的许可证？改进自动化流程中的许可证检查，直到不再发现不允许的许可证。
- 领先其他团队：寻找减轻其他团队负担的机会。例如，安全团队是否因为安全合规检查太繁琐而延迟发布？通过询问他们什么会有助于流程并自动化它来改进流程（例如，以不同格式生成漏洞报告，在将产品发送给安全团队之前捕捉更多漏洞，或进行审计）。
总有改进的机会。我们自动化SCS长期生命的驱动力应该是自动化流程，使我们能够专注于开发高质量产品。
结论
DevOps和DevSecOps的引入增加了开发人员的负担。我们很容易迷失主要目标：按时并在预算内交付产品。虽然承担新角色（如运营和安全）可能看起来像西西弗斯的努力，但不必如此。我们必须专注于提供最大回报的事情，包括：
- 尽可能自动化
- 尽可能早地发现问题
- 尽可能轻松地缓解它们（最好通过自动化PR）
将这些原则付诸实践，确保我们除了主要目标外，还能覆盖运营和安全的角色：及时交付满足客户需求的产品。
本文摘自DZone的2025趋势报告《软件供应链安全：增强软件开发生命周期中的信任和韧性》。阅读免费报告。