2025网络安全成熟度曲线：AI安全、DSPM与零信任落地优先级

简介：《2025年中国网络安全成熟度曲线》是Gartner于2025年7月发布的行业研究报告，面向首席信息安全官、CIO及安全与风险管理从业者，聚焦中国网络安全重心向保护AI、推动业务转型和增强组织韧性转移的趋势。报告给出明确的战略判断：到2027年，60%的大型企业将在安全运营中心引入暴露管理技术以提升事件响应效率；到2028年，60%部署AI的企业将采用协作式AI防御策略。同时系统梳理AI TRiSM、AI网关、数据安全态势管理（DSPM）、软件成分分析（SCA）、对抗暴露验证（AEV）、零信任网络访问等技术的成熟度位置，并结合数据分类、隐私保护与法规遵从要求展开分析，指出监管强制与生成式AI快速落地两股力量正共同加速技术曲线演进。压缩包内为1个PDF文件，约1.39MB、78页，含战略规划假设、技术条目与采用建议，便于按图索骥定位与自身业务相关的技术。已有214人学习，可用于长期安全战略制定、技术选型评估与合规治理参考。

1. 从一份 78 页的曲线图说起：它到底能帮安全团队解决什么

去年底和某实验室的安全负责人聊，他桌上摊着三份厂商的方案书，每份都在讲“AI 安全”，但口径完全不一样：一家说要做模型防护，一家说要做 AI 网关，还有一家把数据分类分级包装成了 AI 安全。他问我一句话——这些东西到底谁先上、谁可以等。这种问题靠看产品白皮书是回答不了的，得有一张站在行业视角的坐标图。这份 2025 年中国网络安全成熟度曲线（Hype Cycle）就是干这个用的：它把 AI TRiSM、AI 网关、DSPM、SCA、AEV、零信任网络访问等三十来项技术摆在同一条曲线上，标注了每项技术的成熟阶段、收益等级和主流采用年限，还给了一张优先级矩阵。它不教你怎么配策略，但它能告诉你，为什么“数据分类”已经在爬坡尾声，而“数据安全态势管理”才刚起步。这份资料适合 CISO、安全架构师和正在做年度安全预算的负责人，尤其适合被 AI 项目推着走、又得对合规负责的那种角色。

2. 曲线怎么读：横轴纵轴背后的判读方法

Hype Cycle 这张图很多人扫一眼就翻过去了，觉得无非是“期望膨胀—幻灭—爬坡”那套老图。真正值钱的是它把技术成熟度和业务收益拆成了两个维度，让你能回答“现在买是不是早了点”这个问题。这份报告的结构是：一张主曲线图 + 一张优先级矩阵 + 每项技术的独立条目（定义、重要性、业务影响、驱动力、用户建议），最后附了不再列入曲线的技术说明。

2.1 五个阶段与两种“过早”

曲线横轴是时间，纵轴是期望值，五个阶段分别是技术萌芽期、期望膨胀期、幻灭低谷期、稳步爬升期、实质生产期。判读时的关键不是看点在哪个阶段，而是看它“移动的速度和方向”。报告里点得很明确：今年移动最快的是安全 AI 助手和软件成分分析（SCA），而数据安全平台（DSP）从萌芽期往膨胀期爬，SASE 从低谷期往上走，SSE 反而从峰值往下掉——原因写得很直白，“采用率低于预期”。

这就引出一个实操判断：处在膨胀期峰值附近的技术，采购窗口通常最差，因为厂商报价高、产品能力还没收敛、集成成本被低估。SSE 就是典型案例，峰值时被当作 SASE 的轻量替代品大力推广，结果国内实际落地不及预期，往下掉了。反过来，从低谷往上爬的 SASE，说明市场已经过了一轮淘汰，留下来的是真能交付的。

提示：读曲线时先看你关注的技术是“从左往右”还是“从右往左”移动。往右是市场认可度上升，往左基本意味着采用不及预期，这时候谈价空间大，但要额外验证交付能力。

2.2 优先级矩阵：收益等级与 2～5 年窗口

主曲线之外，优先级矩阵才是做预算时真正要摊在桌上的东西。它按“收益等级”和“达到主流采用的年限”两个维度切分，报告里的数据分档是：两年内成熟、两到五年、五到十年。

