很多企业在准备 CCRC EAL认证时，一开始会觉得这只是一个“产品安全认证项目”。

产品已经做出来了，功能也能正常运行，内部也有测试报告和产品说明书。于是企业很容易认为：只要把现有材料整理一下，再把产品送去评价，就可以推进认证。

但真正进入项目后，很多企业会发现事情比预想复杂得多。

认证过程中经常出现这些情况：

ST文档反复修改；产品边界说不清；设计文档支撑不了安全功能；测试用例和安全要求对不上；管理员手册缺少安全配置说明；版本、文档、测试报告不一致；实验室反馈问题后，不知道该改产品还是改材料。

这些问题并不一定说明产品本身不安全。很多时候，问题出在企业没有把产品安全能力转化成认证评价能够接受的证据体系。

这也是 CCRC EAL认证中最容易被低估的一点：它考察的不只是产品功能，也考察产品安全能力是否能被清楚说明、被充分验证、被完整追溯。

一、企业常见误区：把EAL认证当成普通测试

很多企业第一次接触 CCRC EAL认证时，会自然地把它理解为“找机构测一下产品”。

但 EAL认证和普通测试有明显差异。

普通测试更关注功能是否可用、性能是否达标、接口是否正常。EAL认证更关注产品安全功能、设计实现、测试验证、文档证据、配置管理和研发过程之间是否形成一致关系。

比如数据库产品声称支持访问控制，认证中需要看到的不只是权限配置界面，还要看到访问控制模型、设计说明、测试用例、测试结果、管理员配置说明之间能否对应。

再比如安全管理平台声称支持审计，认证中不会只看日志能不能生成，还会看审计事件定义、审计记录内容、审计配置方式、审计数据保护、测试覆盖范围是否完整。

所以，EAL认证的关键不是“产品有没有这些功能”，而是“这些功能能不能被证明”。

二、返工点一：产品边界一开始没有定清楚

CCRC EAL认证是针对具体产品和明确版本开展的认证。

但很多企业在项目初期，对“认证对象”理解得不够清楚。

例如：

认证的是整套系统，还是其中一个安全模块？认证的是软件平台，还是包含硬件设备？认证的是标准版、企业版，还是项目定制版？管理工具、客户端、插件、高可用组件是否进入认证范围？云端服务、移动端应用、外部接口是否算在边界内？

这些问题如果一开始没有定清楚，后面 ST、安全功能、设计文档、测试范围都会受到影响。

很多项目之所以反复修改，不是因为材料写得不认真，而是因为认证边界一直在变化。

边界不清，后面所有材料都会不稳定。

三、返工点二：安全功能描述太像产品宣传

企业内部的产品资料通常面向销售、客户和市场，语言更偏功能介绍和产品卖点。

但 EAL认证中的安全功能描述，需要更接近评价语言。

比如“产品具备高强度权限管控能力”这种表达，在宣传资料里可以使用，但在认证材料中还不够。

认证更关注的是：

谁是访问主体；访问对象是什么；访问操作有哪些；权限如何授予；权限如何回收；未授权访问如何被拒绝；管理员如何配置；测试如何证明规则有效。

如果安全功能描述停留在营销层面，评价人员很难判断它对应什么安全要求，也很难设计测试和审查证据。

所以，EAL认证材料需要把产品卖点拆解成可评价、可验证、可追溯的安全功能。

四、返工点三：ST文档没有真正统领项目

在 EAL认证中，ST通常是非常关键的文件。

很多企业会把 ST 理解为“认证材料之一”，实际项目中它更像是整个认证的核心依据。

ST会影响：

产品边界；安全问题定义；安全目标；安全功能要求；安全保障要求；测试范围；文档准备方向；评价活动重点。

如果 ST 写得不准确，后续设计文档、测试文档、用户手册都会跟着出现偏差。

常见问题包括：

ST中的产品范围和实际送测产品不一致；ST中写了某项安全功能，但产品实现支撑不足；ST中安全要求过多，导致测试和文档压力增加；ST中安全功能描述过粗，评价时难以落地；ST没有体现产品真实使用场景和运行环境。

所以，ST不是最后补出来的文件，而是项目早期就应该认真规划的认证主线。

五、返工点四：测试材料和安全要求对不上

很多企业内部都有测试报告，但这些测试报告不一定能直接支撑 EAL认证。

原因在于，内部测试通常围绕产品功能模块展开，而 EAL认证测试需要围绕安全功能要求展开。

举个例子：

内部测试可能写“用户登录功能测试通过”。认证测试更关注身份鉴别机制是否覆盖正常登录、失败登录、口令策略、异常处理、账户状态等场景。

