Gartner发布2024年应用安全成熟度曲线：26项应用安全最新技术发展及应用状况和趋势

为了应对新威胁、不断发展的软件架构和组织结构以及敏捷的开发风格，应用安全创新不断涌现。安全和风险管理领导者应采用创新来提高其网络安全策略的有效性。

战略规划假设

• 到 2025 年，生成式人工智能 (GenAI) 将导致保护其所需的网络安全资源激增，导致应用程序和数据安全支出增加 15% 以上。

• 到 2026 年，40% 的开发组织将默认使用应用程序安全测试供应商提供的基于人工智能的不安全代码自动修复功能，而 2023 年这一比例还不到 5%。

需要知道什么

当安全和风险管理领导者为其组织实施或开发应用程序安全程序时，应用程序架构、角色和攻击正在发生重大转变，再次扰乱了应用程序安全领域。软件工程师现在负责识别和修复代码漏洞，虽然生成式 AI 正在帮助他们完成这项任务，但 AI 应用程序也扩大了攻击面。

许多组织渴望但又难以实施 DevSecOps，因此向应用程序安全态势管理和平台工程团队寻求帮助。云原生应用程序架构和软件供应链攻击需要新的方法和工具来保护组织资产。

安全和风险管理领导者必须利用应用安全领域正确的潜在趋势，在最适合组织成熟度的时间引入最合适的创新。

炒作周期

此技术成熟度曲线追踪了可帮助组织推进其应用程序安全计划的流程和技术的成熟度和采用情况。三大趋势正在通过全新的颠覆性创新重塑应用程序安全的现状：

1.    应用程序安全角色正在不断演变，软件工程师接管了进行“左移”安全测试和修复漏洞的实际工作，而应用程序安全领导者则成为顾问，负责定义应用程序安全策略并监控其正确执行。可达性分析和应用程序安全态势管理 (ASPM) 等创新正在日趋成熟，以服务于安全领导者并改善开发人员的体验和支持。

2.    云原生应用程序将代码与基础设施融合，并提高其部署速度，这需要能够感知工作负载并将开发与运行时互连的应用程序安全性。为了应对不断发展的架构和威胁，遵循此模式的创新（例如 API 威胁防护）正在进一步发展。其他创新（例如 Web 应用客户端防护）正在不断成熟，尽管它们的知名度和采用率仍然很低，这表明该行业需要不断更新对不断发展的威胁的认识。

3.    当部署支持 GenAI 的应用程序时，AI 和生成式 AI 会扩大攻击面，而AI 安全和异常检测开始帮助组织保护支持 AI 的应用程序，方法是提供活动可见性和测试，以识别即时注入和其他攻击的暴露情况。与此同时，应用程序安全工具开始使用 GenAI 提供虚拟安全冠军功能，以帮助软件工程师自动执行应用程序漏洞识别和修复等任务，并提供更安全的代码。

图 1：2024 年应用安全成熟度曲线

优先级矩阵

DevSecOps是一门成熟的学科，被广泛采用；但组织仍在努力简化其日常运营。ASPM 不断发展和成熟，以应对这一挑战，通过提供根据风险不断对漏洞进行优先级排序并协调补救措施的功能。平台工程允许安全领导者在整个开发流程中执行他们的政策，方法是在平台工程团队为软件工程师提供的用于开发和部署代码的工具中执行这些政策。

网络安全平台整合趋势也对应用安全领域产生了影响。云原生应用保护平台 (CNAPP) 不断发展，并通过紧密集成的工具提供应用程序和云基础设施安全扫描、态势管理和运行时保护。

然而，云原生应用依赖于分散的软件开发模型和第三方软件组件，而软件供应链攻击正在迅速增加。软件供应链安全 (SSCS) 正在成为一门融合各种概念的学科，从保护开发环境和管道到软件组成分析 (SCA) 和软件物料清单 (SBOM)。

表1 ：2024 年应用安全优先级矩阵

影响力	距离主流采用需要的时间
	不到 2 年	2 - 5年	5 - 10 年	超过 10 年
颠覆	DevSecOps	人工智能安全代码助手 应用安全态势管理 软件供应链安全
较高	API 安全测试 爬虫管理 云 WAAP 全生命周期 API 管理	API 威胁防护 云原生应用保护平台 DevOps 平台 渗透测试即服务 策略即代码 可达性分析 安全编码培训 软件物料清单 威胁建模自动化	人工智能安全和异常检测 加密敏捷性
中等		应用程序监控和保护 应用程序屏蔽 移动应用程序安全测试 无服务器功能安全	可组合安全 API Kubernetes 安全
较低

来源：Gartner（2024 年 7 月）

脱离炒作周期

保护第三方和 SaaS 应用程序往往与应用程序安全关系不大，而更多的是安全治理问题。提供的解决方案以执行安全策略（如数据丢失预防）为中心。因此，随着技术成熟度曲线继续增加对实际安全性的关注，安全服务边缘 (SSE) 和 SaaS 安全态势管理 ( SSPM)今年已脱离技术成熟度曲线。

混沌工程和服务网格是重要的概念，但它们往往不是应用程序安全讨论的中心，因此今年也没有出现在技术成熟度曲线中。

软件组成分析 (SCA) 是软件供应链安全的重要组成部分，目前已达到完全成熟并脱离了技术成熟度曲线。

萌芽期技术

1、策略即代码

影响力评级：较高

市场渗透率：目标受众的 5% 至 20%

成熟度：新兴

定义：策略即代码 (PaC) 语言将治理和合规性规则表达为代码，因此可以通过自动化工具以编程方式执行这些规则。PaC 语言通常是领域特定且声明性的。使用 PaC，策略被视为软件，使其受到版本控制、代码审查和功能测试的约束。最成熟的 PaC 工具可以将任何业务逻辑呈现为代码。您现在就可以使用它们来实施基础设施合规性、授权、Kubernetes 准入控制等。

为什么重要

在最成熟的自动化管道中，基础设施和运营 ( I&O ) 工程师主要将时间花在优化、治理和合规性上。许多人不再构建基础设施；这项工作已经实现自动化并移交给其他人。现在，I&O 功能围绕其最终用户使用的基础设施服务构建护栏。I &O 必须与安全和合规团队保持一致。PaC 将策略实施纳入其自动化管道，同时保留与典型 IT 组织结构图相似的职责分离。

商业冲击

• 安全性、合规性和自动化：PaC 与基础设施自动化相结合，可自动执行策略，并提供隐含的合规性保证。

• 安全和运营团队的协调：PaC 允许安全和合规团队直接与自动化管道交互。

• 可见性和可审计性：PaC 提供政策文档。可以审计 PaC 工具日志以证明政策正在得到执行。

• 节省时间和精力：PaC 意味着操作员的辛劳更少。

驱动因素

• 专用工具：目前市场上有几种专用的 PaC 工具，其中许多都是开源的。云原生计算基金会项目 Open Policy Agent 已成为PaC 的事实标准。甚至一些其他 PaC 工具现在也使用 Open Policy Agent 策略来代替自己的策略引擎。

• 监管不断加强：GPRS《通用数据保护条例》等法规既增加了合规难度，也增加了合规团队的压力。PaC 允许合规团队和审计人员详细记录他们的政策，并验证这些政策是否得到执行。

• 安全漏洞：上市公司因基础设施配置错误而发生的一系列值得报道的安全漏洞，使每个 IT 组织的安全和合规性实践受到更严格的审查。没有一个 I&O 团队希望其安全故障成为公司登上负面新闻的原因。

• DevOps 和 DevSecOps 的增长：越来越多的公司开始采用 DevOps 和 DevSecOps ，这意味着越来越多的公司正在遇到自动化带来的棘手治理问题。许多快速实施基础设施即代码的团队发现，他们需要更好的政策执行，而 PaC 可以提供帮助。

• 云优化和成本控制：除了安全性和合规性优势外，PaC 工具还可用于强制执行基础设施的构建标准，包括预算。在公共云中，过大或不必要的基础设施会直接产生自付费用，而以编程方式强制执行的政策可以帮助控制支出。

障碍

• 可下载内容稀缺：除非 PaC 工具拥有庞大的社区生成内容库，用户可以从中下载所需的策略，而不必自己编写策略，否则它们将无法真正获得关注。随着时间的推移，随着用户群的扩大和商业产品的采用率不断提高，PaC 工具将达到可下载内容的临界数量，以支持实际用例。

• 技能组合：许多 I&O 专业人员缺乏有效操作自动化和 PaC 工具的技能。

• 集成挑战：与现有工具集成很复杂，通常需要额外的配置。

• 组织惰性：在某些组织中，I&O 与安全或合规团队之间的协作改善实际上是不受欢迎的。这种动态可能会减缓 PaC 计划的速度、范围和规模。

• 成本：即使 PaC 工具本身是免费和开源的，但它们仍可能需要培训或咨询才能有效实施和运行。

2、可组合安全 API

影响力评级：中等

市场渗透率：目标受众的 1% 至 5%

成熟度：新兴

定义：可组合安全 API 是供应商提供的安全功能，例如隐私库、身份验证服务、加密服务和数字签名服务，通常通过 API 访问。开发人员可以使用可组合安全 API 将安全功能嵌入到他们的应用程序中。安全服务也可以从流行的开发人员平台中调用。

为什么重要

可组合安全 API 允许开发人员使用 API 将安全功能嵌入到应用程序中。由于这些服务是由 API 提供的，因此无需使用更广泛的安全平台即可使用这些服务。可组合安全 API 是定制应用程序中安全性的重要推动因素。

商业冲击

• 可组合安全 API 使开发人员能够在他们构建的应用程序中挑选和实现安全功能。这进一步推动了开发人员成为关键技术选择者。

• 可组合安全 API 的使用会产生依赖关系，如果服务不可用或提供商遭受安全漏洞，就会对业务产生影响。

• 可组合的安全 API 可以改善开发团队和安全团队之间的关系，让安全团队评估和批准服务。平台工程团队也可以支持这些安全服务。

• 采用有针对性的可组合安全 API 通常比采用更大的安全平台更便宜。

• 安全机制配置错误是导致组织暴露的常见原因。使用由专业供应商提供的可组合安全 API 可能会降低这种风险。

驱动因素

• API 现在是软件开发的核心部分。开发人员希望通过 API 获得可重复使用的服务，这是“API 优先”方法的一部分。

