做Fortify代码审计时，最容易混掉的是两件事，一件是“这条结果是不是误报，该怎么标”，另一件是“审计注释到底要写到什么程度，后面的人才看得懂”。OpenText官方文档把这条线分得很清楚，审计时可以给问题设置Analysis等审计标签，也可以写COMMENTS；如果确定某条问题以后都不再关心，还可以继续做Suppress，但Suppress属于更强的、偏长期的处理动作。换句话说，误报标注和结果抑制不是同一个动作，注释也不该只写一句“误报”。

　　一、fortify代码审计误报怎么标

　　误报处理先不要一上来就点Suppress，更稳的做法是先做审计判断，再决定是否进入抑制。因为官方文档已经明确，Analysis是问题的主审计标签，可选值里本身就包含Not an Issue；而Suppressed issues则更像“这条以及它未来再次出现的同类结果，都先按抑制状态处理”。

　　1、先用Analysis标明你的审计结论

　　在Audit Workbench里，官方给出的主标签就是Analysis，合法取值包括Not an Issue、Reliability Issue、Bad Practice、Suspicious和Exploitable。真遇到确认不成立的安全问题，先把它标成Not an Issue，会比直接压掉更清楚，因为这一步先把“审计结论”立住了。

　　2、确认以后长期不再跟踪，再考虑Suppress

　　官方文档对Suppressed issues的定义很直接，这类问题适合在你“确定它不是、并且以后也不会成为关注项”时使用；在Visual Studio扩展里，官方还明确写到，Suppress会把该问题以及未来再次发现的同一问题都标成suppressed，因此它本质上是半长期动作，不适合拿来代替普通审计。

　　3、批量误报要先找共性，再批量审计

　　如果一类问题在同一批代码里反复出现，不建议逐条手工写一句“误报”。SSC官方文档已经提供了batch audit能力，而且批量审计时同样可以附带COMMENTS。更稳的做法是先确认这批问题为什么都不成立，再批量改Analysis或批量补注释。

　　4、不要把“过滤掉”当成“审计完成”

　　Fortify也支持用filter set隐藏部分问题，甚至在分析阶段就不把被隐藏的问题写入FPR。但这类做法更适合结果视图收敛，不等于完成误报审计。真正需要审计留痕的场景，还是应先保留Analysis、Comments和必要的历史记录。

　　二、fortify代码审计注释怎么写更清楚

　　注释写得清不清楚，直接影响后面复审、复扫和交接效率。官方文档虽然只要求在COMMENTS框里输入评论并保存，但同时也明确说明，保存后COMMENTS区会把这次和以前的评论都列出来；另外，合并审计数据时，评论还会按时间顺序并到一起。也就是说，Fortify的注释天然就是“会被后面的人持续看到”的，不适合写得过短、过虚。

　　1、先写结论，不要只写“已确认”

　　更清楚的第一句通常应该先把结论写出来，比如“Not an Issue，原因是该输入不可由外部用户控制”，或者“保留为Suspicious，等待业务确认真实可达性”。因为Analysis只是标签，真正让别人一眼看懂的还是文字结论。这个写法虽然是实践建议，但它正符合Fortify将标签与COMMENTS分开保存的使用方式。

　　2、再写触发条件和代码事实

　　注释里至少应补上这条结果为什么不成立，例如“Source参数来自固定枚举”“进入sink前已做白名单校验”“该分支仅在测试桩中存在”“危险函数调用路径不可达”。这样后面复核的人不需要重新从头读完整条调用链，就能先理解你的判断依据。Fortify的审计界面本来就是围绕问题详情和审计评论配合使用的，这类信息写进去最有价值。

　　3、需要抑制时把抑制理由写明

　　如果最后确实走到Suppress，注释最好单独写清“为什么要抑制”，而不是仍只写“误报”。官方文档在Suppress Issues对话框里就给了“describe the reason for suppressing the issue”这个入口，说明产品本身也把“抑制原因”当成应单独记录的信息。

　　4、注释尽量写成可复用口径

　　因为Fortify的评论会被保存并在后续历史里继续保留，而且在合并审计数据时会按时间顺序并入同一条问题记录，所以注释最好写成别人下次还能直接复用的口径，而不是只适合你自己当时能看懂的短句。比如写明代码位置、业务前提、判断依据和处理动作，会比只写“忽略”稳定得多。

　　三、Fortify误报标注与注释怎么统一

　　Fortify误报标注与注释怎么统一，关键不是多写几句，而是让“标签、注释、抑制、历史”四层口径互相对得上。官方文档已经把这几层拆开了，Analysis负责给出审计判断，COMMENTS负责补充理由，Suppress负责长期隐藏或压制，History则负责记录谁在什么时间改了什么。真正稳的做法，是先用Analysis立结论，再用注释补事实依据，最后只对确实需要长期忽略的问题使用Suppress。

　　1、先统一团队的Analysis用法

　　哪些情况标Not an Issue，哪些情况保留Suspicious，哪些情况直接转Exploitable，最好先定口径。否则同一类问题今天被判误报，明天又被另一位审计人改回去，历史会越来越乱。Fortify本身就把Analysis作为primary tag，说明这一步本来就应当先统一。

　　2、再统一注释模板

　　更实用的注释模板，通常至少包含四段，也就是审计结论、代码事实、业务前提、处理动作。这样一来，不论是单条审计还是批量审计，后面别人看COMMENTS都能快速抓到重点。官方虽然不强制模板，但COMMENTS会被持续保留并显示，这本身就说明模板化写法更适合长期维护。

　　3、最后把Suppress留给少数明确场景

　　如果只是当前阶段先不修，或者还需要业务复核，就不建议过早Suppress。官方对suppressed issues的定义已经说明，它适合那些你确定以后都不打算作为关注项继续看的问题，所以这一步更适合放在团队口径已经稳定、证据也写清以后再做。

　　总结

　　fortify代码审计误报怎么标，先用Analysis给出审计结论，确认确实不是问题时优先标Not an Issue，只有在明确长期不再关注时再考虑Suppress。fortify代码审计注释怎么写更清楚，更稳的办法则是把结论、代码事实、业务前提和处理动作按固定顺序写进COMMENTS，而不是只留一句“误报”。把“标签、注释、抑制、历史”这几层统一起来，Fortify的误报审计才更容易复核，也更适合后续复扫和交接。