不买密码产品,自己写开源代码实现加密能过密评吗?

【密评业务真实场景】

★

甲方项目负责人（拿着预算表，眉头紧锁）：“王工，这次系统升级预算被砍。研发说不用买带证的密码产品，直接用开源OpenSSL库，或者自己写代码加密校验，效果一样还省钱。这在密评里能直接过吧？”

密评项目经理（面露难色）：“领导，自己写的代码没经过国密局检测，合规性存疑……用开源库的话，规定好像能给点认可？尺度比较复杂，我得查查。”

甲方项目负责人（敲击桌面）：“什么叫‘好像’？系统下个月就要交账！到底是必须重买设备，还是能直接上线，给个准话！”

大家好，我是孙岩。

在密评项目的实际推进中，因为“预算紧张”或“开发习惯”，业务系统尝试用“开源代码”或“自研软件加密”来替代专业商用密码产品的情况比比皆是。面对甲方的灵魂拷问，测评人员如果拿不出确凿的依据，极容易导致项目卡壳。

不用纠结了！刚刚重磅发布的《商用密码应用安全性评估FAQ》（第四版）针对这个问题（问题Q4）给出了非常明确的“判决书”！今天我们就来为您掰开揉碎地讲清楚。

🔍 核心争议：不用合规密码产品，全靠代码加密行不行？

根据相关国家标准（GB/T 39786-2021和GB/T 43206-2023），被测系统采用的密码产品，理应符合相应等级的密码模块安全要求。但在实际业务中，系统如果没有购买专业的密码产品，而是通过软件代码的方式来实现数据的机密性和完整性保护，到底算不算合规？

新版FAQ明确指出：不能一概而论，必须把“自研代码”和“开源密码库”分开来看！

🚫 情况一：纯自研软件代码加密？直接“亮红牌”！

如果您的研发团队非常“硬核”，从头到尾自己写了一套软件代码来实现数据的机密性和完整性保护，但在测评时又无法提供任何安全性证明，那么对不起，密评的判定结果将是冰冷的两个字：“不符合”。

为什么要求这么严？因为密码学是一门极其严谨的科学。对于纯自研的加密软件：

1. 无法定级：测评人员根本无法判断它的密码模块安全等级。
2. 安全性未知：它采用的密码算法、技术实现过程是否安全无漏洞，完全是个黑盒。
3. 密钥“裸奔”：软实现往往伴随着极高的密钥管理风险，密钥的生成、存储、分发很难做到真正的安全。

因此，纯自研代码在密评中是无法通关的。

⚠️ 情况二：使用第三方开源密码库？可以拿到“感情分”！

如果您的系统使用的是第三方的开源密码库（比如业界常用的OpenSSL）来实现数据的保护，情况则会有所转机。FAQ给出了极具实操性的人性化规定：

如果该第三方开源密码库满足以下两个硬性条件，测评时可以考虑酌情判定为“部分符合”，并给予相应的分数：

1. 久经考验：这个开源密码库必须是经过长期使用，并且没有暴露出安全问题的。
2. 使用正确：研发团队在调用这个开源密码库时，使用的方法和配置必须是完全正确、规范的。

🚨 密评师的“隐藏探照灯”：别以为用了开源库就万事大吉了！测评机构在核查时，会去专业的漏洞网站（如OpenSSL官方漏洞库等）核实您所使用的版本是否存在已知的安全性漏洞。如果用的是带有高危漏洞的旧版本，依然是无法过关的！

💡 总结与实操建议

读完这篇，下次再面对研发团队“自己写代码加密省钱”的提议，您就可以条理清晰地给他们普法了：

“兄弟们，纯自己写加密代码在密评里是绝对行不通的，直接一票否决！如果确实有特殊困难用了知名的开源密码库（比如安全的OpenSSL版本）且调用正确，密评最多只能给个‘部分符合’。想要系统稳稳当当地拿高分、全面满足合规要求，咱们还是得老老实实采购带有国家认证证书的商用密码产品！”

“部分符合”虽然不至于得零分，但距离真正的合规、高安全标准仍有差距。在预算允许的情况下，优先选择合规密码产品，才是系统安全建设的“最优解”！

赶快把这篇文章转发给您的研发团队和项目群吧，让大家在系统规划阶段就统一思想，少走弯路！欢迎在评论区留言，分享您的系统在密码整改中遇到过哪些关于“写代码”的趣事与挑战！

(本文首发于【孙岩讲密评】。基于《商用密码应用安全性评估FAQ》（第四版）整理发布，仅供参考，最终解释权归原发布单位所有。)