• 在完善组织应用程序安全程序时，建议将软件组件标准化。这将推动“默认安全”方法。

• 开发人员通常不是安全专家。使用可组合安全 API 使他们能够在应用程序中包含安全功能，而无需自己构建功能。因此，与完全定制相比，最终的应用程序构建速度更快、更安全。

• 总体而言，向可组合服务的转变推动了以 API 形式交付的安全服务市场的发展。

• 开发人员不仅仅是技术选择或架构的影响者，现在他们还经常推动决策和供应商选择。反过来，供应商越来越多地将开发人员作为产品主导增长销售活动的一部分。这推动了以开发人员为中心的产品的增长。

障碍

• 使用可组合安全 API 会带来增加依赖性、架构复杂性以及中断的风险，或者 API 提供商遭受安全漏洞的风险。

• API 可能难以交换或替换，如果必须将可组合安全 API 更改为另一个，则会带来困难。这种潜在的锁定是一个重大障碍。

• 当安全性已经内置于平台中，或者可以使用编码助手构建时，可能不需要使用单独的安全服务。

3、加密敏捷性

影响力评级：较高

市场渗透率：目标受众的 1% 至 5%

成熟度：新兴

定义：加密敏捷性是指在应用程序中透明地交换加密算法和相关工件的能力，用更新、不同且可能更安全的算法替换它们。

为什么重要

• 随着量子计算的成熟，非对称加密在未来五到七年内面临被破坏或破解的威胁。受到威胁的算法已深入到许多应用程序中，而大多数组织对其所使用的加密技术缺乏清晰的认识。

• 标准网络/PKI 协议正在转向量子安全态势，其中 RFC 8784 和多家供应商支持传输层安全性 (TLS) 和量子安全测试的双签名证书。

• 美国国家标准与技术研究所 ( NIST ) 已将其首个量子安全替代方案格算法标准化，以供广泛使用。格算法的替代方案结构化代码计划于 2025 年获得批准。这些算法将成为供应商和开发人员加密敏捷替代方案的核心。

商业冲击

由于量子计算对现有加密技术构成了越来越大的威胁，Gartner 预计加密敏捷性将成为技术供应商的一大差异化因素。受新算法影响的企业将需要评估并执行以下活动：

• 需要对使用加密或 PKI 的应用程序/通信进行盘点。必须使用元数据数据库跟踪有关算法、密钥大小、到期日期和用途的数据。

• 必须根据应用和用例确定合适的替代品。

• 新算法并不是密码学的直接替代品，因此必须测试替代方案并制定替代策略。

• 必须识别供应商的加密产品，并且供应商需要提供更换时间表。

驱动因素

• 预计需要五到七年才能开发出能够破解 Shor 或 Grover 算法密码的量子计算机。这比大多数组织中敏感信息的典型寿命要短得多，从而导致敏感数据泄露。使用 Shor 算法破解密钥与密钥大小呈线性关系，但受可用量子比特数的限制；一旦算法运行，较大的密钥大小将迅速下降，从而导致实施更改的时间很短。

• 大多数已清查过加密元数据的组织发现，他们已经积累了大量 PKI 技术债务（例如，过期证书、弃用算法、短密钥）。清理这些债务将大大降低组织的风险状况。

• 新算法具有其他用途，可以促进新的商业案例（例如，状态签名、同态加密）。

• 政府机构开始要求向其销售产品的供应商采用量子安全加密策略（例如，US NSM-10、EO-14028）。这包括最终产品中的所有产品或代码，包括开源软件 (OSS) 和其他供应商的产品。与软件物料清单一样，这大大扩展了这些订单的范围，包括许多不直接向政府销售产品的供应商。

• 需要识别供应商产品中的加密技术，并且供应商需要提供潜在更换的时间表。

障碍

• 变革的时间尺度（五至七年）大大超出了许多高级管理人员的预期任期，导致了一种“别人的问题”心态，使得一些决策者优先考虑短期项目。

• 许多组织不知道如何清点他们的加密使用情况，因此他们只能选择由供应商来完成工作或启动内部程序。

• NIST 算法标准化进程缓慢，导致各组织采用的是非标准 OSS 版本的算法。

• 许多组织缺乏领导如此规模的加密项目所需的专业知识。

• 市场对于“量子安全”的含义仍然存在一些困惑，有时导致组织评估那些谈论“量子”但不能解决问题的相对无用的技术。

4、人工智能安全代码助手

影响力评级：颠覆

市场渗透率：目标受众的 1% 至 5%

成熟度：新兴

定义：人工智能 (AI) 代码安全助手 (ACSA) 是一种帮助开发人员识别和修复代码中安全漏洞的技术。为此，它们使用生成式人工智能 (GenAI) 等人工智能形式提供自动修复建议以及直接代码帮助或聊天爬虫。ACSA 主要作为应用程序安全测试 (AST) 产品的功能提供。它们使用云服务来分析代码并提出建议。

为什么重要

开发人员通常没有接受过良好的培训，无法识别和解决其代码中的安全问题。代码助手提供了一种替代方案。在对安全编码数据进行训练时，AST 供应商提供的大型语言模型 (LLM) 会采用复杂的想法并将其格式化以获得最大清晰度。当开发人员在安全环境中获得有效答案时，他们会编写更好的安全代码。虽然大多数组织通过开发人员教练提供答案，但 LLM 和 ASCA 提供了更具可扩展性、以安全为中心的代码建议。

商业冲击

• ASCA 超越了更通用的 ASCA，为 AST 工具发现的特定安全问题提供了即时 (JIT) 解决方案。

• 与大多数工具不同，ASCA 可以处于独特的位置，同时优化多个变量（例如安全性和代码质量）。

• ASCA是下一代工具，用于弥补 JIT 培训和安全补救等剩余差距，将安全性转移到现代安全软件开发生命周期(SDLC) 中。

驱动因素

• 代码助手（例如GitHub Co-Pilot 或 Google Vertex）正在迅速发展，越来越受到开发人员的欢迎。开发人员已经习惯了 AI 助手在代码的多个领域与他们合作。

• 左移计划（即将工作从运行时环境（右侧）转移到开发人员（左侧））通常很难被采用或完全失败。这是因为为开发人员提供可靠安全指导所需的渠道有限且脆弱。这些计划通常依靠专家来指导组织。ASC A 提供了一个机会，可以在组织的多个层面添加虚拟专家，让开发人员可以轻松使用。

• AST 供应商传统上为 AppSec 提供工具，十多年来一直提供安全代码帮助，并可以访问其工具生成的核心安全编码数据。使用这些数据作为训练语料库，并将其与基础模型结合成 ASCA，是合乎逻辑的下一步。

• 开发人员相信 ASCA 将提供可靠的安全建议。Checkmarx 2024 年的一项调查发现，令人惊讶的是，70% 的开发人员对这些工具表示高度或中等的信心。

障碍

• 大多数组织担心通过人工智能助手泄露私人数据或知识产权 (IP)。虽然有办法防止这种情况发生，但信任度很低。

• 斯坦福大学最近的一项研究发现，使用安全助手的开发人员在采用安全助手后犯的错误比以前更多。  

• GenAI偶尔会产生幻觉，识别出不真实或错误的问题，或给出看似合理但不安全或不明智的解释。这种情况很难发现，尤其是对于初级开发人员而言。

• 代码所有权问题令人担忧，尤其是当 ASCA 贡献了大量代码时。鉴于助理通常使用他们接受过培训的代码，而不是创建原创代码，意外获取其他组织的 IP 是一个问题。

• 过度补偿安全性，而忽略性能等问题，是过去此类优化器失败的典型例子。人们担心这种情况可能会发生在 ASCA 上。

5、人工智能安全和异常检测

影响力评级：较高

市场渗透率：目标受众的 1% 至 5%

成熟度：新兴

定义：AI 安全和异常检测包括 AI 模型的运行时控制，无论是在 AI 应用程序之前还是内部。它提供 AI 护栏来检测意图或内容异常（毒性、幻觉），以及针对应用程序滥用和攻击（例如提示注入）的安全控制。它可以是专门的（例如聊天机器人）或范围更广，也可以是模型监控功能的子集。它作为云模块部署，由 API 进行检测或嵌入 AI 应用程序中。

为什么重要

生成式人工智能 (GenAI) 推动了大量新业务计划的涌入，这些计划涉及基于一个或多个人工智能模型的应用程序。这些应用程序，尤其是面向公众的应用程序，需要专门的控制来减轻可能影响组织的风险。人工智能安全和异常检测通过监控模型是否存在政策外、数据泄露、性能漂移、有偏见或有毒的模型输入或输出来帮助缓解内容异常。对于人工智能应用程序安全，它通常侧重于大型语言模型 (LLM)聊天机器人的提示滥用，但也扩展到其他类型的攻击，例如模型查询攻击。

商业冲击

AI 安全和异常检测可实时查看潜在的 AI 异常或攻击。在拥有大量 AI 应用程序的组织中，集中式可见性和警报管理有助于识别使用相同 AI 模型的多个应用程序所共有的问题。基于 LLM 的应用程序在新应用程序中所占的份额越来越大，这些应用程序需要控制输入以避免应用程序滥用，并控制输出以降低品牌受损的风险和基于错误输出的决策。

驱动因素

• 安全团队正在追赶正在进行的人工智能应用计划，并考虑可以轻松部署的人工智能安全和异常检测控制。

• GenAI 正在推动大量安全创新，但异常检测和安全控制可以更广泛地应用于 AI 应用程序和模型。

• 人工智能应用程序需要监控以确保合规实施、避免应用程序滥用并防止恶意活动。

• 功能强大的开源替代方案，例如LIama Guard，可用于商业用途，但有一定的限制。

• 早期创业公司面临着来自大型成熟供应商的激烈竞争，这些供应商提供类似的功能，例如安全服务边缘 (SSE) 。但如今，专业供应商提供了差异化优势，例如可以访问系统提示和原始模型输出，或应用机器学习技术来分析这些输入和输出的意图。

• 即将出台的法规（例如欧盟《人工智能法案》和几项美国法律）和现有的企业政策可能会要求采用应用程序安全实践。这些包括预防性控制和监控，以支持降低高风险人工智能系统的风险。

障碍

• 大多数以 LLM 为重点的产品都处于起步阶段，并非所有产品都涵盖人工智能和安全用例。

