SonarQube安全热点怎么审查 SonarQube安全热点状态怎么同步

SonarQube安全热点的审查，以及安全热点状态的同步，是安全扫描被接入研发流程以后，经常会碰到的问题。安全热点并不是已经被确认的漏洞，它是在提示这一段代码涉及到了安全方面比较敏感的逻辑，需要由开发人员，或者是安全人员，去进一步做出判断。在SonarQube的文档里面，也明确地把安全热点和漏洞区分了开来：安全热点需要经过人工的审查以后，再去判断是不是要进行修复；而漏洞通常代表的是已经影响到应用安全，应当被优先去修复的问题。所以，在处理安全热点的时候，不能只是看它的数量有多少，也不能简单地就把它一键关掉。

一、SonarQube安全热点怎么审查

在审查安全热点的时候，重点是要去判断这一段代码，放在当前的业务场景下面，是不是真的会带来风险。比如加密的算法、随机数、文件的路径、跨域的配置、权限的判断、输入输出的处理，这些都有可能会被标记成安全热点，但是最后的结论，还是要结合代码被调用的场景，和已经存在的防护措施，一起来看。

1、先去查看热点的详情

在【Security Hotspots】这个页面里面，点开具体的热点，先去看一看规则的说明、代码所在的位置、被触发的原因，还有风险的描述。走这一步，并不是为了马上就去改代码，而是要先弄清楚，为什么这一段代码，会被标记出来。SonarQube对于安全热点的审查建议，通常是会引导用户去查看风险的说明、风险评估的提示，还有修复的建议，然后再去决定要不要进行修改。

2、要结合上下文去判断风险

同一类的热点，放在不同的场景下面，结论是有可能会不一样的。比如说，硬编码的字符串，有可能只是一个测试用的常量，但也有可能是密钥；文件路径的拼接，有可能只处理了内部固定的那几条路径，但也有可能接收了从外部传进来的输入；弱随机数被用在普通的编号上面，和被用在安全的令牌上面，这两者的风险是完全不同的。在做审查的时候，需要去看输入的来源、调用的链路、权限的边界，还有运行的环境。

3、要给出一个明确的处理结论

审查完成了以后，需要把热点标记成安全的、确认有风险的，或者是已经被修复了的。SonarQube的安全评审指标，会把那些已经被标记为Acknowledged、Fixed或者Safe的安全热点，看作是已经审查过了的。在标记的时候，不建议只写上一句“已确认”，最好是在记录里面去说明一下，为什么它是安全的，或者是为什么它是需要被修复的。

二、SonarQube安全热点状态怎么同步

安全热点的状态同步，主要看的，是团队到底是在SonarQube的网页端进行处理，还是在IDE和CI的流程当中去联动处理。状态不同步的时候，比较常见的原因，是项目没有被连接到同一个SonarQube项目上面、代码的分支不一致、扫描的结果还没有被重新上传，或者是本地的IDE，没有把连接模式给打开。

1、先去确认项目和分支是不是一致的

在【Project Settings】，或者是项目的页面里面，去确认当前审查的，是正确的项目、正确的分支，还有正确的代码版本。

要是网页端看的是main分支，而开发人员在本地处理的，是feature分支，那么状态就有可能会对不上。在多分支的项目里面，安全热点的状态，和代码所在的位置，以及分支分析的结果，都是有关联的，不要把不同分支的结论，直接就给混在一起用了。

2、重新去运行一次扫描，来更新状态

如果热点所对应的代码，已经被修复了，但是SonarQube的页面上面，却还是显示着未处理的状态，那就需要重新去执行一次扫描，把新的分析结果，上传到服务器上面去。SonarQube它并不是自动就会去读取你本地代码的变化的，只有等到分析的任务完成了以后，服务器上面的热点状态，和代码的位置，才会被刷新。

3、使用IDE的连接模式去进行同步

如果团队是在IDE里面审查安全热点的，那就要去确认一下，IDE的插件是不是连接到了对应的SonarQube项目。SonarQube for IDE这个工具，它在连接模式下面，会去分析本地的文件，并且把本地的安全热点结果，拿去和服务器项目当中的结果，进行比较。这样一来，开发的人员就可以更早地看到相关的热点，但是最后的状态，仍然还是需要和服务器分析的结果，保持一致。

三、安全热点审查记录怎么管理

安全热点这件事，并不是简单地把告警给消除掉，而是要去形成一个审查的闭环。特别是那些被标记成了安全的，或者是确认了风险的热点，到了后续审计的时候，是有可能会被追问依据的。要是记录写得太简单了，别人就很难去判断，当时到底是因为什么，才做出了这样的处理。

1、把判断的依据保留下来

对于那些被标记为安全的热点，需要去说明输入是不是在受控的范围里面、是不是已经做过了权限的校验、是不是有补偿性质的控制措施、是不是仅仅被用在了非安全的场景里面。对于那些被确认了风险的热点，需要去说明修复的方案、影响的范围，还有回归验证的方式。

2、要去关注新代码所带来的热点

质量门禁，它通常会更关注那些新写进去的代码。SonarQube所推荐的质量门禁思路里面，就包含了新的安全热点，需要被全部审查这样的要求。团队可以先保证那些新增加的热点，能够被及时地审查到，然后再去一步一步地，清理掉历史遗留下来的那些热点，这样就能避免老的问题，一次性就把整个开发的流程，都给压垮了。

3、要定期去复核一下历史的状态

在代码被重构了、依赖被升级了、权限的模型发生变化了以后，原来那些被标记为安全的热点，就有可能变得不再安全了。最好是能够定期地去复核一下优先级比较高的那些热点，尤其是和认证、授权、加密、文件上传、命令执行，还有外部输入，相关联的那些位置。

总结

SonarQube的安全热点要怎么去审查，还有安全热点的状态又要怎么去同步，这里面的关键，是要先理解安全热点它并不是已经确认的漏洞，而是一些需要由人工去做出判断的安全敏感代码。在做审查的时候，需要去看规则的说明、代码的上下文、输入的来源，还有防护的措施；在做同步的时候，则需要去确认项目、分支、扫描的结果，还有IDE的连接状态，这些都是保持一致的。把审查的结论、修复的记录，还有复核的依据，都给保留下来，安全热点的管理，才不会仅仅停留在“点一点状态”这个层面，而是能够真正地进入到一个研发安全的闭环里面去。