密评市场在国内：一个被低估的刚需赛道，一把缺失的 AI 标尺

字节炼金术师
20 阅读17分钟

先讲一个现编的故事

2023 年底，一家做政务系统集成的公司拿到了一份整改通知：某厅级单位的核心业务平台，等保三级复测，密码应用不符合 GB/T 39786-2021 要求，限期三个月整改。

通知里列了三条问题：

  1. 登录鉴别采用 RSA-2048 数字证书，不符合国密要求
  2. 后台数据库字段加密使用 AES-128，算法非国密
  3. 数据传输层采用标准 TLS 1.3，未使用 TLCP

这三条，每一条拎出来都够研发团队忙一周。核心开发负责人告诉我，他当时第一反应是去问 AI："等保密评整改怎么做？"

大模型的回答言辞凿凿：换 SM2 证书、用 SM4 加密、部署 TLCP 网关。给的链接是 OSCCA 官网，标准号写的也对。看起来非常专业。

然后他们研究了三天。

卡在哪里了？SM2 证书的申请流程、与认证 HSM 设备的对接、TLCP 握手包里算法套件的协商顺序——这些细节，AI 说得模糊，或者每次问给的答案都略有不同。真正耽误时间的，是那些"知识是对的、但落地细节 AI 说不清楚"的地方。

这不是一个孤例。类似的故事在国内每年都在重复——因为密评整改对很多系统来说，不是"要不要做"的问题，而是"不做就过不了关"的问题。

这背后，是一个被低估的刚需市场。

密评到底是什么，谁在买单

一句话定义：商用密码应用安全性评估（简称"密评"），是依据《密码法》和相关标准，对信息系统密码应用的合规性与有效性进行评估的活动。

法律基线有三层：

层次法规/标准关键要求
基础法律《中华人民共和国密码法》（2020 年 1 月施行）明确密码分类管理，商用密码使用须符合国家标准
配套法规《关键信息基础设施安全保护条例》（2021 年施行）关键基础设施运营者须保障密码应用合规
技术标准GB/T 39786-2021《信息系统密码应用基本要求》规定等保各级别对应的密码应用要求，是密评的核心评分依据

GB/T 39786-2021 把密码应用要求拆成六个维度：物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全、密钥管理、安全管理。密评机构按这六个维度对系统逐一打分，生成评估报告。

谁必须做密评？

按现行政策，以下场景须完成密评（或正处于密评整改推进中）：

  • 等保三级及以上系统：凡在公安机关备案为等保三级的信息系统，密码应用须通过密评
  • 关键信息基础设施运营者：金融、能源、交通、水利、电信等行业的核心系统
  • 政务信息系统：依据国家政务信息化建设相关要求，政务平台需达到密评合格标准
  • 特定行业强制场景：金融监管部门对银行、券商、保险的合规要求中，密码应用合规已成常规检查项

换句话说：只要是跑在等保三级以上的系统，密评就是绕不过去的合规动作。

市场规模：从等保数量往后推

国内目前没有官方公开的密评"完成项目数"实时数据，但有几个可供推算的公开口径。

等保备案基数

根据公安部网络安全保卫局发布的历年等保工作报告（公开发布于公安部官网），全国等保备案系统数量持续增长，其中三级以上系统是密评的主要覆盖范围。截至 2023 年，累计备案三级以上系统数量已超过十万个量级（行业普遍引用，原始数据见各省公安厅等保公告）。

密评机构数量

承担密评工作的测评机构须经国家密码管理局认定（OSCCA 认可测评机构名单公开于官网）。截至 2025 年初，全国具备密评资质的机构约在数十家量级（OSCCA 官网随时更新，建议读者自查最新名单）。

市场规模粗估

参数数量 / 区间来源说明
全国等保三级以上备案系统总量十万量级公安部等保年度工作报告（行业普遍引用）
年新增三级以上备案系统数万级根据近年增速估算，未公开精确口径
具备密评资质的测评机构数数十家OSCCA 官网认可机构名单（实时更新）
单个项目测评周期1–3 个月行业普遍经验，复杂系统更长
单个项目费用区间数万至数十万元参考公开招投标公告，差异较大

说明：以上数字部分来自公开政策文件，部分为行业普遍引用区间，不构成市场研究报告。精确数据请参考 OSCCA 官网、各省密码管理局及相关行业协会的权威发布。