• 基于文本输入的实时安全警报可能会很嘈杂，并且容易出现较高的误报率，例如检测SQL 注入和 XSS 。

• 许多供应商规模较小但发展迅速，其敏捷策略可能会随着行业的发展而摆脱特定的应用类型。

• 缺乏反馈、可靠的独立基准以及关于攻击或幻觉等异常发生率的事实基础不足，使得证明工具的价值变得困难。

• 增加安全控制可能会导致应用程序发布延迟。

• 部署形式因素可能会影响控件可以看到的内容：部署在应用程序前面，它们只能看到用户输入和应用程序输出。应用程序堆栈中的多个入口点可能是必要的，尤其是在多模式AI应用程序的情况下。

• 许多供应商专注于 LLM 用例，例如检测和预防常见的即时注入、幻觉和毒性输出风险。缺乏特定领域或特定业务逻辑的 AI 安全过滤能力。

• 组织可能对检查应用程序输入和输出有隐私方面的担忧。例如，当今许多产品都是通过 API 调用实现的 SaaS 服务，这意味着与提供商的平台共享敏感内容。

膨胀期技术

6、可达性分析

影响力评级：较高

市场渗透率：目标受众的 5% 至 20%

成熟度：青少年

定义：利用可达性分析可以增强对安全风险补救措施进行优先排序的情景。可达性分析与静态应用程序安全测试 (SAST) 和软件组成分析 (SCA) 结合使用，可以揭示哪些漏洞会实际影响应用程序工作负载，从而帮助将漏洞管理情景化。

为什么重要

组织积压的安全漏洞负担过重，需要解决方案来化“山”为“丘”。关键和高严重性安全问题未得到修补的时间越长，它们演变为安全事件的风险就越大。可达性分析有助于减少漏洞管理的工作量。

商业冲击

除了安全问题升级为安全事故的风险之外，由于手动分类漏洞，开发人员需要花费更多时间进行补救，而无法开发新的创收功能。对于网络安全人员来说，在处理软件安全状况时，这会导致更多的挫败感和士气低落。

驱动因素

• 发现的安全漏洞比以往任何时候都多，但管理和补救这些问题的投资却没有跟上步伐。

• 具有已知漏洞的开源软件和第三方软件的使用增加导致了安全问题的出现，从而进一步加剧了安全积压。

• 大多数漏洞是不可利用的，因此开发人员可以优先解决最直接的风险。

• 可达性分析可以通过静态扫描器或监控运行时环境来实现。

障碍

• 必须采用 SAST 和 SCA 等静态安全扫描方法才能使可达性分析发挥作用。

• 可达性分析可以为目前必须管理和配置的现有安全工具添加额外的测试层。

• 在运行时使用时，执行时可能会产生少量的性能开销，但比起以前的创新（例如运行时应用程序自我保护（RASP））来说要小一些。

7、渗透测试即服务

影响力评级：较高

市场渗透率：目标受众的20%至50%

成熟度：成长

定义：渗透测试即服务 (PTaaS) 提供技术主导、时间点和持续的应用程序和基础设施测试，符合渗透测试 (pentesting) 标准，而传统上，渗透测试主要依赖使用商业/专有工具的人工渗透测试人员。该服务通过 SaaS 平台提供，利用自动化和人工渗透测试人员（众包或供应商内部团队）的混合方法，以提高结果的效率和有效性。

为什么重要

渗透测试是安全程序的基础，并受各种合规性标准（例如支付卡行业 [ PCI ]）的约束。PTaaS 通过一个平台提供持续的安全测试，该平台可以更快地安排和执行渗透测试，并与测试人员进行实时通信并查看测试结果。它提供 API 访问，以便与现有的 DevOps 和票务解决方案集成，实现工作流自动化。它还提供了记录和跟踪渗透测试结果的能力，以向领导/审计员展示一段时间内的进展。

商业冲击

PTaaS 是对漏洞扫描和应用程序安全测试的补充，并提供成本优化和渗透测试输出质量改进以及漏洞状态验证。PTaaS使组织能够通过持续评估提升其安全态势，并且与传统渗透测试阶段相比，可以通过访问通过平台提供的实时发现，在软件开发生命周期的早期阶段集成验证，从而能够更快地处理暴露问题。

驱动因素

• 由于公有云的使用加速和面向公众的数字资产的扩展，组织正在转向 PTaaS 来应对攻击面的增加。PTaaS 允许开发人员与渗透测试人员交谈并接受他们的指导，而不是完全依赖扫描仪，例如动态应用程序安全测试/静态应用程序安全测试 (DAST/SAST) 扫描仪。

• 内部安全专业知识有限的组织除了改善其安全态势之外，还必须满足其合规性和风险管理目标，因此寻求渗透测试服务来满足这些举措。

• 为了满足快速的生产期限，具有安全意识的组织必须将更敏捷的渗透测试方式集成到其DevSecOps实践的持续集成/持续交付 (CI/CD) 管道中。

• Gartner 客户表示希望更频繁地进行测试；然而，在现代基础设施中，手动渗透测试成本过高。

• 大多数组织都有渗透测试预算，并且经常寻求更好的方式来使用他们的年度预算。高度自动化、技术主导的渗透测试有可能以相同的价格提供更高质量的交付成果，或者至少以相同的价格提供更频繁的交付成果。

障碍

• 在市场上选择合适的 PTaaS 供应商可能很困难，因为他们的能力各不相同。供应商使用一个或多个自动化和人工测试人员（由内部或社区主导，通常是经过审查的自由职业者）为客户组织执行渗透测试。

• 市场上的大多数 PTaaS 供应商专注于面向互联网的数字资产，如网络和移动应用程序，这些资产可能只能部分满足客户要求。

• PTaaS 供应商可能无法支持需要广泛领域专业知识的非常复杂的环境。

• PTaaS 的深度和可扩展性不如工作说明书 (SOW) 主导的参与那么灵活。因此，如果有一些特定要求，和/或正在寻求广泛的测试，PTaaS 无法满足需求。

8、DevOps 平台

影响力评级：较高

市场渗透率：目标受众的 5% 至 20%

成熟度：成长

定义：DevOps 平台提供完全集成的功能，可使用敏捷和 DevOps 实践持续交付软件。其功能涵盖围绕持续集成/持续交付 (CI/CD) 管道构建的开发和交付生命周期，并包括版本控制、测试、安全性、文档和合规性等方面。DevOps 平台支持团队协作、一致性、工具简化和软件交付指标的测量。

为什么重要

组织使用 DevOps 平台来最大限度地减少由于分散的工具链、手动交接和整个软件开发生命周期缺乏一致的可见性而导致的工具摩擦和操作复杂性。这使产品团队能够在不影响质量的情况下更快地交付客户价值。DevOps 平台市场反映了跨开发、安全、基础设施和运营的技术整合，以简化软件交付。

商业冲击

DevOps 平台能够持续交付业务价值。开发、安全和运营工作流之间的无缝集成、自动化、可扩展性和共享可见性有助于弥合这些团队之间的孤岛。使用通用的开发、安全和运营平台可加速敏捷转型，并帮助组织转向产品和平台团队运营模式。

驱动因素

• 现代化应用程序架构：现代化应用程序以利用新兴的云原生架构需要对底层 DevOps 实践和工具进行根本性的改变。

• 增强开发人员体验：改善开发人员体验、敏捷性以及通过减少由于不断的上下文切换和重复的低价值工作而导致的认知负荷来改善交付节奏的需求正在日益受到重视和关注。

• 安全性和合规性的综合方法：将安全性、合规性和治理作为开发和交付流程的一部分进行集成和自动化正成为优先事项。这要求维护类似生产的开发和测试环境。一些 DevOps 平台提供商将软件组成分析功能作为其产品的功能。示例供应商包括 GitHub、GitLab 和 JFrog。

• 提高工作流程的可视性：组织面临着减少摩擦和手动交接的压力。这需要从构思到生产对软件交付流程有完全的可视性。

障碍

• 想要充分发挥DevOps 平台优势的组织必须愿意完全或部分替换现有的定制工具链。团队可能会觉得这种变化破坏了他们既定的工作方式，并抵制对他们一直使用的工具的任何改变。

• 要充分发挥 DevOps 平台的优势，需要成熟的平台工程能力，但许多组织缺乏这种能力。

• 由于过时的自动化工作流程和遗留应用程序，组织随着时间的推移积累了技术和技能债务。这阻碍了团队采用新工具。

• 依赖单一供应商来满足大部分软件开发需求会增加集中度风险并降低议价能力。

• 目前，大多数 DevOps 平台都无法提供组织构建、交付、衡量和改善软件交付生命周期中价值流所需的全套软件交付功能。

低谷期技术谷

9、Kubernetes 安全

影响力评级：中等

市场渗透率：目标受众的 1% 至 5%

成熟度：新兴

定义：Kubernetes 安全是指为 Kubernetes 容器编排平台实施安全流程、测试和控制。它与单个容器安全紧密结合，但重点关注 Kubernetes 配置、身份和准入控制。

为什么重要

Kubernetes 扩大了组织的潜在攻击面，因为它提供了部署、扩展、监控和管理容器基础设施的功能。攻击面的扩大以及开发人员对 Kubernetes 的广泛采用意味着安全团队需要工具来在这些环境中提供可见性和控制。不安全的 Kubernetes 部署可能会使容器和容器生态系统面临各种攻击。

商业冲击

Kubernetes是目前最突出的容器编排平台，也是事实上的标准。Kubernetes涉及相当大的复杂性和特定的控制平面功能，例如访问控制和基于角色的访问控制 (RBAC)、容器命名空间、容器网络、分段和准入控制。管理这种复杂性需要自动化工具与容器安全系统紧密配合才能实现有效保护。面向 Kubernetes 的安全工具有助于解决这些风险。

驱动因素

• Kubernetes 必须得到保护，因为它的采用范围非常广泛，而且其全部功能也在不断快速变化。它的发展受到开发人员采用容器来开发现代应用程序、以容器形式交付的商用现货 (COTS) 应用程序，甚至旧式应用程序的重新托管的推动。它的使用范围扩展到亚马逊、博通 ( VMware)、谷歌、微软、红帽、SUSE 等公司提供的基于云和/或基于软件的产品。

