如何有效地运用SAST

如何有效地运用SAST

Henry Petroski曾经说过：要构建一套健壮的系统，就必须要明白这个系统可能会怎样失效。错误是不可避免的，但要有有效的措施来控制错误的发生。虽然精确地控制错误的发生不太可能，但是，也可以控制错误发生的可能性。同样针对安全而言，也不可能精确地控制所有安全问题的发生，但是，也可以通过人工或者工具控制错误发生的可能性。特别是对某些类型的安全问题，例如：注入问题、加密算法问题、硬编码密码等问题，还是可以通过SAST工具有效地去挖掘的。也就是说，通过SAST可以于充分挖掘一些可能导致安全问题的漏洞类型的。

传统的瀑布式开发，开发的周期相对比较长，在开发流程的每个阶段加入一些安全方面的控制，就相对比较容易一些，研发人员也愿意配合。但是，随着敏捷开发和DevOps等快速开发流程的流行，在每个版本的开发周期比较短的情况下，如何将工具有效地融入流程是一个挑战，否则，工具所能发挥的作用就会大打折扣。

如何将SAST工具有效地融入到开发流程中呢？ 下面就从选型到最后的实施的几个方面来聊一下如何选择和使用SAST。

第一、工欲善其事必先利其器，在工具选型时，就需要特别注意，如何选择有效的工具【可以参考另外一篇博客：https://blog.csdn.net/jimmyleeee/article/details/123953757】。在选型的过程中，需要预先设计好所关注的工具的哪些指标？例如：支持的语言和框架、误报率、自己使用了哪些工具需要和它集成等。

在设置好这些标准之后，需要根据产品的特征选择一些公司内部的有代表性的产品，代码量也需要有一定的数量，例如：10万以上，同时也可以选择几个最大的项目以便用于测试性能。这里选择项目时，需要注意，像业界的比较流行的开源漏洞测试项目尽量要避免，因为SAST工具在研发的过程中测试时，一般都会选择这种典型的漏洞测试项目来测试并且进行结果修正，所以，一般测试的结果都会很好。选择项目时，需要根据公司内使用的比较多的框架，在这些框架的基础上，选择比较典型的项目，每种类型都要选择2-3个，例如：典型的web应用和微服务项目等。这样就可以根据不同的项目的类型来测试SAST工具的扫描效果。

在检测的内容方面也需要验证工具是否能够满足需求，有的工具可以检测到源代码中是否有敏感信息（电话、邮件或者静态IP），有的工具可能就不支持，有的工具提供自定义规则功能，就需要自己定义规则来拓展。

有的工具支持扫描二进制代码，有的工具只能扫描源代码，【可以参考另外一篇博客https://blog.csdn.net/jimmyleeee/article/details/122689163】，需要根据已有的代码格式来选择供应商。如果有些系统是第三方开发的，自己没有源代码，选择工具时，就需要考虑支持扫描二进制代码的工具，这样就可以在验收时通过工具扫描交付的系统的二进制包来判断要交付系统的大概的安全状况是否满足交付的需求，是否有明显的严重的安全隐患。

随着开源软件的使用，第三方库的漏洞造成的影响也越来越大，例如：Log4j核弹级漏洞和OpenSSL滴血漏洞等，有效地挖掘含有漏洞的第三方库也非常重要。如果一个厂商能够提供SAST和SCA，并且能够使用统一一个入口，就比使用两个系统和两套认证体系容易使用，而且，两个系统打包在一起也会比单独购买两套系统成本更低。

第二、误报的问题处理，在推SAST的过程中，最大的阻碍就是误报率，当一个扫描报告呈现到开发人员面前，看到了很多问题，其中很多是误报，就会感到很沮丧甚至是愤怒，觉得这纯粹是在浪费他/她的时间，进而导致开发人员可能不配合。在实际的应用中，曾经遇到过购买了SAST却没有充分使用的案例也常有。因此，如何有效地降低误报就很重要，降低误报的方法有多种，一是，支持批处理，可以一次处理很多类似的误报；二是，可以根据产品的架构修改扫描规则，这就对操作人员有很高的要求，不仅需要了解漏洞的原理，还需要了解SAST产品如何定义规则；三是，SAST有自动学习功能，可以根据已标误报的漏洞的数据，通过机器学习，能够自动识别其他类似的误报，虽然已经有这方面的产品出来了，不过，做的比较好的产品还没有；再者，就是在报告发布之前，通过安全专家先审计一番，进行一次过滤。总之，无论采用哪一种方法或者类型的工具，误报问题的解决是顺利推动工具的前提。

