软件供应链安全正在迅速发展，如果首席信息安全官 (CISO) 只关注软件组件分析 (SCA) 和软件构建材料清单 (SBOM)，他们可能只会得到问题的部分解决方案。 CSO（www.csoonline.com）提供了一个初步的检查清单，以规划软件供应链安全解决方案堆栈。
随着安全领导者在建立软件供应链安全计划方面的进展，他们面临着一个喜忧参半的情况。确切地说：技术正快速发展，有利也有弊。
好消息是，软件供应链安全的蓬勃发展与创新为我们提供了更多机会，以增强对加入软件组合的大量组件和代码的可见性和透明度。
然而，坏消息是，实验和创新正在同时朝着许多不同的方向发展，而工具领域则变成了令人困惑的一团混乱，充斥着新的和不断演变的类别以及专门的产品。
其中一些是更传统的应用安全工具，它们正在不断发展，以更加符合开发者的需求。还有一些是传统的开发者工具，它们正在加强安全方面的控制和功能，以满足供应链风险的挑战。还有一些是源自DevSecOps领域的工具，专门旨在促进这些领域之间的相互合作。
Tanium的产品顾问Tom Goings告诉CSO：“了解软件供应链安全情况如此困难的一个原因是，在供应链中存在许多环节，其中一些环节可能会出现问题。可以直接在软件中引入漏洞，就像几年前的SolarWinds示例一样，也可能在常见库（例如Log4j）中存在漏洞，甚至可能出现类似受损的证书授权机构（CA）之类的情况。”
没有软件供应链安全的黄金标准。
尽管市场上出现了一些软件供应链安全产品组合和平台，但这些产品的功能组合千差万别。
这些平台主要围绕的主要工具类别通常是软件构成分析（SCA）和生成软件材料清单（SBOM）的工具，这些被称为现代软件的“成分列表”。尽管SCA和SBOM通常构成许多软件供应链安全工具的基础，但对于试图建立支持全面供应链风险管理计划的首席信息安全官（CISO）来说，这实际上只是冰山一角。
达尔·加德纳（Dale Gardner），Gartner的应用安全高级主管和分析师，在接受CSO采访时表示：“在考虑供应链安全时，人们通常专注于使用SCA等工具，也关注SBOMs。这些是解决方案的非常重要的部分。但实际上，它们只是一个非常局部的解决方案。”
还涉及到许多其他方面，包括秘密管理、依赖关系映射和管理、CI/CD管道安全、有效的存储库管理等等。大多数专家都认为，安全团队难以从一个供应商那里找到他们需要的一切。
咨询公司Coalfire的应用安全高级经理迈克尔·博恩（Michael Born）解释说：“我认为，没有一个供应商可以以适应所有组织要求的方式处理与软件供应链安全相关的所有挑战。” 他告诉CSO，这种分散并不一定是一件坏事。“这可能会使组织陷入与供应商绑定相关的风险，并且可能意味着组织发展或变化的速度可以超过供应商的进步速度。”
这种分散现象不仅是由于来自多个不同技术视角（开发工具、运维工具、安全工具）的有机创新，还因为涉及到一系列不同的用例。
德勤（Deloitte）网络风险服务实践的网络风险安全供应链负责人Sharon Chand解释说：“我们必须非常明确地了解我们正在讨论哪种风险或哪种用例，以找到合适的软件解决方案或整体解决方案组合来解决这些问题。因为我需要哪种解决方案实际上取决于我在软件供应链安全场景中的位置。如果我是软件的制造商，情况会与我是软件的消费者不同。而且通常情况下，在整个供应链生命周期的某些时刻，每个人都将同时扮演这两个角色。”
组织如何将所有这些组合在一起将高度取决于他们的用例、基础设施以及团队技能和文化的构成。不幸的是，目前尚没有轻松的方法来构建这个组合。
10种安全工具
以下列表为首席信息安全官（CISOs）提供了一个很好的起点检查清单，用于规划适合他们的软件供应链安全解决方案堆栈。这个列表并不是100%详尽无遗的，而且可能会迅速变化。但它包括了安全领导者可能希望考虑的主要工具类别和功能，用于他们的软件供应链安全路线图。
SCA和SBOM
目前，SCA工具可能以其在软件供应链安全中的角色而闻名，但这一类别的起源故事始于更加普通的领域。最初，这些工具的构思是帮助开发团队跟踪其构建中的开源组件使用情况，以便更好地掌握许可证合规性。随着供应链安全逐渐引起更多关注，SCA工具加强了对与跟踪的组件相关的漏洞和安全风险的深入分析和管理，并成为组织生成SBOMs并管理其开源使用的主要方法之一。 Mend.io（前身为WhiteSource）、FOSSA和Synopsys Black Duck是这种演进路径的典型例子。
生成SBOMs的方式并不仅限于使用SCA。其他一些SBOM生成方法包括使用命令行界面（CLI）工具，如CycloneDX CLI和SPDX工具，运行时分析，如Rezilion，或二进制分析，如ReversingLabs。但对于那些构建软件供应链解决方案堆栈或生态系统的供应商来说，SCA往往是必备条件。其中一些是SCA供应商，通过内部开发或收购，扩展到了下面描述的其他工具类别。其他一些可能从一开始就以开发人员为目标，将SCA纳入供应链工具的组合中；Snyk是一个很好的例子。最近还有更多的合作伙伴关系，比如Synopsys和ReversingLabs宣布的合作，扩展了供应链安全能力，而不会将客户锁定在单一平台上。
代码扫描和渗透测试
在软件供应链的核心是一个应用安全问题，因此传统的应用安全代码扫描工具将在这个解决方案堆栈中发挥作用是理所当然的。静态应用程序安全性测试（SAST）、动态应用程序安全性测试（DAST）、交互式应用程序安全性测试（IAST）和运行时应用程序扫描保护（RASP）工具，以及渗透测试的谨慎使用，都可以帮助组织测试其自身的内部代码，并提供进一步的检查来验证第三方代码，作为风险的备份，这些风险在使用常见的SCA或SBOM测试工具和技术时“可能被忽略”，Coalfire的Born说。
他表示，通过完整的代码扫描维护多个层次至关重要，还有那些渗透测试的抽查。
他说：“SCA和SBOM产品依赖于已知的、先前确定的漏洞，而彻底的应用程序渗透评估可能会在检查第三方库和框架时识别出脆弱的代码使用情况，这些脆弱性在其他地方可能先前未报告。”
SBOM的丰富化和汇总
随着组织创建自己的SBOM并接受供应商提供的SBOM，这些文档的聚合、丰富化和管理将成为使其运营化的日益重要的一部分。例如，添加漏洞可利用性交换（VEX）信息将成为为SBOM提供上下文的日益重要的一部分。类似地，这些工具可能会用来丰富SBOM信息的数据包括组件健康检查，如OpenSSF Scorecard数据，以及来自CISA的已知利用漏洞（KEV）数据库的漏洞预测评分系统（EPSS）分数。
此外，仅仅将SBOM信息聚合到软件组合和业务线中将成为安全领导者日益关注的问题。这仍然是一个新兴领域，还没有真正形成行业分析师确定的类别，因此首席信息安全官必须在SCA+类型的工具、开源工具和新平台中寻找这些功能，这些新平台希望能够开创自己定义类别的道路。其中一些示例包括Cybellum、Anchore和Rezilion，以及像Bomber这样的新开源工具。
秘密管理
共享密钥扫描和管理正从独立的工具类别迅速发展为嵌入到各种软件供应链安全工具中的功能。这是因为嵌入在源代码、配置文件和基础设施代码中的秘密仍然在开发和生产环境中广泛存在，迫切需要解决这个问题。
一份最近更新的Gartner报告建议：“不应将诸如凭证文件、私钥、密码和API令牌之类的秘密提交到源代码控制存储库中。使用秘密管理工具安全地存储和加密秘密，强制执行访问控制，并管理秘密（即创建、轮换和撤销）。”
这是一个基本的工具组件，因为攻击者可以利用共享的秘密来完全破坏组织的软件供应链的完整性。
依赖管理和映射
依赖管理和分析是另一个有些模糊的类别，与其他工具类别（如SCA和SBOM聚合）有很高的重叠度。但它值得特别提出，因为它涉及到一些最棘手的软件供应链安全问题的核心。
安全倡导者对于当前SBOM的状况提出的一些最大的抱怨之一是，它们仍然难以传达与列出的软件相关的传递性依赖关系。
首席信息安全官（CISOs）及其团队将需要更好的方法来绘制和管理横跨其应用程序、API、CI/CD管道组件和基础设施即代码的隐藏依赖关系的网络。一些可用的工具包括依赖关系映射工具，性能和弹性相关方也倾向于使用这些工具，比如Datadog和Atlassian提供的工具。此外，SCA和SBOM管理工具通常将这些功能整合到其工具中。在这方面最近进入市场的一个值得注意的参与者是Endor Labs，该公司于2022年10月退出隐身模式，并自称为“依赖关系生命周期管理”解决方案。上个月，该公司入选RSA Conference的创新沙盒（Innovation Sandbox）决赛。
可信的存储库和注册表
虽然构件存储库和容器注册表本身不是安全工具，但与有纪律的政策和流程一起使用，可以在管理供应链风险方面发挥重要作用。建立可信的构件存储库和容器注册表是为开发人员建立“安全防护栏”的基础设施的基本部分。提供经批准的组件的集中来源是一种积极的方式，可以预防问题，建立组织软件中使用的内容的有效治理。
Gartner分析师写道：“这些存储库充当了经过批准和审查的构件和软件组件的可信源。这使得软件‘成分’的集中治理、可见性、可审计性和可追踪性成为可能。”
安全的代码签名
随着开发人员在软件的整个生命周期中提交和部署代码和容器，代码签名越来越成为确保代码和容器完整性的最佳实践。这不仅是对抗篡改建立强大的内部控制的关键过程，还是在向外部客户交付产品时建立客户信任的关键过程。自然地，代码签名证书是软件供应链攻击者的首选目标，因此首席信息安全官（CISOs）及其团队需要确保选择正确的工具并建立控制措施，以确保他们的代码签名过程真正安全。在这个领域的一些重要参与者包括Garantir、Keyfactor、CircleCI、Cosign和Venafi。
CI/CD管道安全
持续集成/持续交付（CI/CD）管道是开发人员用来生成他们的代码的软件“工厂”的一部分，因此是整个供应链的固有部分。因此，加固这些环境的安全工具是健全供应链安全计划的一部分。我们已经讨论了秘密管理，这是这个类别的一个重要方面。其他包括CI/CD策略和治理管理，比如像Apiiro和Cycode这样的公司正在生产的内容，以及良好实施的特权访问控制和强身份验证。
第三方风险管理平台
到目前为止，描述的大多数工具主要集中在深入挖掘内部开发的软件中使用的第三方组件。但那些组织对其可见性不如内部组件那么高的第三方商业软件呢？这就是第三方风险管理（TPRM）工具和流程发挥作用的地方。即使联邦SBOM要求争取在未来几年推动软件供应商提供更大的透明度，但目前大多数组织仍然相当盲目。尽管TPRM风险评分工具，如SecurityScorecard或RiskRecon，不能完全解决这个问题，但它们至少可以充当潜在风险的代理，可能会使组织识别出需要与某些供应商和软件提供商深入了解其代码的地方。
Deloitte的Chand表示：“我认为TPRM提供可以发挥作用的地方是，如果存在风险，而我能够识别出风险，也许那就是我真正想要集中精力研究SCA并了解软件的构成的地方。这变成了一种风险缓解技巧，而不是我要在我正在生产或采购的所有软件上涂抹的一种万能解决方案。”
她说，软件供应链安全领域仍然缺少一个坚实的工具链接，可以将应用安全风险与业务风险联系起来，她认为下一个创新的重大机会可能在于供应商和从业者如何将TPRM平台与更广泛的供应链风险管理（SCRM）流程以及来自SBOM和CI/CD管道的数据联系起来。
IaC安全和CNAPP
用于测试和部署代码的基础架构本身也是代码，是供应链的基本组成部分。因此，首席信息安全官（CISOs）至少应考虑将基础架构即代码（IaC）扫描和安全工具纳入其更广泛的供应链安全计划中。这些工具往往处于软件供应链安全工具和云原生应用程序保护平台（CNAPP）之间，这可以说是涉及到云安全和一般安全运营领域。但CNAPP提供了许多其他供应链安全支持，特别是容器可见性和运行时安全方面。容器在软件供应链中是不断增长的攻击目标，运行时安全措施可以为工作负载提供生产环境后的后备支持。
近期评论