对于快速发展的软件供应链安全技术来说，好消息是，快速的创新步伐提供了越来越多的机会，可以提高软件产品组合中大量组件和代码的可见性和透明度。
坏消息是，实验和创新同时朝着许多不同的方向发展，安全工具领域是一个令人困惑的混合体，混杂着不断发展的各种类别和利基产品。
其中一些是更传统的应用程序安全工具，它们正在向更适合开发人员的方向发展。还有一些是传统的开发工具，它们增加了以安全为中心的控制和功能，以应对供应链风险的挑战。还有一些来自DevSecOps的领域，旨在促进开发和安全领域之间的相互协作。
Tanium公司的产品顾问Tom Going表示：“人们很难对软件供应链的安全有一个清晰的认识，原因之一是供应链中有很多环节可能出错。企业可能会在软件中直接引入漏洞，就像几年前的SolarWinds数据泄露事件一样，在Log4j等常见库中存在漏洞，甚至像一个受损的证书颁发机构这样的东西。”
软件供应链安全没有黄金标准
虽然有一些软件供应链安全产品栈和平台开始在市场上整合，但这些产品的功能组合却多种多样。
这些平台倾向于围绕的主要工具类别是软件组合分析(SCA)和生成软件材料清单(SBOM)的工具，即现代软件的所谓“成分列表”。虽然SCA和SBOM倾向于构成许多软件供应链安全工具的支柱，但对于试图构建路线图以支持管理供应链风险全面计划的首席信息安全官来说，这确实只是冰山一角。
Gartner公司的高级主管兼应用安全分析师Dale Gardner表示，“当人们关注供应链安全时，他们关注的是使用SCA等工具，他们关注的是SBOM。这些都是解决方案中非常重要的部分，但它们实际上只是一种不全面的解决方案。”
这还涉及许多其他活动部分，包括机密管理、依赖关系映射和管理、持续集成(CI)/持续交付(CD)管道安全性、有效的存储库管理等。大多数专家都认为，安全团队将很难从一家供应商那里找到他们需要的一切。
咨询机构Coalfire公司的应用程序安全高级经理Michael Born解释说：“我认为，没有一家供应商能够以满足所有企业需求的方式处理与软件供应链安全相关的所有挑战。”他表示，缺乏整合并不一定是件坏事。他说，“这可能会使企业陷入与供应商锁定相关的风险，并且可能意味着企业成熟或变化的速度比供应商能够跟上的速度快。”
这种碎片化不仅是来自几个不同技术角度(以开发为中心的工具、以操作为中心的模具、以安全为中心的工具)的有机创新的结果，而且还有一系列不同的用例。
德勤公司的网络风险安全供应链负责人Sharon Chand解释说:“我们必须非常具体地了解正在谈论的风险或用例，以便能够找到合适的软件解决方案或整体解决方案堆栈来解决这些问题。因为我真正需要什么样的解决方案将取决于在软件供应链安全场景中的位置。如果我是软件生产者，那么看起来与软件消费者不同。通常情况下，在整个供应链生命周期的某些阶段，每个人都会同时处于这两种状态。”
企业如何将它们整合在一起将高度依赖于他们的用例、基础设施，以及他们团队的技能和文化的构成。不幸的是，目前还没有简单的方法来构建这个堆栈。
安全工具的十个类别
下面的安全工具列表为首席信息安全官提供了一个很好的入门清单，用于规划适合他们的软件供应链安全解决方案堆栈。这份名单虽然并不详尽，而且可能很快就会改变，但是它包含了主要的工具类别和网络安全领导者可能想要考虑的软件供应链安全路线图的特性。
(1)SCA和SBOM的生成
SCA工具目前最为人所知的是它们在软件供应链安全中的作用，但这一类别的起源故事开始于更为平淡无奇的领域。这些工具最初是为了帮助开发团队在其构建中跟踪其开源组件的使用情况，以处理许可合规性。随着供应链安全开始获得更多关注，SCA工具内置了对与跟踪组件相关的漏洞和安全风险的更深入分析和管理，并成为企业生成SBOM和管理其开源使用的主要方法之一。Mend.io(前身为WhiteSource)、FOSSA和Synopsys Black Duck就是这种进化路径的主要例子。
SCA并不是生成SBOM的唯一选择。其他一些SBOM生成方法包括使用命令行界面(CLI)工具，例如Cyclone DX CLI和SPDX Tool，运行时分析，例如Rezilion;或二进制分析，如ReversingLabs。但SCA往往是那些构建软件供应链解决方案堆栈或生态系统的供应商的赌注。其中一些是SCA供应商，他们通过内部开发或收购扩展到下面描述的其他工具类别。其他公司可能从一开始就考虑到了开发人员的心态，包括混合供应链工具中的SCA;Snyk就是一个很好的例子。Synopsys和ReversingLabs最近宣布了更多的合作伙伴关系，在不将客户锁定在单一平台的情况下扩大了供应链安全能力。
(2)代码扫描和渗透测试
保护软件供应链的核心是一个应用程序安全问题，因此传统的应用程序安全代码扫描工具将在这个解决方案堆栈中发挥重要作用。静态应用程序安全测试(SAST)、动态应用程序安全测试(DAST)、交互式应用程序安全测试 (IAST)和运行时应用程序扫描保护(RASP)工具，以及明智地使用渗透测试，可以帮助企业测试他们自己的内部代码，并提供对第三方代码的进一步检查，以作为应对风险的后盾。Coalfire的Born说，“使用常见的SCA或SBOM测试工具和技术可能会检测不到这些风险。”
他说，通过全面的代码扫描来维持多层安全是至关重要的，渗透测试的抽查也是如此。
他说:“SCA和SBOM产品依赖于已知的、先前发现的漏洞，而彻底的应用程序渗透评估可能会在检查第三方库和框架时识别出脆弱的代码使用情况，而这些代码以前可能在其他地方没有报告过。”
(3)SBOM的丰富和聚集
当企业创建他们自己的SBOM并从他们的供应商那里摄取SBOM时，这些工件的聚合、丰富和管理将成为操作它们的一个日益重要的部分。例如，添加漏洞可利用性交换(VEX)信息将成为情景化SBOM的一个日益重要的部分。类似地，这些工具可以潜在地丰富SBOM信息的数据包括组件健康检查，例如OpenSSF记分卡数据和CISA已知被利用漏洞(KEV)数据库中的漏洞预测评分系统(EPSS)分数。
此外，简单地汇总软件组合和业务线中的SBOM信息将是网络安全领导者日益关注的问题。这仍然是一个新兴的领域，尚未真正整合成行业分析师确定的类别，因此首席信息安全官必须在SCA+类型的工具、开源工具和新平台中寻找这些功能，这些工具正在开辟他们自己的类别定义路径。这些例子包括Cybellum、Anchore和Rezilion，以及Bomber等新的开源工具。
(4)机密管理
共享机密扫描和管理正在从一个独立的工具类别快速转变为一个功能，该功能正在融入软件供应链安全工具的各个方面。这是因为在开发和实际环境中，针对嵌入在源代码、配置文件和基础设施代码中的机密数据的网络攻击活动仍然猖獗，因此迫切需要解决这个问题。
Gartner公司在最近发布的一份报告中建议：“凭证文件、私钥、密码和API令牌等机密信息不应提交给源代码控制存储库。使用机密管理工具安全地存储和加密，实施访问控制，并管理秘密(即创建、轮换和撤销)。”
这是一个基本的工具组件，因为网络攻击者可以利用共享的秘密来完全破坏企业软件供应链的完整性。
(5)依赖关系管理和映射
依赖关系管理和分析是另一个有点模糊的类别，与SCA和SBOM聚合等其他工具类别高度重叠。但这是值得呼吁的，因为它触及了一些最棘手的软件供应链安全问题的核心。
安全倡导者对当今SBOM状态的一些最主要抱怨是，它们仍然难以传达与列举的软件相关的可传递依赖关系。
首席信息安全官和他们的团队将需要更好的方法来规划和管理隐藏的依赖关系网络，这些依赖关系网络横跨他们的应用程序、API、CI/CD管道组件和作为代码的基础设施。一些可用的工具包括依赖映射工具，性能和弹性利益相关者也依赖于这些工具，例如Datadog和Atlassian。此外，SCA和SBOM管理工具经常将这些特性合并到它们的组合中。最近在这方面打入市场的一个值得注意的参与者是EndorLabs公司，该公司于2022年10月脱离隐身模式，将自己描述为“依赖生命周期管理”解决方案。上个月，该公司进入了RSA大会创新沙盒的决赛。
(6)受信任的存储库和注册中心
虽然工件存储库和容器注册表本身不是安全工具，但是将它们与规范的策略和过程一起使用可以在管理供应链风险中发挥重要作用。建立可信的工件存储库和容器注册中心是为开发人员建立“安全护栏”基础设施的基本部分。提供经过批准的组件的集中来源是一种主动的方法，可以避免出现问题，并对进入企业软件的内容进行健全的治理。
Gartner公司的分析师写道:“这些存储库是经过批准和审查的工件和软件组件的可信来源。这实现了对软件成分的集中管理、可见性、可审核性和可追溯性。”
(7)安全代码签名
随着开发人员在其生命周期内提交和部署软件，代码签名正日益成为确保代码和容器完整性的最佳实践。这个过程不仅对于建立强大的内部控制措施以防止篡改至关重要，而且对于建立客户对交付给外部客户的产品的信任也至关重要。当然，代码签名证书是软件供应链攻击者青睐的目标，因此首席信息安全官及其团队需要确保他们选择正确的工具并建立控制措施，以确保他们的代码签名过程真正安全。这一类别中的一些主要工具包括Garantir、Keyfactor、CircleCI、Cosign和Venafi。
(8)CI/ CD管道安全性
持续集成(CI)/持续(CD)交付管道是软件“工厂”的一部分，开发人员依靠它来生产代码，因此，它是整个供应链的内在组成部分。因此，加强这些环境的安全工具是健全的供应链安全计划的重要组成部分。已经解决的机密管理问题是这个类别的一个重要方面。其他包括CI/ CD策略和治理管理，就像Apiiro和Cycode这样的公司正在开发产品，以及实现良好的特权访问控制和强身份验证。
(9)第三方风险管理平台
到目前为止，大多数工具主要集中于深入挖掘内部开发软件中使用的第三方组件。但是，对于那些没有太多可见性的第三方商业软件怎么办?这就是第三方风险管理(TPRM)工具和流程发挥作用的地方。即使SBOM要求在未来几年内竞相推动软件供应商提高透明度，但目前大多数企业都很盲目。虽然TPRM风险评分工具(例如SecurityScorecard或RiskRecon)不能完全解决这个问题，但它们至少可以作为风险的代理，可能会让企业确定他们需要与特定供应商和软件提供商合作，以深入挖掘他们的代码。
德勤公司的Chand表示:“我认为TPRM产品可以发挥作用的地方是，如果存在风险，我们能够识别风险，也许这就是我真正希望将精力集中在SCA和理解软件组成的原因。它成为了一种风险缓解技术，而不是我在生产或购买的所有软件中普遍使用的解决方案。”
她说，软件供应链安全领域仍然缺乏应用安全风险和业务风险之间的可靠工具联系，她认为下一个重大创新机会可能在于供应商和从业者如何将TPRM平台和更广泛的供应链风险管理(SCRM)流程与来自SBOM和CI/CD管道的数据联系起来。
(10)IaC安全和CNAPP
用于测试和部署代码的底层基础设施也是代码，是供应链的基本部分。因此，首席信息安全官应该考虑至少将基础设施即代码(IaC)扫描和安全工具作为其更广泛的供应链安全计划的一部分。这些工具倾向于跨越软件供应链安全工具和云原生应用程序保护平台(CNAPP)之间的界限，这可以说是开始进入云安全和其他安全运营领域。但是云原生应用程序保护平台(CNAPP)提供了很多其他的供应链安全支持，特别是在容器可见性和运行时安全性方面。容器是软件供应链中主要的攻击目标，在运行时采用的安全措施可以在工作负载进入生产环境之后为其提供支持。
