软件测试体系之安全测试工具集成方案_安全开发平台与devops平台集成

DevOps这个概念大家都早已不陌生，该开发模型为企业带来了敏捷的开发效率，帮助企业应对越来越复杂的软件和越来越快的发布频率。但是在这个过程中，安全问题也日益凸显。本文我们跟大家分享一套方案，将安全测试工具集成到DevOps中，也就是现在流行的DevSecOps。 

DevSecOps这个概念在近两年非常流行，下面我们先一起来看一下加入安全之后我们会面临哪些困难和挑战？

首先我接触的大部分企业都是在开发周期的最后阶段才开始考虑做应用安全测试和防护。在开发阶段首先是考虑功能怎么实现，业务优先，第二会考虑性能，功能和性能都没问题后，才会考虑安全性的问题，就已经太晚了。

很多企业是这样想的，到最后会有渗透测试，渗透测试做完就没有问题了。这是远远不够的，首先，渗透测试不是那么全面，其次，放在最后做，发现问题后，可能就已经来不及修复了。马上要上线，很少有企业会因为漏洞而推迟上线时间。如果修复的不够及时，不够迅速，可能在修复的期间内就已经被利用了。所以说尽早发现问题是非常重要的，这也是我们DevSecOps最核心的理念。一个是要把安全嵌入到整个软件开发生命周期中，每个环节都要嵌。第二，安全左移，把安全的理念左移到开发人员。

在大部分企业中，安全相关的人员占的比重很小，除此之外还有一个现状，安全团队更多的是网络安全专家，对于编程和应用开发并不是非常懂。我们的开发人员往往对安全的知识也不太了解，对安全开发和安全知识的储备不足。这样就导致了开发人员写的代码可能存在很多安全问题。到了安全团队那里，会发现这些问题他们根本解决不了，就产生了一个鸿沟。

所以我们的DevSecOps的核心思想就是把安全左移，把安全的重心放在开发阶段。在DevSecOps核心理念中，一定要把安全工作移到开发阶段，最好能够移到需求分析阶段。让我们的开发团队、开发部门能够承担安全的责任和工作。企业的应用安全工作不应该是完全由安全团队来负责的，一定是由开发和测试团队共同承担企业的应用安全职责。这就是DevSecOps的核心理念，开发团队不但要承担功能的实现，安全性也要保障。

第二点是，企业普遍认为做安全扫描需要太多的时间。不光是扫描应用本身，还要扫一些端口、数据库、系统等等。想进行更为全面的扫描，可能会花很多的时间，企业往往会有这样的顾虑。
第三点，当问题发生时，我们安全团队在找问题的时候，往往会发现，真正的问题并不是网络层面，而是来自于我们的应用本身，一部分是应用的业务层的源代码，还有一部分是代码依赖的一些底层的开源组件。最后发现，问题其实是来自于开发人员，但是背锅的却是安全人员。

所以很多时候，我们的开发人员发现问题比预期要晚得多，往往是到最后阶段才知道代码存在问题，然后再去定位、修复、再去发布应用，这样就会耽搁很多时间。所以我们提倡一定要尽早发现问题，在开发阶段就开始规范化我们的安全编码，尽早去做安全测试。

其实随着自动化工具的部署，扫描时间越来越短。之前可能需要人工去进行审计检查，有了自动化的工具之后，扫描时间的趋势是越来越短了。对扫描后的结果和漏洞分析需要的时间可能越来越多了，需要去判断分析，是不是真的有危险？需不需要改？怎么改？这个很重要。这一点是我认为目前企业遇到的最大的困难和挑战。

我们部署了很多的自动化测试工具之后，针对测试的结果需要花费很多精力，对分析的人员也有很高的要求。既要懂软件开发的知识，又要懂安全，还要懂整个的业务场景。根据需求才能够去判断针对扫描后的结果要不要改，怎么改。

以上这些就是我们目前面临的困难和挑战，我们做好DevSecOps也是为了解决这些困难和挑战。通过跟大家分享一些好的实践方法，从流程和工具角度去给到大家一些建议。保障企业的业务系统能够平稳安全地运行。

工具和流程都是指技术层面的。在技术层面，我认为目前最重要的三个目标和方向就是集成，自动化和敏捷。做好应用安全，做好DevSecOps，在技术层面最重要的就是这三点。

