开源之所以在软件开发中大量使用的原因是它提供了经过良好测试的构建块，可以加速复杂应用程序和服务的创建。但是第三方软件组件以及包和容器的便利性同时也带来了风险——软件供应链攻击。
软件供应链攻击日益普遍，Gartner 将其列为2022 年的第二大威胁。Gartner 预测，到 2025 年，全球 45% 的组织将遭受一次或多次软件供应链攻击，在参与调研的 CIO 中有82%认为他们所在的企业将容易受到攻击。其中包括通过广泛使用的软件组件（如 Log4j）中的漏洞进行的攻击、针对构建流水线的攻击（如 SolarWinds、Kaseya 和 Codecov hacks），或者黑客入侵软件包存储库本身。
攻击者逐渐发现软件供应链是最薄弱的环节，将攻击优先级从生产环境转移到软件供应链，这也就是为什么软件供应链攻击数量激增的原因。对使用开源代码库的研究表明，漏洞和过时或废弃的组件很常见：81% 的代码库至少有一个漏洞，50% 的代码库有多个高风险漏洞，88% 使用的组件不是最新版本或两年内没有新开发。
CIO 们在制定软件供应链安全防护策略时，可以假设他们的开发人员的开发环境和使用的工具都已经收到损害，借鉴此类场景来制定策略和政策，来最大限度减少攻击对企业软件供应链的影响和损害。
建议 CIO 们像对待影子 IT 一样去思考“影子代码”的影响与威胁。因此这不仅是一个安全问题，而是真正深入到如何获取软件的问题，不论这个软件是开源的还是商业的。如何将开源软件带入开发和生产环境，如何更新，如何控制以及怎样控制，这些都是值得思考的问题。
物理供应链已经使用标签、成分清单、安全数据表和材料清单，因此监管机构和消费者知道产品的最终结果。新举措旨在将类似的方法应用于软件，帮助组织了解依赖关系网络及其软件开发过程的攻击面。美国政府关于软件供应链安全的行政令要求向联邦政府提供软件的软件供应商提供软件物料清单 (SBOM)，并使用 SLSA 安全检查表的供应链级别来防止篡改。也正因为如此，越来越多企业开始认真对待他们的软件供应链。
Linux 基金会最近的一项调查发现，企业对 SBOM 的需求意识开始提高，目前47% 的 IT 供应商、服务提供商和受监管的行业使用 SBOM，88% 的人预计将在 2023 年使用 SBOM。SBOM 对已经对软件组件和 API 进行资产管理的企业最为有用，如今拥有强大软件开发流程的企业发现可以生成软件材料清单的工具更容易使用。SBOM 可以由构建系统创建，也可以由软件组成分析工具在事后生成。许多工具可以集成到 CI/CD 流水线中并作为构建的一部分运行，甚至可以在下载库时运行。
为了让 SBOM 更好地发挥作用，企业需要明确开发团队获取开源软件的相关政策，开发人员需要清楚地知道公司的安全策略和政策是什么，为了保障开发软件安全，开发人员必须明确他们正在获取的开源软件是没有被篡改的。因此，CIO 们应该首先向他们的开发团队教育和灌输一些基本步骤，即使用新兴的行业标准方法，一是锁定构建系统，二是创建一种可重复的方法来验证软件工件的可信度，然后再将它们带入开发和生产环境。
保护企业的软件交付流水线也很重要。NIST 的安全软件开发框架 (SSDF) 和 SLSA 是很好的起点：它们涵盖了各种成熟度级别的最佳实践，从简单的构建系统开始，然后使用日志和元数据进行审计和事件响应。BitBucket、GitHub、GitLab 等版本控制系统都包括安全和访问保护功能（包括越来越精细的访问策略控制、分支保护、代码签名、要求所有贡献者进行 MFA 以及扫描机密和凭据），但需要在使用的时候明确启用。此外可以通过在单个堆栈中实施 SLSA 来保护构建流水线，例如用于可重复安全创建工件 ( FRSCA ) 的项目，虽然目前尚未具备投入生产的能力，但在未来 CIO 可以期望在构建系统时包含更多此类实践。
不过 CIO 们需要留意 SBOM 只是保护流水线安全的解决方案中的一部分，且 SBOM 创建和使用 SBOM 的工具也仍在完善，请求和使用的过程也需要优化。因此在要求供应商提供 SBOM 时，还需要明确 SBOM 的更新频率，是否包含漏洞报告和通知等。企业还需要工具来阅读 SBOM，并制定流程以对这些工具的发现采取行动。
CIO 们应当明确 SBOM 是一种推动力，可以帮助企业应对可能发生的事件，但它不是解决软件供应链安全的万能灵药。同时目前行业响应的速度以及围绕 SBOM 标准和代码证明仍有待提高和加强。不过随着对 SBOM 的需求上升，我们对此可以保持乐观态度。
Seal 软件供应链防火墙旨在为企业提供代码安全、构建安全、依赖项安全及运行环境安全等4大防护，通过全链路扫描、问题关联及风险阻止的方式保护企业软件供应链安全，降低企业安全漏洞修复成本。