软件供应链安全是一个关键的风险和合规性问题,但大多数组织都以分散的方式处理它。缺乏一个包罗万象的框架会遗留安全漏洞。通过实施三支柱框架,安全和风险管理领导者可以确保广泛的保护。
主要发现
-
对软件供应链的攻击给组织带来重大的安全、监管和运营风险。有数据显示,这些攻击造成的损失将从 2023 年的 460 亿美元上升到 2031 年的 1380 亿美元。
-
在全球范围内,包括法律法规在内的合规要求以及非正式的行业指导正在实施,以迫使对软件供应链安全 (SSCS) 和应用程序安全风险采取更积极的应对措施。
-
Gartner 2023 年技术采用调查发现,近三分之二的组织报告称他们已经实施或正在实施 SSCS 计划。尽管如此,多起事件和指标表明,这些努力(通常在整个组织内缺乏协调)未能解决严重的安全漏洞。
建议
-
制定一项协调战略来增强 SSCS,解决软件供应链框架的管理、创建和使用支柱中的所有风险因素。
-
确定安全、软件工程、采购、供应商风险管理和其他方的利益相关者,教育他们了解所涉及的风险并支持他们采取必要的行动以减轻危险。
-
与相关利益相关者协调,制定并实施计划,以弥补与SSCS工作相关的流程和工具的不足。
战略规划假设
到 2027 年,80% 的组织将在整个企业内采用专门的流程和工具来降低软件供应链安全风险,而 2023 年这一比例约为 50%。
介绍
破坏性攻击凸显了对软件供应链安全的迫切关注。这些攻击的估计成本高达数百亿美元,预计到 2031 年将增长 200%,达到 1380 亿美元(见图 1)。
图 1:全球软件供应链攻击年度成本
主要攻击面和风险包括:
-
软件开发基础设施:通过渗透开发环境,攻击者将恶意软件整合到已部署的软件中。
-
恶意代码:2023 年在 245,000 个开源软件包中发现了恶意软件,是 2019 年以来所有年份发现总数的两倍。
-
开源漏洞:超过 90% 的专有代码包含开源依赖项,其中 74% 包含高风险依赖项。安全开发实践不足会增加代码中出现漏洞的概率。
-
被遗弃且维护不力的开源依赖项:大约一半的开源依赖项在两年多的时间里没有开发活动,导致这些项目实际上被遗弃了。许多项目缺乏强大的维护者团队。如果在这些依赖项中发现漏洞,修复要么会被延迟,要么根本就不会出现。
软件供应链安全也是一个监管和合规问题,全球政府和行业都提出了要求。
Gartner 技术采用报告的约 59% 受访者表示,他们已经或正在部署 SSCS 措施。但Gartner 客户的研究表明,这些努力往往脱节。努力往往集中在问题的单一方面,组织利益相关者之间几乎没有协调。这种孤立的方法会导致重复和低效,以及糟糕的结果。许多组织正在重新考虑他们的软件供应链战略。在 Gartner Peer Connections 讨论中,67% 的参与者表示他们已经重新评估或计划重新评估他们的 SSCS 战略(截至 2024 年 5 月)。
软件供应链安全可以看作是一个涵盖三大支柱的框架:管理、创建和使用,如图 2 所示。通过实施这样的框架以及支持流程和工具,安全和风险管理领导者可以确保对问题做出协调响应,最大限度地减少保护盲点或漏洞,并降低整个软件开发和使用生命周期的风险。
分析
制定协调的 SSCS 战略
软件供应链安全是用于管理、创建和使用软件的一系列流程和工具,以减轻针对软件的攻击或其作为攻击媒介的使用:
-
管理重点评估第三方软件的风险及其可接受性。
-
创建专注于安全开发以及软件工件和开发流程的保护。
-
使用通过验证、来源和可追溯性来确认软件的完整性。
图 2:软件供应链安全的三大支柱
为了实现软件供应链安全的最高有效性和效率,需要整个组织利益相关者的协调和参与。他们的信息需求以及他们为支持 SSCS 而采取的行动依赖于组织开发、使用和分发的软件的共享信息,以及相互关联和相关的流程。Gartner 建议组织在三大支柱上实施 SSCS 功能:
-
软件开发中的监管包括根据已知的安全和运营风险主动评估和批准依赖项和软件工件,以尽量减少未来出现的问题。通过采取主动的方法并考虑各种风险,开发团队可以消除维护不善或不安全的工件,减少仅在项目中包含问题后才发现问题而导致的返工和摩擦。
-
创造包括两个主要领域:
o 首先,它涉及在开发过程中管理依赖项和工件。虽然尽早评估这些元素(请参阅管理支柱)对于防止引入有问题的依赖项至关重要,但此支柱有助于通过软件物料清单跟踪软件包的使用情况,从而简化未来的漏洞修复。
o 其次,确保开发环境安全至关重要,包括保护开发人员工作站、存储库、版本控制、集成和构建系统以及部署流程。这可以防止对开发基础设施的攻击,近年来,这种攻击已导致严重的供应链漏洞。威胁建模和安全测试等活动(通常与核心应用程序安全活动相关)也通过在代码开发中推广“安全设计”方法增强了供应链安全性。
-
使用增强了软件采购过程中传统的第三方风险评估。使用由采购和供应商风险管理团队进行,由 SSCS 的技术专家支持,涉及评估供应商软件安全措施并评估交付的代码是否存在策展中讨论的风险类型。此处收集的数据还可以简化对新出现的漏洞的事件响应。
管理
管理支柱涉及实施流程和工具,以便主动评估软件依赖项和其他工件,以识别与安全、许可、知识产权、供应链和运营相关的潜在风险。目标是通过仅评估和授权特定组件来防止使用不良组件。虽然这可能是一项复杂的任务,但好处是显而易见的,包括降低不安全或维护不善的依赖项带来的风险,并避免因使用不可接受的依赖项而导致的浪费精力和返工。
有不同的方法可以实现这一点:
-
创建和维护可信存储库:这涉及建立一个已根据组织标准审查和批准的代码和工件存储库。开发人员无需从外部来源下载,而是从此存储库检索已批准的工件。但是,设置此存储库需要付出大量努力,包括建立基础设施、制定政策、评估代码和实施支持流程。对于资源有限的组织来说,这种方法可能不可行。
-
自动管理工具和商业订阅:这些选项提供了一种更简单、资源密集程度更低的评估和控制工件的方法。一些软件组合分析和管理工具根据组织标准评估工件,并阻止下载不符合这些标准的软件包。这些工具结合使用专有研究和公开信息来评估与特定软件包相关的风险。或者,组织可以考虑订阅 Red Hat 或 Tidelift 等提供商的服务,这些服务支持维护和安全修复。
规划活动通常由开发和工程团队、应用程序安全团队和开源计划办公室进行。
尽管 Gartner 强烈建议使用此类评估,但目前很少有组织执行此类主动风险评估。这通常是由于缺乏内部先例、对所涉及风险的认识有限以及担心限制对依赖项的访问会阻碍开发过程。然而,忽视这些评估可能会导致安全或运营问题。例如,项目维护者或供应商可能不会优先考虑安全的开发实践,从而增加漏洞风险。此外,维护不善的代码可能会导致安全修复延迟或不可用,从而需要开发人员创建自己的修复程序或寻找替代依赖项。
管理行动行动计划
实施以下活动来支持管理支柱:
-
评估依赖项和其他工件的安全性和操作风险,并在将其包含在代码中之前控制它们的使用。这可以通过受信任的存储库、在开发人员开源选择期间进行更动态的检查以及通过使用提供支持依赖项的商业订阅来实现。可以使用支持各种属性的工具来衡量风险,包括:
o 已知漏洞
o 法律上不受欢迎或限制性的许可
o 通过OSSF 记分卡等指标衡量运营和供应链风险。(记分卡包含对 19 种不同属性的评估,包括采用各种安全实践、分支保护措施、贡献者数量以及缺乏许可证。)
-
获取并评估与 SSCS 相关的工件,例如软件物料清单 (SBOM)、漏洞可利用性交换 (VEX) 披露,以及其他工件,例如来自商业供应商的安全软件开发实践证明。(有关更多详细信息,请参阅SBOM 的创新洞察。)
-
测试代码和其他工件是否存在恶意或可疑代码(例如恶意软件、后门)。
创建
创建支柱包括在开发过程中评估和保护软件所采取的活动以及加强和保护开发环境本身的努力。
开发成果
工件(包括开源和商业依赖项、SDK、容器映像和专有代码)是在开发过程中导入或创建的。基于将恶意代码偷偷引入依赖项的攻击越来越普遍。下载和添加此类依赖项可以激活恶意软件,恶意软件可以传递给下游用户,使攻击者能够访问开发资源或其他不利结果。恶意内部人员还可以在开发过程中操纵代码,进行未经授权的更改或添加恶意代码。图 3 基于 ReversingLabs 进行的分析,概述了在开源依赖项中发现的越来越多的恶意组件。
图 3:开源软件中存在恶意代码
开发环境
开发流程涵盖开发人员的工作站、存储库和版本控制系统、集成和构建服务器、测试框架、部署工具等。攻击者通过网络钓鱼或其他形式的凭证盗窃等手段获取环境访问权限,从而发动了多起备受瞩目的供应链攻击。最终结果类似于针对带入系统的工件的攻击——引入恶意代码或未经授权访问资源,从而实现代码操纵、IP 盗窃和其他不良后果。
组织可以求助于各种框架和指导来帮助防范这些威胁。
Gartner 就该主题提供的指导——软件工程领导者如何降低软件供应链安全风险——概述了涉及代码保护、交付流程和操作环境的几项具体任务(见图 4)。
图 4:减轻软件开发和交付中供应链安全风险的最佳实践
另一个资源关注的是相同的问题,即软件工件的供应链级别 (SLSA) ,这是开源社区和行业参与者正在开发的框架。SLSA 针对各种“轨道”(迄今为止,已定义构建轨道)进行阐述,这些轨道由不同的保证级别组成。例如,构建轨道提供四个级别:
-
0 级——无保证。
-
1级——记录软件包构建过程的来源,帮助识别错误并提供文档以供将来参考。
-
2级——由构建系统生成的加密签名来源,旨在检测构建过程后的篡改。
-
3级——强化构建平台,用于检测构建过程中的篡改。
实施 SLSA 等框架需要工具来生成和验证所需的各种证明和记录。对于 SLSA,请考虑使用商业工具,或研究开源工具及其生态系统的使用情况。示例包括Sigstore (加密签名);元数据生成器(例如GitHub SLSA Generator )以及In-Toto ,它提供工作流和证明以支持生成和记录证明。
安全软件开发框架 (SSDF)是NIST 基于经过验证的安全软件开发实践而制定的一套指南。它是评估软件开发实践(例如供应商的实践)的基准。供应商越来越多地被要求在采购和供应商风险管理活动中提供其遵守 SSDF 的证据。
SSDF 包括与供应链安全相关的实践,例如“保护软件”,但它还涵盖应用程序安全的其他方面。其中包括设计安全软件、确保必要的组织结构和流程以支持应用程序和 SSCS,以及漏洞响应。
寻求全面指导以建立整体应用程序安全框架的组织可以使用 SSDF 作为模型。Gartner 还就此主题提供建议,包括《软件工程领导者应用程序安全指南》和《构建应用程序安全程序的指导框架》。
在创建支柱中,SSCS 任务通常由应用程序安全、开发和工程团队执行,有时也由其他安全成员执行,例如来自安全运营中心 (SOC) 或产品安全事件响应 (PSIRT) 团队的成员。这些团队必须合作实施一套实用且平衡的控制措施,尤其是针对开发人员工作站和开发流程中的访问控制。
控制不足或松懈会增加攻击成功的可能性。然而,虽然严格的控制可以防止攻击,但它们可能会阻碍开发人员的生产力和支持。因此,组织应该召集不同的团体来协商控制措施,以反映:
-
正在开发的应用程序的总体风险和敏感性。
-
攻击可能造成的潜在风险(例如数据泄露、法规不合规、业务影响)。
-
开发管道控制所造成的延迟或其他负面影响。
自动化(利用开发基础设施来执行安全策略)可能大有裨益。在这种情况下,安全性定义了特定的策略来反映组织对给定应用程序的期望风险状况。使用自动化系统根据这些策略评估工件可确保快速评估和判断,从而有助于避免部署延迟。授权的工程人员可以处理例外情况,例如批准有问题的构建以快速解决生产中断。他们的活动应受到监控和记录,以供参考和审计。
创建行动计划
在创建支柱中,需要采取以下行动:
-
重新评估依赖项的风险并控制其在开发中的使用。这是初步评估的次要措施,可确保未纳入未经授权的依赖项。此步骤还有助于跟踪依赖项的实际使用和部署,这对于事件响应至关重要。如果管理活动不足,这将成为主要的风险缓解活动,需要在构建过程中进行更严格的控制,这可能会导致开发过程中断。
-
如果此时发现问题,请向开发人员提供指导,建议使用特定依赖项的替代版本来解决安全问题,或完全使用替代依赖项。有关使用中的依赖项的相对风险的信息,或依赖项的更新版本导致开发人员代码发生重大变化的可能性的信息可能会有所帮助。
-
保护和加强开发环境和工件。这可以通过强大的身份验证和访问控制来控制对代码和其他资源以及开发基础设施的访问来实现。应执行职责分离和最小特权访问等原则。
-
实施开发工具供应商提供的安全控制,例如策略定义和实施、分支保护以及服务器和进程的管理。理想情况下,访问软件工件和进程应通过存储库、服务器和测试框架等系统进行。这些系统充当代理,通过可以实施访问控制策略的系统来调解对代码和进程的访问。
-
在需要直接访问系统或进程的情况下,请使用特权访问管理 (PAM) 等工具。PAM 提供必要的访问权限,同时保持所需的控制和监控,以最大限度地降低不当活动的风险。
-
确保开发和运营团队积极参与定义和制定政策。所有利益相关者之间缺乏对开发环境中控制问题的规划和协商将不可避免地导致失败。
-
实施流程和工具(如 SLSA),以便检测篡改或未经授权更改软件的企图。这些工具还可以报告工件来源和完整性。
-
在构建过程中生成 SBOM(以及相关工件,例如 VEX 披露)。此信息应与内部团体(事件响应、产品安全等)和外部实体(业务合作伙伴、客户等)共享。
使用
使用支柱包括在购买之前或期间对商业和开源软件进行评估,以识别和降低风险。这一点很重要,因为有些案例中攻击者利用恶意代码破坏了商业软件,进而影响了客户。代码维护不善(包括使用过时或不安全的依赖项)表明存在重大技术债务,并对用户构成重大风险。这些评估还可以深入了解供应商所采用的应用程序开发和安全实践的严谨性。
Gartner 建议企业开展三项活动来识别和管理由于供应商应用程序安全流程不佳而导致的软件相关风险:
-
将软件供应链和应用程序安全评估纳入现有的供应商风险管理计划。组织需要更深入地研究供应商的应用程序安全实践。上述 NIST 框架SSDF可用于评估供应商的努力。安全和风险管理领导者应与采购和供应商风险管理团队合作,对供应商是否遵守此框架或类似框架进行评估。
-
要求软件内容和组成透明,包括开源依赖项和其他商业代码。软件内容可以通过 SBOM 确定。数据库(包括OSSF Scorecard项目等开源项目以及专有产品)可以提供有关各个依赖项的信息。买家应评估这些信息,并选择具有强大应用程序安全实践的供应商。
-
采用专门的测试和评估来搜索软件包中的恶意代码。虽然这是适用于所有类型的软件包应用程序的最佳做法,但它对于高风险系统尤其重要,因为恶意代码的影响更大。在部署之前结合使用专门的工具对软件进行沙盒处理可以帮助识别恶意代码。渗透测试等更传统的方法也可以提供帮助。在进行此类评估之前,应咨询法律顾问,以确保不会发生违反许可协议或控制法律法规的情况。
使用行动计划
为支持使用支柱应实施的具体活动包括:
-
实施流程和技术来接收、分析和存储 SBOM、VEX 漏洞披露和其他 SSCS 相关工件。这样做将确保可以轻松访问这些工件及其所包含的信息,以进行风险管理并评估新漏洞的影响。
-
制定政策,概述与商业和开源软件相关的可接受风险以及例外情况的程序。考虑以下因素:
o 是否存在漏洞,以及在什么情况下可能允许使用有漏洞的代码。
o 许可证条款不为组织所接受(需要法律顾问)。
o 指示代码总体健康状况和声誉的属性(如更新频率、维护者社区规模、遵守安全软件开发实践)。有关相关数据,请参阅OSSF Scorecard项目。
-
对于商业或合同软件开发,遵守安全软件开发流程的证明。SSDF 是一个全面的例子。其他替代方案包括《软件开发人员验证最低标准指南》和ISO/IEC 27034-1:2011 信息技术 - 安全技术。在适用的情况下,考虑特定行业或地区的指导或法规。
-
跟踪应用程序(内部开发和外部获取)中使用的依赖项(开源和商业),以快速识别可能受影响的系统。
-
对代码进行主动测试(二进制分析、渗透测试等),尤其是对敏感或高风险系统。法律顾问是必要的,因为许可协议和当地法律可能会限制测试范围。
确定利益相关者
如图 5 所示,有效的 SSCS 涵盖组织的多个部分。跨组织协调和信息共享可通过确保一致遵循 SSCS 标准来改善结果。各个团体都可以从共享信息中受益。例如:
-
采购和供应商风险管理团队在评估供应商和软件的风险时可以利用应用程序安全团队开发的开源风险数据。
-
当运营安全和事件响应团队能够轻松访问软件清单(商业和专有)及其所包含的依赖项并响应依赖项中的漏洞报告时,他们的效率会大大提高。
-
为了确保信息共享的便利及其在工作组之间的一致性,应该考虑一个通用的存储库,尽管工具和功能各不相同,使这项任务变得困难。
图5:软件供应链安全跨组织协调
采用流程和工具
鉴于组织使用和创建的软件数量庞大,以及为支持改进风险管理而需要分析和评估的数据量,某种程度的工具是不可避免的。不幸的是,市场很复杂,许多供应商(和几个开源项目)提供产品和工具来支持 SSCS 生命周期的不同元素。
相对较少的供应商能够提供完全涵盖 SSCS 框架所有支柱的综合解决方案,因此尽管更加整合的解决方案可以带来诸多好处(更容易的信息共享、简化的供应商管理等),但买家通常需要考虑多种工具来解决问题的不同部分。
评估和采购工作应从评估不同阶段对特定组织的重要性开始。例如,内部开发相对较少或使用外部依赖关系较少的组织可以降低专注于策划和创建阶段的功能和工具的优先级,转而强调在使用阶段对商用现成软件的评估和管理。
了解了相对优先级后,买家可以开始确定最符合其需求的供应商。鉴于市场的复杂性和不同工具功能的变化,咨询 Gartner 分析师有助于确定最符合特定组织需求的供应商。然后,买家可以继续评估最有可能完全满足其独特需求的工具。
在评估工具时,请考虑框架不同支柱的行动计划中概述的功能和任务(如上所述),作为评估标准的起点。问题的跨组织性质将推动来自多个利益相关者的代表的需求,以确保充分考虑功能。这些人还可以提供对其他要求的见解,例如将 SSCS 工具集成到其他组织系统(例如,软件资产管理、应用程序安全和 ASPM、SIEM 等运营安全系统以及 IT 服务管理工具)的需求。
Gartner 的其他研究可以提供有关 SSCS 领域内供应商的见解。例如:
-
软件工程领导者如何减轻软件供应链安全风险提供了用于秘密扫描和管理、可信组件注册表和工件签名等功能的商业和开源工具列表。
-
SBOM 的创新洞察包含支持 SBOM 生成和管理功能不同方面的工具列表和链接。