首先是集成。一个应用的诞生是非常不容易的，整个生命周期是非常复杂的一个过程。其中涉及到很多开发的工具链、测试的工具链。我们也称之为SDLC，工具链非常多，在这些工具链中，我们都应该将应用安全嵌入进去，做好集成这点很重要。

再就是自动化。尽量去提高效率，减少人为的工作量。通过无感知的方式去完成我们的测试，不需要投入太多的人力和时间。比如说通过一个命令脚本，在下班的时候开启一个自动化扫描任务，第二天一上班测试完成了，我们开始去分析结果就可以了。我们的触发条件不只是特定的时间，也可以是比如说我们有一个新的变更、有一个新的版本要发布，就触发新一轮的测试，通过自动化的方式去测试。

最后一点是敏捷。我们提倡敏捷开发、敏捷测试，敏捷的含义不光是测试的效果，不光是指快速地测完，这只是一个方面。我们更多的是提倡能够把测试的结果非常敏捷、快速地提交给开发人员，开发人员能够很快地看到这个测试结果，而且通过这个报告分析结果，能够快速地修复。最根本的目的是把它修复掉，这是敏捷的价值。

下面我们从实践的角度去跟大家进行探讨。一个企业如果想做好业务安全的测试和防护应该怎么做？最佳实践是什么？最完美的是三步走，分三个阶段。这三个阶段要循序渐进，不可能一下子实现。

第一步，在业务系统上线前，在源代码编写阶段和测试阶段进行安全检测，在源头上识别并控制软件的风险。安全测试一定是必要的。哪怕我们只做黑盒测试、动态分析。当然最好的实践是在开发阶段就已经开始做基于代码的安全测试。

然后到了第二步，光做安全测试肯定还是不够的，我们是希望把安全的基因部署到我们整个生命周期里。比如说最开始的需求分析，这个时候还没有工具去测，因为还没有开始软件开发。这个时候就开始考虑到安全，是不是有一些安全的功能，在设计阶段就可以将一些基于安全的具体的功能涉及到我们的应用开发中，做一些威胁建模。

到了开发阶段就可以有一些自动化的工具包供我们去测试了。这个阶段，工具就很重要了。工具是集中了业界最顶尖的专家团队，总结了全球的安全知识库，可以帮助我们非常高效、全面地进行测试。从开发阶段到测试阶段，不管是黑盒、白盒、灰盒，都有自动化的工具可以帮助我们。

到第三步，我们光上线之前做好了还不够，上线之后还有可能被威胁。发布的时候已经保证这个应用很安全了，可能还有一些风险是在生产环境下进行的攻击，这个时候还需要监控，实时防护生产环境下的应用。这样才形成了我们整个安全的SDLC。

以上是我跟大家分享的一个最佳实践的思路，接下来我们就为大家讲一些具体的流程和方案。

首先我们讲一下，整个软件开发生命周期如何做好端对端的应用安全。我们先讲几个应用安全业界主流技术，首先是大家都比较熟悉的静态代码分析SAST，还有一个是DAST——动态应用安全测试，还有IAST，交互式的应用安全测试。我们通俗来说也就是白盒测试、黑盒测试、灰盒测试，涵盖了安全测试的三个方向。

现在还有一个方向叫RAST，实时防御监控，runtime 也就是实时的应用自我防御，它的主要特点就是自我防御。我们做安全的可能都了解WAF，应用防火墙，它毕竟还是一个网络边界的产物。比如说我们疫情期间，穿防护服就是一个WAF防护，但是最根本的还是打疫苗，RAST就相当于打疫苗。

我们的应用本身被植入了一些代码，在程序的出口和入口进行插桩，让我们的应用本身具备防御能力，这个技术在这几年还是比较流行的，大家还是比较关注的。

这些就是我们应用安全测试主流的防御技术。针对这些技术，业界也有很多相应的工具产品，能够涵盖这里面所有工具的品牌还是非常少的，Miro Focus就是其中之一，它的产品覆盖了整个生命周期，有相关的解决方案。

我们做应用安全首先是要测试、分析，可视化非常重要，就是能够把所有的测试结果能够统一地展现出来。我们的各类测试会产生很多的测试数据、测试结果、监控数据，这些漏洞信息需要有一个统一的、可视化的平台做展现，这也是非常重要的。

因为我们所有的黑盒测试、白盒测试、灰盒测试都是有相关联性的。这也是为什么我建议，由一个厂商提供所有的产品是最好的，就是因为不同阶段的测试工具产生的测试结果都是针对同一个应用，有很强的关联性，需要有一个统一的视图把所有的不同阶段的测试的结果和关联性进行统一的展现。也就是需要软件安全中心这样的概念。

