专业CMA\CNAS第三方软件测试报告服务商

维度	安全功能测试	渗透测试/漏洞扫描
核心目标	验证“有没有”和“对不对”	验证“能不能攻破”
测试依据	需求文档、设计文档、安全标准	攻击者视角、已知漏洞库
测试方法	正向验证 + 反向逻辑验证	模拟黑客攻击、模糊测试
覆盖范围	全覆盖（所有安全功能点）	抽样覆盖（寻找最弱点）
输出结果	功能符合性结论（通过/不通过）	漏洞列表及风险等级
适用阶段	开发完成、验收前（必须项）	上线前、定期巡检（加强项）

关键结论：一个系统可能通过了渗透测试（没被攻破），但安全功能测试不达标（如日志未记录、密码策略未生效），这在合规验收中是一票否决的。

二、安全功能测试的六大核心维度（基于GB/T 25000.51）

根据国家标准，安全功能测试主要围绕信息安全性的六个子特性展开：

2.1 保密性

目标：确保数据只能被授权用户访问。

测试点：

数据传输加密：验证敏感数据（密码、身份证、银行卡号）在传输过程中是否采用HTTPS/TLS加密，是否明文传输。

数据存储加密：验证数据库中敏感字段是否加密存储（如AES、SM4国密算法）。

隐私保护：验证前端展示时是否对敏感信息进行脱敏处理（如手机号中间四位掩码）。

2.2 完整性

目标：确保数据在存储和传输过程中未被篡改。

测试点：

防篡改机制：验证关键数据（如金额、权限标识）是否具备校验机制（如数字签名、哈希校验）。

输入验证：验证系统是否能拦截非法字符、SQL注入、XSS脚本等试图破坏数据完整性的输入。

一致性检查：验证多副本数据或主从数据的一致性。

2.3 抗抵赖性

目标：确保操作行为可追溯，操作者无法否认。

测试点：

日志审计：验证系统是否记录了关键操作（登录、增删改、授权）的时间、用户、IP、操作内容。

日志保护：验证日志文件本身是否防篡改、防删除，普通管理员是否无权修改日志。

数字签名：验证关键交易或审批流程是否使用了电子签名或时间戳技术。

2.4 可核查性

目标：确保每个动作都能关联到具体的责任主体。

测试点：

身份唯一性：验证是否存在共用账号，是否强制实名制。

权限最小化：验证用户是否仅拥有完成工作所需的最小权限。

会话管理：验证超时自动退出、单点登录互斥、并发登录限制等功能。

2.5 真实性

目标：确保用户、系统或数据的身份是真实的。

测试点：

身份鉴别：验证用户名/密码、生物特征、多因子认证（MFA）的有效性。

密码策略：验证密码复杂度、长度、有效期、历史密码重用限制是否生效。

防暴力破解：验证连续失败登录后的账号锁定或验证码机制。

2.6 内部安全性

目标：确保系统内部资源不被未授权访问或滥用。

测试点：

越权访问：验证水平越权（A用户访问B用户数据）和垂直越权（普通用户访问管理员功能）。

资源隔离：验证多租户环境下的数据隔离性。

异常处理：验证系统在报错时是否泄露堆栈信息、数据库结构等敏感信息。

三、常用测试方法与技术手段

第三方机构通常采用“黑盒为主，灰盒为辅”的策略，结合自动化工具与人工逻辑分析。

3.1 静态分析 (SAST) - 代码级

方法：在不运行代码的情况下，扫描源代码或二进制文件。

用途：发现硬编码密码、不安全的加密算法调用、潜在的SQL注入点。

工具：Fortify, SonarQube, Coverity, 国产固源等。

3.2 动态分析 (DAST) - 运行态

方法：在软件运行时，通过发送各种请求来观察响应。

用途：验证运行时的安全功能，如会话管理、错误处理、输入过滤。

工具：OWASP ZAP, Burp Suite Professional, AppScan。

