随着应用或者API被攻击利用已经越来越多，虽然来自开源组件的漏洞加剧了这一现象的发生，但是，其实主要还是在于应用程序或者API本身没有做好防范，根源在于源代码本身的质量没有严格把控。AST是指Application Security Testing，主要包括静态应用测试（SAST）、交互式应用测试（IAST）、动态应用测试（DAST）以及软件成分分析（SCA）等工具。
应用测试工具AST是专门用于检测源代码安全问题的工具，如何有效地将AST工具应用于开发过程中，也是一个比较有挑战的事情。
将AST工具集成在SDLC中自然是一个比较常用的好方法，可以在开发的过程中尽早地发现代码中的问题，及时解决，降低又问题带来的可能的攻击和损失。这也就是“安全左移”所说的“将安全尽早地应用开发过程的开始阶段，不仅仅是在后期测试才开始关注安全”，因为早发现的代价小，影响小，成本也最低。
“安全左移”概念很好，关键是要知道什么时候以及如何融入到SDLC过程中，AST启用的频率是多少。特别是敏捷开发和DevOps盛行的年代，SAST工具如何能够自动地集成到流程中至关重要。
根据Gartner的“How to Deploy and Perform Application Security Testing”建议将AST应用到开发阶段测试、发布前测试以及产品线测试。在产品开发和发布之前的开发过程中，在build pipeline之中发起SAST与SCA检测，在产品上线之前，使用IAST/DAST检测，在产品上线之后，可以使用DAST测试。这样可以保证应用在部署和使用过程中，是经过充分测试的。当然这里也并不是说非常严格地每一段只能做某个一测试，在发布之前，也可以启用SAST或者SCA看看发布的包的质量到底如何，作为是否可以发布的一个参考，效果会更好。有的产品可以扫描二进制文件，在产品上线之后，也可以定期扫描一下运行产品部署包的安全质量状态。
在开发过程中，如何有效地利用SAST和SCA也是一个挑战。使用IDE中的插件，在开发写代码时实时检测，可以在第一时间发现有问题的代码，及时修复，代价也最低。但是，当开发人员很多的时候，同时提交的代码比较多，而SAST和SCA的扫描又比较耗资源和时间，当请求超过SAST和SCA的服务器所能承受限度时，就会出现排队的现象，导致耗时比较长，影响开发效率，即使SAST支持增量开发，有时排队也会比较长。所以，扫描的频率太频繁，也未必是一件好事。
在发布前的测试，可以考虑内部安全团队使用IAST工具或者DAST工具测试，也可以考虑使用第三方的团队测试。工具方面，目前还没有什么特别好的自动化DAST，一般的DAST的测试时间会比较长，对于敏捷开发和DEVOPS而言，有点不适应。使用第三方团队的好处是他们可以从不同角度来分析系统，能够发现内部团队的盲点。虽然有自动化测试工具，这个阶段的测试可能更加依赖手工操作，由于发现的问题可能会影响产品的发布，需要建立一个处理严重安全问题的机制或者流程，保证在遇到严重的安全问题时，各方针对它的处理流程都没有异议。发布前的测试结果，需要设置一个安全阈值，当某级别的安全问题超过多少时，或者含有某个级别的安全问题时，是不允许发布的，如果紧急需要发布，这就需要一个批准流程，然后，需要考虑后期的如何及时打上补丁。安全阈值的设置很关键，必须放到产品的发布标准里，让每个团队都了解产品发布的标准。
产品上线之后的测试，就需要注意，因为毕竟产品线已经在运行，在使用DAST工具从监测时，有些测试用例会比较影响产品的正常运行，就需要界定范围哪些操作是不能做的，特别是注入问题像SQL注入，它有可能会篡改数据库中的数据，甚至可能删除数据库中的数据，导致DOS，现实中就曾有测试人员使用DAST自动化扫描客户的产品环境，导致产品环境被扫描挂了，最终项目没有完成，还赔了不少钱。但是，DAST工具可以检测像XSS这种攻击，一般都不会导致什么严重的问题。产品线上的测试就不能真刀实枪地进行，而是像武林高手比武一样，要点到为止，使用自动化工具时，就需要设置一下扫描的规则集，防止可能严重影响产品环境测试用例。测试时也需要关注在前期阶段已经发现的问题是否有可能再次出现。为了以防万一DAST工具会对产品环境造成影响，建议使用一般的账号进行DAST测试，而不是使用admin或者权限比较高的用户进行测试。由此可见，在产品上线之后，再想挖掘问题和修复问题，就需要小心谨慎，而且代价也大。
根据前期阶段测试发现的安全问题，进行总结，在结合产品运行环境的防护设备WAF、WAAP或者RASP，修订这些工具的规则，让他们可有效地识别前期测试发现的安全问题的类型并且及时阻止相关的攻击，可以更好地提高产品的防护能力。
由于现在大多数都是用云环境或者数据中心，而且使用微服务部署，一台机器可能部署多个服务。为了保证所有的产品和服务都在管理和监控的列表里，要有工具经常扫描环境中的资产，防止有些服务在没有经过严格的流程控制就直接部署到产品环境中去。
AST可以有效地提高应用程序自身的安全，不应该是独立的活动，应该很好地融入到开发流程之中，需要长期跟踪与改进，让它能够长期地高效地融入到流程。
对于一些没有办法将“安全左移的产品”，包括遗留系统和外包系统的处理也需要慎重，因为任何一个疏忽都可能被攻击者利用。遗留系统由于时间长久，使用的技术可能都是比较老的技术和语言，如果有源代码而且购买的SAST支持这种语言，可以优先考虑使用SAST工具先扫描看一下结果，了解产品的大概的安全状况。对于Web系统而言，需要针对防护设备WAF等针对遗留系统也要设置好规则，加强防护。对遗留系统而言，可能使用DAST就不太合适，因为遗留系统所能够承担的负载不够大，很容易导致DOS，影响系统正常使用。针对对外的系统或者接口，需要重点人工测试。
当有些组织和单位将开发外包时，因为在开发过程中无法确保AST能够比较严格地进行，就需要在验收阶段把好关卡。可以通过让开发公司提供相关的报告来说明产品的质量，也需要在验收时增加安全相关的测试指标，例如：使用SAST扫描发布的二进制包，看报告中的安全问题是否达到可接受的安全标准，这些都需要在外包时就把验收标准定好。对于购买的商业软件，也应该像外包软件一样对待。
工欲善其事必先利其器，要想推动AST，就必须要有合适的工具，自动化的工具关键的是如何误报率和漏报率的问题，误报率太高，会影响使用人对工具的使用积极性，漏报太多，又失去了使用工具的意义。自动化工具通常都是针对公共的框架或者开源组件进行定制，但是，针对组织内部使用的自定义的框架就不支持，这就需要工具能够支持自定义规则的功能，通过自定义的规则可以有效地降低误报和漏报。【关于如何选择SAST可以参考：】简单易懂是推动工具的重要前提，工具能够提供比较容易懂的说明与解决方案也很重要。为了让开发更容易理解安全问题的产生原理和如何修复，产品具备比较详细的修复指导方案与说明，就非常重要，有的产品指导文档比较难懂，就会导致用起来比较难，还需要人工准备相关材料进行培训。
AST发现问题之后，如何有效地推动问题的解决是一个不小的挑战。特别是在敏捷开发流行的时代，开发团队都有各自的项目的进度安排，当安全问题出现时，他们改如何应对？如果在开发阶段能够实时发现并解决，就不存在这个问题，但是，如果在产品后期发现或者上线之后才发现，开发已经在开发新的版本时已经有了日常的工安排就会有冲突，而且安全问题的推动也需要开发学习一个新的技能，那就是如何正确地解决问题？这就需要一个机制来保证安全问题的推进。我们曾经采用过的方案是：让每一个团队都有一个人专门对接安全问题，并且在组织内部定义好这个人的职责，提供相关培训，提高他的安全意识和知识。当一个项目有安全问题时，首先联系这个负责人，把问题的来龙去脉讲清楚，也提供相对应的解决方案供参考，让他在团队内部负责问题的推动与解决。此方案确实效果不错，但是，有一个问题就是在人员流动比较大的公司，这个角色的人员可能流动比较大，需要及时维护好这个数据列表，同时，新的人进来，要能够及时培训到位【关于培训，如果有在线培训资料，就可以很好地让新人自学，再加上定期的开会交流，就可以保证每个人的安全意识和知识，这有需要有人跟踪与推荐。】，才能有效地推进。当然以项目的方式在公司内部统一推动某一种漏洞类型的整改，也是可以尝试的，因为成立项目，就需要把每一个团队里抽掉一个人员参与这个项目，可以统一调研正确的解决方案，也可以及时沟通解决问题中遇到难题。
有时一个安全问题的解决，更是一个挑战，懂安全的人可能对产品的框架了解的不够，而开发人员针对安全又了解的不够彻底，因此一个问题的解决方案不能单纯地依赖一些已知的公共的解决方案，需要开发和安全人员一起共同协商解决方案。针对有些框架的问题可以统一解决的，安全团队和开发人员一起能够提供一个可以共同使用的库供所有团队使用那是最好。不过，需要找到愿意配合的开发人员，或者找到能力比较强的安全人员可以搞定这个库，这就对安全的人员要求比较高了，首先，安全知识必须过硬，充分与各个团队沟通，开发出来的库考虑到了一些可能；其次，必须有充足的开发知识，能够了解公司的二方库的开发与发布流程；最后，就是还需要各个团队沟通协商，推动库的使用以及后期问题跟踪与解决。
为了有效地解决问题，就需要AST工具能够具备bug跟踪系统集成的能力，当AST工具发现问题可以自动将问题提交到bug系统跟踪，开发只需要在bug系统一个地方跟踪所有问题，可以减少开发团队和安全团队之间的隔阂。当然，在提交到bug系统之前，需要确保误报的问题能够很好地解决，在提交之前有一个审查并且根据审查的结果改进扫描规则，可以帮助降低误报。例如，有些工具扫描之后，发现的问题处在一个初始状态，当经过人的审查之后，将安全问题改为确认状态，这时就可以将问题同步到Bug跟踪系统，解决误报的问题。自动化的脚本根据工具的SDK或者API将问题及时同步到Bug系统，就可以提高效率。
AST在研发过程中是必须要具备的，因为它可以达到以下几点目标：
- 减少在线运行产品的漏洞数量；
- 在产品早期发现问题，降低解决漏洞的成本和带来的风险；
最近，安全界又出现了Application Security Orchestration and Correlation（ASOC）工具，它是一个通过自动化工作流来简化漏洞的测试与修复，它结合多种源头的数据（SAST、IAST、DAST以及SCA等）来实现测试自动化。ASOC工具通过关联和分析发现的问题来集中并优先考虑使用什么补救措施，它充当了应用开发和安全测试工具之间的管理层，大大提高漏洞修复的效率。
有时为了能够主动发现产品上的安全问题，也可以启用漏洞奖励计划，发起众多安全爱好者帮助企业发现产品线上的问题。集思广益，固然可以发现众多问题。但是也要注意不同的人员的安全知识背景残差不齐，提交的漏洞质量也很多，需要有人及时过滤。有时一些比较严重的问题的发现可能比较耗时，可能有些人会尝试通过发现大量的低级别的漏洞来获得奖励。这种低级别的漏洞可能对系统不会造成什么直接的影响，但是数量一旦瞬间多了起来，内部团队的应急响应的负担就会重，反而可能会影响一些严重级别的漏洞响应时间。所以，在发布漏洞奖励计划时，最好能够划分一下大概的漏洞类型范围，针对漏洞的严重级别和对应的奖励有一个明确的定义，或者在某一个时间段，限定漏洞的类型，这样集中发现问题，统一来解决。由于参与测试漏洞奖励的人，可能会更多关注一些容易发现问题的接口和一些容易发现的漏洞类型（例如：XSS），因此，测试的覆盖范围没有办法保证，不能用漏洞奖励这种活动代替内部的安全测试，它只是一个补充而已。
总之，AST应该在开发阶段就充分利用来发现代码的安全问题并及时修复；在发布前的阶段可以根据前一阶段的结果进行有针对性地测试，最好使用不同的工具，这样可以发现不同的安全问题；在产品发布之后，需要关注的配置和使用的组件的漏洞，及时打上补丁。针对对外开放的应用无论是自研的还是购买的，必须要结合几种方法和工具深入检测，防止未经过测试的代码的系统就对外开放使用。