• Kubernetes 可以被视为云中的云；Kubernetes 环境的安全性非常复杂，并且包含许多与云资产其他部分相同的复杂性。这推动了对控制措施的需求，以解决这些特定的复杂性。

• Kubernetes 安全解决方案可以对容器实施网络分段。集群中的每个容器都是一个独特的网络端点，从而导致广泛的网络攻击面。东西向流量大幅增加，分段的价值也相应更高。Kubernetes安全解决方案可以满足这些分段要求。

• 通过有效使用准入控制来限制恶意或易受攻击的容器映像的部署，可以增强左移和一般容器安全性。

• 云原生应用程序保护平台 (CNAPP) 正在整合 Kubernetes 安全功能。

障碍

• Kubernetes 安全模糊了应用程序安全、基础设施安全和容器安全之间的界限，造成组织内的供应商、产品和职责重叠。

• 仅 Kubernetes 安全无法解决容器化应用程序的整体安全问题。相反，容器化工作负载还必须按照所有其他安全实践和策略进行保护。存在多个其他攻击点。

• Kubernetes 通常只是架构的一部分，该架构还包括平台服务、平台即服务 (PaaS)甚至无服务器功能。在这些情况下，团队很难理解整个系统，而不仅仅是 Kubernetes 风险。

• 并非所有容器即服务产品的运作方式都相同，这可能会带来支持和管理挑战。

• 除非 Kubernetes 安全解决方案旨在为开发人员提供最小的摩擦，否则他们的采用充其量会受到抵制，最坏的情况是被主动规避。

10、软件物料清单SBOM

影响力评级：较高

市场渗透率：目标受众的 5% 至 20%

成熟度：成长

定义：软件物料清单 (SBOM) 是一种结构化、机器可读的元数据，可通过构建软件包所用的开源或专有组件来唯一标识软件包。SBOM 旨在跟踪和共享软件组件的详细信息及其跨组织的供应链关系。这可以提高整个软件供应链的透明度、可审计性和可追溯性，从而加快解决安全和合规性问题。

为什么重要

Gartner 估计，新软件项目中 40% 到 80% 的代码行来自第三方（例如，运行时、库、组件和软件开发工具包 [SDK]）。这些外部代码大部分来自无数开源项目；其余专有代码来自对其状态或状况几乎不透明的供应商。这些外部软件资产（尽管被成千上万的用户利用）的质量和安全性各不相同。

商业冲击

SBOM 旨在解决共享开源和第三方软件的根本问题。虽然组织可以使用相同的组件，但重复跟踪漏洞和分析合规性违规行为的工作效率很低。软件包数据交换 (SPDX) 和 CycloneDX 等 SBOM 标准建立了通用基础设施和数据交换格式，以共享有关软件包的详细信息。这种标准化通过组织之间更好的协作缩短了解决问题的时间。

驱动因素

• 软件许可证识别和风险评估— SBOM 可以指示用于分发特定软件包的许可证，以支持法律风险评估。与商业软件一样，开源软件 (OSS) 几乎总是根据许可协议的条款进行分发，该协议明确规定了软件的使用方式。有些被认为是宽松的，有些则是限制性的。限制性许可证可能会带来巨大的法律风险和知识产权损失。

• 需要提高安全性和合规性—美国（如食品药品监督管理局 [FDA] 和联邦能源管理委员会 [FERC]）和欧洲（欧盟网络安全局 [ENISA]）的监管机构要求所有与政府机构和受监管组织进行交易的组织必须提供 SBOM。这些法规的目标是提高对软件组件和依赖关系的可视性，以准确确定组织面临的安全风险和漏洞。

• 需要提高软件的可见性和可追溯性 — SBOM 可以为软件工程和供应商风险管理团队提供更高的透明度，让他们了解软件的构建方式、软件的组件组成以及识别和修复安全漏洞的速度。当团队发现组件中的缺陷或漏洞时，他们可以使用 SBOM 快速识别受易受攻击组件影响的所有软件。SBOM 还为他们提供信息，以评估易受攻击组件带来的潜在影响和风险。

障碍

• SBOM 并非万能药。它们的实用性取决于实施的流程和工具，这些流程和工具用于处理、分析和利用它们所包含的信息。采用 SBOM 的障碍包括由于非标准数据格式而共享 SBOM 数据；无法根据 SBOM 中的内容自动化软件交付工作流程；以及快速大规模地生成、使用和安全分发它们的能力。

• 将 SBOM 无缝集成到软件开发、打包和发布活动中对于其广泛采用至关重要。扩大 SBOM 的使用范围所面临的挑战包括基于 SBOM 中信息的策略自动化、跨组织边界的安全分发以及管理其生命周期。对 SBOM 进行来源认证是将其视为依赖关系元数据的可信来源的先决条件。依赖关系及其版本的动态性质要求每次更新工件时都要重新生成和更新 SBOM。

• SBOM 本身是不够的，因为它们无法提供代码中漏洞的可及性上下文。它们应该与漏洞利用交换 (VEX) 一起使用，以便团队对漏洞进行分类。

11、软件供应链安全

影响力评级：颠覆

市场渗透率：目标受众的20%至50%

成熟度：成长

定义：软件供应链安全 (SSCS) 是一套流程和工具，用于管理、创建和使用软件，以减轻对软件的攻击或将其用作攻击媒介。管理侧重于评估第三方软件的风险并评估其可接受性。创建侧重于安全开发以及软件工件和开发流程的保护。使用通过验证、出处和可追溯性来验证软件的完整性。

为什么重要

鉴于针对软件供应链的持续攻击、全球监管要求以及开源依赖项的广泛使用，确保整个软件供应链的安全对于组织的所有部门来说都至关重要。鉴于日益增长的数字化流程和服务，这一点尤为重要，因为软件是大多数知识产权的来源和存放中心。

商业冲击

• SSCS 有助于防止和减轻针对应用程序和底层开发基础设施的破坏性攻击，从而保护组织和下游用户。

• SSCS 对于满足监管要求和买家对提高供应商应用程序安全措施透明度的需求是必要的。

• SSCS 可以帮助避免因临时努力保护开发环境和应用程序工件而增加的摩擦和生产力损失。

驱动因素

• 软件供应链攻击变得越来越复杂，恶意行为者利用软件采购、开发和交付生命周期每个阶段的弱点。攻击数量急剧增加，Sonatype软件供应链报告指出，2019 年至 2022 年期间的软件供应链攻击事件年增长率平均为742 %。这些攻击威胁组织的效率及其运营能力，可能导致数据泄露、其他安全事件和知识产权损失。它们甚至对人类安全构成威胁。

• 世界各地的政府和监管机构都在关注如何鼓励或迫使组织改进SSCS工作。在美国，重点关注的是“财政权力”，联邦政府各部门都采取了多项举措，重点是防止安全措施不佳的供应商进入利润丰厚的市场。但这些活动并不局限于美国。北美、欧盟、英国、东南亚和日本的政府都采取了各种行动，从通过立法到其他努力，以提高人们对这些问题的认识和理解。

• 在对近 500 名 Gartner 客户进行的非正式调查中，约 70% 的受访者表示他们已经或正在重新评估其 SSCS 策略。虽然许多组织已开始部署流程和工具来管理 SSCS 风险，但这些努力往往是脱节的，并且只关注问题的特定要素。随着领导者开始认识到这些初始方法的缺点，并且随着他们对问题有了更多的了解，实施更全面的计划的努力就会产生效果。

障碍

• 大多数组织对 SSCS 缺乏全面了解，因此尚未采用全面的方法来管理软件供应链风险。这种观点将涵盖通过管理和选择安全软件（在开发和采购期间）、在创建期间和在消费过程中（因为组织会跟踪代码的使用情况和不断演变的威胁）来确保安全性。例如，许多组织专注于获取软件物料清单 (SBOM)，但尚未确定如何评估、存储和使用这些工件。

• 为确保整个软件供应链中软件工件的完整性和出处而做出的努力正在涌现，但在范围、执行和采用方面却参差不齐。实施控制措施（例如，限制可使用的依赖项）可能会引发摩擦，并需要与受影响的利益相关者协商流程。

 

12、应用安全态势管理

影响力评级：颠覆

市场渗透率：目标受众的20%至50%

成熟度：成长

定义：应用程序安全态势管理 (ASPM) 工具通过收集、分析和确定整个软件生命周期内安全问题的优先级来持续管理应用程序风险。它们从多个来源获取数据，关联和分析结果，以便于解释、分类和补救。它们支持实施安全策略并促进安全问题的补救，同时提供对整个应用程序风险的全面了解。

为什么重要

复杂的现代应用程序在开发和运营过程中创建孤立的安全数据，使可见性和控制变得异常困难。ASPM 支持在整个 DevOps 环境中集成安全工具和数据，使组织能够实施安全策略和流程。主要优势包括对发现结果进行优先排序和分类，确保将重点放在最关键的问题上，同时以对所有利益相关者都有意义的方式评估风险。

商业冲击

ASPM 通过集成应用程序安全工具和控制、提高可见性和控制能力以及实现风险的衡量和管理，为安全和软件工程团队提供帮助。应用程序安全数据（包括测试结果和监控）的分类通过优先安排资源以专注于最关键的问题来提高生产力。ASPM 可以从运营和风险导向的角度清晰地了解应用程序安全状态，并提供更好的见解。

驱动因素

• 由于应用程序复杂性增加以及应用程序安全工具提供的数据量快速增长，应用安全和软件交付团队在整个软件开发生命周期 (SDLC) 中难以确定补救和缓解措施的优先级。ASPM 通过从整个 SDLC 中的多个来源获取信息、关联结果并集中可见性来解决这一挑战。

• 优先级排序功能有助于工程团队获得对安全工作的认可和支持。这些团队经常被来自多种工具的孤立数据淹没。整合信息、评估其有效性并确定补救措施的优先级是一个繁琐的过程，无法扩展以应对数据量和工程流程的速度。

• 确保安全问题得到解决变得更加耗时且容易出错，这加剧了人们认为安全是一种障碍而不是好处的看法。 ASPM 可以帮助验证和确定警告的优先级，确保团队专注于最大程度降低风险的任务。

• 由于缺乏有意义的业务指标和威胁情报，安全和工程团队很难报告应用程序的业务和其他风险状况。ASPM 产品可以帮助将原始漏洞数据转换为更适合高管和应用程序所有者的形式。