两个关键事实：数据分类和 SIEM 是唯一两项预计两年内成熟的技术；而包括安全 AI 助手、AI 网关在内的大多数创新，成熟周期在五到十年。DSPM、SCA、威胁暴露管理被标为“变革型收益”，AI TRiSM 和隐私技术则因为能直接降低数据暴露、AI 误用和合规失败的风险，拿到了高收益评级。

这个分档直接决定了资源分配逻辑。两年内成熟的，是“现在必须补齐的基础能力”，投入产出确定，别再观望；五到十年的，是“试点 + 观察”的节奏，预算给小额验证，别一次性上大平台；两到五年的，才是真正需要重点下注的区间，因为窗口期就在眼前，晚一步就要被动追赶。

2.3 用一张表把技术分档落到预算上

把报告里的信息整理成一张可直接用于立项讨论的表，比逐页翻 PDF 高效得多。下表按成熟周期分档，把报告明确提到的技术和它的判读要点对齐：

这张表用的时候有个细节：报告里 DSPM 的市场渗透率写的是“目标受众的 1% 以下”，处在萌芽期。这意味着你现在找厂商，大概率是在陪产品一起成长，合同里必须写清楚能力交付节点和退出条款。我一般会建议这类采购把付款拆成三段，最后一段绑在“能连通现有数据源并输出可核对的数据地图”这种可验证结果上，而不是绑在上线时间上。

2.4 中国市场的两个驱动力：合规执法与 GenAI 落地

这份曲线和全球版最大的差异，在于它明确点出了两股力量在推着整条曲线加速。一是数据安全法规的执法力度——网络数据安全管理相关规定在 2025 年初进入强化执行阶段，企业不能再停在“建制度”层面，必须拿出能自动映射数据位置、敏感度和访问关系的技术手段，这直接解释了 DSPM 为什么被推到萌芽期前排。

二是生成式 AI 的落地速度。报告引用了一组调研对比数据：国内 GenAI 采用率从 2024 年的 8% 上升到 2025 年的 43%。这个跳变带来的不是单纯的“要保护 AI”，而是双向需求——既要保护 AI 的数据、应用和模型，又要把 AI 用在安全能力上。AI 网关之所以被触发，正是因为企业从试验走向规模化后，API 密钥管理、限流、用量与成本追踪、多模型智能路由这些事散在各处，已经管不住了。

报告还提了两条战略假设，值得抄进年度规划里：到 2027 年，国内 60% 的大型组织会在安全运营中心里采用暴露管理来优化响应效率；到 2028 年，60% 部署 AI 的组织会采用协作式 AI 防御策略，而当前这个比例只有 5%。这两个数字的分量在于，它把“跨团队协作防御 AI 风险”从一个理念变成了一个明确的时间表——如果你的组织现在还没有安全、算法、数据、法务的联席机制，那 5% 到 60% 的这段路就是要补的课。

3. 把 AI 安全拆成可落地的三层：模型、网关与数据

AI 安全这个词在厂商嘴里被用得极泛，这份报告的处理方式相对克制：把它拆成 AI TRiSM、AI 网关、DSPM 等几个边界清晰的技术条目。按这个拆分方式做架构设计，能避免“什么都想管、最后什么都不管”的局面。

3.1 AI TRiSM：治理、可信与运行时风险的边界

报告对 AI TRiSM 的采用驱动写得很具体：数据被泄露、第三方风险、输出不准确或不合预期，以及“确保企业 AI 的行为与意图一致”。这四类驱动对应的是四个不同的控制面，很多团队把它们混成一个“AI 安全平台”，结果验收时说不清到底防住了什么。

我的拆法是：

• 治理层：模型与数据集的登记、来源与授权记录、用途边界声明。这一层本质是台账，工具化程度可以低，但必须存在，否则出事时无法追溯。
• 可信层：输入输出的内容安全、幻觉与越权输出的拦截、提示注入的检测。这一层适合在网关侧做统一策略，而不是每个应用各写一套。
• 运行时风险层：模型调用链的可观测性、异常行为检测、模型与上下游系统的权限边界。

报告把 AI TRiSM 放在膨胀期高点附近，理由是客户问询量在年初某开源推理模型发布后明显上升。这个信号对架构师的意义是：现在做 AI TRiSM，多数是在跟产品共同定义边界，所以方案里一定要留出“策略可插拔”的余地，别把某一家的检测引擎硬编进业务代码。

3.2 AI 网关的集中管控配置思路

