我们系统要做安全检查，先做渗透测试还是代码审计？

这个问题，大多数第一次来找我们做安全检测的客户都会问，而且问的时候多半带着点“是不是选一个就行”的期待。

先说结论：顺序上，常规做法是先代码审计，后渗透测试。但具体怎么排，得看你的系统是什么情况、时间紧不紧、有没有源码。

代码审计+渗透测试

一、为什么常规是"先静态，后动态"

1.代码审计是从源代码里把漏洞的根找出来：SQL注入点在哪一行、权限校验漏在哪个接口、密钥是不是硬编码了、第三方组件有没有已知CVE。这些问题定位到行号，开发拿过去就能改，改起来成本最低。

2.渗透测试是站在外部模拟攻击，验证系统到底能不能被打穿。它不负责告诉你哪行代码写错了，它负责证明“这个口子真的能进，进去以后能拿到什么”。

所以先堵源头，再验疗效。先把编码层面能修的修掉，再让攻击方去测一轮，看看还剩什么打不穿的硬骨头。

反过来也行，但你会得到一个很挫的结果：渗透测试报了一堆问题，开发改到一半发现，其中一大半是编码规范问题，当初要是先审一遍代码，本来不用这么折腾。

还有一层：渗透测试是有破坏性的。虽然正规机构会控制力度，但扫描、探测、 fuzzing 这些动作对生产环境终究是个负担。先把明面上的洞补一补，再上渗透，风险也小一点。

二、有几种情况，建议反过来或者只做渗透

话不能说死，以下几种场景我们通常会给不一样的建议。

一是没有源码。

买来的商用产品、外包交付但合同里没约定源码、老系统源码早就对不上了等这些情况就别谈代码审计了，直接渗透测试加漏洞扫描，实在不行再加一层软件成分分析（SCA）查依赖组件。

二是时间特别紧。

比如马上要验收、要上线、要过评审，只剩一两周。代码审计的周期摆在那儿，中小型系统也要一两周起步，大型系统更久。这时候优先做渗透测试，先把最可能被利用的那几个口子封住，代码审计排到下一期。安全是持续的事，别指望一次全做完。

三是只想验证“现在能不能被打穿”。

有些客户的目的很明确：我就想知道外部黑客进不进得来，内部谁写的代码我不关心。那直接渗透测试，干净利落。

四是系统特别大、模块特别多。

这种情况下两项往往是并行的，不同团队同时干，效率最高。但注意，复测的顺序不能乱：代码问题修完再回归，最后统一做一次完整的渗透验证。

三、一个经常被忽略的点：顺序不重要，闭环才重要

说实话，我见过太多项目，两项都做了，钱也花了，最后安全检查还是没过。原因不是顺序排错了，是检测出来的问题没整改，或者整改完没复测。

一份只丢问题清单的报告，价值大概只有一半。另一半在于：开发看懂了没有、改对了没有、改完有没有引入新问题。所以签合同的时候，别光看总价，问清楚三件事：误报会不会人工剔除？报告给不给到具体位置和修复方案？包不包含复测？这三个问题的答案，比“渗透还是审计”这个选择题重要得多。

四、给你一个可以直接用的判断方式

两者测试顺序

1.自研系统、有源码、等保三级或涉及敏感数据：两项都做，先代码审计，后渗透测试，最后复测。

2.商用产品无二次开发、展示类系统、低风险：渗透测试加漏洞扫描为主，代码审计看甲方或主管部门要求。

3.赶工期：先渗透，代码审计往后排，但一定要排，别取消。

4.只想摸底：渗透测试就够了，但要清楚它扫不到代码里的暗病。

安全检测最耗时间的从来不是测，是改，不要等到验收前几天才想起找柯信检测做测试，务必要留出整改的窗口，比纠结先做哪项有意义得多。如果拿不准该走哪种组合？可以把系统类型、有没有源码、大概什么时候要报告说一声，我们帮你排个顺序和周期。

标签：渗透测试、代码审计