在代码扫描结果评审的时候，经常会碰到这样一类情况，开发的人看到了缺陷，想把它的状态改成误报、已经确认、等着修复，或者是指定给某一个人去处理，可页面上的按钮却是灰色的，又或者点了保存以后，状态压根儿就没有变，其实，在Coverity Connect里面，审计这个操作，它本质上是一种分诊的权限，用户得在对应的流上面，拥有处理问题的权限才行，而且这个流，还必须关联着一个有效的分诊存储库，权限和对象的范围，只要有一个地方没对上，都会出现改不了的情况，按照官方的权限说明，分诊问题的权限，就是用来修改和更新某一个流里面，那些问题的分诊状态的。

　　一、审计状态改不了怎么办

　　当Coverity的审计状态改不了的时候，先别急着让管理员直接去给一个全局的权限，一种更稳当的排查办法，是先去看一看当前的页面、当前的缺陷、当前的流，还有当前登录的这个用户，是不是处在一种可以被审计的状态里。

　　1、先看看是不是把出现位置的视图给打开了

　　要是页面上那个显示出现位置的选项被勾上了，那审计的面板就很可能会变灰，因为这个时候看到的，是缺陷在代码里出现的位置，而不是那个可以直接去修改的问题对象，官方社区里的说明也提到过，勾上了这个选项以后，系统会提示不能去修改那些出现的位置，需要再切回到问题的视图里面去，所以，先去视图的设置里，把这个选项的勾给取消掉，然后再回到问题的列表里面，去尝试修改一下状态。

　　2、检查一下缺陷是不是属于当前可以审计的范围

　　有些缺陷，是从别的流、旧的历史快照，或者是同步过来的项目里面来的，用户能看到它，但可不代表就一定能去改它，进到缺陷的详细页面里面，去确认一下它所在的项目、流和组件，跟当前用户的权限范围是不是一致的，如果同一个编号的缺陷，在好几个流里面都出现过，那还要确认一下，现在要改的，是不是正好就在当前评审的那个范围里面。

　　3、检查一下分诊存储库是不是正确地关联上了

　　在Coverity Connect里面，每一个流，都需要去关联上一个分诊存储库，用户才能对这个流里面的问题，去进行审计处理，官方的术语说明里面也写过，每一个流必须关联唯一的一个分诊存储库，这样用户才能去审计这个流里面那些编号所对应的实例，如果流在被迁移、复制，或者是新建了之后，没有正确地关联上分诊存储库，那就有可能出现状态保存不了，或者是面板没法用的情况。

　　4、用一个管理员的账号来做个对照测试

　　要是普通的用户怎么都改不了，那就可以让管理员的账号，在同一条缺陷上面，去试着改一下看看，如果管理员能改，那基本上就说明，问题出在了用户的权限或者组的权限上面；要是连管理员都改不了，那就得接着去查视图的模式、流的配置、分诊存储库，还有系统服务的状态了。

　　二、审计权限配置哪里容易出错

　　Coverity的权限配置，最容易出错的一个地方，就是把“能看见”和“能改动”这两件事给当成一回事了，用户能够进到项目的页面里，能够看到缺陷的列表，但这并不代表他就已经具备了审计的权限。

　　1、角色给到了项目，但是没有给到流

　　Coverity Connect是支持在不同的层级上，给用户或者用户的组去分配角色的，权限会受到分配层级的那些影响，官方的文档也说明过，管理员是可以在好几个不同的层级上，去给用户或者组来分配角色的，如果分配的角色，只覆盖了项目查看的权限，而没有覆盖具体那个流的审计权限，那用户就会出现一种情况，就是能看，但是不能动手去改。

　　2、用户组被同步了以后，权限却没有跟着对应上

　　企业里面经常会用LDAP或者统一账号，来同步用户的组，问题常常就出在，组的名字是同步成功了，可是在Coverity里面，角色并没有被正确地绑定到那个组上面去，表面上看，用户已经是登录进来了，可实际上，他并没有落到那个具备了分诊权限的组里面，处理的时候，要去检查一下配置里面用户和组的成员关系，然后再去检查一下对应的角色，是不是包含了审计的权限。

　　3、只给了查看的权限，却没有给分诊的权限

　　有些管理员，会给用户分配像项目查看者、开发者这一类的角色，可是这个角色里面，却没有把分诊问题的权限给包进来，这样一来，用户能打开缺陷的详细情况，却没有办法去修改它的分类、归属人、严重程度，还有处置的动作这些字段，应该进到配置的角色管理里面，去检查一下那个角色是不是已经包含了分诊问题的权限，并且去确认一下，角色能起作用的范围，是不是把目标流给覆盖到了。

　　4、同步集群或者多实例的环境里，权限没有同步过去

　　要是公司用的是主从实例或者企业级的集群，那么用户在一个实例上是有权限的，可不代表在另一个实例上，也一定就能去做审计，官方的场景文档里面，专门就说明过，怎么去同步企业集群里，给指定的流授予审计权限的问题，这也就说明了，这种环境是要按照不同的实例和不同的流，去分别确认授权的。

　　三、审计记录怎样避免反复返工

　　当Coverity的审计状态可以被修改了以后，还要把操作的过程记录给留清楚，不然的话，到了后面去做质量复盘、客户评审，还有安全审查的时候，还是会被人追着问。

　　1、把审计的字段口径给统一起来

　　团队内部需要去约定好，分类、处置动作、严重程度、归属人这些字段，到底要怎么填，比如说，被当成误报的、已经确认下来的问题、暂时不去处理的，还有已经修好了的，都要有一个固定的判断口径，不要让每个人，都按着自己的理解去随便填。

　　2、审计的备注里，要把处理的依据给写上

　　备注那一栏，不要就只丢下“已确认”“误报”“后面再说”这几个字，一种更合适的写法是，去说明一下当时做出判断的依据是什么、代码的位置在哪里、风险的影响是怎么样的，还有打算采取什么后续的动作，这样后面再碰到同类的问题，来评审的人就能看得明白，当时为什么要那样去处理。

　　3、状态的变更，要能对应到缺陷的闭环

　　如果一条缺陷，被标记成了是需要去修复的，那就要能够追得到代码是提交在哪一次的、版本号是多少、重新扫描的结果怎么样，还有关闭的记录在哪里，Coverity的审计记录，不要跟研发的缺陷单子给割裂开了，要不然的话，在工具里面看着好像是已经关闭了，可是在项目管理那边，却仍然没有形成一个闭环。

　　总结

　　Coverity的审计状态改不了的时候，要怎么去排查，还有它的权限配置，到底容易在什么地方出错，排查的时候，要先去看一看当前所在的视图，是不是在问题的层面，然后，再去查一下流、分诊存储库、用户的角色，还有分诊问题的权限，在配置权限的时候，不要光看用户能不能进到项目里面去，而是要确认清楚，他是不是能够在目标的那条流上，去修改审计的状态，等到审计能够被修改了以后，还要把字段的口径和备注的规则给统一起来，把Coverity扫出来的结果、缺陷单、代码的修复，还有复扫的记录，都给连成一条线，这样后面再做评审的时候，才不至于反反复复地去补各种材料。