• 在具有多种开发和部署流程的组织中，为策略实施建立自动化控制是一项复杂工作，导致倾向于建立和实施“一刀切”的策略定义方法。ASPM 在应用程序开发和部署流程与安全控制之间的集成和中介功能提供了对这些控制进行集中管理的能力，并允许采用更精细的实施方法。

障碍

• 有效的安全测试自动化需要了解应用程序的总体风险和所需的测试类型。如果缺乏这种了解，阐明优先级排序和分类工作所依赖的政策的努力将变得复杂，并导致 ASPM 工具的效益降低。

• 一些供应商专门提供与开发或运营安全工具的集成。这为提供应用程序安全风险的“全栈”视图设置了障碍。更广泛集成产品的进展显而易见。

• ASPM 工具通过汇总和分析数据来工作，并且一定程度的抽象是固有的。这带来了一个风险，即关键信息可能在处理过程中被无意中忽略，从而产生误报或虚假的安全感。

• 尽管用户非常清楚 ASPM 可能解决的问题，但他们可能不知道有这些工具的存在。这导致评估和采用延迟。

13、无服务器功能安全

影响力评级：中等

市场渗透率：目标受众的 1% 至 5%

成熟度：新兴

定义：无服务器功能安全提供独特且差异化的控制，以确保无服务器功能（也称为 fPaaS）的开发、部署和运行安全。全面的解决方案从开发、授权和访问检查中的主动漏洞和配置扫描开始 - 通常与轻量级运行时保护和行为分析相结合。

为什么重要

所有超大规模云提供商都提供无服务器功能，并且可以将其包含在云原生应用程序中，作为一种简单且可扩展的方式，以实现事件驱动的微服务架构。这些服务对开发人员很有吸引力，但存在潜在易受攻击的代码和环境配置错误的风险，而且由于其短暂性，很难用传统控制来保护。

商业冲击

通过从代码开发开始确保无服务器功能的安全性和合规性，信息安全组织可以安全地支持开发人员采用这些技术，同时最大限度地减少业务影响或运营放缓。从长远来看，无服务器功能有可能通过将攻击面的重要元素的责任转移到超大规模企业而不是企业，从而改善企业的整体安全性。

驱动因素

• 作为云原生应用程序的元素，无服务器功能的采用正在增加。

• 无服务器功能具有差异化的攻击面，推动了对安全功能的需求，例如软件组成分析、漏洞扫描、API 安全、运行时保护以及正确且合规的无服务器平台即服务 (PaaS)配置。

• 无服务器功能安全性具有独特的优势，可以帮助组织预防、检测和应对任何利用与无服务器功能相关的问题的攻击，因为它为环境提供了可见性和安全控制。

• 云权限极其复杂，无服务器功能安全允许检测和修复增加风险的过度权限功能。

障碍

• 信息安全通常对无服务器功能的使用视而不见，并且没有意识到它们带来的风险，因此降低了这些功能的安全性。此外，很少有针对无服务器代码的攻击被明确记录下来，这意味着任何可察觉的风险对于投入的精力和金钱来说都很低。

• 无服务器功能安全必须对开发人员产生最小的阻碍，以避免其采用受到开发人员社区的干扰。

• 可用的运行时保护选项非常少，缺少使用运行时保护代码注入或包装无服务器功能。

• 无服务器安全工具仍在不断成熟，跨多平台安全部署的标准尚未定义。

14、Web 应用客户端保护

影响力评级：较低

市场渗透率：目标受众的 5% 至 20%

成熟度：新兴

定义：Web 应用程序客户端保护可防御在客户端而非服务器端发起的应用程序级攻击。攻击的一个典型示例是针对客户端 JavaScript（例如 Magecart）的恶意脚本注入。客户端安全创新可监控用户和应用程序的活动，并检测恶意操作和组件。

为什么重要

事实证明，在现实生活中，客户端攻击的影响尤其大，因为它们利用了现代应用程序日益分散的设计。特别是，单页应用程序将控制和软件逻辑迁移到客户端，而客户端很容易受到攻击。例如，通过将恶意脚本注入JavaScript应用程序，攻击者诱骗数千名访问者访问银行和在线商务网站，要求他们提供信用卡信息。

商业冲击

金融服务、票务和在线零售等行业的公司都经历了大量欺诈性脚本注入到其 Web 应用程序中的情况。这些攻击会窃取客户的付款信息，并使组织面临巨额罚款。组织最近已转向客户端安全，以保护其应用程序免受此类攻击。

驱动因素

• 客户端攻击（例如Magecart组织发起的攻击）主要影响在线零售、航空和票务网站。攻击者注入恶意脚本，诱骗网站访问者交出其凭证或付款详细信息。

• 支付行业的监管指导将客户端保护能力作为强制性要求。

• 该领域的大多数方法都侧重于 Web JavaScript 监控。在观察 Web 应用程序后，客户端保护可以开始识别异常或未经批准的行为，并根据设置报告或阻止它。

• 内容安全策略和子资源完整性是用于提高浏览器安全性的标准化机制。它们允许组织定义允许的网页组件列表并在客户端执行完整性检查。这些安全控制措施曾被视为 JavaScript 监控的替代技术，但最近逐渐成为客户端保护工具的附加组件。

• 云 Web 应用程序和 API 保护 (WAAP) 提供商一直在推出客户端保护功能作为其产品的一部分。

障碍

• 许多组织仍然缺乏对客户端应用程序威胁的认识。与此同时，尽管客户端攻击仍然很普遍，但在经历了一段时间的激烈活动后，客户端攻击最近有所减少。

• 各种方法都有其优点，但目前还没有一种方法能够提供企业可以遵循的既定标准。

• 由于缺乏明确的技术所有权，该技术的采用速度变慢。企业中的三个不同实体（开发、安全和业务线）参与购买过程。

• 对性能影响、可能的客户隐私问题以及阻碍业务流量的误报的担忧常常导致企业不愿使用客户端保护产品。

15、API 威胁防护

影响力评级：较高

市场渗透率：目标受众的 5% 至 20%

成熟度：成长

定义：API 威胁防护可保护 Web API 免受漏洞利用、滥用、访问违规和拒绝服务 (DoS) 攻击。专业 API 威胁防护工具、API 网关以及 Web 应用程序和 API 防护 (WAAP) 通过提供可见性、API 参数和有效负载的内容检查组合、流量管理以及流量分析以进行异常检测来保护 API。

为什么重要

组织使用 API 来提供对数据和应用程序功能的访问。API 易于暴露，但难以防御。这会产生一个不断增长的大型攻击面，导致越来越多的公开 API 攻击和漏洞。使用特权升级等技术对 API 进行成功攻击可能会导致数据泄露，从而导致敏感数据丢失以及声誉受损。对 API 进行成功的 DoS 攻击可能会导致可用性不足。

商业冲击

当 API 通常用于访问数据或应用程序功能（通常与记录系统相关联）时，API 漏洞的影响可能很大。隐私法规通常要求报告私人数据是否通过不安全的 API 泄露。API 很容易且有意地进行编程，因此漏洞可能会泄露大量数据。区分恶意访问和有效访问的挑战进一步使 API 保护任务复杂化。

驱动因素

• 不断曝光的 API 泄露事件不断提高人们对 API 威胁防护必要性的认识。

• 某些行业，包括金融服务和电子商务，涉及的 API 本质上价值很高，因此容易受到滥用和欺诈。

• 现在，生成式人工智能 (GenAI) 广泛使用 API 来访问数据，以提供模型训练数据，因此对数据访问的保护需求也随之增加。

• 一些老牌供应商已经开始使用机器学习来检测潜在有害的 API 使用模式，从而保护 API 免受威胁。其中包括 WAAP 供应商。

障碍

• API 威胁防护的组织所有权是一项挑战，因为首席信息安全官领导下的安全团队通常管理 Web 应用程序防火墙 (WAF)，而 API 网关通常由 API 团队管理。这可能导致 API 威胁防护因缺乏专业知识而被忽视。

• 许多 API 安全问题与业务逻辑有关。针对业务逻辑威胁的防护很难完全自动化，因为防护工具需要理解逻辑并识别异常用法。

• 行为异常检测本质上会产生误报。尽管 GenAI 的使用日益广泛，但目前大多数 API 威胁检测工具仍需要人工干预来处理误报。

16、应用程序监控和保护

影响力评级：中等

市场渗透率：目标受众的 1% 至 5%

成熟度：成长

定义：应用程序监控和保护是安全性和操作性应用程序监控的融合，旨在整合方法并简化检测。结合使用时，它可以向应用程序所有者发出异常应用程序行为警报，这些行为表明可能由硬件或软件问题或恶意行为者导致的服务故障。它还可以采取保护措施，例如移动工作负载、启动新映像、限制请求和阻止潜在攻击。

为什么重要

在 DevSecOps 式协作和集成的推动下，云原生应用程序的运营监控和安全监控/保护用例正在慢慢融合。在大多数成熟的开发组织中，DevOps 产品团队或站点可靠性工程团队将负责服务连续性，无论问题是软件错误、硬件故障还是攻击者。融合的安全和应用程序性能监控将支持这一点。

商业冲击

从业务部门和最终用户的角度来看，由于硬件故障或安全攻击导致的 IT 服务交付失败并不是单独的问题。通过结合性能和保护监控，IT 组织可以提高应用程序的稳定性、性能和服务质量。它们还应避免因性能和安全流程之间缺乏协调而导致的次优结果，并减少供应商总数以及许可和支持成本。

驱动因素

• DevOps 产品所有者越来越多地承担其产品的服务水平的主要责任，包括可用性和一线安全监控。使用一个供应商进行安全监控，使用另一个供应商进行运营监控，会重复工作，增加复杂性，并可能抑制我们打算保护的产品应用程序的性能和稳定性。多家监控供应商正在推行这种将应用程序性能和安全监控功能相结合的策略，以用于云原生应用程序，并向市场推出具有竞争力的产品。

• 云原生应用保护平台市场融合了安全和运营监控功能。例如，Dynatrace 最近收购了 Runecast以实现安全态势可视性，Snyk 收购了 Helios以实现运行时可观察性。

• 集成式端到端数字体验监控需求需要安全性和可观察性方法的融合。例如，2023 年，Netskope 收购了 Kadiska 。

• 托管容器和无服务器代码服务的采用正在增加，信息安全不能仅仅依赖甚至主要依赖基于代理的方法来实现可见性。

