什么是软件供应链安全？
软件供应链涵盖了在产品或应用程序的整个软件开发生命周期 (SDLC) 中影响或发挥作用的所有因素。
近年来，针对软件供应链的攻击变得越来越普遍且更加复杂。在他们的 2022 年报告中， Gartner公司 陈述： “预测企业攻击面的不断扩大，并增加对身份威胁检测和修复以及数字供应链完整性的流程和工具的投资。”
确保软件创建和部署中涉及的所有组件、活动和 SDLC 实践的安全比以往任何时候都更加重要。开发团队和软件供应商必须确保他们只使用没有已知漏洞的代码组件，并找到方法来验证其构建的完整性，检查是否存在未经授权的篡改。
软件供应链安全的定义
软件供应链是指整个软件开发生命周期（SDLC）中与应用程序开发相关的一切。创建和部署软件需要保护其供应链的活动、流程和组件。在这方面需要考虑很多因素，包括自定义代码（内部组件）、开源依赖项和库（第三方组件）、构成 CI/CD 流程的 DevOps 工具和基础设施，最后是开发人员和 DevOps团队。
组织有责任执行这些安全活动并向消费者提供其安全工作的证明。
针对软件供应链的攻击：为什么如此常见？
现代软件管道是自动化环境，依赖于各种工具进行持续集成和持续交付。一个软件项目最终可能会包含数千个开源依赖项。
恶意行为者可以通过利用开源包管理器中的“逻辑缺陷”将流氓库冒充为合法库。例如，带有恶意软件的软件包可以在可信维护者不知情的情况下被归咎于他们。这种错误的信任可能会在代码中引入有问题的隐藏漏洞。这些漏洞可以让攻击者访问敏感数据，或者允许他们在整个供应链中植入恶意软件和控制系统。
现代开发环境有其自身的漏洞，各种软件供应链攻击都针对 CI/CD 管道，在整个开发过程的某个时刻插入恶意代码。在这里，零信任假设也是获得最终软件产品信任的适当方法 - 检查、验证和验证内部开发链中的每一步。
当今的 CI/CD 管道缺乏可见性和控制来充分保护软件开发过程。他们还很难检测代码篡改，这使得这种攻击媒介更具吸引力。
SSDF (NIST 800-218) 已最终确定并生效
SSDF (NIST 800-218) 框架 要求供应商实施涵盖软件开发生命周期（SDLC）的安全实践。它促进透明度和防篡改措施，以减少安全漏洞和恶意干扰。
具体来说，它包含基于证据的方法的指南，以保护软件本身不被篡改。
SSDF 有四个主要部分：
01 /
准备组织 (PO)：
确保人员做好准备、流程和技术到位，以便在组织级别（在某些情况下）为单个开发小组或项目执行安全软件开发。
02 /
保护软件 (PS)：
保护所有软件组件免遭任何未经授权的访问或篡改。
03 /
制作安全良好的软件 (PW)：
生产安全性良好的软件，其版本中的安全漏洞最少。
04 /
响应漏洞 (RV)：
识别软件版本中的残留漏洞，做出适当响应以解决这些漏洞，并防止将来出现类似的漏洞。
您不应将 SSDF 视为清单，而应将其视为规划和实施基于风险和基于证据的方法来开发安全软件的指南。
公司必须采取措施改善其安全状况，以促进遵守新出现的监管变化。
SLSA 是您应该遵守的框架
源自 Google 的一个名为 SLSA（软件工件供应链级别）的框架为如何达到软件供应链保护的四个级别提供了指导。该框架侧重于工件构建的完整性，旨在防止篡改和保护工件。
SLSA 的工作方式如下：您实施应在管道中实施的安全控制清单，这些控制位于您引入软件项目的子域中，例如源控制系统、构建系统和依赖项。
SLSA 规定了四个级别的合规性，目标是达到第 4 级，这将具有最高的安全价值，但要求列表更长。
SLSA 框架基于起源的概念。代表“证据链”的文档，表明工件的起源和构建过程。当您提高 SLSA 级别时，您需要更好地保护证据本身。
您应该将 SLSA 视为行业标准，是您必须遵守的可识别且商定的保护和合规级别。
如何保护您的软件供应链？
然而，我们想强调 安全控制的三个主要类别：
1. 保护软件开发生命周期的配置
凭证泄露、权限控制不足以及易受攻击的构建系统会产生影响软件生产商的攻击面。利用这些漏洞的攻击者可以窃取不安全的秘密或篡改软件工件。此类中的一系列商业和开源解决方案可以提供控制来映射安全状况中的差距并修复它们。
2.避免依赖易受攻击或恶意的依赖项
开源和商业软件中总会不断发现新的漏洞。软件生产商必须通过升级易受攻击的开源组件、扫描其专有代码中自身造成的漏洞以及向软件消费者告知软件物料清单 (SBOM) 及其相关影响来降低这种风险。这些消费者反过来可以采取相应的行动。
被劫持的开源项目帐户和伪装成合法的恶意软件包会带来额外的风险，主要影响管道中的秘密窃取。开源社区和一些商业供应商正在努力通过增强声誉和恶意行为检测来解决这个问题。
3. 验证软件工件的完整性和安全构建
网络安全需要深度防御。当使用传统的攻击面减少、检测和声誉保护方法时，攻击可能会从裂缝中溜走。此外，如今下游软件消费者对这些控制几乎没有影响力。最多，他们可以依赖供应商的时间点安全审核，例如提供漏洞快照的代码扫描，而这些供应商并没有建立真正的信任，即软件工件在开发生命周期中受到良好的保护和保护。
现在可以使用一类新的、新兴的控件来持续证明每个软件工件构建的完整性和安全开发过程。这些证明没有信誉，可以在寻求验证的生产者和下游消费者之间共享。不可否认性是通过加密方法实现的，因此，显着提高了任何攻击者渗透供应链的代价。
软件供应链安全领域的专家认为这种方法至关重要。然而，虽然存在一些开源构建块来支持此类控件，但只有少数供应商可以提供集成解决方案。
完整的软件供应链解决方案必须包括：
收集证据并签署它作为软件开发和构建过程的证明。通常，此证据是带有元数据的文件哈希，这些元数据在流程中的相关步骤、有关安全相关步骤的事件（例如代码提交者身份、代码审查、自动安全测试等）之间进行比较。还需要提供有关在构建软件工件时软件生产者的构建过程的安全状况的证明。
安全的证明存储，允许可见性并支持分析，例如验证代码完整性。
一种策略引擎，根据组织定义的策略或基于标准的策略来衡量这些证明，以验证和演示合规性。
软件生产者或消费者之间信任相关信息的共享中心；这可以是企业间或企业内部）。
验证软件完整性具有挑战性
理论上检查代码完整性应该很容易。只是比较文件，对吗？事实上，有很多事情需要考虑。对于初学者来说，每种语言编译文件的方式都不同。最重要的是，根据文件的用途，文件的使用方式有很大不同。有些是要更改的，有些是要删除的，有些是在编译过程中创建的。
除此之外，公司不想将其专有代码交给彼此。
贯穿整个 SDLC 的代码保证
Scribe 致力于持续保护您的整个 SDLC。通过从开发和构建过程的各个部分收集的证据，Scribe 使用数字签名来创建不可伪造的证明。
一旦签署，每一份证据都可以在以后进行验证，以确保所有流程都按计划进行，并且没有发生计划外的更改。
遵循 SSDF 中列出的最佳实践，Scribe 允许您采用常识性策略来增强您在整个开发过程中的信心。要求签名提交、开发人员 2FA、两人代码审查等策略有助于建立信任，让人们相信每个软件都是按照正确的安全态势生成的。
将所有这些证据以及代码完整性报告以及所有策略和证明的摘要收集在一个位置，可以提高开发过程和最终生成的软件工件的可见性和信心，并与 SSDF 指南保持一致在新的网络法规的基础上。
允许选定的订阅者查看产品对策略要求的合规性和完整性结果，可以让用户对您的开发流程和最终软件产品有更大的可见性和信任。
最终结果不仅是检测代码或管道篡改，还能够证明软件设计和构建期间进行的测试和安全程序，以及源代码和开源包的完整性用于构建它。
自动化 SLSA 合规性评估
必须持续测量动态管道的安全性。 SLSA（软件工件的供应链级别）定义了四个软件供应链保护级别以及如何达到这些级别的指南。
SLSA 合规性评估可以自动化以满足他们的要求。但一个组织应该如何着手收购一个呢？您应该遵循哪些具体的最佳实践？
观看此视频，我们分享在现实场景中使用 Sigstore 和 OPA 等开源工具实现自动化的最佳实践。概念和技术最佳实践都揭示了评估和自动化 SLSA 合规性的现实细节和挑战。
| 使用抄写器之前 | 使用抄写器后 | |
|---|---|---|
| 信任中心 – 信息共享 |
|
|
| 安全 SDLC – 政策与合规性 |
|
|
| 完整性和篡改检测 |
|
|
| 提升品牌曝光性 |
|
|
| 安全态势 |
|
|
Scribe Security - 新的软件供应链安全标准
跟踪软件开发过程中的每个细节和事件，以及软件组件和工件的完整性
验证软件开发过程的任何部分均未发生篡改
验证用于构建代码的 CI/CD 工具的完整性
确认开发过程的完整性——确保与安全相关的步骤是根据组织的策略进行的并且没有被绕过
通过收集和签署代码中发生的任何事情的证据，在开发生命周期的每个阶段，攻击者都更难篡改文件、工具或 CI/CD 管道的预期行为。
帮助？
