通常开发设计的研发是先实现顶层设计和日期表，随后再分功能模块去实现具体源代码实现。但对于安全审计来讲这一研发可以相反，即实现具体实现的解析后再反方向推断总体的的设计理念，随后按照这一推断的思路去寻找某些不曾碰触的模块实现。假如愿意对目标系统有更加深层次的了解，那样该审计对策是一个很好的选择；但与此同时这也表明该方式 的审计速度不易太快，由于通常咱们是以实现细节开始反向复原出初始的设计构架。

值得一提的是，通常咱们只须要对某些关键功能模块实现反方向建模，例如运用的安全分系统、键入过滤功能模块或是别的普遍采用的关键模块等。在建模的研发中，咱们其实是把自己放到开发人员或是系统架构师的地方去慎重考虑功能模块的设计，因而这也是根据具体源代码去发掘逻辑漏洞的最好对策。

在应对大中型源代码时，咱们的脑子几乎不太可能一次性地把全部运用构造消化吸收掉，因而就须要实现减枝。具体方法便是先是审计源代码作出某些猜想的假定，随后在具体检测中认证这种假定。无论假定是不是恰当，能否都能根据检测去加重自已对该系统的了解和认知。该审计对策的目标是以源代码实现去复原开发人员或是安全系统架构师预置的安全边界，进而对复原后安全边界实现深化审计，搭建具体攻击的危害实体模型。1个具体的方式 是根据搜集整理源代码中的安全校检有关源代码片段实现纪录，随后对这种对于安全边界的查验实现收集整理，最终总结出初始的安全等级区划。这种初始的安全验证是咱们对运用安全边界建模的重要信息来源，该对策的优点是可以使我们致力于安全有关的源代码地区，而且搭建更加完整的设计构架。如果我们手上有目标运用的设计文档或是标准指南，那样1个形象化的审计对策便是根据比照标准和实现源代码来查找当中的未声明情形或是矛盾之处。尽管绝大多数情况下咱们并没有那样完整的文本文档，但一样可以采用该对策来发觉某些设计实现中的漏洞。根据重点关注源代码实现中的黑色地带，换句话说某些条件支系的临界值解决，咱们还可以大概推断什么是文本文档中所未声明的情形。简单来讲，咱们的目标是先推断和复原目标功能模块的首要功能和常规情形，随后再对于当中的临界值情况实现重点审计。