• 基于容器和 Kubernetes 的应用程序提供了新的检测方法，包括特权容器、DaemonSet和sidecar 。

• OpenTelemetry、扩展伯克利数据包过滤器和WebAssembly等举措将有助于巩固监控方法。

障碍

• 这种监控的需求由两个或三个独立的团队推动——安全、应用程序运营和基础设施运营——他们可能有不同的供应商偏好和要求以及预算。

• 由于担心性能和不稳定性，一些团队不愿意采用任何安全监控，因为他们仅仅为了生产可见性而采用应用程序性能监控。

• 大多数运营监控厂商的安全能力还不成熟，大多数安全监控厂商的运营监控能力也还不成熟。

• 许多组织的 DevSecOps 团队不具备处理一线安全监控责任的技能。

• 语言和框架的激增使得实施单一的监控策略变得十分困难。

• SaaS 应用程序监控需要新方法。这里的可视性需要更多的网络性能和数字体验监控类型的方法。

17、云原生应用保护平台

影响力评级：高

市场渗透率：目标受众的 5% 至 20%

成熟度：成长

定义：云原生应用程序保护平台 (CNAPP) 是一套集成的安全和合规功能，旨在帮助保护和保护整个开发和生产过程中的云原生基础设施和应用程序。CNAPP 整合了大量以前孤立的功能，包括容器扫描、云安全态势管理、基础设施即代码扫描、云基础设施授权管理和运行时工作负载保护。

为什么重要

全面保护云原生应用程序需要使用来自多个供应商的不同工具，而这些工具很少能很好地集成。这种集成和自动化的缺乏会减慢开发人员的速度，并导致风险可见性分散。CNAPP 产品允许组织使用单一集成产品来保护云原生应用程序的整个生命周期，并获得整体云风险的综合视图。

商业冲击

云原生应用程序保护平台整合了分散的安全测试和保护工具，增加了 IT 的成本和复杂性。使用 CNAPP 产品将提高开发人员和安全专业人员的效率。它还将降低复杂性并提供更好的风险可见性，同时保持开发敏捷性并改善开发人员的体验。

驱动因素

云原生应用保护平台：

• 随着云原生应用程序的快速开发、投入生产和迭代，减少出现配置错误、失误或管理不善的可能性。

• 融合并减少持续集成/持续交付 (CI/CD) 流程中涉及的工具和供应商的数量。

• 降低创建安全且合规的云原生应用程序相关的复杂性和成本。

• 促进云安全态势和状态的报告和审计。

• 通过无缝集成到开发人员的开发流程和工具中的安全扫描功能来提高开发人员的接受度。

• 在开发中重视主动扫描，减少对运行时保护的依赖，这非常适合容器即服务和无服务器功能环境。

障碍

• 擅长运行时保护的云工作负载保护平台（CWPP）供应商不一定擅长集成开发，反之亦然。

• 容器和无服务器功能形式的C原生工作负载不需要重量级的运行时保护功能。

• 没有任何一种 CNAPP 产品可以解决所有问题。各种功能将融合在一起，但需要几年时间。

• 组织可能会单独购买应用程序安全测试工具，这些工具由负责管理工作负载运行时保护的不同团队选择。即使在运行时，也可能有单独的团队负责 Web 应用程序保护。

• 组织在云原生应用程序开发方面的不成熟可能会阻碍采用和分散购买动议。

• 采购中心和影响者正在转向新的角色，例如 DevOps 架构师和云安全工程，需要信息安全团队与这些用户进行协调。

18、API 安全测试

影响力评级：高

市场渗透率：超过50%的目标受众

成熟度：成长

定义：API 安全测试是一种专门的应用程序安全测试 (AST)，用于识别 API 中的漏洞。检查应包括传统的应用程序漏洞（例如注入攻击）和 API 特定问题（例如损坏的对象级授权）。有时支持发现功能，以确保识别未知 API 并测试其漏洞。

为什么重要

API 是支持Web 的应用程序的主要攻击面。对 API 的攻击和滥用会导致严重的不良后果，包括数据泄露和其他安全事件。DevSecOps 团队专注于在开发过程中进行 API 安全测试以防止这种情况发生。漏洞评估团队可能会测试生产 API 的安全性；但是，API 会带来独特的风险。

商业冲击

API 是许多组织数字化转型工作的基础要素。因此，保护 API 免受攻击和滥用是许多安全和风险管理 (SRM) 专业人员持续关注的问题。部署前和部署后的特定 API 测试为整体 API 安全策略奠定了坚实的基础。自动化 API 发现是必要的，因为许多组织难以维护 API 清单，需要帮助找到它们以便进行测试和管理。

驱动因素

• 为了支持数字化转型，API 在应用程序架构中变得很常见，用于实现信息流并支持流程、应用程序和系统之间的交易。然而，这种增长引起了攻击者越来越多的关注，API 已成为许多系统的主要攻击面。

• API 攻击已导致数据泄露和其他安全事件，给组织和个人造成重大损失。因此，DevSecOps 团队以及应用程序由 API 支持的业务领导者对 API 测试和安全性越来越感兴趣。

• 由于 API 的创建、开发和部署可能管理松散，安全团队经常要应对未记录或影子 API，这些 API 存在于正常流程和控制之外。此类 API 可能在安全设计和测试方面存在缺陷，从而带来更大的风险。因此，发现部署到生产中的 API 是另一个重要需求。

• API 安全测试有助于避免与漏洞和其他类型的安全事件相关的有形成本和无形成本。

• 传统 AST 工具（静态应用程序安全测试 (SAST)、动态应用程序安全测试 (DAST) 和交互式 AST (IAST)）最初并非设计用于测试与针对 API 的典型攻击相关的某些独特类型的漏洞。它们也不针对较新类型的 API（例如 GraphQL 或 gRPC）。特定于 API 的漏洞和现代 API 格式促使安全和开发团队实施专门的 API 安全工具，专注于测试、发现影子 API 和防范威胁（或三者结合）。

障碍

• 传统工具对检测特定于 API 的漏洞提供的支持不一致。API 容易受到大多数传统应用程序攻击，但其他攻击也很常见。例如，许多违规行为都提到了对象标识符的授权检查不当，并且业务逻辑测试难以自动化。可能需要专门的工具或渗透测试才能可靠地检测这些缺陷。

• 测试工具可能不支持所有 API 协议。SOAP 仍然被广泛使用，尽管它正在被 REST API 取代。基于 GraphQL 和基于 gRPC 的 API 越来越普遍，因此需要工具供应商提供额外的支持才能进行有效的测试。

• 市场上仍然存在一些混乱，各种类型的公司提供产品（包括传统 AST 供应商，以及API 测试和保护供应商），使评估和选择工作变得复杂。

• 许可和定价可能难以管理，尤其是在缺乏发现的情况下。

19、云 WAAP

影响力评级：高

市场渗透率：目标受众的20%至50%

成熟度：成熟主流

定义：云 Web 应用程序和 API 保护 (WAAP) 专注于缓解针对 Web 应用程序和 API 的运行时攻击，如开放 Web 应用程序安全项目 (OWASP) 十大 Web 应用程序安全风险所示。功能包括 Web 应用程序防火墙、DDoS 缓解、爬虫管理和 API 安全。创新的驱动力是抵御因 Web 应用程序和 API 数量增长而导致的不断扩大的攻击面的需求。

为什么重要

在本地或云端托管 Web 应用程序及其链接API的组织越来越多地购买云 WAAP 解决方案，因为与传统虚拟设备相比，它们更容易部署，交付和管理也更灵活。再加上 API 流量的不断增加（由 CI/CD 实践以及微服务架构的激增推动），对云 WAAP 的需求也随之增加。

商业冲击

现代应用程序大多基于 Web、采用微服务架构，并且可通过 API 访问。这些应用程序及其API是需要保护的高风险目标。与设备解决方案相比，云 WAAP 解决方案更易于组织部署。它们还具有高度可扩展性，并提供集中管理、集中可视性和与超大规模服务器的更强大的集成。

驱动因素

• 基于 Web 的应用程序和 API 激增：现代软件开发已从单片应用程序设计转向微服务架构。基于微服务的设计将单个单片应用程序分解为几个松散耦合的独立软件实例（通常容器化）。这些实例通过 API 在内部相互通信，通过 API 或基于 Web 的协议在外部相互通信。

• 应用层攻击数量不断增加：需要强大的应用层安全性来减轻这些攻击。

• 攻击者团体继续使用并改进自动凭证填充攻击：爬虫越来越多地被用于此类攻击。这对零售和银行业来说是一个关键问题。

• 转向混合云架构：这正在将买家策略从传统设备模式转向云交付服务。通过采用能够通过通用管理界面覆盖云和本地环境的云交付服务，可以减轻在每个物理位置部署和管理一组离散设备的负担。基于CDN的云 WAAP 解决方案除了提供 WAAP 安全服务外，还提供缓存服务并允许更低的延迟，据观察，对于拥有分布式客户群的组织来说更具吸引力。

• 支持集成：一些云 WAAP 提供商正在增加与提供更多左移功能的供应商的集成，这使得应用程序安全团队能够确保其应用程序在开发和运行时的安全。

障碍

• 隐私：云 WAAP 解决方案可以访问解密流量，这带来了隐私和合规性挑战。随着云采用率不断提高，以及越来越多的供应商提供自带密钥 (BYOK) 功能，这一问题可能会变得不那么明显。

• 复杂性：缺乏对应用程序安全状况和相关风险的全面了解，此外还缺乏与应用程序安全测试工具的集成选项。此外，云 WAAP 解决方案中不同组件的管理责任和购买中心的划分也非常复杂。

• 成本：与云 WAAP 产品相比，现有/捆绑合同中的 WAAP 产品可能更便宜。此外还有额外的迁移成本，尤其是对于需要重新设计解决方案的组织而言。

• 应用程序适合性：拥有内部部署应用程序的组织可能看不到云 WAAP 部署的价值，或者不支持统一的管理方法，他们使用托管虚拟设备为内部部署和云托管应用程序保留相同的集中式控制台。

• 技能差距：管理包含许多应用程序安全功能的 WAAP 解决方案需要技能高超（因此薪水也很高）的应用程序安全专家。此外，云 WAAP 解决方案不断扩展的功能集导致许多组织使用托管安全服务，这需要额外成本。