真正关键的信号不是某个具体数字，而是以下几个结构性事实：

  1. 等保三级以上系统数量庞大，且仍在持续增加——密评需求存量和增量都有
  2. 测评机构数量有限，供给侧天然存在产能约束
  3. 密评整改本身不是一次性动作，系统迭代后需要复评——这是重复性需求
  4. 《密码法》2020 年施行，配套细则持续落地，合规压力只会增强而非减弱

产业链与角色地图

密评市场不是一个简单的"甲方花钱、机构出报告"的两方结构，实际上涉及五类角色。

┌─────────────────────────────────────────────────────┐
│              监管层：国家密码管理局（OSCCA）            │
│              认定测评机构、发布标准、监督合规             │
└─────────────────────────┬───────────────────────────┘
                           │  认定 + 标准输出
          ┌────────────────▼────────────────┐
          │         测评机构（数十家）          │
          │  承接密评项目、出具评估报告          │
          └────────┬──────────────┬──────────┘
                   │              │
         ┌─────────▼──────┐  ┌───▼──────────────────┐
         │    甲方（被测方）  │  │  密码设备 / 产品厂商    │
         │  金融、政务、能源  │  │  HSM / SVS / UKey    │
         │  医疗、交通、央企  │  │  密码模块、SSL VPN     │
         └────────┬───────┘  └───────────────────────┘
                  │
         ┌────────▼────────────────┐
         │   开发者 / 集成商           │
         │  承接整改实施、写代码        │
         │  夹在甲方和测评机构之间       │
         └─────────────────────────┘

每个角色的关键动作：

  • 监管层：制定标准（GB/T 39786-2021、GM/T 系列）、认定测评机构资质、指导密评整改
  • 测评机构：入场调研、技术检测、生成评估报告、出具整改意见
  • 密码设备厂商：提供合规的硬件（HSM、SVS、UKey）和配套软件 SDK
  • 甲方：出钱、配合测评、推动内部整改落地
  • 开发者 / 集成商：真正写代码完成国密替换、对接密码设备 API、跑通测试——也是最容易被"卡"的一环

这五类角色里，开发者所处的位置最尴尬：他要同时理解甲方的系统现状、测评机构的评判标准、密码设备的 API 接口，还要在紧张的工期内把代码改对。

三类客户的真实痛点

甲方：钱没多少，问题全给我

典型场景：某城商行收到监管密评整改要求，内部 IT 团队五人，其中没有人系统学过国密标准。

痛点一：预算和工期不匹配

密评整改往往被当成"合规动作"纳入预算，而不是"技术改造"。但实际上，涉及 SM2 证书替换、TLCP 网关部署、HSM 密钥托管的改造，工作量完全是技术改造量级。预算和工期给的是"打个补丁"，实际要做的是"改发动机"。

痛点二：内部没有懂的人

GM/T 系列标准有十余个，相互引用关系复杂。很多甲方工程师能找到标准原文，但从标准条文到具体实现之间有大量"老师傅传帮带"的知识——SM2 签名里 Z 值的计算方式、SM4 分组模式的选择与等保要求的映射关系、数字信封格式规范——这些内容在标准里一笔带过，在网上几乎没有系统性的中文工程文档。

痛点三：改算法会牵一发动全身

把 RSA 改成 SM2 听起来是换一个库的事，但实际上：证书要重新申请（CA 机构、格式、字段），业务系统要重新对接（认证中间件、接口协议），测试环境要重新搭（需要真实的国密设备或可靠的 Mock），上线前还得再走一轮安全测试。一条"换算法"的整改项，可能拉出一个月的工程量。

测评机构：单子越接越多，人手越来越紧

具备密评资质的测评机构数量有限，但要覆盖的系统数量在持续增长。

痛点一：重复性劳动占用大量人力

密评报告有固定的章节结构：密码应用现状描述、逐条评估、不符合项整理、整改建议。每个项目这套流程都要走一遍，大量文字是可以模板化的，但实际上很多工作还是靠人工完成。

痛点二：初级测评人员培养周期长

测评工作需要同时懂技术（能看懂系统架构和代码）和懂标准（能对应 GB/T 39786-2021 条款）。这两类知识的组合不常见，新人培养到能独立承担测评项目，需要相当的时间积累。