3.3 交互式分析 (IAST) - 混合态

方法：在应用内部植入Agent，结合动态流量和代码执行路径进行分析。

用途：精准定位漏洞位置，误报率低，适合复杂业务逻辑验证。

3.4 手工逻辑验证 - 核心

方法：测试人员根据业务逻辑，设计特定的测试用例。

典型场景：

越权测试：修改URL中的ID参数，尝试访问他人数据。

流程绕过：直接访问支付成功页面，跳过支付步骤。

并发竞争：模拟多线程同时操作同一账户余额，验证原子性。

状态机测试：验证订单状态流转是否符合预设规则（如“已发货”不能直接变“待支付”）。

3.5 配置核查

方法：检查服务器、数据库、中间件的安全配置。

内容：默认口令修改、不必要端口关闭、错误信息屏蔽、SSL/TLS版本配置等。

四、第三方机构开展安全功能测试的全流程

具备CMA/CNAS资质的第三方机构，其测试过程必须严格遵循ISO/IEC 17025实验室管理体系，确保报告具有法律效力。

4.1 阶段一：项目启动与需求分析

资料收集：获取《需求规格说明书》、《系统设计文档》、《安全设计方案》、API接口文档。

标准确认：确定测试依据（如GB/T 25000.51、GB/T 22239等保2.0、行业标准）。

范围界定：明确测试的功能模块、用户角色、数据范围。

输出：《测试方案》、《安全功能测试用例初稿》。

4.2 阶段二：用例设计与评审

用例设计：

正向用例：验证正常授权下的功能是否可用。
反向用例：验证未授权、越权、异常输入下的功能是否拦截并提示。
边界用例：验证极限条件下的安全表现。

内部评审：由资深安全专家审核用例的覆盖率和深度，确保无遗漏。

客户确认：与建设方确认测试场景的合理性（避免破坏生产数据）。

4.3 阶段三：测试环境搭建与预检

环境独立性：必须在独立测试环境进行，严禁直接在 production 环境进行破坏性测试。

数据准备：构造包含不同权限级别、不同敏感等级的测试数据。

工具校准：对自动化扫描工具进行规则库更新和误报率校准。

4.4 阶段四：测试执行

自动化扫描：运行DAST/SAST工具，生成初步报告。

人工深度测试：

执行手工逻辑验证用例。
对自动化工具发现的疑点进行人工复核（去误报）。
尝试绕过已部署的安全机制（WAF、防火墙），验证其有效性。

问题记录：详细记录每个问题的复现步骤、截图、日志证据、风险等级。

4.5 阶段五：回归测试

缺陷修复：开发方修复问题后，提交新版本。

回归验证：

验证原问题是否彻底解决。
验证修复过程是否引入了新的安全问题（副作用）。

多轮迭代：直至所有高危、中危问题清零，低危问题有明确处置计划。

4.6 阶段六：报告编制与三级审核

报告起草：汇总测试数据，生成《软件安全功能测试报告》。

三级审核制度（CMA/CNAS强制要求）：

编制人：对数据真实性负责。

审核人：对测试方法的科学性、结论的逻辑性负责。

授权签字人：对报告的法律效力、合规性负责（必须持有CNAS授权签字资格）。

盖章出具：加盖CMA、CNAS章及检测机构公章，生成防伪二维码。

五、常见误区警示

误区	真相	风险
“扫一下没漏洞就是安全”	漏扫只能发现已知漏洞，无法验证业务逻辑安全（如越权）。	业务逻辑漏洞导致数据泄露。
“功能测试包含安全测试”	常规功能测试只测“通不通”，不测“安不安全”。	系统功能正常但裸奔，不符合等保要求。
“一次测试管终身”	系统迭代、环境变化都会引入新风险。	旧报告无法证明新版本的合规性。
“开发自己测就行”	缺乏独立性和专业性，容易灯下黑。	验收不通过，审计不认可。