如何选择代码检查工具，看这一篇就够了！

秘籍序言：

小猿，你遇到的问题，在上一家菊厂打扫卫生的时候，耳濡目染，发现那里的猿类已经找到了解决之道，代码检查工具正是他们的理想之选，但考虑工具种类众多，合适自己的并不多，这里有一本秘籍，它会助你开辟取经之路，同时可以提升你的质量意识和老板们的产品信心，眼下你的痛点问题也就迎刃而解，胜利终将属于你！

标准 01：匹配的语言技术

如果你正在使用 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 的支持情况。甚至有时甲方会将这些标准遵从度作为交付的验收标准。

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

标准 02：无缝融入软件开发流程

未合理地集成到开发人员的工作流程中往往会形成落地代码检查工具的门槛。开发者如何触手可及地使用工具的能力成为关键：比如快捷的拉取代码、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|企业微信）与用户即时通讯。

标准 03：报告能力

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

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

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

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

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

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

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

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

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

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

标准 04：规则管理能力

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

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

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

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

标准 05：快速

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

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

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

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

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

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

标准 06：精确

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

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

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

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

标准 07：可扩展

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

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

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

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

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

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

标准 08：其它（用户可视情况考虑）

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

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

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

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

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

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

本文转载自 华为云产品与解决方案 公众号。

原文链接：https://mp.weixin.qq.com/s/DHn3-obYLrUrdwE0ssDFsQ