很多团队说做Fortify基线，实际做出来的却只是一次首扫结果。真正能长期拿来比新增、比移除、比审计效率的基线，关键不在“先扫一次”，而在“先把应用版本、模板、过滤口径和后续上传方式固定住”。Fortify Application Security会把新上传结果并入同一个应用版本的既有结果里，并判断问题是不是上一次就存在，问题在最新扫描里消失后还会被标记为removed，所以基线本质上是同一应用版本上的第一份稳定全量结果，而不是单独一份文件。

　　一、fortify基线怎么建

　　基线要按“先定版本，再做首扫，再固定后续比较范围”的顺序建，顺序一乱，后面新增问题和存量问题就很容易混在一起。

　　1、先定应用版本

　　基线不要直接理解成一份FPR，更稳的做法是先在SSC里定好对应的application version，让后续全量扫描都往这个版本持续上传。因为Fortify判断新问题、更新问题和移除问题，本来就是围绕同一个应用版本里的历史结果做的。

　　2、首扫必须用全量扫描

　　基线首扫尽量不要用quick scan顶替。官方文档明确写到，Application Security默认会忽略quick scan生成的FPR，目的就是避免它覆盖full scan结果，所以真正要拿来建基线的，应当是一次稳定的full scan。

　　3、首扫前先定issue template

　　Fortify的issue template不只是显示样式，它会影响问题分类、优先级和后续度量。更关键的是，官方明确建议只在该application version还没有处理过结果时再改template；一旦结果已经处理，再改template，旧指标不会重算，基于旧模板生成的指标也不能删除。

　　4、标签口径在基线前一起定

　　如果你们要用custom tag管基线内问题、延期问题和新增问题，最好在模板层就先定好。官方说明里提到，issue template关联的custom tags，会在application version首次用这个模板创建时作为默认标签集带进去，所以标签口径越早定，后面越不容易返工。

　　二、fortify基线创建与冻结口径怎么定

　　基线创建完以后，最怕的不是问题多，而是口径开始漂。所谓冻结，不是说谁都不能动，而是把会改变结果边界的那几样东西单独管起来。

　　1、先冻结应用版本口径

　　同一条研发线的持续扫描，尽量固定在同一个application version下比较。因为Fortify的新旧问题识别、本次更新合并和removed状态，都是围绕这个版本的历史结果做的；版本随手切来切去，新增问题口径就会断。

　　2、再冻结template口径

　　issue template一旦在结果处理后再改，不仅旧指标不重算，还会让现有审计会话失去同步。所以模板要么在基线前定死，要么后续确实要改时，直接把它当成一次新的基线事件来处理，不要在原版本里硬改。

　　3、过滤口径必须单独冻结

　　Fortify支持用Audit Workbench里的filter set配合issue template在分析阶段隐藏问题，而且官方写得很明确，被这种filter set隐藏的问题不会写进FPR。也就是说，过滤条件不是普通显示偏好，而是结果边界本身，所以是否启用filter set、启用哪一套filter set，必须在基线前定下来。

　　4、把冻结对象写成清单

　　真正落地时，建议至少把四样东西写进冻结清单，也就是application version、issue template、filter set和扫描模式。前两项决定历史比较是否连续，第三项决定哪些问题能进入FPR，第四项决定你拿来比较的是full scan还是quick scan结果。

　　三、Fortify基线变更谁来批准

　　基线最容易失真，不是因为工具算错，而是因为变更入口太散。只要把哪些动作算基线变更先说清，后面治理就不会一直返工。

　　1、更换issue template算基线变更

　　这类变更会直接影响指标口径，官方也建议不要在已有处理结果的版本上随便改，所以谁来批、何时批，最好和普通审计操作分开。

　　2、重写filter set也算基线变更

　　因为filter set可能让一部分问题根本不进入FPR，所以它不是普通显示设置，而是范围调整。只要过滤规则改了，这一版基线看到的问题边界就已经变了。

　　3、切换扫描模式要重新确认

　　如果原来拿full scan做基线，后面却想用quick scan去接着比，口径很容易出偏。更稳的做法，是把扫描模式变化视作需要重新审批的配置变化，而不是研发自己临时切换。

　　4、审批通过后再决定是续用还是重建

　　如果只是正常代码演进，就继续在原application version上累计扫描；如果改的是template、filter set这类边界项，更建议直接新建版本重建基线。这样后面的新增、移除和审计统计会清楚很多。这个做法是根据Fortify对application version连续比对、template变更后不重算指标以及filter set会改变FPR边界这几条官方行为推出来的。

　　总结

　　fortify基线怎么建，核心不是先扫一次，而是先把application version、full scan、issue template和标签口径定住。fortify基线创建与冻结口径怎么定，关键也不是写一条“以后不许改”，而是把template、filter set和扫描模式这几类真正会改变结果边界的项单独冻结。这样做下来，Fortify后续看到的新增问题、更新问题和removed问题，才更接近一条稳定、可审计、可追溯的基线。