功能模块剖析的1个隐藏假定是源代码功能模块以文件开展区划，因而事实上剖析1个功能模块便是剖析相应的源代码。功能模块剖析的环节通常便是从头至尾浏览1个源代码文件，并且不跟踪当中启用到的外界变量，也并不在意现在变量的引入状况，只将现在遇到的问题记下来。或许你可能会感觉这种对策较为野蛮，但事实上很多资深的代码审计技术人员都很喜欢这类方法。例如前Kali的某安全顾问在审计新的代码仓库时都是先使用该对策，寻找相近enable的软件目录并一行行浏览当中的胶水源代码，以对此项目的源代码设计风格建立基本掌握。

功能模块剖析的优势是迅速掌握APP的的源代码设计风格，针对高内聚力的功能模块剖析可以不摆脱文件，可以对功能模块内部完成有一个基本了解。但缺陷也很显著，这类统计分析方法较为费劲，并且在长期的不断剖析后人脑非常容易觉得疲惫；此外在审计环节中纪录全部的潜在性问题也是个繁杂的工作任务，在多个小时的纪录后难以有热情去再次坚持到底。因而，假如在实行此对策的环节中觉得神情恍惚的情况下，最好是先休息一下，或是转换到别的不那样焦虑的审计对策中。引入剖析和功能模块剖析相近，重要差别取决于大家对焦的是面向对象源代码中的类或是结构体完成。针对面向对象的语言而言，该审计对策比纯粹的功能模块剖析要更加高效率，由于通常目标自身是高内聚力的。与此同时该剖析环节也更不易造成审计环节中发生方向偏移。但是和功能模块剖析的优势一样，在审计环节中大家一样须要保证注意力集中，要不然也有可能会发生看错的状况。在对APP的系统开发和算法设计拥有充足的了解后，大家就可以挑选某些安全有关的计算方法并剖析其完成。这种审计对策的实效性取决于大家所选择计算方法的的关联性，因而须要在对审计目标有相应了解以后才能够明确什么是重要的计算方法和源代码。这种重要计算方法通常牵涉到APP安全模型的设计或是密码算法完成，例如网站APP中的sessionId完成计算方法或是APP开发人员自定的数据加密校检计算方法等。这一个类对策和以上的正面对策恰好反过来，重要从有可能造成漏洞的最底层源代码下手。这类对策通常会使用某些自动化技术分析工具做为辅助，随后反方向跟踪去认证漏洞的开启途径。特定一连串的敏感启用，反方向剖析这种启用是不是构成可使用的漏洞。最容易的方法是根据正则去特定敏感变量或是语句，根据文字搜索软件去搜索潜在性漏洞并开展认证。