软件供应链安全：如何防范潜在的攻击？

   来源：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框架要求，并实验一种验证和生成软件证实的方法，这些证实是关于整个软件供应链中软件工件的经过身份验证的声明（元数据）。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。