软件开发的现代框架和方法侧重于软件交付的速度和可靠性,以及软件利益相关方之间的共享所有权。
除了向左移动安全性的 DevOps 做法之外,许多其他 DevOps 做法也有助于交付更安全的软件。加强利益相关方协作、工作可见性、可重现的构建版本、自动化测试、增量更改,这些都是可以支持软件安全性的实践。事实上,《加速:2022 年 DevOps 现状》报告发现,信任度较高的文化更有可能采用实践来强化软件供应链,使用 CI/CD 有助于实施安全性实践。
但是,现代开发框架缺乏相关指导,无法帮助组织了解其软件所面临的威胁,评估其检测和应对威胁的能力,以及实施缓解措施。他们还倾向于专门关注组织内的代码和流程,而忽略可能影响应用完整性的外部因素。例如,入侵开源软件包的攻击会影响直接或间接依赖于该软件包的任何代码。此类软件供应链攻击自 2020 年以来急剧增加。
软件供应链
软件供应链由组织内部和外部有助于开发和交付软件的所有代码、人员、系统和流程组成。包括:
- 您创建的代码及其依赖项,以及用于开发、构建、打包、安装和运行软件的内部和外部软件。
- 与系统访问、测试、审核、监控、反馈、沟通和审批相关的流程和政策。
- 您信任的用于开发、构建、存储和运行软件及其依赖项的系统。
鉴于软件供应链的广泛覆盖面和复杂性,有许多方法可以对您向用户提供的软件进行未经授权的更改。这些攻击途径会贯穿整个软件生命周期。虽然某些攻击是攻击目标(如对 SolarWinds 构建系统的攻击),但其他威胁是间接的,或者因为存在过程中的漏洞或被忽视而进入供应链。
例如,在一篇有关 2021 年 12 月 Apache log4j 远程执行漏洞的博文中,Google Open Source Insights 团队指出 Maven Central 中有超过 17,000 个受影响的软件包。大多数受影响的软件包并不直接依赖于有漏洞的 log4j-core
软件包,而是有需要该软件包的依赖项。
流程缺口(例如缺少代码审核或部署到生产环境的安全标准)可能会导致不良代码意外进入供应链。同样,如果您使用可信版本控制系统以外的源代码进行构建,或者从可信构建系统和工件代码库之外的系统打包和部署应用,则不良代码可能会进入软件。
根据 2021 年软件供应链现状报告,2020 年至 2021 年期间,开源软件的使用和对软件供应链的攻击都急剧增长:
- 2021 年,软件供应链攻击的年同比增加了 650%。
- 开源软件包的可用性和需求持续增长,2021 年开源组件下载量同比增长 73%。
- 漏洞在最热门的开源项目中最常见。
为了保护软件的完整性,请务必了解您的安全状况:您的组织在检测、响应和修复威胁方面的准备程度如何。
合规性要求和评估框架
人们对供应链安全性的担忧日益加剧,因此专门针对供应链安全制定了新的政府法规,例如:
- 美国行政命令
- 欧盟网络和信息安全 2 指令
新的框架不断涌现,可以帮助组织评估其安全状况并了解威胁缓解措施。
- 软件工件的供应链级别 (SLSA),这是一个受 Google 软件安全性实践启发的开源框架。
- 政府组织提供的框架,例如:
- 美国国家标准与技术研究院 (NIST) 安全软件开发框架 (SSDF)(美国)
- 信息安全评估框架(英国)
这些框架采用成熟的软件安全做法,并以合适的格式构建它们,有助于您识别需要应对的安全威胁以及采取哪些措施来缓解威胁。
在 Google Cloud 上保护您的软件供应链
Software Delivery Shield 在 Google Cloud 上提供了全代管式软件供应链安全解决方案。它融合了最佳实践,包括 SLSA 和 NIST SSDF 等框架中的实践。您可以根据自己的优先级和需求逐步采用解决方案的组件。
后续步骤
- 了解软件供应链面临的威胁。
- 评估现有安全状况,以便确定强化安全状况的方法。
- 了解保护软件供应链的做法,以及 Software Delivery Shield 中的功能如何提供帮助。
- 详细了解 Software Delivery Shield 并查看快速入门。