Fortify的规则包应当怎样更新，以及规则包更新以后扫描出现的差异又该怎样去判断，这里的关键并不只是把规则更新到最新版本，而是需要弄清楚这次更新会不会改变扫描的结果。Fortify的规则包里面包含了安全规则和与之相关的元数据，SCA可以通过fortifyupdate这个命令去获取或者导入安全内容；在SSC里面，也可以从规则包的页面去执行服务器的更新。规则包发生变化以后，新增的漏洞、消失的漏洞，还有严重等级的变化，都有可能出现，因此在更新前后需要把基准结果保留下来，不能只盯着最终的漏洞数量去看。

　　一、Fortify规则包怎么更新

　　规则包更新之前，先要确认当前使用的是本地SCA扫描，还是统一上传到SSC去管理的。如果扫描端和服务端的规则包版本不一样，那么结果的展示、问题的分类以及审查的口径，都有可能出现差异。

　　1、确认当前规则包的版本

　　先要去查看SCA和SSC当中已经安装的规则包版本，确认扫描端、服务器端还有流水线环境这三者是不是一致的。特别是在多台构建机器同时进行扫描的时候，不能只更新其中的一台，否则同一份代码就有可能扫出不同的结果。

　　2、使用fortifyupdate进行更新

　　在SCA的安装目录下面，使用fortifyupdate这个命令去更新规则包和安全内容。fortifyupdate能够从规则包的更新服务器上面把安全内容下载下来，也可以把已经下载到本地的安全内容导入进去，这样不管是联网的环境还是离线的环境，它都能够适用。在命令的参数里面，还可以进一步区分是只更新规则包，还是只更新外部的元数据。

　　3、在SSC当中更新规则包

　　如果团队是使用SSC来统一管理扫描结果的，那就可以由管理员或者安全方面的负责人，在规则包管理的页面上去执行更新。更新完成了以后，需要把导入的时间、规则包的版本、执行人以及适用的项目都记录下来，这样后面去解释扫描差异的时候才会比较方便。

　　二、Fortify规则包更新后扫描差异怎么判断

　　规则包更新以后，扫描结果发生了变化，这并不一定就表示代码有了改动。很多的差异，其实是来源于规则的增加、规则逻辑的调整、分类的变化，或者是元数据的变化，所以在判断的时候，需要把代码的变化和规则的变化分开来看。

　　1、先把代码的基线固定下来

　　在规则包更新之前和之后，最好是使用同一份代码、同一套编译脚本，还有同一组扫描参数，重新去进行扫描。这样做可以把变量压缩到最少。要是代码的版本也发生了变化，那后面就很难再去判断，新出现的问题到底是因为代码被修改过了，还是因为规则包发生了变化。

　　2、对比问题的状态

　　在进行对比的时候，不要只看漏洞的总数是增加了还是减少了，而要把它拆分成新增的问题、消失了的问题、严重程度发生了变化的问题、分类有了变化的问题，以及路径出现了变化的问题。新增的问题，有可能是新的规则识别出来的真实风险，也有可能是因为规则变得更严格了才带出来的新告警；而消失了的问题，也不一定就表示代码已经被修好了，它也有可能是因为规则调整了以后，不再被触发了。

　　3、查看规则信息的变化

　　对于那些新增的或者变化比较大的问题，需要回到规则的说明当中，去查看规则的ID、类别、严重级别、触发的条件，还有数据流的路径。要是同一批问题集中地来自某几条规则，那就应该优先去判断这几条规则是不是在这一轮规则包的更新当中发生了变化，而不是把每一条都当成新漏洞去处理。

　　三、规则包更新差异怎么形成闭环

　　规则包的更新，并不是一次单纯的技术操作，它还会影响到漏洞的基线、风险的统计，还有整改的计划。项目里面如果不把这些记录下来，到了后续评审的时候，就很容易出现“为什么同样的代码，突然间就多出来了这么多问题”这样的疑问。

　　1、把更新的记录保留下来

　　在规则包更新记录里面，需要写清楚更新的时间、更新的方式、规则包的版本、扫描工具的版本、影响到的项目，还有执行人。这份记录不必弄得很复杂，但是它要能够说明差异是在什么背景下出现的。特别是在发布之前、安全审计之前，或者是客户交付之前去更新规则包的，就更要把时间点和影响的范围写清楚。

　　2、建立起差异的说明

　　对于规则包更新以后新增出来的大量问题，可以先去做一次分类的说明。哪些是属于新增规则所发现的问题，哪些是属于严重等级发生了变化的问题，哪些是需要进入到整改流程的，又有哪些是需要进一步去确认是不是误报的，这些都需要有一个处理的口径，不能直接把所有新增的条目都压给开发那边。

　　3、必要的时候重新建立基线

　　如果规则包的跨度很大，扫描的结果变化非常明显，那就建议重新去确认安全基线。旧的基线可以保留下来，作为历史对比使用，但是新版本规则包下面的结果，则需要作为后续整改和度量的主要依据。不然的话，项目就会长期在旧的规则和新的规则之间反复地来回解释。

　　总结

　　Fortify规则包怎么更新，以及规则包更新以后扫描差异怎么判断，可以按照“先确认版本，再去更新规则包，接着固定代码重新扫描，再对比新增和消失的问题，最后把差异的原因记录下来”这样的思路去处理。规则包更新本身属于正常的维护动作，但是它会对扫描结果产生直接的影响。只要把工具的版本、规则包的版本、代码的基线、扫描的参数，还有差异的结论都保留下来，后续进行安全评审的时候，就能够说明结果的变化并不是随意的波动，而是有据可查的规则更新所带来的影响。