20、威胁建模自动化

影响力评级：高

市场渗透率：目标受众的20%至50%

成熟度：早期主流

定义：威胁建模自动化工具可自动创建安全需求和威胁模型。它们可以与软件开发生命周期 (SDLC) 工具集成，以管理需求并执行验证。威胁建模自动化工具可动态突出显示应用程序架构的潜在安全影响，并推荐安全编码实践或架构对策。

为什么重要

威胁建模以揭示安全需求是创建安全应用程序的关键。工具通过将安全性进一步移至 SDLC 的最开始，自动化并促进这些流程。虽然它们不保护代码，但它们使创建安全代码和应用程序架构变得更容易。它们还有助于确保确定适当的安全要求，而不是广泛的标准，这些标准不足以保护高风险应用程序，同时使低风险项目负担过重。

商业冲击

威胁建模自动化工具可显著减少创建和维护威胁模型、安全要求和风险评估所需的工作量。这可确保可以尽早定义特定于单个项目的安全规范，同时降低成本和风险，而不是事后再定义。这为组织内的多个群体（包括架构师、开发人员、安全团队甚至业务利益相关者）带来了巨大好处。

驱动因素

• 各类组织都在努力创建安全的应用程序。问题包括支持安全性的功能和对策不足（例如身份验证、访问控制和数据保护）以及基本的安全设计缺陷，所有这些都使应用程序容易受到攻击。威胁建模自动化工具可以帮助解决这些问题。

• 安全设计计划和安全软件合规性要求使威胁建模成为必不可少的最佳实践。自动化威胁建模工具使实践更快、更具可扩展性。它们还有助于确保满足与要求和法规相关的特定要求。

• 现代应用程序（包括分布式云原生技术、内部和第三方 API 的使用增加以及各种形式的AI ）更加复杂，手动准确建立威胁模型的难度也更大。威胁建模自动化可加快这些流程，并帮助建模者确保他们已识别所有威胁和相关对策。

• 快速的开发速度限制了威胁建模的时间。敏捷等迭代开发方法意味着威胁模型必须更频繁地更新。这两个因素都给手动方法带来了压力，并且更有可能限制威胁建模的范围或完全跳过。

障碍

• 准确表示快速变化的应用程序的能力仍然是威胁建模自动化工具的弱点。当今的大多数工具都需要用户干预才能随着应用程序的变化而更新模型，这会导致用户放弃使用。随着供应商开始将系统直接链接到云平台或基础设施即代码文件，确保更改自动反映在模型中，然后模型将自动生成更新的指导，这种情况正在改善。

• 功能各不相同。免费和开源工具易于采用，但在建模更复杂的系统时却不够用。这促使人们考虑使用商业工具，尽管其局限性限制了大多数高级用户的适用性。

• 大多数组织在建立应用程序安全计划时仍将重点放在应用程序安全测试上。这些工具对于在开发阶段识别代码中的漏洞至关重要，但无法在规划时识别设计缺陷。

复苏期技术

21、应用程序屏蔽

影响力评级：中等

市场渗透率：目标受众的 5% 至 20%

成熟度：成长

定义：应用程序防护可防止和检测篡改和逆向工程等攻击。它是一种应用内保护技术，这意味着其功能直接在应用程序内实现，而不是在线或在托管系统上实现。应用程序防护可用于任何类型的应用程序，但目前特别关注移动应用程序。

为什么重要

现代应用程序架构（例如移动应用程序）将软件逻辑移至前端，并将敏感数据放在设备上。这些架构暴露的功能，如果不加以保护，可能会导致应用程序或其后端的数据泄露，以及用户设备应用程序功能的欺诈性使用或入侵。当应用程序传输或存储敏感数据，或启用支付时，应用程序屏蔽是一项重要的安全措施。

商业冲击

应用程序防护可保护企业的软件和应用程序免遭克隆、欺诈、知识产权 ( IP)盗窃和其他形式的滥用。它还可用于增强某些行业的用户体验，包括金融服务和在线零售。通过强化应用程序，在线零售商可以最大限度地减少对其客户的限制。

驱动因素

• 两大类功能正在成为应用程序防护的基础：强化和防篡改。强化通过使逆向工程变得更加困难，阻止攻击者窃取信息（例如 IP 或凭据）或克隆应用程序。强化包括代码混淆和白盒加密等技术。防篡改对应用程序运行的环境进行侦察，以识别潜在风险。防篡改包括模拟和调试检测等技术。

• 应用程序屏蔽适用于在不受信任的环境中运行的应用程序。面向消费者的移动应用程序在金融服务、在线零售、医疗保健、保险和汽车等垂直行业的采用率正在不断提高。

• 买家越来越要求产品的完整。除了强化和防篡改功能外，买家还越来越多地寻求超越屏蔽的反恶意软件功能和功能，例如多因素身份验证，以最大限度地减少其应用程序中集成的安全产品数量。

• 随着企业和独立软件供应商越来越意识到这些解决方案的可用性，采用率也在不断增长。

障碍

• 混淆等强化技术必须适应移动设备和物联网 ( IoT) 等设备和操作系统。尽管这些技术基于成熟的技术，但它们最初是为了保护机顶盒和数字媒体而设计的，需要重新适应较新的平台。

• 保护技术处于不断发展的状态，因为它们必须跟上新的、更先进的攻击以及底层操作系统的变化。

• 应用程序防护基于复杂且研究密集型的技术，许多经验丰富的安全和开发从业者对此并不特别熟悉。即使风险可能很明显，但最终用户可能不会立即意识到减轻这些风险的技术和功效。

• 最终用户购买者认为应用屏蔽产品价格昂贵。

22、安全编码培训

影响力评级：高

市场渗透率：目标受众的20%至50%

成熟度：早期主流

定义：安全编码培训提高了人们对影响的认识，并能够预防源代码中的漏洞。开发人员使用不同的方法（如即时培训、游戏化课程、研讨会和挑战）接受特定编码语言和框架的安全编码实践培训。

为什么重要

根据2024 年 Gartner 软件工程领导者调查，75%的软件工程领导者表示，应用程序安全是被认为最重要的技能，自2022 年以来这一比例显著上升。安全编码技能会随着时间的推移而发展，并且通常是一般软件工程教育所缺乏的。确保软件工程师掌握最新的安全编码技能将提高对引入漏洞风险的认识。

商业冲击

任何编写软件的组织都需要关注安全性，过时的安全培训与没有培训一样糟糕。软件中的安全问题将导致更多不安全的应用程序。它会带来不良后果，例如新功能部署的准备时间更长，未解决的漏洞风险增加，并降低软件工程师的士气。

驱动因素

• 应用程序安全是软件开发组织关注的重点。

• 根据2023 年 Gartner 软件工程安全调查，更直接参与安全活动的软件工程师看到了安全结果的改善。

• 缺乏安全意识的开发人员通过引入易受攻击的代码、第三方组件和基础设施配置来创建不安全的应用程序。

• 保持最新的安全编码实践将有助于缩短修复问题的时间来降低软件漏洞暴露的风险。

• 生成式人工智能正在被用来增强培训内容的创作，但它也推动了更多关于如何使用这些人工智能编码助手的培训。

障碍

• 就像任何教学方法一样，不同类型的安全编码培训对某些人来说效果更好或更差（演示、测试、研讨会等）。

• Gartner 还从其 2023 年软件工程安全调查中发现，软件工程师没有足够的时间学习，也没有获得完成学习的奖励。

• 当培训每年进行一次时，培训课程之间知识保留的缺失可能会导致应用程序更容易受到攻击。

• 安全编码培训的产品和定价模式可能千差万别，因此很难了解需要什么。

23、移动应用程序安全测试

影响力评级：中等

市场渗透率：目标受众的20%至50%

成熟度：早期主流

定义：移动应用程序安全测试 (AST) 可识别并帮助修复 iOS 和 Android 设备移动应用程序中的漏洞。移动 AST 分析源代码、字节或二进制代码，并观察或攻击移动应用程序以识别引入安全漏洞的编码、设计、打包、部署和运行时条件。

为什么重要

攻击者可以利用移动应用程序窃取企业数据并欺骗客户。移动AST 在很大程度上采用了与传统 AST 类似的技术，以适应移动设备环境以及随之而来的更敏捷的开发流程。

商业冲击

根据组织的结构，移动 AST 可能由安全和应用程序开发团队使用，有时由业务部门直接使用。尽管每个提供移动应用程序的组织都应该进行安全测试，但受监管和其他高安全性行业（如金融服务、医疗保健和在线零售）采用移动 AST 的紧迫性更高。

驱动因素

• 拥有移动应用程序的组织需要适用于移动环境的 AST。移动 AST 工具必须支持特定于移动的编程语言和框架。除了传统的应用程序漏洞外，它们还需要识别特定于移动的漏洞，例如不安全的存储和硬编码凭据。

• 通常，已经在 Web 应用程序中采用 AST 的组织需要一种更快、更具成本效益的替代方案，专门用于移动 AST。

• OWASP 移动应用程序安全验证标准 (MASVS) 为移动应用程序安全测试提供了一套细粒度的要求，这有助于移动 AST 供应商和从业者更好地构建移动 AST 需求。

• 开展移动AST有助于简化商业应用商店的审批和发布流程。例如，通过应用防御联盟 (ADA) 移动应用安全评估 (MASA)，Google 认可已根据 MASVS 1 级要求进行独立安全测试的移动应用。

• 开源软件( OSS) 组件和软件开发工具包 (SDK) 经常与移动应用程序一起使用，它们也经常是移动应用程序漏洞的根源。随着软件物料清单 ( SBOM ) 的使用开始出现，移动 AST 评估第三方代码的能力变得越来越重要。

• 虽然移动 AST 产品主要用于自主开发的应用程序，但一些企业正在使用它们进行应用程序审查。这使组织能够识别漏洞或恶意应用程序。移动威胁防御产品也经常解决此用例。

障碍

• 移动平台仍在不断发展，尽管发展速度比过去要慢；因此，移动 AST 尚未完全成熟。移动 AST 中使用的技术与多年来用于测试基于 Web 的应用程序的成熟静态AST (SAST)、动态 AST (DAST)、软件组合分析 ( SCA)和交互式 AST (IAST) 技术相同。但是，当应用于移动应用程序时，测试必须进行调整以识别客户端代码漏洞。

