前边早已讲解了源代码安全审计普遍的一点对策，适用于为代码审计给予大概的发展战略方位。这节首要讲解一点详细代码审计工作上使用的小窍门，做为以上代码审计对策的填补。在审计某一功能模块源代码时，我们可以利用跟踪数据流分析或是跟踪控制流的形式去阅读文章，那样那类方式比较好呢？回答是既不关注数据流分析都不关注控制流，反而是只关注本功能模块的实现。由于很多年的实践经验告知咱们，灵力是影响代码审计工作效率的重要缘故，而在不同功能模块中往返跳转通常产生了精神实质的耗费。例如在一些繁杂的项目源代码中，搜索某一变量的实现会一次又一次点开新文件，进而一次又一次涌出须要处理的新问题，在连续不断跟踪的环节中，通常会迷失自我在遗忘的大海中，进而忘记了原先的审计工作。

假如的确要打破沙锅问到底，那样也提议在审计记录上先做一个标识，等实现现阶段功能模块的审计后再对它进行详细分析。

旧地重游

佛洛依德曾经讲过，重要的书都应当连续读2遍。由于第二次读的情况下，你早已了解结果了，那样才能够真真正正了解开始。另个缘故是第二次阅读文章时，你拥有不同的心态，很有可能会从另一种视角对待问题。

代码审计亦是如此，通常针对这段源代码咱们通常须要阅读文章多次才能够找出当中全部种类的漏洞。例如在头遍审计中，很有可能首要关注整数金额外溢、代码优化或是格式化字符串数组有关的安全漏洞；而第二次的审计则首要关注功能性的实现，例如传参定期检查一点易于了解错误的API接口启用(如strncpy、strlcpy)；三遍则首要关注进程间不确定性的同步、竞争问题或是TOCTOU的资源浏览管控，……各抒已见。

没有一个规范说针对某一段源代码应当审计阅读文章是多少遍，详细情况须要依据源代码详细的运转前后文开展判定，例如针对单核源代码就不用关注多线程同步问题了。可是不管怎样，针对重要源代码最少也需要阅读文章2次，由于假如只看1次过得话非常容易忽略重要的源代码相对路径。