前面我们讲到过DevSecOps在技术方面的一个关键点是集成，就会涉及到我们开发生命周期的工具链，我们上图中列出的还不是全部，大家都知道涉及到的工具链太多了。仅仅是开发工具，主流的就有好几种，最主流的像eclipse、Visual Studio、IntelliJ IDEA。开发完成后，就到了代码管理环节，常见的像GitLab、GitHub、Bitbucket。还有构建用的Maven、Gradle等等。再就是CI/CD持续发布、持续集成，最常见的是Jenkins，很多平台都是基于Jenkins开发的。

测试完成之后，要跟踪缺陷，还会用到Jira、Bugzilla这些工具。还有一些针对开源组件的测试平台，以上这些都是我们会用到的工具链。

我们在开发的过程中，通过工具的应用、一些在线的培训都能够帮助我们开发人员丰富安全编码的知识、具备安全编码的能力。在这些工具链中，都可以将安全测试嵌入进去。

以IDE为例，IDE本来是个开发者平台，我们可不可以边开发边做安全测试呢？是可以的，在开发的同时就可以保证代码的安全性。我认为，安全左移，其实就是移到了开发人员的IDE上，这也是左移最重要的一个体现了。

那我们在CI/CD的时候，是不是可以同步把代码也测了呢？我们在构建build的时候可以同时把代码做一个安全测试吗？都是可以的，都可以集成进去。同时，安全问题也是bug，也可以通过Bugzilla这些工具去管理，而不仅仅是管理功能缺陷。

上面这个图就是我们今天重点要跟大家分享的一个DevSecOps最佳实践的流程图，也就是如何把应用安全很好地嵌入到我们的整个流程里面去。

首先，在开发的这个闭环中，开发人员在IDE开发代码的同时，我们就可以将应用安全测试嵌到开发工具里。具体例子，比如说我们在eclipse上，通过安全工具的插件，把安全审计的功能嵌入进去。

IDE里就多了一些菜单和选项，能够让我们在开发的时候就可以做相应的安全的检查。这样的检查是自查，这时候开发人员并没有提交代码。

当然这里也涉及到企业文化，比如开发人员说“我没空去做检查，我的职责是实现软件功能，我可能没有时间和精力去做安全测试”。这时候应该怎么办呢？我们还有一些插件是可以实时检测的，就是每写一行，就同步告诉你，你写的这一行有没有安全问题。

不需要开发人员再花时间去做安全测试，而是实时地去检查代码。我们可以称之为“安全小助手”，帮助我们做代码的检查。当然最好还是做全面的检查，去做安全测试，当然要花一些时间，比如可能我们需要在下班的时候开启一个扫描，第二天上班的时候再去看扫描结果。

代码提交到仓库之后，这个时候，我们需要通过Jenkins去做CI/CD了，在这个时候去做安全测试也是非常好的。因为这个时候我们已经形成一个版本了，模块也已经完成了，可以把完整的项目代码拉出来，做一个完整的、全面的安全扫描测试。

这一部分在我们的用户实践里面是最广泛的，比开发人员自查自检要广泛。因为很难保障开发人员自己去检查自己的问题，因为没有一个机制强迫开发人员去做这个事情。但是在CI/CD阶段，流程里肯定是要加这个环节，这是必须要做的一件事情。

测试完成之后，我们的测试结果要自动传到可视化的漏洞安全管理平台上去，我们需要将测试结果可视化，而且需要很方便就可以看到。而且也可以通过专门的相关的人员，如审计员，去把这些测试结果里面确定的bug，提交到Jira这类缺陷管理平台里面，做跟踪和管理。直到开发人员把这些问题修复掉，bug关掉了就算结束了。

我们在下一轮再去做扫描，验证是不是已经被修复了，再做一次测试。而且这种上线之前的自动化测试不仅仅是针对源代码的安全测试，还可以模拟黑客，对web应用做漏洞扫描。

这一点也是目前比较新的理念，大家对黑盒测试的理解往往是上线之前最后阶段才测，但是我们建议在CI/CD阶段应用发布的时候就可以去做一次模拟黑客的web漏洞扫描了，这是可以做到的。我们后面也会讲到，黑盒测试是可以再左移到CI/CD阶段的。