痛点三：取证和报告的合规性压力

密评报告有明确格式要求，测评过程的取证（截图、日志、配置）要留档。任何遗漏可能导致报告被质疑或需要补充测评，进一步消耗人力和时间。

开发者：代码能跑，但跑的对不对没底

这是距离我最近、也最能感同身受的角色。

痛点一：标准文档是反工程师的

国密标准是学术语言写成的，充满了"应"、"宜"、"可"这类措辞，不给示例代码。GM/T 0018-2023 服务器密码机接口规范有几十个 API 函数，每个函数的参数语义都需要结合上下文才能理解。对一个没有硬件的开发者来说，甚至无法快速验证自己的理解是否正确。

痛点二：AI 给的答案"看着对，跑不通"

这是当前阶段的核心矛盾。主流大模型知道 SM2、SM3、SM4 的基本概念，能把算法名称说对，能引用正确的标准号——但在具体实现细节上极不稳定：

  • SM2 签名需要 Z 值预处理（参见 GM/T 0009-2012），但多数 AI 生成的代码里根本没有这一步
  • 数字信封格式（SM2+SM4，参见 GM/T 0010-2012）的封装结构，AI 给的 ASN.1 结构十有八九有细节偏差
  • SVS 接口的参数编码方式（有些接口用 DER 格式，有些用原始字节），AI 几乎无法保证给对

开发者无法依赖 AI 直接生成可用的国密代码，但也没有更好的参照——硬件设备不一定有、标准文档不够友好、社区示例代码极少。

痛点三：没有便宜的验证环境

要验证一段 SM2 签名代码是否真的正确，通常需要一个能接受签名并验证的服务端——也就是一台 SVS 或 HSM。真实设备价格高、部署复杂，不是每个开发者都有条件。结果是：代码写完只能靠"单侧测试"（自签自验），进了联调才知道格式到底对不对。

AI 在密评里的价值缺口

上面这些痛点，都指向同一个问题：密评领域现有的 AI 能力，与实际需要之间有一个可见的鸿沟。

现状：AI 停在"知识层"，下不到"执行层"

在密评场景里问 AI，通常会得到两类回答：

类型一：能说对标准号，但下不了手

Q: GM/T 0029-2014 的 SignData 接口，输入数据和输出签名的格式是什么？

AI A: 根据 GM/T 0029-2014，SignData 接口用于 SM2 签名...
       返回结果为签名值，格式参见标准文档。
       
AI B: 签名值为 DER 编码的 SM2 签名，包含 r 和 s 两个整数。
      （实际上：SVS 接口返回的是 P1 格式裸字节，不是 DER SEQUENCE）

类型二：给了代码，但跑不通

AI 生成的 SM2 签名代码，如果没有正确处理 Z 值（用户 ID + 公钥信息的哈希），在对接真实设备时必然验签失败。而这种错误不会在"自签自验"场景下暴露。

为什么这件事比其他领域更难

密评的难点不在于"知识量"，在于知识的细粒度和可验证性：

  • SM2 和 SM4 的算法原理，LLM 能说清楚
  • 但"具体这个接口的这个参数，是 DER 还是原始字节"——这种细节，LLM 训练语料极少，且无法自行验证
  • 不符合项的严重程度判断（是"严重"还是"一般"还是"轻微"），需要理解 GB/T 39786-2021 附录 A 的分级逻辑，这部分 AI 表现差异极大，且无法客观衡量

结果是：大家都感觉 AI 在密评上"差点意思"，但没有人能量化"差在哪里、差多少"。

这就是缺一把尺子的问题。

GM-Bench：给"AI 懂不懂国密"装一把尺子

GM-Bench 是为了解决这个问题而做的评测基准——面向商用密码合规（密评）场景的 LLM 评测集。

为什么需要专门评测？

通用 LLM 评测里没有密评专项，而且这类评测往往靠人工打分或 DeepSeek 打分——在密评这个领域，DeepSeek 自己也不一定能给出正确的参考答案。

GM-Bench 的核心设计原则是：能用代码验证的，就用代码验证；不靠人工主观打分。

六个评测维度