第三、与已有工具的集成，并且实现自动化。为了有效地利用SAST工具，就需要将SAST融入到构建流程或者开发工具中，这就需要SAST提供很好的集成支持，无论是SDK、API还是CLI工具，需要根据已有的工具提供的支持方式，选择可以与已有工具有效地集成在一起的，并且能够实现扫描的自动化，并且根据工具的扫描结果设置一个阈值，控制构建的流程。

而工具的扫描结果再问题确认后，如何能够及时跟踪与解决是一个挑战。一种方法是将扫描的结果发给开发人员，让开发人员根据扫描报告逐个确认并且解决，这种方法需要研发人员配合才可以，否则，需要有人员去跟踪和推动。另外一种方法，就是自动报成安全类型的bug，让开发根据bug的处理流程来处理，由于每个bug的解决都是独立的，很难统一跟踪和了解某种各类型的bug的安全处理。还有就是根据漏洞问题的数量的多少，如果比较多的话，可以成立一个项目进行跟踪，好处是可以统一思想，统一解决方案，统一跟踪，难点是如何协调各个相关的组能够步调一致地根据项目的进程来处理问题。

无论用什么方法，如何及时处理Bug是一个问题，毕竟，在项目最开始扫描的时候，问题是很多的，有可能扫描出来的问题，在某次开发改动代码时改掉了【例如：相关代码被删除】，然后，当开发再去根据Bug来修复问题时，就会发现问题不存在，这是就容易产生一定的冲突。在解决此类问题时，我们就曾经使用过自动化处理的方法，大概的处理流程如下：

 自动化处理脚本相当于一座架在SAST和Bug系统之间的桥梁，自动化脚本定时调用SAST的SDK或者API获取最新的扫描结果，针对某种漏洞类型的确认的安全问题在Bug系统又没有对应漏洞的，直接报Bug处理，同时记录下当前的漏洞和Bug的对应关系。当之前扫描的问题，问题可能被修复，在此次扫描的报告中不存在时，就自动将Bug系统对应的Bug的状态改为关闭状态。如果漏洞的状态不是确认状态，例如：因为代码改动之后，当前的漏洞不是问题了，被标为误报，而且Bug系统有对应的Bug，也直接将Bug系统的Bug关掉。

通过这种自动化的操作，可以在代码修复之后或者扫描结果经过确认之后，自动化处理一批Bug的状态，降低人工参与，否则，当一个报告有很多漏洞时，一个一个地处理，还是比较耗时和麻烦的。

第四、问题挖掘出来之后，需要有统一的指导方针指导开发人员正确地修复漏洞。虽然SAST工具都会提供一些大概的修复的方案，但是，真正能够直接用于指导实施的很少。这就需要公司的安全团队针对所有漏洞类型写出符合公司内部产品特点的解决方案，并且提供示例代码。如果有些问题可以统一使用一种共同的方法解决的，安全团队可以提供一些解决安全问题的安全库，同时，提供安全示例和指导文档，让开发可以统一地快速地正确地解决安全问题。另外，使用统一的开发库来解决安全问题的好处是可以根据这个库来统一调整扫描规则，万一修复之后有误报，只需要根据安全库的信息调整扫描规则即可。如果对安全人员而言独立开发一套安全库有挑战，也可以邀请开发小组的开发人员参与共同开发，这样可以更好地贴近使用的实际情况，能够更好地满足实际的需求。

第五、不断优化SAST的扫描结果。SAST工具在使用的过程中，需要及时解决已经发现的问题，例如，某个误报在处理之后，类似的误报还再出现的话，就会使得开发人员有抵触心理，为什么总是弄一些误报让我来处理。还有就是SAST在左移的时候，可能会在IDE的插件里发起扫描，扫描的时间的长短就很关键，有的工具扫描比较大的项目可能会花很长时间，有的甚至会画上小时级别的时间，如果有很多开发同时Check in代码，就会出现排队的情况，导致开发效率下降。这就需要工具能够支持增量扫描降低扫描时间，同时，还能够根据扫描量的需求增加扫描引擎，进行动态负载均衡。

可能有的公司为了能够更好地提高系统的代码质量，就尝试使用两种工具同时扫描系统的代码。这时就需要考虑好两种工具是否有重叠？如果一个工具是集中关注安全问题，一个工具关注代码的质量问题，几乎没有重叠，就没有什么问题。如果两个工具有重叠的，而且扫描结果也有重叠，最令人厌恶的是时同样的误报需要处理两次。

总之，SAST工具从选型阶段就要做好充足的准备，充分调研内部的可能的需求，这样选出的工具才能在使用的过程中更加容易融入到公司内部的研发流程之中，更加有效地发挥它的作用。