然后在问题修复完成之后，才能保证上线。上线之后，在生产环境中，我们的安全防护也是必不可少。当然，我们现在更多的是部署WAF、web应用防火墙这种边界的防御。但是未来的大方向我觉得还是RAST技术，应用的自我防御。因为WAF产品毕竟是网络边界产品，有很多威胁防御不了、发现不了。从应用本身内部去发现和监控问题，这一定是未来一个大的方向和趋势。

所以在上线后的阶段，我们需要部署一些工具，去实时监控、防御，在生产环境下运行的应用。以上就是我们整个DevSecOps的流程。下面针对各个环节中需要用到的业界比较先进的一些工具为大家进行一下介绍。

首先为大家介绍的是静态代码分析工具，静态代码测试是很重要的，做应用安全最佳的切入点就是在开发阶段做代码的静态应用安全测试分析。这里给大家主要推荐的是Fortify，这是业界做应用安全测试最早的产品，甚至可以称之为应用安全测试工具的“鼻祖”，这款工具在应用安全领域一直是处于引领地位的。

我们推荐这个工具的首要原因是，它覆盖的语言多，因为我们的企业级应用可能会用到很多的开发语言。现在开发语言的种类越来越多，常见的是Java类的，还有一些其他的小众语言，也在逐渐被普遍应用。

像现在比较流行的Go语言、Kotlin，以及一些脚本语言。我们前面也谈到了，移动应用现在发展得很迅猛，像苹果的开发语言Objective C、Swift。这么多的新兴开发语言就需要我们的自动化工具涵盖更多的开发语言。

除了语言覆盖广，更关键的还是要检测到更全面的安全漏洞和代码缺陷。还有就是漏报率和误报率，也很重要。这几个维度都是很重要的。

最后才是效率，虽然效率也很重要，但是比起精准性来说，我认为精准性更为重要，因为安全不能够有漏报。误报可以解决，但是漏报没有发现，没有办法解决，这个危害就很大。

测完之后你并不知道有些漏洞还没有被发现，还隐藏在你的程序里面，一旦被利用，后果不堪设想。所以我们追求的理念是零漏报，当然是非常难做到的，我们之后尽量地减少漏报。

误报我们可以通过一些手段去解决，去调优规则库、调优规则和策略，来减少误报。大家在选择产品的时候，一定要选择规则库更为全面的产品。

应用安全测试最关键的一点就是修复，发现问题可以精准的定位，能够迅速修复掉，这是最关键的。

首先漏洞的定位是很重要的，一定要准确，可以准确地告诉你是这里有问题，什么问题？怎么改？级别高不高？作为一个自动化工具来说，这些要素是缺一不可的。

我们要了解漏洞的严重程度有多高，中低风险的我们可以暂不修改，因为我们的精力有限，所以需要要将精力放在风险最高的问题上，所以我们需要一个非常清晰的风险级别的划分。

还有就是定位一定要准确，最后是需要一个非常详细的修改建议，照着这个修改建议去修改是最安全的、最标准的。如果工具给到我们的建议很模糊、不够明确，我们的开发人员可能还是不知道应该怎么修改这个问题，因为他们可能并不是那么了解安全编码。

漏洞知识库也非常重要，大家如果感兴趣可以去登陆（https://vulncat.fortify.com/zh-cn）这个网址，这个是我个人认为业界最强的软件安全漏洞的知识库。这里面涵盖了我们业界关于代码编写缺陷的最完整的内容。

《软件开发七宗罪》这是很多年前非常畅销的一本书，他把软件开发缺陷分了七个大类。安全是比较主要的一个大类，还有其他的，像代码质量、环境问题等等。

这个知识库的分类非常好，可以按照大类去分，也可以按照开发语言去分。fortify现在已经支持28种语言，这个知识库把属于每一种语言的漏洞的种类都列了出来，而且还是全中文分析。大家如果对安全编码、应用安全漏洞方面感兴趣的话，可以登陆这个网址，去了解我们业界最新的、最权威的、最全面的关于代码开发编写的漏洞知识库。

我们做代码安全编程是希望无感知地实施，我自己作为程序员深有体会，我自己本身并不想做额外的工作。我的目的就是把功能实现，如果还花时间去做安全测试，没有时间，没有精力。仅仅是实现功能都需要加班，怎么可能还有时间去做安全测试呢。测完了我还要去看问题，还要判断，还要分析，还要去改，需要花费太多的时间了。

