代码走查怎么进行？如何确保走查质量？

代码走查不是拉几个人对着代码挑刺，也不是跑个工具出个报告就走人，它是一套有标准流程、有质量管控的结构化人工检查方法，专门挖自动化工具发现不了的隐蔽问题，比如业务逻辑漏洞、权限设计缺陷这些，工具扫一百遍都扫不出来，只有人盯着代码逻辑才能找着。

代码走查

一、代码走查流程

根据柯信检测给政企、金融客户做了n次走查的经验，标准流程分四个阶段，少一个都不行。

1.准备阶段

首先要确定走查的范围，不是所有代码都要走查，优先选核心交易模块、权限控制模块、支付链路、加密模块这些高风险区域，还有高频改动的模块、之前出过bug的模块，这些是重点。

然后要定明确的检查清单，不能靠参与的人凭感觉看，清单要覆盖四个维度：

逻辑维度（算法是不是符合设计？有没有考虑边界条件？并发场景有没有问题？）

规范维度（命名是不是清晰？注释是不是到位？有没有符合编码规范？）

安全维度（用户输入有没有校验？有没有SQL注入、越权访问的风险？敏感信息有没有脱敏？）

性能维度（有没有死循环？有没有慢查询？有没有资源泄漏的可能？）。

2.执行阶段，也就是走查会议

单次走查的代码量控制在300-400行以内，时长不超过1小时，超过这个量大家的注意力就会下降，效果大打折扣。

会议的流程一般是代码作者先讲这段代码的设计思路、实现逻辑，然后参与的人对着检查清单逐条过，有疑问当场提，有争议当场讨论，不用纠结谁对谁错，目标就是把问题找出来。

我们之前给一个电商系统走查订单模块，作者讲库存扣减逻辑的时候，测试人员当场问了一句“如果两个用户同时下单，库存只剩1件，你这里有没有做原子性校验？”，一查果然没有，及时补了分布式锁，避免了超卖的风险。

3.记录阶段，所有问题都要留痕，分级管理。

我们一般用红黄绿三色标记：

红色是必须修复的严重问题，比如安全漏洞、逻辑错误、会导致系统崩溃的bug；

黄色是建议优化的改进项，比如代码重复可以提取、命名不规范、注释不够清晰；

绿色是通过的项。

每个问题都要记录清楚位置（精确到文件和行号）、问题描述、建议的修复方案，不能只写“这里有问题”，要让开发拿到就能改。

4.闭环阶段，这一步很多团队不做，等于走查白做。

这一步有些机构不做，但如果省略，走查可能就白做了。

所有红色问题必须开发修复之后提交复测，确认修复有效，没有引入新的问题，才算闭环。

我们做第三方走查的时候，会跟踪所有红色问题的修复情况，直到全部闭环才出具报告，见过太多“改了个表面、根因没动”的情况，比如一个SQL注入漏洞，开发只在前端加了校验，后端接口没改，攻击者绕过前端还是能注入，这种必须复测才能确认。

二、怎么确保走查质量+走查踩坑。

很多团队做走查最后变成了走过场，就是踩了几个坑：

1.参与的人视角太单一，全是写代码的，只关注功能实现，没人从安全、测试的角度看问题，我们建议至少加1个非该模块开发的人员，新鲜视角更容易发现问题。

2.单次走查规模太大，一次走几千行代码，大家看到后面都麻木了，根本不会仔细看，记住“小而频”比“大而全”效果好，分多次走查，每次聚焦一个小模块。

3.没有检查清单，全靠个人经验，不同的人走查出来的结果差很多，有了清单就有统一的标准，不会漏项。

4.问题不跟踪，走查的时候说得好好的，回头开发一忙就忘了，没人催着改，下次还犯同样的错，必须把问题和工单系统关联，跟踪到闭环为止。

5.走查的氛围不要太严肃，不要搞成批斗会，目标是提升代码质量，不是批评人，轻松的氛围下大家更愿意提问题，交流也更充分。

说白了，代码走查不是成本，是投资，花1个小时走查，可能帮你避免上线之后花100个小时救火。如果你手头有核心模块需要做走查，不确定怎么定范围、定清单，可以直接找我们柯信检测聊，可以根据项目实情帮你出一份针对性的走查方案。

标签：代码走查、安全测试报告