• 许多组织的应用程序安全程序不够先进，并且尚未测试移动应用程序代码。

• 组织通常认为后端的风险最高，因此较少关注移动 AST。

成熟期技术

24、爬虫管理

影响力评级：较高

市场渗透率：超过50%的目标受众

成熟度：成熟主流

定义：爬虫管理解决方案可以检测并响应与网站、移动应用和 API 交互的自动化应用程序和爬虫。它们可以阻止不必要的自动化活动，同时确保人类用户和合法爬虫能够按照业务的意图进行访问。评估交互的人性通常是通过分层方法来实现的，即检查网络信号、设备和会话属性，并可能迫使用户解决 CAPTCHA。

为什么重要

随着爬虫程序的复杂程度不断提高，爬虫程序流量也不断增加。攻击者使用爬虫程序自动对在线资产进行业务逻辑滥用攻击，包括抓取竞争数据、库存抓取和凭证填充，以及完全或部分拒绝服务（无论有意还是无意）。攻击者将专业爬虫程序与人工操作的欺诈农场服务相结合的既定方法需要不断改进的检测和响应解决方案。

商业冲击

尽管最初用于保护大型 B2C Web 应用程序，但爬虫管理已越来越适用于任何面向公众的 B2C 或 B2B 终端，因为恶意自动流量会直接影响业务成果。恶意爬虫会导致页面加载时间变慢、囤积库存，并通过凭证填充或凭证破解来协助帐户接管，从而对用户体验 (UX) 产生负面影响。

驱动因素

• 需要防止使用生成式人工智能应用程序创建的基本爬虫或脚本发起的大规模、低复杂度的自动攻击。

• 领导者越来越认识到爬虫管理跨越多个用例和业务部门，这使得这些功能更受追捧。

• 传统的CAPTCHA 解决方案可以由爬虫或委托给 CAPTCHA 解算器服务的 hu-bot 来解决。此外，构思不当的 CAPTCHA 解决方案可能会降低用户体验。这推动了对用户体验影响最小的爬虫管理解决方案的创新，例如设备智能、行为生物识别和加密工作量证明等隐形挑战。

• 爬虫管理解决方案可以识别恶意爬虫并保护合法应用程序用户和授权爬虫的用户体验。企业认可的爬虫可以包括搜索引擎爬虫、自动测试和 Web 应用程序监控软件、爬虫流程自动化或其他机器对机器 (M2M) 通信。M2M 通信包括在 Microsoft Teams、Slack、Stride 和一些爬虫市场等环境中运行的爬虫。

• 爬虫缓解通常被捆绑到内容交付网络 (CDN) 解决方案中，从而降低了组织探索爬虫管理优势的障碍。

障碍

• 对封锁单个合法用户的恐惧通常高于对恶意爬虫造成的损害的认知。

• 人们一直担心，许多爬虫管理供应商过于频繁地使用 CAPTCHA，通常是为了测试误报。这通常占流量的不到 1%，而且 CAPTCHA 解决方案是专有的，并且相对优化。然而，组织仍然担心 CAPTCHA 挑战固有的摩擦。

• 当解决方案仅关注某些用例或保护某些应用程序（例如登录页面）时，来自 Web 应用程序和 API 保护（WAAP）提供商的捆绑产品可能会产生困难，从而导致保护不完整。

• 一些组织现在不得不依赖多家供应商来缓解最广泛的攻击——将内置于 CDN 或 Web 应用程序防火墙/WAAP 解决方案中的解决方案与更专业的独立解决方案相结合。前者更侧重于容量攻击，后者更侧重于业务逻辑攻击。这对运营、供应商管理和成本都有负面影响。

25、全生命周期 API 管理

影响力评级：较高

市场渗透率：超过50%的目标受众

成熟度：成熟主流

定义：全生命周期 API 管理涉及 API 的规划、设计、实施、测试、发布、操作、使用、版本控制和退役。这些解决方案还有助于创建 API 产品、构建 API 生态系统、促进 API 采用并提供业务价值报告以实现商业化。这些功能通常打包为 API 门户、网关和设计、开发和测试解决方案以及策略管理、分析和安全的组合。

为什么重要

API 被广泛用作连接系统、应用程序和设备、集成业务合作伙伴以及构建模块化和可组合软件架构的主要选择。将 API 用作数字产品（直接或间接货币化）的现象也在增加。数字化转型计划加速了对 API 的创建、管理、运营和安全的需求。它们还使全生命周期API 管理成为每个组织必不可少的基础能力。

商业冲击

全生命周期API 管理提供了管理和治理 API 所需的框架和工具，这些 API 是多体验应用程序、可组合架构和数字化转型和业务模式的关键推动因素的基础。它支持创建可以直接或间接货币化的 API 产品，而其安全功能则有助于保护组织免受与 API 泄露相关的业务风险。

驱动因素

• 组织正面临 API 的激增，这源于连接系统、应用程序、设备和其他业务的需求。API 在内部、外部、B2B、私人和公共数据共享中的使用推动了使用全生命周期API 管理来管理和治理 API 的需求。

• 打包数据、服务和见解的 API 越来越多地被视为可货币化并支持平台业务模式的产品。全生命周期 API 管理提供了将 API 视为产品的工具。

• 数字化转型推动了 API 的使用增加，这反过来又增加了对全生命周期API 管理的需求。

• 寻求加速增长和业务弹性的组织正在采用基于 API 的架构来消除或现代化其遗留的单一应用程序。

• 开发人员对 API 的关注度正在不断提高。基于事件的 API 的新方法、设计创新和建模方法（如 GraphQL ）正在推动人们对全生命周期 API管理的兴趣，从而带来更多的实验和增长。

• 云采用和云原生架构计算方法（包括无服务器计算）正在增加 API 在软件工程架构中的使用，尤其是在微服务、服务网格和无服务器的背景下。

• 随着人们对 API 安全性的认识不断提高，以及对 API 安全性的重视程度不断提高，各组织开始负责发现和管理 API。这通常从现有 API 的运营管理开始。

• 金融、保险和医疗保健行业受监管的行业特定举措继续提供稳定的需求。然而，API 的使用正在大多数行业（尤其是零售、技术和电信、制造业）中蔓延，从而增加了需求。

• 作为云服务、安全解决方案和其他捆绑软件应用程序的一部分，API 网关的商品化和广泛可用性增加了涉及多个网关（包括来自多个供应商的网关）的分布式 API 管理的需求。

• 生成式人工智能和大型语言模型在软件工程中的影响力日益增强，可能会增加并重塑对 API 的需求。

障碍

• 缺乏对充分的组织治理流程的承诺阻碍了全生命周期 API 管理的采用。这可能是由于缺乏技能或专业知识，或者过于注重官僚方法而不是联合和自动化治理方法。

• 缺乏对业务价值（可量化的业务增长或运营效率）的战略关注，而过于关注技术用例，可能会使业务用户和赞助商失去兴趣。这在 API 程序未能实现承诺的投资回报的情况下尤其明显。

• 传统的单网关 API 管理方法不再适合现代分布式 API 管理方法。

• 其他市场供应商提供的部分或全套嵌入式 API 管理功能可能会部分满足 API 管理的使用案例并减少市场机会。这些功能包括应用程序开发、iPaaS、安全解决方案和 B2B 产品。

• 现在，越来越多的组织选择更有针对性、更轻量级的解决方案来解决全生命周期 API 管理的特定部分，而不是包罗万象的复杂解决方案。

26、DevSecOps

影响力评级：颠覆

市场渗透率：超过50%的目标受众

成熟度：成熟主流

定义：DevSecOps 是将安全性和合规性测试集成并自动化到敏捷 IT 和 DevOps 开发流程中，尽可能无缝且透明，而不会降低开发人员的敏捷性或速度，也不需要他们离开开发工具链。理想情况下，产品还可以在运行时提供安全可见性和保护。

为什么重要

DevSecOps 提供了一种将安全性有效集成到开发流程中的方法，从而消除或减少安全性与开发之间的摩擦。目标是务实地实现支持快速开发的安全、可行的软件开发生命周期 (SDLC)。DevSecOps 已成为主流开发实践，尽管具体细节可能因组织技术和开发流程的成熟度而异。

商业冲击

DevSecOps 的目标是在不影响安全性和合规性的情况下加快开发速度。此外，安全策略的外部化使业务部门和安全组织能够定义和优先考虑策略护栏，并让开发人员专注于应用程序功能。安全基础设施的策略驱动自动化可提高合规性、安全执行质量和开发人员效率以及整体 IT 效率。

驱动因素

• 自十多年前 Gartner 提出这一概念以来，将安全性和合规性测试无缝集成到开发流程和开发工具中的 DevSecOps 思维模式引起了市场的共鸣，这一实践得到了广泛的采用。

• 采用 DevOps 和其他快速开发实践需要能够跟上快速发展步伐的安全性和合规性测试。

• DevSecOps 产品在开发过程尽早应用，而与旧开发模型相关的传统应用程序安全测试 (AST) 工具在开发周期的后期应用，这让开发人员和业务利益相关者感到沮丧。

• 测试结果需要以补充开发人员现有工作流程和工具集的方式集成到开发过程中，并且不需要他们学习不相关的技能。

• 开源的使用大大增加了开发人员无意中使用已知易受攻击的组件和框架的风险。

• 越来越多的平台工程团队已经接受了 DevSecOps 原则。

• 新兴标准，例如 OASIS 的静态分析结果交换格式 (SARIF)，可帮助不同的工具以可互操作的方式交换漏洞信息。

• 新兴的应用程序安全态势管理( ASPM) 工具有助于提供更多背景信息来识别、确定优先级并修复 DevOps 环境中的应用程序安全问题。

障碍

• 错误实施、孤立且繁琐的安全测试是 DevOps 的对立面。因此，开发人员认为安全测试工具正在拖慢他们的速度。

• 开发人员不了解他们的编码所引入的漏洞。

• 开发人员不想离开他们的开发（持续集成/持续交付 [CI/CD]）流程来执行测试或查看安全性和合规性测试工具的结果。

• 从历史上看，静态应用程序安全测试 (SAST) 和动态应用程序安全测试 (DAST) 工具一直受到误报或模糊信息的困扰，因此让开发人员感到沮丧。

• 现代 CI/CD 管道中使用的开发人员工具的多样性将使 DevSecOps 产品的无缝集成变得复杂。