代码质量检测（二）—— 如何选择代码检查工具

        在上一章节《代码质量检测（一）—— 常用代码质量管理工具》中，我们介绍了当前业界比较常用的几款开源代码质量工具，通过综合对比发现，基本都是静态分析工具。那么面对如此繁多的工具，我们如何选择符合自己的工具来使用呢？

        一般选择这类工具时，需要从如下几个方面考察：

（1）该工具是否具有强大的检测能力，比如：是否支持我们所使用的语言？是否本身具备完善的检测规则或者能够拓展检测规则？是否支持源码和字节码检测？

（2）该工具是否具有多种检测方式，比如：是否支持全量和增量检测？是否支持多包批量检测？是否支持定期定时检测？是否支持命令检测？

（3）是否具备强大的检测引擎，比如：检测效率和bug挖掘深度、检测代码覆盖率等等，是否支持第三方组件检测能力？是否支持第三方工具集成能力（IDE插件、API接口、命令、Jenkins、Gitlab-CI集成等）？

        具体如何选择，可以参考华为云产品与解决方案中的思路，如下述选择标准。

一、选择标准

1.1 匹配的语言技术

        如果你正在使用Java开发，那么使用C/C+的检查意义不大。

        如果你正在使用Android开发，那么使用支持Spring框架的检查意义不大。

        如果你关注运行时错误类的检测（比如空指针、资源泄露等），那么使用编码风格类的检查意义不大。

•  语言支持：评估时组织需清点使用的编程语言、版本列表，然后去寻找对应的工具，毕竟不同工具支持的编程语言可能会有差异。为何版本也会有讲究？以Java为例，JDK 7新引入的try-with-resources, JDK 8新引入的Lambda表达式如果你引入的工具不支持，很有可能会引起相关的误报或者漏报，甚至会导致工具运行错误。

• 框架支持：如果开发的应用使用框架，应用就会自动继承该框架中的漏洞。而检查工具的能力也会依赖于对框架的理解度。以Android为例，如果工具不支持Android，意味着Activity没法识别为资源从而形成误报。常见的框架大致分为三类：

–   服务端框架：那些运行在服务端的框架/库，比如Spring, Struts, Django etc.

–   移动端框架：那些运行在移动端的框架/库，比如Android, IOS等。

–   客户端框架：那些运行在浏览器端的框架/库，比如ReactJS，JQuery，Angular等。

•  标准支持：多数情况下，工具能否支持特定的行业标准将是一个不错的参考起点。如果专注安全，你可能会关注CWE, OWASP TOP 10的支持情况；如果属于汽车行业，你可能会关注MISRA的支持情况。甚至有时甲方会将这些标准遵从度作为交付的验收标准。

•  规则支持：用户如何更好地理解规则到底能够扫出哪些问题，规则列表和对应的详细解释是个很好的入口。

1.2 无缝融入软件开发流程

        未合理地集成到开发人员的工作流程中往往会形成落地代码检查工具的门槛。开发者如何触手可及地使用工具的能力成为关键：比如快捷的拉取代码、IDE边编码边检查、代码评审时的检查机器人、持续集成时的自动化检查，比如缺陷管理系统里可以统一处理检查出的问题，比如检查出的问题可以通过IM与开发者即时通信…

• 第三方仓库集成（eg. GitHub/CodeHub）：支持自动化的从第三方仓库源拉取代码，替代自定义代码拉取逻辑、问题负责人分配逻辑等。

• IDE插件（eg. VSCode | Intellij）：一般可提供on-the-fly/代码保存时/代码提交时的即时检查能力，所见即所得。整体用户是否使用的自由度较大，无法形成管控。考虑到本地开发效率，检测深度往往不够，需要配合后面的自动化评审和CICD检查。

• 代码评审插件（eg. PR | MR)：像一个自动化的代码评审机器人，可以帮助你避免很多常见的基本问题，比如基本的编码规范评审。

• CICD插件（eg. Jenkins | DevCloud）：会作为DevOps工具链里的重要一环，这个步骤常常会开启深度检测的能力。

• 缺陷管理系统集成：扫出的问题可自动或手动提单到缺陷管理系统（eg. JIRA)。

• IM系统集成：扫出的问题可发送到消息通知系统（eg. WeLink|企业微信）与用户即时通讯。

1.3 报告能力

        面对目标受众，以不同的方式展示报告也是同等重要的！例如开发人员需要尽可能多的详细信息，而管理人员需要专注于问题概览（eg. 目前的产品是否符合发布条件）或者高风险的漏洞分布等

• 基于角色的报告：不同角色能够通过报告获取到自己想要的信息。

