为了发现软件的安全漏洞和缺陷，确保应用系统是安全可靠的，就需要针对Web系统做应用检测，识别Web应用程序中架构的薄弱环节，以免轻易的受到恶意攻击者的攻击。
主要市场上主要的检测技术主要是DAST、SAST、RAST和IAST，每种技术都有一定的优缺点。我们注意了解一下。
DAST是Dynamic Application Security Testing的首字母缩写，是动态应用程序安全测试技术。该种分析技术在测试或运行阶段分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击，分析应用程序的反应，从而确定该Web应用是否易受攻击。所以该种技术主要采用渗透测试，发现应用系统的潜在风险。
SAST是Static Application Security Testing的首字母缩写，是静态应用安全测试技术。SAST类工具的技术实践大致可分为以下几种：
（1） 正则匹配：代表工具Cobra，Raptor；
（2） 基于语法树:代表工具P3C,Fireline；
（3） java语言可基于class文件:代表工具Findsecbugs；
（4） 基于控制流、数据流、函数调用关系等:市面上的商业级SAST类产品比较多。
当然，效果是逐渐递增的，难度也是逐渐增大的，
要实现还原代码的数据流、控制流和函数调用关系，需要将编译中的前端模块完全实现一遍，基于中间代码去还原数据流和控制流等，大致流程主要是通过词法和语法分析后，进行语义分析，生成中间代码，再生成数据流、控制流、函数调用关系等，在这些分析的基础上，进行缺陷匹配检测。
词法分析和语法分析一般可以借鉴相应的开源工具可以完成，但是语义分析依赖于各种语言的语法，针对每种语言一般需要单独实现，不同的语言翻译成同一套规范的中间代码，根据翻译来的中间代码，符号表等来恢复数据流、控制流和函数调用关系等，然后根据这些流来确定污点传播过程，进而确认是否存在漏洞。
基于SAST技术的产品具有误报率高、耗时长、内存消耗高的特点，该原因也跟这个复杂流程相关，各个安全厂商自己基于编译原理相关内容实现的代码分析层，也需要针对不同的语言实现不同的语法树从而增加了复杂度和时间成本。另外
还原的数据流、控制流等难以做到100%准确，同时对超过100万行以上代码分析，暂用的资源高（主要是对内存的消耗），复杂度较高，数据流、控制流的构建过程自然就耗时长，导致了SAST类产品误报率高和耗时长这两个问题难以解决。导致即使能够集成到IDE中，开发人员也可能无法忍受较长时间的等待。
IAST：Interactive Application Security Testing，交互式应用安全测试。
近实时检测、误报率极低、可定位到代码行数、展示污点调用过程等等，非常适用于DevOps理念。产品中也会尽力体现污点调用过程，代码行数等不同于DAST的，偏代码层的信息，。
为代码审核员和审查员提供了一个平台，用于构建和调整强大的、高度定制的查询，以交互询问其独特的代码库和环境。
具有更复杂代码探索需求的分析师可以利用全面的CPG图形映射创建高度特定和有针对性的查询，从而绕过常见的误报源。示例包括识别代码中存在的任何问题（用户输入受到适当保护）的能力，以及存在任何间接数据流（用户输入未直接用于接收器）的能力。
RASP：Runtime application Security Testing，运行时应用安全测试。
很多企业在上线前进行漏洞检测，都要求解决高中危漏洞，在业务紧急上线的情况下，低危漏洞往往可以选择性的忽略，一般会经过评审，各个负责人签字等流程，DevOps因为强调速度，这种情况则更多，但是作为一个安全人员或者项目经理，忽略这些低危漏洞真的放心吗？攻击者可能不会通过这些低危漏洞来直接攻击业务，但是往往成为攻击链中的一环，获取某些敏感信息等，那RASP的作用就是在运维阶段，继续针对性的保护那些被忽略的低危漏洞。
每种技术都有自身的优缺点，只有适合自己的工具就是最好的工具。
