近年来，人们非常重视软件供应链的安全。尤其令人担忧的是开源软件发行版中固有的风险越来越多。这引发了围绕云原生开源安全的大量开发，其形式包括软件物料清单 (SBOM)、旨在验证 OSS 包来源的项目等。
许多组织循环使用大型开源包，但只使用其中的一小部分功能，从而打开了不必要的攻击面。OSS 仍然容易出现拼写错误和新的零日漏洞。更不用说像 Log4j 这样的漏洞在很大比例的部署中仍然没有修补。
2023 年末，我们思考云原生开源安全的现状。收集了想法以及其他一些报告和专家观点，以描绘云原生供应链安全的现状以及在不久的将来的预期。
2023 年，我们看到云原生领域在安全方面取得了许多重大发展，特别是在保护供应链的标准方面。例如，根据 Sonatype 的第九届年度软件供应链状况， SBOM 使用的成熟度正在不断提高，53% 的接受调查的工程专业人士表示，他们正在为每个应用程序生成 SBOM 。
围绕Sigstore 签署软件工件以验证信任证明和来源的运动。SBOM 解决供应链中关键问题的趋势，SBOM 质量还有改进的空间。像 OpenVex 这样的新框架最终可以帮助使 SBOM 格式更加准确。
今年的进展更多地体现在‘第一步’阶段，即制定一些措施来解决签名和 SBOM，下一步我们会看到这些工具提供更高质量的安全输出。
最严重的 OSS 漏洞
在上述研究中，Sonatype 报告发现 245,000 个组件下载存在已知漏洞。令人印象深刻的是，其中 96% 都有可用的固定版本。他们还跟踪发现，四分之一的 Log4j 下载都是存在臭名昭著且高度可利用的 Log4Shell 漏洞的易受攻击版本。
域名仿冒仍然是向 OSS 软件组件插入恶意代码的主要方法，攻击者可以利用这些代码窃取密钥或在系统中创建后门。然而， 下一个趋势可能是不良行为者寻找方法向实际开源项目贡献恶意代码。明天复杂的攻击策略可能看起来像是无意的事故，比如为了“修复代码中的错误”而提交的代码实际上可能会导致漏洞利用。
鼓励 IT 领导者放眼全局。作为一个行业，我们需要开始关注如何更全面、更有效地解决漏洞问题。这涉及深入了解您的软件依赖性和风险管理基础设施以实现快速补丁。
在过去的一年里，生成式人工智能在激烈的浪潮中崭露头角，带来了许多新的网络安全影响。数据科学工作流程处于早期发展阶段，容易出现安全缺陷。业界需要迅速认识到这是一个问题，并且需要采取制衡措施来验证人工智能/机器学习模型的可信度。
生成式人工智能有利于自动化云原生 DevOps、代码审查和特定的防御策略。然而，我们需要更好地了解这些模型所训练的数据以及这些模型的监管链，以避免人工智能数据模型中毒或篡改。
值得庆幸的是，我们看到了围绕 AI/ML 提高可见性和制定安全标准的势头。例如，领先的 SBOM 标准 CycloneDX 最近将描述机器学习模型的方法纳入其规范。新的 OWASP LLM 安全 Top 10 可以作为解决一些与 LLM 相关的关键威胁的指南。
缓解云原生供应链威胁的方法
使用 SBOM。SBOM 可以让您了解正在运行的软件以及在何处运行，这可以在您需要修补漏洞、了解许可风险或一般软件生命周期终止政策时提供帮助。
从第一天起就确保整个软件供应链的安全是一项挑战。因此，鼓励 IT 领导者从容易实现的目标开始，实施更具安全意识的实践，例如选择更安全的基础映像、用更成熟的组件替换不安全的 OSS 组件，以及在 CVE 出现时采用自动化方法将其删除。
缓解云原生供应链威胁的另一种方法是主动减少不必要或传递性依赖（可能存在漏洞）。建议使用最少的容器映像来减少总体表面积。由于您的软件中没有任何不必要的工具或组件，攻击者无法利用它为您的环境带来更多安全风险。
可观察性对于提供开发流程的全面监控和分析也至关重要，有助于识别异常情况和潜在的安全漏洞。重要的是，它有助于增强整个供应链的可见性，从源代码存储库到部署环境。这种透明度使团队能够跟踪代码流和依赖项，以识别任何意外的更改或未经授权的访问点。
《2023 年软件供应链安全报告中的 CISO 和开发人员趋势》发现，不到一半的 CISO 认为他们的开发人员非常熟悉其开发工具和工作流程的安全风险。该报告还显示，大量组织报告了漏洞扫描误报疲劳。
鉴于这些发现，我们需要团队之间更多的认识和协作以及更准确和可操作的扫描。优先考虑快速更新和修补有助于消除这种疲劳。
到 2024 年，我们将看到更多‘第一步’进展，以实现整个行业更好的软件供应链安全实践。展望未来，预计人们将通过 SLSA 来源和更值得信赖的证明等策略，迈向更先进的状态，以确保供应链安全。
将责任推卸给拥有开源安全性的人已不再是一种选择，每个人都应该认真对待这一问题，并开始逐步减少今天可以做的事情，以达到拥有设计安全的软件的稳定状态。