– 报告概览：管理者可以了解项目（包含跨项目）的整体概要，比如质量是否达标通过，问题严重性分布、问题责任人分布、安全标准遵从分布（eg. CWE/OWASPTOP 10的遵从情况）等。

– 报告详情：开发者能够通过具体的详情信息了解并修复扫出的问题。例如问题的基本信息、问题位置、修复建议等。

•  报告自定义：不同角色能够在看到报告后，进行相关的处理甚至自定义报告的内容或形式。

–  能够标记问题为误报，且下一次不会重复报出。

–  能够标记问题负责人，工具可以的话还能够根据一定的规则自动归属问题负责人。

–  能够自定义报告的内容或形式：比如增加问题责任人分布的直方图。

•  提供问题历史趋势：包含聚焦特定类型的问题历史趋势、查看增量报告（对只关注新问题的场景尤其有用）等。

•  提供导入导出：可以从第三方导入或者导出报告到本地。能够支持不同格式（比如XML/HTML/PDF/EXCEL）以满足不同诉求。

1.4 规则管理能力

        组织在应对不同的项目时，往往会出现选择规则困难、自定义规则困难、集中管理规则困难等问题，流程复杂时需要形成规则管控尤为困难。

•  开箱即用：不同项目能够根据自身的业务属性快速选择适合自己的规则集，比如Android项目是不是有个Android的开箱即用规则集，安全项目是不是有个安全类的规则集，后面开发者也可以在这个基础上快速自定义。

• 可定制：能够按需定制规则集，包含支持规则集的继承，支持不同生命周期下的规则集配置、支持具体规则的优先级调整等。

•  可管控：能够对规则集进行权限管控和内容管控，比如不同项目、不同阶段必须使用指定的规则集，部分规则扫出的问题必须清零等。

1.5 快速

        在可接受的时间内提供结果反馈也是个关键因素。

•  单任务加速分析：利用多线程、多核、分布式的能力（eg. 文件并行检查、规则并行检查等）。

• 多任务并行：多个任务能够在多台机器并行执行。

• 增量检查：仅对变化的文件进行检查等。

•  规则参数调优：根据需要调整检测精度、范围等。

•  其它：虚拟机参数调优等。

1.6 精确

        无效的告警以及缺陷场景定义的不清晰往往会让检查工具失去信任。

•  精确的问题上下文信息：以空指针问题为例，能指出问题位置（能够标识出空指针的来源和解引用位置更佳）、问题优先级、修复建议等。

•  低误报率：误报指的是检查出的问题不是真实问题，工具在这个指标上越低是越好的。理想情况下，扫描出的问题都是真的问题。实际情况却由于缺陷模式定义的不准确以及不够完整甚至错误的上下文信息获取（eg. 是否支持数据流分析、是否支持跨函数的过程间的分析等）导致误报。

•  低漏报率：漏报指的检查出来问题漏掉了真实问题，工具在这个指标上越低是越好的。它往往与上面的误报形成矛盾，工具在扫出更多真实问题的同时会引入更多的假问题。理想情况下，扫描出的问题全覆盖了所有的真问题。实际情况却由于缺陷模式定义的缺失以及上下文信息理解的缺失导致漏报。

1.7 可扩展

        工具内置的检查能力不一定能够满足用户的诉求，工具默认的交互方式不一定满足用户的诉求。

• 自定义插件：用户能够针对具体的上下文场景在原有工具的基础上进行二次开发，比如组织要求统一使用自定义封装类YYY替换掉原有的系统类XXX，Findbugs自定义插件传送门。

•  自定义model：当工具无法获取引用库（包含框架）的内容时尤其有效。比如用户能够自定义污点分析里的source、sink等，Infer自定义model传送门。

•  REST API：用户能够针对具体的上下文场景打造自动化的解决方案，包含集成工具或报告等。

•  自定义工具：工具本身作为平台服务能够自由接入第三方工具作为互补也是一个重要考虑。

•   其它：可扩展的门槛也会是个重要考虑，比如是否提供开箱即用的二次开发脚手架，是否提供配置即代码，是否支持类查询语言的二次开发。

1.8 其它（用户可视情况考虑）

•  售后服务：商业工具的技术支持、开源工具的社区支持等。

•  UI易用性：工具是否简单易操作？

•  触发器支持：比如定时触发、代码提交触发、代码合并触发等。

•  使用成本：购买的成本是否在组织预算范围内（免费的商用服务）？组织使用的成本是否符合公司的价值主张。

•  工具开源：免费、避免重复造轮子、开源足够自由，但工具的稳定性和技术支持不一定可以得到保障。

•  问题可自动修复：工具扫出问题后提供修改指引是第一步，进一步是否提供自动修复的建议或者完全的自动修复。

•    …