AI 网关在国内被触发，动机非常务实：成本不可预测 + 内容安全。企业规模化使用多个大模型后，API Key 散落在各业务代码里、没有统一限流、不追踪 token 成本、切换模型要改代码——这些是典型的工程债。网关的价值就是把这些收敛成一个统一入口。

下面是常见做法的一个最小配置骨架，用 YAML 表达策略意图（不同产品字段名不同，这里只体现结构和参数含义）：

gateway: providers: - name: llm-a base_url: https://internal-llm-a/v1 api_key_ref: vault://ai/llm-a # 密钥走密钥管理，不落在配置文件里 weight: 70 # 路由权重，用于灰度与成本分流 - name: llm-b base_url: https://internal-llm-b/v1 api_key_ref: vault://ai/llm-b weight: 30 rate_limit: default_qps: 20 # 全局默认，按业务线可覆盖 per_tenant: true # 按租户隔离，防止单业务打满 burst: 40 # 允许的瞬时突发 routing: strategy: cost_aware # 成本优先；可选 latency_aware / quality_aware fallback_on_error: true # 主模型失败自动切备用，避免业务中断 max_retry: 1 # 重试次数要克制，避免放大计费 guardrails: input_scan: [prompt_injection, pii] # 入向检测：提示注入、个人敏感信息 output_scan: [sensitive_content, pii] on_violation: block_and_log # 命中即拦截并留痕，不要只告警

配置里有几个参数值得多说一句。weight权重路由不只是为了灰度，也是成本调节阀——把高成本模型权重压低、把常规请求导到便宜模型，月度账单差别很明显。max_retry必须设小，模型调用失败后重试会重复计费，重试两次的账单事故我见过不止一次。on_violation选block_and_log而不是纯告警，是因为内容安全的违规输出一旦流到用户侧，事后追责的成本远高于拦截误伤的成本，误伤率可以通过规则调优压下来，但漏放出去收不回来。

落地顺序上，我的建议是先把“密钥集中 + 限流 + 用量成本看板”三件事做完，这三件不涉及策略判断，阻力最小、收益最直观；再做内容安全护栏，因为护栏规则需要业务侧一起定，周期会长一些。

3.3 DSPM：在混合多云的“数据黑匣子”里建立可见性

报告对 DSPM 的定义很实在：发现此前未知的数据，覆盖本地数据中心和云服务商；对未知的、未发现的结构化和非结构化数据做特征刻画与分类；评估谁有权访问，从而判断安全态势和暴露面。它解决的问题是——在复杂、混合、多云的データ资产里，组织根本不知道敏感数据在哪。

这一层和合规是直接绑定的。报告明确写了新规要求对数据处理活动（含第三方共享）做全面风险评估，而 DSPM 的价值就是把敏感度、位置、访问关系自动映射出来。没有这张地图，合规评估就只能靠访谈和表格自填，风险敞口无法量化。

落地时的常见路径是先做“发现与分级”，再做“访问关系与暴露评估”，最后才是“与 AI 治理联动”。第三步是这份报告特别强调的方向：通过 DSPM 识别哪些敏感数据可以安全用于模型训练、分析或对外共享。这个判断如果只靠人拍脑袋，要么过度保守导致 AI 项目推不动，要么过度放开导致合规事故。

注意：DSPM 处在新兴阶段，国内可选项有限。做 PoC 时优先验证两件事——能否覆盖你真实的混合数据源类型，以及分类结果是否可人工校正并回流。只做一次性扫描、结果不可维护的工具，半年后就会变成新的技术债。

4. 把曲线翻译成三项动作：暴露管理、SCA 与零信任接入

前两章讲的是“怎么读”和“AI 安全怎么拆”。这一章落到具体的技术替换与接入动作上，这三项在这份曲线里位置明确、边界清晰，也最容易在预算会上被追问“为什么是它”。

4.1 AEV 与 EAP：从模拟攻击到可执行验证

报告把两项技术移出了曲线，理由写得很直接：BAS 被 AEV 取代，ASM 被 EAP 取代。

先看 AEV（对抗暴露验证）。取代 BAS 的原因是安全测试的范围变了——企业不再满足于“模拟一遍攻击看告警响不响”，而是要自动化、持续地验证暴露是否真实存在，并标出通往关键资产的脆弱路径。报告提到一个重要驱动：国家级攻防演练这类合规动作需要持续验证能力。这个变化带来的实操差异是：BAS 的输出是“检测覆盖率”，AEV 的输出是“哪条路径可以被真实打穿、先修哪个”。后者才能直接喂给修复排期。

