在软件开发中，“密评” 是涉及敏感数据的项目绕不开的合规安全环节 —— 金融 APP、医疗病历系统、政务平台若密评不通过，不仅上线受阻，还可能违反《密码法》面临处罚。不少人会把密评和等保混淆，其实它是更聚焦 “密码应用安全” 的专项评估。今天就讲清软件开发中密评的核心：定义、评估重点、落地方法，帮团队少走返工路。

一、密评是什么？有法规依据的 “密码安全体检”

先理清核心概念：密评全称是 “商用密码应用安全性评估”，依据《中华人民共和国密码法》《商用密码应用安全性评估管理办法》，核心是检查软件系统中 “商用密码” 的应用是否合规、有效 —— 简单说，就是看软件里 “加密、解密、签名” 等密码功能，是不是用对了、用安全了。

为什么软件开发必须关注密评？

• 
  

• 合规底线：《密码法》明确，“涉及国家安全、国计民生的重要信息系统，商用密码应用必须做安全性评估”，比如理财 APP、医院系统、政务平台，上线前必须过密评；

• 安全刚需：密码是数据的 “最后一道锁”，若算法用错、密钥管不好，即便过了等保，数据仍可能被破解；

• 等保关联：等保 2.0 将 “密码应用” 纳入核心评分项，密评不通过的系统，等保测评也难达标。

二、软件开发中，密评到底评什么？4 个核心阶段重点

密评不是 “上线前突击检查”，需贯穿开发全流程，评估重点随阶段变化，核心看 “密码应用是否嵌对、嵌牢”：

1. 需求阶段：评 “密码需求有没有规划”

很多项目踩坑的起点，是需求阶段没考虑密码 —— 比如开发理财 APP，没规划 “支付数据怎么加密”，后期补改成本极高。密评此阶段查 3 点：

• 有没有明确 “哪些数据要加密”（如身份证号、支付金额属高敏感数据，必须加密）；

• 有没有选对 “密码场景”（传输用 TLS、存储用 SM4、登录用 SM3 哈希）；

• 是不是用 “国家认可的商用密码”（如 SM2、SM3、SM4，禁止用未经认证的境外算法）。

反例：某医疗 APP 需求阶段没规划，开发时用境外 RC4 算法加密病历，密评直接判定 “不合规”，只能全量返工换 SM4。

2. 设计阶段：评 “密码方案合不合理”

设计错了，后面改相当于 “拆了重盖”，此阶段密评重点看 3 个逻辑：

• 全链路加密覆盖：数据从 “产生→传输→存储→销毁”，是不是都有密码保护？比如用户银行卡号，传输用 TLS 1.3、存储用 SM4、删除时销毁密钥，少一步都不行；

• 密钥管理安全：密钥是 “解密钥匙”，密评查：密钥是不是存在专门的 KMS（密钥管理系统），而非写在代码 / 普通数据库；有没有 “90 天定期换密钥” 的机制；

• 身份认证合规：比如管理员登录，是不是用 “密码 + SM2 数字签名” 双因素认证，避免单一密码被破解。

某政务平台设计时，把密钥存在普通服务器配置文件里，密评要求整改：必须迁移到国家认证的 KMS，否则不通过。

3. 开发阶段：评 “密码功能有没有嵌对”

开发是密码落地的核心，密评盯 “代码里的密码应用是否规范”，避免 “表面合规、实际漏洞”：

• 算法使用正确：是不是用对国密算法（SM2 用于签名、SM4 用于加密），有没有 “错用场景”（如用 SM3 哈希做加密，SM3 实际只适合完整性校验）；

• 代码无密码漏洞：比如密钥硬编码（String key = "123456"）、用固定盐值加密（所有用户密码用同一盐值，黑客破解一个就能批量破）；

• 密码功能不走过场：比如设计 “密钥定期换”，但代码没写自动换逻辑，靠人工改 —— 密评判定 “功能无效”。

常见错误：某电商 APP 用 SM4 加密收货地址，但密钥写在application.properties里，黑客拿到配置文件直接解密，密评判定 “高风险”，整改为密钥存 KMS、代码动态调用才通过。

4. 测试 / 运维阶段：评 “密码功能能用、管得住”

此阶段密评看 “实际效果”，而非 “设计”：

• 测试阶段查有效性：用工具模拟 “密钥泄露”“算法破解”，看密码能否防住 —— 比如破解存储的加密数据，若能轻易解开，说明加密逻辑有问题；

• 运维阶段查规范性：比如密钥有没有 “双人保管”（避免一人拿全密钥）、日志有没有 “密钥操作记录”（谁调用、何时调用留痕）、员工离职有没有 “密钥回收机制”。

某银行后台，管理员能单独导出所有用户加密密钥，密评判定 “管理不合规”，加了 “双人审批调用” 功能才通过。

三、怎么 “一次过密评”？避开 3 坑，做好 2 事

不少团队觉得密评 “难”，其实是踩了 “突击整改” 的坑，掌握方法能大幅降返工率：

避开 3 个常见坑

1. 坑 1：先开发，后补密码某政务 APP 没规划密码就开发，上线前密评发现 “身份证号明文存储”，暂停上线花 2 个月重构，成本增 30%；正确：需求阶段拉密码厂商、安全团队一起定方案。

2. 坑 2：用境外算法凑数有些团队觉得 “RSA、AES 方便”，忽略《密码法》“关键场景必须用国密”，密评直接打回；正确：优先选国密算法，不确定查 “国家商用密码算法目录”。

3. 坑 3：密钥管理靠人工某企业用 Excel 记密钥，员工离职拷贝带走致数据泄露，密评判定 “严重不合规”；正确：用国家认证的 KMS，自动管密钥生成、存储、更换，避免人工干预。

做好 2 件关键事

1. 定 “密码开发规范”给开发团队明确规则：敏感数据存储前必须调 SM4 加密、密钥从 KMS 动态获取（禁硬编码）、日志不记明文密钥，开发时对照自查；

2. 提前做 “自评 + 预测评”别等上线前找官方测评，开发中期找第三方密码厂商做 “预测评”，提前发现问题（如加密链路断点），整改成本比后期低 80%。

四、案例：手机银行 APP 的密评落地流程

以开发手机银行 APP 为例，密评贯穿流程的正确做法：

1. 需求阶段：明确 “支付数据、登录密码、余额” 用国密，传输 TLS 1.3+SM2、存储 SM4；

2. 设计阶段：密钥分级管理 —— 用户密码 SM3 哈希、支付密钥存 KMS、管理员操作需 SM2 签名；

3. 开发阶段：调用国密 SDK，密钥从 KMS 动态获取，无硬编码；

4. 测试阶段：用工具破解加密数据，验证无法解开；测试密钥更换功能，确认正常；

5. 运维阶段：KMS 密钥双人审批调用，操作日志存 1 年以上；

6. 正式密评：找官方认可机构测评，拿合规报告后上线。

结语

对软件开发来说，密评不是 “负担”，而是 “安全与合规的保障”—— 本质是帮团队 “把密码用对、用牢”。只要从需求阶段就规划好，融入开发全流程，避开突击整改的坑，密评就能 “一次过”，不用反复返工。