很多团队做Fortify审计时，最容易乱掉的不是漏洞本身，而是状态口径和处理节奏。表面上看，大家都在给问题打标签，实际到了复盘时却发现同一类问题有人标成可利用，有人标成误报，还有人一直停在未处理状态，后面自然很难统计整改进度。OpenText官方文档对这件事说得很清楚，Application Security默认提供一个名为Analysis的标签来支撑审计，问题是否算完成审计，取决于主标签有没有被赋值；同时，平台还支持用custom tags、issue templates和application version profile把审计流程固定下来。也就是说，Fortify的审计状态不是随手写备注，而是要先把标签、主标签和状态映射定清。

　　一、Fortify代码审计状态怎么配

　　Fortify代码审计状态怎么配，关键不是先给问题打很多标签，而是先把真正决定审计状态的那一个标签收住。官方文档明确说明，系统默认的Analysis标签就是开箱可用的审计标签，它的取值会直接影响问题在审计列表里的分析状态图标；同时，应用版本要完成审计，必须给被指定为primary的标签赋值，而默认的primary tag就是Analysis。

　　1、先确认主标签是谁

　　更稳的做法是先决定当前项目到底继续使用默认Analysis，还是改用你们自己定义的list-type custom tag做primary。官方说明里写得很明确，只有list-type custom tag才能被设成primary，而且问题要想被系统视为已审计，必须给这个primary tag赋值。若这一步没先定清，后面状态统计一定会乱。

　　2、再把状态值收成固定集合

　　如果沿用默认Analysis，早期官方帮助里给出的默认值包括Exploitable、Not an Issue、Suspicious、Reliability Issue和Bad Practice。现在更稳的项目做法，是不要让团队自行发挥，而是按你们的审计口径把值收成固定集合，例如真实漏洞、非问题、待确认、设计类问题这几类，然后全团队统一使用。这样后面状态汇总和问题分流才有一致口径。

　　3、把Issue State一起映射好

　　OpenText官方在custom tag value配置里还提供了Issue State，也就是把某些标签值映射为Open Issue或Not an Issue。这个动作很重要，因为它直接决定后面按Issue State分组时，哪些问题还算待处理，哪些已经算关闭或非问题。也就是说，状态配置不能只停在“标签名字好不好懂”，还要把这些值和开放状态、非问题状态真正挂上。

　　4、最后把标签分配到应用版本

　　标签建好以后，并不会自动出现在所有项目里。官方文档说明，要让一个custom tag真正参与某个application version的审计，必须到该应用版本的PROFILE里把它assign上，并且按需要设成primary。很多团队前面标签体系已经设计好了，后面还是用不起来，问题通常就卡在这一步。

　　二、Fortify代码审计工作流如何设置

　　Fortify代码审计工作流如何设置，重点不是只建几个标签，而是把标签、模板和应用版本三层串起来。OpenText官方对这条链路已经给了清楚入口，也就是custom tags负责描述审计状态和补充属性，issue templates负责规定默认的审计标签集合和显示方式，application version再把这些标签真正落到项目执行层。这样设置完以后，团队在不同项目上的审计动作才不会各做各的。

　　1、先在Administration里定义custom tags

　　官方文档里，custom tag是审计流程的基础单位。更稳的做法是先在Administration下把Analysis之外需要的标签也补齐，例如误报原因、处置建议、责任角色、业务影响这类补充标签。这样后面审计人员在处理问题时，既能标结论，也能把后续跟踪信息一并留下。

　　2、再通过issue template固定默认标签集

　　OpenText官方说明里，custom tags可以和issue template关联，而且这些与issue template关联的标签，会在应用版本创建时作为默认标签集带进去。这个动作非常适合统一工作流，因为你可以按业务线、语言栈或团队模式准备不同模板，而不是每次建新应用版本再手工补标签。

　　3、把审核动作收成固定顺序

　　真正能执行的工作流，不应只是“看问题再打标签”。更实用的顺序通常是先确认是否为真实问题，再给primary tag赋值，再补责任和处理类标签，最后按Issue State判断它是open还是not an issue。这样做的原因很直接，官方已经把primary tag和Issue State做成了审计完成与否的核心口径，所以团队的处理顺序也应该围绕这两层来排。

　　4、需要自动化时再接Audit Assistant

　　如果项目还用了Fortify Audit Assistant，官方文档说明可以把Audit Assistant的analysis tag values映射到你们的list-type custom tag values上，并且在启用auto-apply时自动回填。也就是说，前面状态值和主标签如果没设计好，后面想接自动审计时也会很难落地。

　　三、Fortify审计闭环怎么落地

　　Fortify审计闭环怎么落地，真正要解决的不是“平台能不能配出来”，而是“团队之后会不会一直按同一套逻辑用下去”。很多团队前面把标签和模板都建好了，后面一到项目高峰期，审计人员还是会重新发明状态，结果报表越来越难看。更稳的做法，是把primary tag、Issue State、issue template和application version profile一起固定成标准流程，让新项目、新版本都沿用同一套配置。这样Fortify审计状态才不是一次性设置，而会慢慢变成项目的日常工作方式。

　　1、先固定一套主标签口径

　　不要让不同项目自己决定primary tag用哪个。官方已经说明默认是Analysis，而且只有list-type标签能做primary。更稳的做法通常是统一沿用Analysis，或者统一替换成一个团队约定好的主标签，避免同平台里出现多套审计完成标准。

　　2、再固定模板和应用版本继承关系

　　既然custom tags可以通过issue template带到应用版本里，那更好的做法就是把模板作为统一入口，而不是每个版本单独手工配一遍。这样做以后，团队的审计字段、默认状态值和主要工作流都能一起继承，后面维护成本会低很多。

　　3、最后用报表口径反推执行质量

　　工作流配完以后，不要只看界面能不能选标签，还要回头看项目里有没有大量未赋primary值的问题、有没有open与not an issue分布异常、有没有标签值使用混乱的情况。因为官方已经把审计完成、Issue State和标签值映射绑定到了同一套机制上，所以这些异常分布本身就是工作流没跑顺的信号。这个判断是根据官方状态机制整理出来的。

　　总结

　　Fortify代码审计状态怎么配，关键是先把primary tag、状态值集合和Issue State映射定清，而不是只给问题加一堆标签。Fortify代码审计工作流如何设置，关键则是用custom tags、issue templates和application version profile把同一套审计动作固定下来。等这两步都走顺以后，再把Fortify审计闭环怎么落地变成团队统一习惯，后面的漏洞审计、状态统计和自动化辅助才会真正顺起来。