甲方要求交付第三方测试报告，还需要单独做代码审计吗？

第三方测试报告包含了‘源码级安全检查’？不都是测软件吗？

不都是。 这两个词看着像兄弟，其实干的是完全不同的活。一个在门外踹门，一个把锁拆开看锁芯。你要交的材料、花的钱、验收会上能不能过关，全取决于你有没有早点分清这件事。

第三方测试报告

一、先搞清楚：第三方测试报告到底测了什么

别急着想代码审计。先看甲方要你交的那份东西是什么。

绝大多数情况下，“第三方软件测试报告”指的是黑盒层面的验证：功能有没有按需求实现、性能指标达没达标、兼容性好不好、界面和文档对不对得上。依据通常是 GB/T 25000.51 那一套，交付物是一份盖章的报告，结论是“通过”或“不通过”。

它站在用户的视角。测试人员对着界面和接口，输入数据、观察输出、记录偏差。测得再细，也有一层天花板：看不见内部。

这就带来一个很现实的问题。有些缺陷，从外面几乎不可能发现。

所以答案很明确：如果甲方的要求里出现了“源码”“代码安全”“静态分析”“安全漏洞扫描”这类字眼，光有一份功能测试报告是不够的。 哪怕那份报告盖了CNAS章、做得再漂亮，也覆盖不到那一层。

二、那什么情况下可以不做？

也不是所有项目都得加。钱和时间都是真的，没必要瞎花。

可以省的情况：纯内部系统、不涉及个人信息和资金、没有对外接口、甲方也没提安全条款。跑一遍自己的自动化用例，再加一轮内部代码走查，基本够了。或者你的系统压根没怎么写业务代码，买的成熟产品做配置化落地，自研部分很薄，那代码审计的投入产出比就很差。

不建议省的情况：涉及支付、涉及个人信息或敏感数据、有对外 API、要被等保覆盖、要入网、要长期运维。还有那种“别人写的老系统，现在交到你手上”的项目，你不知道里面埋了什么，做一次比猜十次便宜。

有个简单的判断办法：想想最坏情况发生时，代价是什么。功能测试漏了一个 bug，用户骂两句，下个版本修掉。安全漏洞漏了，可能是数据、是钱、是通报、是负责人被约谈。这两类风险的量级根本不在一个平面上。为了省那点钱在人工复核上打折，这个折扣要到出事那天才会兑现。

三、真要加，怎么加才不花冤枉钱

很多人踩的坑不是“没做”，而是做了两遍，还多花了钱。

最常见的一种：先找一家做第三方功能测试，报告出了；甲方说还要源码检查；又找另一家做代码审计。两家各走各的流程，环境搭两遍，资料交两遍，沟通两轮。周期直接翻倍。

其实完全可以一次做完。正规的检测机构通常既具备功能与性能测试能力，也能做代码审计和安全检测。同一套环境、同一批资料、同一个项目组，先把黑盒走完，再把源码过一遍，最后出一份总报告或者一份主报告带安全附件。省时、省钱，而且结论不自相矛盾，你很难想象两份不同机构出的报告对同一个系统给出完全不同的评价时，验收会上该信谁。

另外一个必须提醒的点：代码审计不能只靠工具跑一遍。

SonarQube、Fortify、Checkmarx 这类工具确实要用，覆盖广、速度快、不会漏掉低级的复制粘贴错误。但它们的误报率高得惊人，报二十处，真正成立的可能只有三四处。工具不懂业务，它只知道“这里拼接了 SQL”，不知道前面已经做过参数化了。

测试工具

未经人工复核的扫描结果，只能叫清单，不能叫报告。拿原始导出件当交付物交给甲方，专家翻两页就看出来了。验收会上被问一句“误报怎么处理的”，答不上来会很尴尬。

所以合理的做法是：工具打底，工程师逐条复核，筛掉误报，合并重复项，把同一条根因在不同文件里的表现收拢成一条，然后补上复现步骤、风险说明、修复建议。这才是你花钱买到的东西。

四、现在就能做的三件事

如果你手上正好有这么个项目，别急着比价。先发我们三样东西：

一是甲方的要求原文，尤其是“交付物清单”和“技术指标”那几页。我们先帮你看清到底要几种报告、依据哪套规范、有没有指定资质条目。很多时候你会发现，甲方要的其实比你以为的少；也有时候会发现，你以为够了的那份，其实差了一大块。

二是技术栈和大致代码量，哪些模块优先、第三方依赖审不审、前端审不审。范围界定这一步最容易漏，不写清楚，后期一定分歧。

三是时间节点，包括初验、终验、材料报送的日期。我们倒推给你排个工期，告诉你来不来得及、哪几步可以并行。

评估完了，要是我们发现你自己装个开源扫描器定期跑就够用，我们会直说。毕竟一份审不出东西、会上被问住的报告，对我们也没好处。

对你来说，真正贵的从来不是多做一项测试。而是做到一半才发现，做错了。

标签：第三方测试报告、代码审计报告