现代化运营举措将增加对软件供应链安全的需求

如今，软件供应链的安全受到威胁并不奇怪。 首先log4j登上新闻头条，让每个人都争先恐后地缓解软件供应链中非常普遍且有问题的漏洞。

最近， Spring4Shell出现在我们的关注范围内；另一个由框架引入的漏洞给需要应对威胁的企业带来了混乱。

因此，看到GitHub 推出针对软件供应链安全的新功能，我们感到很高兴。 在阅读了Sonatype 最新的软件供应链状况报告后，感觉特别愉快，该报告提供的统计数据足以让任何有安全意识的技术人员感到恐惧，无论他们的角色是什么。 值得注意的是：

• 目前有 3700 万个 OSS 组件版本可用
• 29％的热门项目至少包含一个已知的安全漏洞
• 针对开源供应商的网络攻击同比增长 650%

这些发现尤其令人不安，因为报告确定“现代应用平均包含128 个开源依赖项”。

现在，你知道我不喜欢做数学，但是我们来做些数学吧。

在2022 年application策略报告中，我们发现了几个值得注意的统计数据：

• 现代应用（容器原生和移动）平均占企业应用程序组合的 33%
• 所有行业的企业平均维护约 200 个应用

因此，200 的 33% 意味着典型企业在其产品组合中平均拥有 66 个现代应用。 使用 Sonatype 的开源依赖性平均值，这意味着普通企业可能承担保护 8448 种不同开源依赖性的负担。 现在，应用之间几乎肯定存在重叠。 容器原生应用几乎总是共享相同的容器编排环境（Kubernetes 现在是 COE 之王），因此在特定依赖性方面负担实际上较低，但并不意味着在出现漏洞时每个实例都需要更新。

无需进行更多的计算，我们都同意，考虑到应用程序组合的规模及其对开源依赖关系的包含，确保当今软件供应链的安全是一项重大任务。

GitHub 的新功能通过“查找和阻止当前仅显示在拉取请求的丰富差异中的漏洞”来帮助解决这一问题。 换句话说，它集成到 CI/CD 管道中并实时扫描已知漏洞。

凉爽的。 这并不是什么不寻常的能力。 多年来，DevSecOps 一直在推动这种“左移”的安全运动。 大多数 CI/CD 管道（无论使用什么工具）都能够对代码执行安全扫描。 然而，并非所有软件都具备扫描已知漏洞的能力，这些漏洞可能深藏在依赖关系中，或者是难以检测到的逻辑错误的结果。

现在，您当然应该在 CI/CD 管道中包含尽可能多的安全性，以根除以后可能给您带来麻烦的漏洞和错误。 但这不是我们进行这次练习的原因。

SRE、软件和供应链安全

我之所以指出现有软件供应链存在的问题，是因为随着企业采用 SRE 方法实现运营现代化，情况只会变得更糟。 这是因为从本质上讲，SRE 实践依赖于自动化，而我相信您知道，自动化依赖于软件和脚本，其中许多都是开源的。

事实上，得知 DevOps 使用的许多开源工具将被 SRE 使用并不奇怪。 如果您想简化角色和关系，SRE 就是用于生产的 DevOps。 虽然 DevOps 从业者通常专注于软件构建和发布流程，但 SRE 专注于软件操作流程。 这不仅意味着应用程序，还意味着应用程序安全和交付服务以及平台和环境（如核心、云和边缘）。 SRE 人员的范围涵盖整个 IT 堆栈，这使得他们在保护软件供应链方面的任务变得更加困难。

可以说，软件供应链的安全应该是所有组织关注的问题，因为它影响整个应用生命周期——从开发到构建到发布到部署到运营。

对于希望在数字化转型过程中生存下来的企业来说，这应该是一个值得关注的问题。 世界各地的企业都在经历重大转变，它影响着组织的核心：企业架构。

大多数企业架构都是几十年前建立的，其基础是资源固定、不灵活、数据中心是商业世界的焦点的前提下开发的框架。

如今，这些都不再是事实，即使曾经是，业务也已经发生了变化。 如今，业务日益数字化，而具有数据驱动流程的数字业务无法通过旨在表示具有人为驱动流程的物理业务的架构来充分表示。 企业架构必须实现现代化，并且在实现过程中必须纳入新的领域，例如 SRE 操作。

事实也确实如此。 我们今年的研究发现，37% 的组织已经采用 SRE 运营来实现应用程序和操作的现代化，另有 40% 的组织计划在未来 12 个月内这样做。 这意味着工具和脚本、软件和数据以及支持组织内这一新角色的整套技术。

软件、脚本和堆栈带来了供应链和安全性。 我们从 DevOps 中学到的一件事是，在实现操作现代化时不能忽视的，那就是 SRE 实践将面临许多相同的技术债务和安全挑战。

好消息是，与 DevOps 和构建流程不同，SRE 运营将成为组织的新实践。 建立新的实践意味着建立新的运营方式——包括从一开始就建立安全性。