这是我的清单上的东西，我用于我的客户（包括你提到的一些）：

• 覆盖范围（根据组织今天的需求，并期望在未来使用）
  • 语
  • 架构（例如，一些工具非常适合 Web 应用程序，但对于富客户端甚至 Windows 服务/守护程序来说就不那么好了）
  • 框架（例如支持 ASP.NET 但不支持 MVC，或支持 Java 但不支持 Spring）
  • 需要的标准库（例如识别 Hibernate、log4j 或 AntiXSS，仅举几个有问题的库）
• 扫描性能。在这我包括两个：
  • 速度
  • 可扩展到大型代码库（包括 LoC、子系统/项目和外部参考）
• 完整性——即扫描中包含的规则/脚本，足以提供对输出的信心，或者换句话说，最大限度地减少假阴性。
  • 请注意，这既是提供的规则列表（例如检查“SQL 注入”）；
  • 以及这些检查的质量，即实际捕获SQL 注入。（例如，该领域的某个领导者，应该保持无名，很容易被许多形式的代码流混淆，从而错过基本的注入缺陷。）
• 结果的准确性。这适用于 ARE 报告的结果（与缺失的结果相反，在“完整性”中涵盖）。精度差可以在以下方面看到：
  • 大量误报
  • 重复
  • 分类错误
  • 错误的优先级（例如，将影响非常低的错误标记为“高风险”）
  • 不相关的结果（即准确但与应用程序或架构完全无关的代码缺陷；例如，在非 HTML、非 HTTP 和非交互式应用程序中发现 XSS，或在客户端应用程序上进行 SQL 注入）。
• 可定制性——正如你所说，定制源、接收器和过滤器；还报告；而且，同样如此，自定义规则/脚本并添加自定义逻辑（不仅仅是源->过滤器->接收器）。请注意，许多工具允许您“自定义”它们的规则，但这实际上仅限于添加源/接收器/过滤器。
• 可持续性/可重复性- 我指的是重复扫描的处理。它如何处理变化？以前标记为误报的问题？我有比较吗？
• 部署模型，例如通常组合：
  • 单一审核员站
  • 共享服务器，通过远程访问
  • 网络访问
  • 开发者插件
  • 构建服务器可插拔性
  • （当然还有能力为每个人设置不同的政策）
• 可用性。这包括：
  • UI（包括热键等）
  • 审核员过滤能力
  • 通过突出显示足够多的代码流来提供足够的上下文
  • 静态文本，例如解释、描述、补救、外部资源链接、OWASP/CWE 中的 Id 等。
  • 其他用户功能 - 例如，我可以添加手动结果（自动扫描未找到）吗？
• 报告- 根据需要灵活地每个项目（不要忘记为开发人员提供详细信息，为经理提供高级信息），以及汇总的跨项目。还有对比之类的。
• 安全性（在服务器模型的情况下） - 保护数据、权限管理等（很像任何服务器应用程序......）
• 成本。这至少包括：
  • 硬件
  • 许可证 - 以下任何或所有：
    • 每个座位 - 审计员
    • 每个座位 - 开发商
    • 每个席位 - 报告用户
    • 每台服务器
    • 每个项目
    • 每行代码
    • 网站许可证
  • 维护
  • 服务 - 例如部署、调优、自定义集成等
  • 培训（培训师和审核员/开发人员的时间）
• 集成：
  • 源头控制
  • 错误跟踪器
  • 开发环境（IDE）
  • 构建服务器/CI/CD
  • 自动化

回顾一下，我认为它几乎是按偏好顺序排列的——从基本要求开始，到适用性、质量、易于部署、效率、好用......

以下是关于如何评估静态分析工具的最重要的知识：

在您自己的代码上尝试一下。

我会再重复一遍。在您自己的代码上尝试一下。你需要运行一个试验，用它来分析你的一些代表性代码，然后分析它的输出。

原因是静态分析工具的有效性差异很大，它们的有效性取决于你的公司倾向于编写什么样的代码。因此，最适合您公司的工具可能与最适合未来另一家公司的工具不同。

你不能通过功能列表。仅仅因为一个工具说它支持 Java 并不意味着它会擅长分析 Java 代码——或者擅长分析你的 Java 代码和发现你关心的问题。

大多数静态分析供应商很乐意帮助您设置免费试用版，以便您可以在自己的代码上试用他们的工具——所以请接受他们的报价。

Gary McGraw 和 John Steven 写了一篇关于如何选择安全静态分析工具的好文章。除了指出您需要在自己的代码上尝试工具以查看哪个最好之外，他们还指出您应该考虑该工具可以根据您的环境和需求进行定制的程度，以及为此的预算成本。

一长串标准可能会分散您的注意力，也可能会帮助您想出一个好的解决方案。

以“误报”问题为例。这是此类工具的固有问题。长期的解决方案是学习如何与他们一起生活。这意味着您的编码人员将不得不学习围绕静态分析工具进行编码，了解导致它触发误报的原因，并以不同的方式编写代码，以免触发误报。对于那些使用 lint 的人，或者那些试图免费编译代码的人来说，这是一种熟悉的技术：您调整代码，直到误报停止触发。

最大的标准是了解您要解决的问题。让你的程序员完成一次运行静态分析器的步骤，消除代码中最大的问题，坦率地学习他们应该已经了解的编程知识，而不是犯这些错误，这是一个巨大的好处。但是连续运行静态分析器的边际价值要小得多，边际成本要高得多。

多年来，我一直是 Gimpel 的 C++ 代码 PC-Lint 的忠实粉丝。对我来说最大的两个因素是语言覆盖（当时没有其他人拥有它，真的）和“宜居性”。如您所知，使用静态分析是一种主观的事情。Gimpel 在他们的手册中有一章叫做“与 Lint 一起生活”，它很好地讲述了各种起伏。使其宜居需要能够自定义发出的警告和错误，但不会让开发人员疯狂地使用它。

与可扩展性相关，我在分析工具无法处理第三方代码（库等）方面遇到了麻烦，所以在一个大项目中，这当然也是一个考虑因素。