选型时我会盯三个点：验证动作是否能安全回滚（避免把生产打挂）、路径图谱是否能和现有资产库对齐、每次验证是否能输出可复现的证据链。第三条尤其关键，攻防演练场景下，“我们验证过”需要有凭据，不能只有一句结论。

再看 EAP（暴露评估平台）。它取代 ASM 的理由是定位变了：传统攻击面管理侧重资产与漏洞的“可见”，而 EAP 要在单一平台里给出“有优先级、可执行”的漏洞与错误配置视图，目标是提升运营效率、简化修复流程。这两者的差别在落地时非常明显——ASM 交付的是一堆资产清单和漏洞列表，EAP 交付的是“本周该修这二十个，因为它们在关键业务链路上且已被验证可利用”。

如果组织已经有 ASM，不必急着替换，可以先补两个能力：一是把漏洞数据与业务关键性做关联打标，二是把修复动作的闭环状态纳入平台。这两步做完，其实就已经在往 EAP 的方向走了。

4.2 SCA：开源组件与模型供应链的早期识别

软件成分分析在今年的曲线上移动很快，报告给的原因是开源模型和第三方组件在 AI 与数字系统中的快速增长，“早期识别安全与许可问题”是减少开发延期、保证可信度的关键。注意这里的措辞是“早期识别”，也就是左移——在研发阶段拦，而不是上线后扫。

一个可以直接抄的接入方式是把 SCA 挂到构建流水线里，用阈值卡住构建：

# 在 CI 的构建阶段执行，失败即阻断合并 sca scan \ --path ./ \ --format json \ --output sca-report.json \ --fail-on "severity>=high" \ --fail-on "license in (AGPL-3.0, GPL-3.0)" \ --exclude "**/test/**" \ --sbom-output sbom.cdx.json

参数含义逐条说：--fail-on是阻断条件，按严重度或许可证类型设，是这条流水线真正的“闸门”；--exclude排除测试目录，否则误报会把闸门冲垮，团队很快就会要求关掉；--sbom-output顺手产出 SBOM，这个文件在出供应链事件时是救命的东西——没有它，你连自己用了哪个版本的组件都说不清。

阈值设置有血泪经验：一开始就把severity>=medium全阻断，结果第一个星期流水线几乎全红，团队直接绕过。合理做法是先用high以上做硬阻断，medium只告警并进周报，观察两三周把误报规则调干净，再逐步收紧。许可证那块要单独设，AGPL 这类传染性许可证在商业产品里出现，法务介入得越晚越麻烦。

提示：AI 项目里除了代码依赖，模型权重、数据集、推理框架也要纳入成分清单。传统 SCA 工具未必覆盖这些，需要额外维护一份模型与数据来源台账，两者合起来才算完整的供应链视图。

4.3 ZTNA 与 SASE：平台整合期的接入取舍

报告提到平台整合需求时点了一串产品：SASE、SSE、DSP、SIEM、EAP。其中 SASE 因网络与安全整合需求从低谷上行，SSE 因采用不及预期从峰值下行，ZTNA 则受益于零信任推进而采用上升。

这个组合给出的判断是：如果组织正在做远程接入改造，ZTNA 是确定性较高的投入；SASE 可以谈，但要按“整合后能省掉几套设备、几条专线”来算账；SSE 要谨慎，它的下行说明很多组织发现单独上 SSE 并不能解决实际问题，最终还是得回到 SASE 的整体框架里。

接入侧最常见的翻车点是策略粒度。零信任的核心不是“换一个远程接入工具”，而是把访问控制从“网络位置”改成“身份 + 设备状态 + 上下文”。很多项目上线后体验很差，原因往往是策略只做了身份认证，没做设备合规状态检查，结果一台不合规的终端照样能进。落地上我一般要求先定义清楚三件事：设备合规基线是什么、不合规时的降级动作是什么（只读？只能访问自助修复页？）、策略变更的审批链是谁。这三件不定，工具再好也是白搭。

5. 避坑清单：五个在真实项目里反复出现的翻车点

这一章单独拉出来，是因为这份报告里那些“为什么这项技术在下行、那项被移出曲线”的说明，本身就是别人的踩坑总结。结合国内落地场景，整理五条高频问题。

5.1 把 AI 网关当成纯转发代理