这里再给大家推荐一个插件，叫安全小助手，嵌入到开发人员的IDE上，只要他完成了一段代码，或者一行代码，就会马上得到一个风险提示。这个提示是在IDE界面上就直接提示，不需要点任何按钮，也不需要等待。我们还有一些在线的培训，帮助开发人员去了解安全编码的规范。

还有一个很重要的方面是第三方开源组件的测试，像前段时间的Log4J，还有前两年的“心脏出血”之类的事件都属于开源组件的问题。做Java开发写log基本上都要用到这个组件，这些组件的问题其实都不是业务层面程序员的代码出现了问题，而是底层出现了问题。

所以我们不但要保证开发人员写的代码是安全的，同时还要保证代码依赖的、引用的开源组件也是安全的。所以我们的安全测试需要全面，代码扫描不只是扫描本身编写的代码，代码依赖的底层的依赖库、公共库也要保证安全。

这里我们推荐的Sonatype工具，可以帮助我们很好地发现公共的开源组件的问题，而且还可以跟Fortify相结合，既扫源代码，又扫依赖库，这样才是最全面的。

我们前面还讲了黑盒测试，它跟白盒测试是非常不一样的。黑盒测试的对象不是源代码，是一个网页。模拟黑客对网页或web应用做漏洞扫描，无关开发语言、服务器，黑盒测试并不知道里面是什么技术。只是模拟黑客对应用本身做漏洞扫描，发现一些容易被利用的高风险的问题。

在靠近上线的时候，黑盒测试非常重要，我们想验证前期的代码测试是不是有效果，是不是已经把一些高风险的问题修复掉了。

给大家推荐的黑盒测试工具WebInspect的界面如上图所示，它的原理是爬网。我们每个网站的主页都有很多链接，WebInspect通过爬取网站所有链接的url，然后再把这些爬取的url，用测试用例去发起请求。

这个发起请求的过程就很类似于黑客发请求的过程，不断对被测试的web应用的服务器发起大量的请求。然后通过请求返回的页面去分析有没有一些容易被利用的安全隐患和风险。

这就是黑盒测试工具的原理和特点，和白盒测试是很不一样的。它们分别应用于不同的阶段，一个是在开发阶段，一个主要在测试阶段。第二个是他们的技术原理和关注的问题也不一样。我个人认为，白盒测试和黑盒测试是相辅相成的，相互补充、缺一不可的。

白盒测试并不能解决所有的问题，一些协议的问题、应用服务器的问题等，靠代码扫描是测不出来的。并且针对代码问题的修复，也不可能是完全修复掉，很多时候可能只是修复了一些高风险的漏洞。

但是有一些是中低风险的，危害也不小，可能我们会疏漏了，就需要黑盒测试来查漏补缺。现在还有一种灰盒测试，把黑盒测试更加精细化了，测试的维度更加深了。

黑盒测试往往是在项目已经完成后才开始做，这个时候往往已经有些晚了，我们最佳实践的建议是左移，将黑盒测试左移到应用发布的时候。在应用打包发布到应用服务器上面的时候，发布完之后，我们的代码已经可以可视化了，变成网页了，可以通过浏览器去查看了。

这个时候我们通过Jenkins这类工具去调用黑盒的web漏洞扫描工具，去完成自动化的扫描测试。一旦发布到Tomcat后，我们就触发扫描的命令，自动触发黑盒扫描，发现问题后将结果传给软件安全中心，查看结果，分发bug，直到修复。这个时候我们会发现，黑盒测试也可以跟CI/CD集成。

最后我们讲一下软件安全中心的重要性。工具的本身是负责测试的，这些测试是针对某一个特定项目的测试结果，我们要做好整体的视图，把不同的工具、不同阶段的测试结果由一个统一的安全管控平台做可视化的展现。

没有绝对的安全，安全做得再好，也不能解决100%的问题，但是我们要做好安全的“可知”、“可视”、“可管”。

“可知”指我们测试完之后，发现了一些问题，知道问题在哪儿，漏洞在什么地方，在代码的哪一行，该怎么改。

“可知”还不够，还要“可视”，需要有一个可视化的平台，统一地去做展现。比如说领导层，他并不关注漏洞的代码怎么改，他想看到的是整体的安全状况。哪些漏洞在企业中存在最多，哪个项目问题最多，哪个项目组问题最多等等。对于程序员来说，想看到的点就是微观层面了，自己负责的代码有没有什么问题，问题在哪里，怎么改。“可知”、“可视”之后，才能够“可管”，我们才能够很好地去管理企业的应用。