类别名称题数评分方式考察核心
C1条款归属60 题字符串精确匹配能否将密评场景归属到 GB/T 39786-2021 正确条款
C2标准映射40 题字符串精确匹配能否把设备/协议/算法对应到正确 GM/T 编号
C3SKOD 评分50 题容差评分（绝对误差 ≤2）能否对实际系统做出合理的四维密评打分
C4不符合项分级40 题F1 分数 + 严重程度匹配率能否识别不符合项并判断严重/一般/轻微
C5代码改写30 题实际运行验证能否生成可跑通的国密迁移代码
C6工具调用80 题MCP 序列对比能否选出正确的工具调用序列完成任务

C5 和 C6 是 GM-Bench 的差异化所在：生成的代码会被实际执行，对接 SVS/SDF/SKF Mock 设备，验证签名、加密、摘要能否真正跑通。工具调用序列和参考答案做 trace diff，不允许冗余调用。

现在就能跑

# 安装
git clone https://github.com/kintaiW/gm-llm-bench
cd gm-llm-bench
pip install -r requirements.txt

# 跑 C1-C4（无需 Mock 设备，最简单）
export OPENAI_API_KEY=sk-...
python harness/run_eval.py \
  --model gpt-4o \
  --categories C1,C2,C3,C4 \
  --output leaderboard/results/gpt-4o.json

# 跑完整评测（需要 svs-mock 服务，参见 03 篇）
export ANTHROPIC_API_KEY=sk-ant-...
python harness/run_eval.py \
  --model claude-opus-4-7 \
  --categories C1,C2,C3,C4,C5,C6

一道 C3 题示例

C3 考察 SKOD 四维打分（S=完备性，K=正确性，O=有效性，D=合规性，各维 0-5 分）：

{
  "id": "C3-001",
  "category": "C3",
  "scenario": "某电商平台（等保三级）：用户登录为用户名密码，数据传输 HTTPS（RSA 证书），数据库字段 AES-128 加密，密钥硬编码在配置文件，无密码设备。",
  "reference_scores": {"S": 1, "K": 0, "O": 1, "D": 0},
  "scoring_tolerance": 2,
  "explanation": "S=1（密码应用极不完整），K=0（无任何国密算法），O=1（加密措施极弱），D=0（完全不符合密评要求）"
}

这类题，「知道 SM2 是什么」的 AI 不一定会打分——它需要理解 GB/T 39786-2021 的评分框架，而且评分还要在合理误差范围内，不是一个简单问答能解决的。

给不同读者的下一步

如果你是甲方技术负责人

  • 用 GM-Bench 跑一下你内部在用的 AI 辅助工具，看它在 C1-C4 的得分——这能帮你判断这个 AI 是否值得在密评整改中信任
  • 对比不同 AI 在 C3（SKOD 评分）和 C4（不符合项分级）的得分，这两个维度最能体现 AI 对密评标准理解的深度

如果你是测评机构人员

  • gm-agent-stack 的三个 Mock（SVS/SDF/SKF）可以作为培训新人的模拟环境：不需要真实设备，就能让新人把 28 个 GM/T 接口操作一遍
  • GM-Bench 的题库（C1/C2/C4）可以用来评估团队成员对标准的掌握程度，比口头问答更客观

如果你是在做密评整改的开发者

先看第 3 篇教程：《3 小时完成一次模拟密评》

三步走：

  1. 跑起来 SVS Mock（不需要真实设备）→ 把接口联调环境搭起来
  2. 用 LLM + MCP 做接口探索 → 消除"不知道参数格式"的不确定性
  3. 跑 0029-svs-test 合规测试套件 → 验证接口行为符合 GM/T 0029-2014

改一个 URL，对接真实设备时的联调时间会大幅压缩。

几点说明

关于密评市场数据：本文引用的数字均来自公开政策文件、OSCCA 官网及行业普遍引用的区间估算。该领域缺乏权威的市场规模研究报告，本文不做精确数字推断，建议读者参考最新的 OSCCA 官方发布。

关于 AI 能力评价：GM-Bench 是研究性评测基准，评测分数不构成任何官方密评认证或合规证明。题目基于公开标准设计，经人工审核，但可能存在理解偏差，欢迎通过 GitHub Issue 反馈。

关于 gm-agent-stack：三个 Mock 服务（SVS/SDF/SKF）仅供学习和开发测试使用，不替代真实密码设备，严禁用于生产环境。密评合规结论须由具备资质的测评机构出具。

延伸阅读

avatar
文章
阅读
粉丝