共计 1826 个字符，预计需要花费 5 分钟才能阅读完成。
随着古代软件开发越来越依赖于第三方资源，针对软件供应链的歹意攻打数量也随之激增。 据业内权威机构 Gartner 预计，软件物料清单 (SBOM) 的采用率在 2025 年将会达到 60%。 Gartner 明确揭示软件开发企业及组织，如果想要在软件市场上保持良好的竞争力，筹备好向客户提供 SBOM 是十分必要的。
SBOM 是治理古代软件部署的复杂性和安全性的重要根底。想要成为软件产品行业中的领导者，就必须满足对技术、最佳实际和解决方案一直增长的需要，以反对 SBOM 的交付。毫不夸大的说，SBOM 对于软件供应链平安治理至关重要。Gartner 示意，只管在 2022 年采纳要害工作软件解决方案的企业要求在其许可或反对协定中披露 SBOM 还不到 5%，但这一比例在 2025 年将会达到 60%。
SBOM 的重要性显而易见，但也须要企业感性对待其性质和用处。SBOM 和那些解决、剖析和利用平安相干信息的工具和流程一样重要。例如软件成分剖析 (SCA) 和代码签名，这些也是残缺软件供应链的必要元素。
当先于对 SBOM 的需要
Gartner 倡议软件提供商尽快满足 SBOM 披露的最低要求。与此同时，在筹备 SBOM 时，该当针对相应行业的需要和动静进行定制。只管当下软件供应商还没有收到要求披露 SBOM 的申请，但 Gartner 依然倡议软件提供商当先于对 SBOM 的需要，创立产品外部软件资产的残缺清单。
此外 Gartner 还倡议软件提供商将其每项资产归类为“商业秘密”或“齐全披露”。软件供应商可能决定从 SBOM 中排除或披露商业秘密，但通过客户许可协定中的窃密协定能够来爱护这些商业秘密。同时还倡议软件供应商创立所有内部依赖项的残缺清单，受与资产提供商签订的服务水平协定 (SLA) 束缚的依赖项应归类为“商业反对”。依赖项的任何 SLA 都应要求残缺的 SBOM 披露，而没有合同 SLA 的依赖项应归类为“自反对”。同时，软件供应商该当为这些依赖项创立一个自我反对的 SLA。该 SLA 应包含对残缺 SBOM 的发现和跟踪。
充分发挥 SBOM 的平安价值
Gartner 倡议软件资产提供商该当确保他们有能力为其自主开发的资产创立残缺的 SBOM。在满足客户对 SBOM 的最低需要的同时，供应商该当超过满足最根本的需要。SBOM 的目标是为软件用户提供对形成软件解决方案的资产的洞察力，以便他们致力纠正和打消通过 SBOM 披露发现的平安问题，从而防止网络歹意攻击者利用这些平安问题及破绽用于本人的攻打向量策略。
同时能够尝试制订和应用让 SBOM 可能发明更多平安价值的策略。比方将 SBOM 交付与更加宽泛的平安机会，更深刻地集成到 DevSecOps 实际中，以及以将其与长期产品路线图分割起来的形式扩大和倒退 SBOM 技术。
古代软件开发环境
Gartner 预估在将来的软件我的项目中，将有 40% 到 80% 的代码来自第三方，大部分内部代码来自无数个开源我的项目，而其余的专有代码来自供应商，对其平安状态和情况的可见性非常低。与此同时，许多开源软件 (OSS) 依赖项的治理不善让状况变得更加简单。在适度依赖开源软件的技术生态系统中，许多组件可能齐全不足足够的商业反对起源。因而，软件的平安情况及实际会因供应商而异。
在现实状况下，软件供应链上的每个贡献者都将为其组件的品质和安全性提供保障，而这些保障将从供应链中的一个环节传送到下一个环节中。任何组件的更新将会立刻公布，而对应的依赖关系会主动在整个软件供应链中变动和流传。然而，在事实软件行业的使用环境中，许多软件供应链上的提供商经常未可能充沛做好平安保障，或者因为不足执行此操作的工具而无奈做好这一点。
SBOM 将必不可少
在将来的软件倒退中，SBOM 对软件开发企业来说将变得至关重要。为软件解决方案提供残缺、精确和最新的 SBOM 这一要求，将成为将来三年内大多数客户参加的强制性因素。因为无奈精确地发现和跟踪外部和内部依赖项，许多技术和服务提供商将难以满足必要的 SBOM 要求，这些提供商将和会一些无奈或不愿提供 SBOM 披露的软件供应商一样，在将来被逐步排除在许多竞争机会之外。
Seal 软件供应链防火墙针对单个我的项目或全局为您提供依赖组件的具体洞察。在新版本中，Seal 软件供应链防火墙反对导出 SBOM，并针对 SBOM 进行了加强。同时反对查看和检索单个我的项目或全局的依赖组件，反对查看依赖树和各组件的依赖门路，提供依赖组件的发行信息、许可证、破绽状况、平安评分等信息。
申请试用：https://seal.io/trial
