作者 | Mary Branscombe
译者 | 张增斌
超过90%的软件应用程序使用开源组件，与开源软件相关的依赖关系和漏洞极其复杂。使用开源软件能够提高开发人员的开发效率，但不意味着更加安全。在数字化转型加速的当下，在推动创新的过程中，开源的复杂性和开发速度限制了软件供应链安全控制的有效性。
软件供应链攻击变得如此普遍，以至于Gartner将其列为2022年的第二大威胁。据研究预测，到2025年，全球45%的组织将会遭受一次或多次软件供应链攻击，82%的CIO认为他们将更容易受到攻击。这些攻击包括通过广泛使用的软件组件(如Log4j)中的漏洞进行的攻击，对构建管道的攻击(例如：SolarWinds、Kaseya和Codecov黑客攻击)，或黑客破坏软件包存储库本身。
Cycode首席执行官Lior Levy解释道：“攻击者已经将优先级从生产环境转移到软件供应链，因为软件供应链是最薄弱的环节。”，“软件供应链仍然是相对容易攻击的目标，软件供应链攻击依然会不断增加。”
最近备受瞩目的事件给软件开发行业敲响了警钟，Aqua Security战略高级副总裁Rani Osnat说。“我们已经发现了几十年来的不透明和缺乏透明度，这就是为什么它如此重要”。
对使用开源代码的代码库的研究表明，漏洞和过时或废弃的组件很常见：81%的代码库至少有一个漏洞，50%的代码库有多个高风险漏洞，88%的代码库使用的组件不是最新版本或两年内没有进行更新开发。
但是这些问题不太可能削弱开源的普及。当LastPass受到攻击时，它不会丢失客户数据，但未经授权的一方能够查看和下载它的部分源代码，这可能会使将来更容易攻击密码管理器的用户，而Twilio漏洞使攻击者能够对下游组织发起供应链攻击。
警惕“影子代码”的威胁
CIO需要考虑到最糟糕的状况：假设所有代码，无论是内部还是外部，甚至他们的开发人员使用的开发环境和工具都已经受到破害，从而来制定相应的政策来保护他们的软件供应链免受攻击并将其影响降至最低。
事实上，Osnat建议CIO们像对待影子IT一样思考“影子代码”的潜在风险（在没有 IT 监督或安全审查的情况下添加的脚本和库）。他说：“这不仅仅是一个安全问题，而是一个需要你深入考虑如何获得软件的问题，无论是开源的还是商业的：你如何把它引入你的环境，你如何去更新它，你想要什么样的控制措施，你想从你的供应商那里获得什么样的。”
提升透明度：推广使用软件物料清单
物理供应链已经使用标签、配料表、安全数据表和物料清单，因此监管机构和消费者知道产品最终会出现什么结果。新计划旨在将类似的方法应用于软件，帮助组织了解依赖关系网络及其软件开发过程的攻击面。
白宫关于软件供应链安全的第14028号行政命令要求为联邦政府提供服务的软件供应商提供软件物料清单(SBOM)，并使用软件工件的供应链级别(SLSA)安全清单来防止篡改。正因为如此，“我们看到很多企业更加认真地看待他们的软件供应链”，Forrester高级分析师Janet Worthington表示：“现在所有的公司都生产和消费软件，我们看到越来越多的生产商来找我们说，‘如何生产安全的软件，我可以用软件物料清单来证明’。”。
有许多跨行业项目，包括NIST的全国供应链网络安全改善计划(NIICS)，微软和其他IETF成员的供应链完整性，透明度和信任计划(SCITT)，以及OpenSSF供应链完整性工作组。
Worthington说:“每个人都在采取更全面的方法，并说，等一下，我需要知道我将什么带入我的供应链，我正在用什么来创建软件”。
Linux基金会最近的一项调查发现，采用软件物料清单的意识很高，目前有47%的IT供应商、服务提供商和受监管行业使用SBOM，88%的人预计在2023年使用SBOM。
SBOM对于已经拥有软件组件和API资产管理的组织最为有用。Worthington说：“今天拥有强大软件开发流程的人们会发现，插入可以生成软件物料清单的工具更容易”。
SBOM可以由构建系统创建，也可以事后由软件组合分析工具生成。她说，许多工具可以集成到CI/CD管道中，并作为构建的一部分运行，甚至当你移除库也可以运行。“它可以警告你：'嘿，你的管道中有这个组件，它有一个关键问题，你想继续吗？'”
Chainguard首席执行官Dan Lorenc表示：“为了使这一点有用，你需要明确你的开发团队如何获取开源软件的政策”，“开发人员如何知道他们公司的政策是什么，什么被认为是‘安全的’？他们如何知道他们正在购买的开放源码(这是目前开发人员使用的所有软件中的绝大多数)确实没有受到任何损害？”
他指出了JavaScript、Java、Kubernetes和Python用来建立软件包的开源Sigstore项目。他说：“Sigstore对软件的完整性就像证书对网站一样；它们基本上建立了一个托管链和信任验证系统。”
Lorenc说：“我认为CIO应该首先向他们的开发团队灌输这些基本步骤：一是使用新兴的行业标准方法，锁定构建系统；二是创建一种可重复的方法，在将软件构件引入环境之前验证其可信性。”
为你使用的开源组件做出贡献
Worthington指出，无论是组件、API还是无服务器功能，大多数组织都会低估他们正在使用的功能，除非他们进行常规盘点。她说：“他们发现其中一些API没有使用正确的身份验证方法，或者可能没有按照他们预期的方式编写，甚至有些API已经被弃用”。
除了漏洞之外，评估软件包背后的社区支持与了解代码的作用同样重要，因为并非所有维护者都希望将他们的代码视为关键资源。“并非所有的开源都是一样的，”她警告说。
Worthington表示：“开源可能可以免费下载，但使用它肯定不是免费的。你对它的使用意味着你有责任了解它背后的安全态势，因为它在你的供应链中。你需要为它做出贡献。你的开发者需要参与修复漏洞。”，他建议各组织也应准备好以货币形式捐款，要么直接向开源项目捐款，要么向其提供资源和资金支持的倡议捐款。“当你创建一个开源策略时，其中的一部分就是了解预算和影响。”
不要认为这仅仅是一笔开支，实际上这反而是一个更好地了解你所依赖的组件的机会。“这甚至有助于留住开发人员，因为他们会认为自己是社区的一部分。他们能够贡献自己的技能。他们可以在简历上使用这一点，”她补充道。
请记住，漏洞可以在你的技术堆栈中的任何位置找到，包括大型机，这些大型机越来越多地作为工作负载的一部分运行Linux和开源，但通常缺乏其他环境中常见的安全流程和框架。
保护你的软件交付管道
保护你的软件交付管道也很重要。NIST的安全软件开发框架(SSDF)和SLSA是一个很好的起点：它涵盖了各种成熟度级别的绝佳实践，从简单的构建系统开始，然后使用日志和元数据进行审计和事件响应，直到完全安全的构建管道。CNCF的软件供应链最佳实践白皮书、Gartner关于降低软件供应链安全风险的指南以及包括流程和工具的微软OSS安全供应链框架也很有帮助。
然而，重要的是要注意，仅仅打开旨在查找恶意代码的自动扫描工具可能会产生太多的误报而没有帮助。尽管BitBucket、GitHub、GitLab等版本控制系统包括安全和访问保护功能(包括越来越精细的访问策略控制、分支保护、代码签名、要求所有贡献者使用MFA以及扫描机密和凭据)，但它们通常必须显式启用。
此外，诸如可重复安全创建工件工厂(FRSCA)之类的项目旨在通过在单个堆栈中实现SLSA来保护构建管道，但CIO应该期望构建系统将来包含更多这些实践。
事实上，虽然SBOM只是答案的一部分，但创建和使用它们的工具也在不断成熟，请求和使用它们也在不断完善。Worthington建议，合同不仅需要指定你想要的SBOM，还需要指定你希望它们更新的频率，以及它们是否包括漏洞报告和通知。“如果发现像Log4j这样的新的重要漏洞，供应商会告诉我吗，还是我必须在SBOM中搜索自己，看看我是否受到影响？”
组织还需要工具来阅读SBOM，并制定流程来对这些工具的发现采取行动。Worthington说：“我需要一个工具，它可以告诉我（SBOM）已知的漏洞是什么，许可证的影响是什么，以及这种情况是否会持续发生。”
CIO们应该记住，SBOM“是一个推动者，但实际上并不能解决任何问题，确保供应链的安全。它可以帮助你应对可能发生的事件”，Osnat说，他对行业响应速度以及围绕SBOM标准和代码认证进行的广泛合作持乐观态度，这将有助于使工具互操作（这是Linux基金会研究中组织提出的一个特别关注的问题）。这可能会导致整个行业的透明度和报告标准得到与SOC 2相同的改进。
Osnat表示，尽管如此，CIO们不必等待新的标准或工具来开始让安全成为开发人员角色的一部分，因为近年来质量已经成为了一部分。他的建议是：“首先让你的CISO和首席工程师坐在一个房间里，找出适合你的组织的模式，以及如何实现转型。”