现象：网关上线后，成本没降、内容安全事故照出，团队认为“网关没用”。

原因：只做了请求转发和密钥收敛，没开限流、没做用量归集、没配内容护栏，等于换了个地方调模型。

解决：上线验收至少包含三项指标——按租户的 token 用量报表可查、限流在压测下生效、护栏规则命中后有完整留痕。三项缺一项就不算交付完成。

5.2 DSPM 扫描结果无人维护

现象：第一次扫描出的数据地图很漂亮，三个月后业务已经变了，地图还是旧的，合规评估不敢用。

原因：把 DSPM 当成一次性项目而非持续运营能力，没有指定数据地图的 owner，也没有把分类校正流程固化。

解决：明确一名数据地图责任人，把“新增数据源必须登记、分类结果季度复核”写进流程；采购时把“分类结果可人工校正并回流”列为硬性要求。

5.3 SCA 阈值一刀切导致流水线被绕过

现象：接入第一周大量构建失败，研发直接申请豁免，之后所有项目都带着豁免标签跑。

原因：初始阈值过严，误报未清理就开了硬阻断。

解决：分级放开，先用高危硬阻断、中危告警，两到三周清理误报规则后再收紧；豁免必须有审批人和有效期，过期自动恢复阻断。

5.4 零信任只认证不校验设备状态

现象：接入改造完成后，安全团队抽查发现不合规终端仍能访问核心系统。

原因：策略只做到身份认证层，设备合规状态、访问上下文没有纳入决策。

解决：补齐设备合规基线检查，定义不合规时的降级访问路径，并把策略变更纳入审批。验收时用一台故意不合规的终端做穿透测试。

5.5 按曲线位置而非收益等级做采购决策

现象：某项技术正处在膨胀期高点，被当作“趋势”紧急立项，一年后产品能力未收敛，投入沉没。

原因：只看曲线位置不看优先级矩阵里的收益评级和成熟年限，把“热度”当成“成熟度”。

解决：采购决策以优先级矩阵为准，五到十年周期的技术一律先小额试点，合同里写清能力交付节点与退出条款；两年内成熟的技术优先补齐，别在基础能力上欠账去追新概念。

6. 一份可复用的年度安全规划推演模板

把这份曲线用出价值的最后一公里，是把它变成一张能过会的规划表。我现在的习惯是拿到这类报告，先不急着读正文，而是先做三步推演，再回头核对报告里哪些条目支持或推翻我的判断——这样读得下去，也不容易被报告本身的叙事带着走。

第一步，列出组织当前的真实暴露面。不是列资产数量，而是列“哪些业务链路涉及敏感数据、哪些已经接了外部大模型、哪些依赖开源组件且版本不可控”。这一步输出的是一个短清单，通常不超过十条，但每条都必须能指到具体系统和责任人。

第二步，把清单上的每一项映射到曲线里的技术条目和优先级矩阵的格子。举两个映射的例子：

第三步，用报告里的两条战略假设做反向校验。把“2027 年 60% 大型组织在 SOC 采用暴露管理”和“2028 年 60% 部署 AI 的组织采用协作式 AI 防御”当作两个检查点问自己：如果同行在两年内做到这个比例，我们靠什么跟上？如果答案里出现“靠某个人盯着”，那这项能力就没有真正建立，需要工具化或流程化补上。这个反问比任何成熟度评分都管用。

还有一个容易被忽略的用法：报告里“退出曲线”的那部分别跳过。BAS 被 AEV 取代、ASM 被 EAP 取代，这类替换信息对存量工具管理极有价值。我一般会把退出项单独列一张表，标注现有工具的到期时间和替换窗口，避免在已被取代的品类上续费三年。这个动作每年能省下的预算，往往比新立项省出来的还多。

最后说个验证方法。规划表做完后，挑一项“两年内成熟”的技术（比如数据分类或 SIEM 的集成优化）和一项“五到十年”的技术（比如 AI 网关），分别设一个九十天的可验证目标：前者看“分类结果能否被下游 DSP、DLP 直接消费”，后者看“用量成本报表能否按业务线拆开”。能验证的才写进规划，验证不了的先降级为观察项。从那以后我每次做年度安全规划，都强制走一遍“现状清单—矩阵映射—假设校验—九十天可验证目标”这四步，宁可规划薄一点，也不留那种写得很漂亮、年底无法验收的条目。希望帮到你。

本文还有配套的精品资源，点击获取