阅读量:2
来源：https://thehackernews.com/2024/06/practical-guidance-for-securing-your.html
软件生产组织面临越来越大的监管和法律压力，要求其保护供应链并确保软件的完整性，这不足为奇。在过去几年里，软件供应链已经成为攻击者越来越有吸引力的目标，他们看到了将攻击增加几个数量级的机会。例如，看看2021年的Log4j漏洞，Log4j（由Apache维护并用于无数不同应用程序的开源日志框架）是使数千个系统面临风险的漏洞的根源。
Log4j的通信功能很容易受到攻击，因此为攻击者向日志中注入恶意代码提供了机会，这些代码随后可以在系统上执行。发现后，安全研究人员看到了数百万次尝试利用，其中许多变成了成功的拒绝服务（DoS）攻击。根据高德纳的一些最新研究，到2025年，近一半的企业组织将成为软件供应链攻击的目标。
但是什么是软件供应链呢？首先，它被定义为组织内外所有代码、人员、系统和流程的总和，这些代码、人员、系统和流程有助于软件工件的开发和交付。保护软件供应链如此具有挑战性的原因是开发现代应用程序的复杂性和高度分布式。组织雇佣全球开发人员团队，他们依赖于前所未有数量的开源依赖项，以及用于构建和部署应用程序的广泛代码存储库和工件注册表、CI/CD管道和基础设施资源。
尽管安全性和合规性一直是企业组织最关心的问题，但保护组织软件供应链的挑战越来越大。然而，许多组织在实施DevSecOps实践方面取得了实质性进展，其中许多组织仍然发现自己处于弄清楚该做什么的早期阶段。
这正是我们把这篇文章放在一起的原因。虽然以下绝不是详尽的列表，但这里有四个指导原则，可以让您的软件供应链安全工作朝着正确的方向发展。
在应用安全性时考虑软件供应链的各个方面
鉴于超过80%的代码库至少存在一个开源漏洞，OSS依赖关系理所当然地成为软件供应链安全的核心焦点。然而，现代软件供应链包括其他实体，这些实体的安全状况要么被忽视，要么在组织内没有得到足够广泛的理解，无法得到适当的管理。这些实体是代码存储库、CI和CD管道、基础设施和工件注册表，每一个都需要安全控制和定期合规性评估。
框架，如用于CI/CD和CIS软件供应链安全基准的OWASP Top-10。遵守这些框架将需要细粒度的RBAC，应用最小权限原则，扫描容器和infrastructure-as-code漏洞和错误配置，隔离构建，集成应用程序安全测试，以及正确管理机密——仅举几例。
SBOM对于修复零日和其他组件问题至关重要
白宫于2021年年中发布的旨在加强国家网络安全态势的第14028号行政命令的一部分要求软件生产商向其联邦客户提供软件材料清单（SBOM）。SBOM本质上是正式记录，旨在提供对构成软件的所有组件的可见性。它们提供了详细的机器可读清单，列出了所有开源和第三方库、依赖项以及用于构建软件的组件。
无论组织是否受到EO 14028的强制，为软件工件生成和管理SBOM都是一种有价值的做法。SBOM是修复组件问题或零日漏洞的不可或缺的工具。当存储在可搜索的存储库中时，SBOM提供特定依赖项存在的地图，并使安全团队能够快速追踪漏洞回到受影响的组件。
使用策略即代码管理软件开发生命周期
在现代应用程序开发的世界中，坚如磐石的护栏是消除损害安全性和合规性的错误和故意行为的必不可少的工具。在整个软件供应链中的适当治理意味着组织已经使做正确的事情变得容易，而做错误的事情变得极其困难。
虽然许多平台和工具提供了可以快速执行的开箱即用策略，但基于开放策略代理行业标准的策略即代码支持创作和执行完全可定制的策略。根据供应商、版本、包URL和许可证等标准管理从访问权限到允许或拒绝使用OSS依赖项的所有策略。
能够使用SLSA验证和确保对您的软件工件的信任
用户和消费者如何知道一个软件是值得信赖的？在确定软件工件的可信度时，你会想知道谁写了代码，谁构建了它，以及它是在哪个开发平台上构建的。知道里面有什么组件也是你应该知道的。
一旦可以验证出处（软件的来源和保管链的记录），就可以决定是否信任软件。为此，创建了软件工件的供应链级别（SLSA）框架。它使软件生产组织能够捕获软件供应链任何方面的信息，验证工件及其构建的属性，并降低安全问题的风险。在实践中，软件生产组织必须采用并遵守SLSA框架要求，并实施一种验证和生成软件证明的方法，这些证明是关于整个软件供应链中软件工件的经过身份验证的声明（元数据）。