内部测试可能写“权限管理功能正常”。认证测试更关注不同用户、不同角色、不同对象、不同操作下，访问控制规则是否按预期生效。

内部测试可能写“日志功能正常”。认证测试更关注关键安全事件是否被记录，审计记录是否包含必要信息，是否能查询、保存和保护。

这就是为什么很多企业明明有测试报告，认证时仍然需要补测试。

测试不是越多越好，而是要能支撑安全要求。

六、返工点五：管理员手册没有体现安全配置

很多企业会重视设计文档和测试文档，却忽视用户手册和管理员手册。

但在 EAL认证中，管理员手册非常重要。

原因很简单：很多安全功能需要管理员正确配置后才能发挥作用。

比如：

如何创建用户和角色；如何分配权限；如何开启审计；如何配置口令策略；如何设置安全参数；如何查看安全日志；如何进行备份恢复；如何处理异常状态；如何安全安装和部署产品。

如果产品中有这些功能，但管理员手册没有写清楚，评价时就会出现问题。

认证不仅要证明产品具备安全能力，也要证明用户或管理员能够按照文档正确、安全地使用这些能力。

七、返工点六：版本和配置管理不一致

很多软件产品迭代很快，认证过程中仍在不断更新版本。

这对 EAL认证来说是一个风险点。

因为认证需要确认：

送测产品是什么版本；ST对应哪个版本；设计文档对应哪个版本；测试报告对应哪个版本；用户手册对应哪个版本；整改后的版本变化是什么；最终交付版本和认证版本是否一致。

如果版本管理混乱，就容易出现“文档写的是A版本，测试测的是B版本，最终交付的是C版本”的问题。

这种情况会明显影响评价效率。

所以，企业在启动认证前，需要尽量固定认证版本，并建立清晰的版本基线和变更记录。

八、返工点七：问题整改没有形成闭环

认证过程中，实验室或评价人员通常会提出问题。

有些企业会把问题整改理解成“把文档改一下”。但很多问题背后可能涉及产品实现、测试覆盖、文档一致性、版本更新和配置管理。

例如：

测试用例不覆盖，可能需要补测试；文档和产品不一致，可能需要改文档，也可能需要改产品；安全功能描述不清，可能需要重写ST和设计说明；版本信息不一致，可能需要重新梳理基线；管理员手册缺少配置说明，可能需要补充操作步骤和限制条件。

整改不是简单答复问题，而是要形成闭环：问题原因、修改内容、影响范围、验证结果、版本记录都要能说清楚。

九、企业如何降低CCRC EAL认证返工风险？

企业如果已经计划启动 CCRC EAL认证，建议前期先完成几项基础工作。

第一，先明确产品边界。到底认证哪个产品、哪个版本、哪些模块和哪些安全功能，需要在项目初期明确。

第二，先评估目标等级。客户要求 EAL3+、EAL4+ 或更高等级时，要判断现有产品和材料是否具备基础。

第三，先梳理安全功能。把产品功能转化为认证评价能理解的安全功能，而不是直接使用宣传话术。

第四，先规划ST文档。ST应当作为项目主线，而不是后期补交材料。

第五，先检查材料一致性。ST、设计文档、测试文档、用户手册、管理员手册和产品实现要相互对应。

第六，先控制版本变化。认证过程中尽量减少无计划版本变更，保证文档、测试和交付物一致。

这些工作做在前面，项目后期返工会少很多。

CCRC EAL认证的难点，在于把产品能力变成评价证据

很多企业做 CCRC EAL认证遇到困难，并不是产品没有安全能力，而是没有按照认证评价逻辑组织证据。

EAL认证真正关注的是：产品边界是否清楚，安全功能是否可评价，设计文档是否能支撑实现，测试证据是否覆盖要求，版本配置是否可追溯，用户和管理员文档是否能指导安全使用。

对于面向政企、金融、运营商、能源、军工、关键信息基础设施等高要求场景的产品，提前规划 CCRC EAL认证，不仅有助于支撑招投标和客户准入，也能帮助企业系统梳理产品安全能力。

浙江望安科技有限公司长期围绕 国际CC认证、CCRC EAL认证、安全合规咨询、产品安全评估与认证实施服务 为软硬件企业提供专业支持，可协助企业完成产品边界梳理、认证路径规划、ST材料准备、测试整改和获证推进。

如需了解更多 CCRC EAL认证、CC认证及产品安全合规服务内容，欢迎访问 浙江望安科技有限公司官网，获取更多解决方案与服务信息。