专业软件测试工程师告诉你：如何选择现代的静态分析工具

从50000英尺的高度看，所有静态分析工具看起来都一样。他们分析代码，不执行代码并发现缺陷、漏洞和其他问题。

所有工具都会生成警告和报告。它们通常集成到IDE和CI/CD/build系统中。如果您想成功地将任何编码工具集成到您的日常开发中并获得最大的投资回报，则必须全面评估您的选择。

超越静态分析工具

当试图确定哪种静态分析工具最有效时，许多评估人员会采用一种通用的方法来为其团队或组织选择工具。他们使用相同的代码运行每个工具，比较结果，然后立即选择报告最多违规情况的工具。

 这并不是真正的产品评估。这是一场烘烤。赢家不一定是在团队或组织内建立可持续、可扩展的静态分析过程的最佳工具。

实际上，在成功进行这些静态分析时，通常会忽略许多关键因素，这些因素是成功采用静态分析与另一失败尝试之间的区别。

评估您的静态代码分析需求和当前状况

在开始寻找工具之前，请对您的组织进行残酷诚实的调查。评估以下内容：

您的组织需要什么。要成功进行静态分析，重要的是要了解要解决的问题。

• 静态分析正在解决哪些具体的痛点？
• 组织是否有合规要求？
• 应用程序安全性值得关注吗？
• 已经做什么了？
• 谁需要查看分析报告并采取行动？

您的组织所在的位置。了解新工具的目的以及它们是否适合您的组织也很重要。

• 您当前的开发过程是否稳定，可重复且精简，足以为静态分析奠定坚实的基础？
• 先前评估或实施静态分析工具的结果是什么？

工具选择过程中的标准

在开发过程中选择静态分析工具进行采用和最终集成需要付出努力和计划。这不仅仅是技术审查。该过程需要检查该工具与您的组织的适合程度。评估销售和支持工具的供应商也很重要。

工具评估标准

以下是对候选工具进行技术评估时要考虑的标准：

• 必要准则的涵盖范围
• 内置检查器的质量，以获取必要的准则
• 覆盖行业和企业标准
• 分析的深度和广度
• 减少噪音的实用方法（违反可忽略的检查程序）
• 误报的合理数量和方法
• 可接受的假阴性数
• 轻松调整内置检查器以适合您组织的政策
• 轻松添加新的自定义检查器以检查唯一需求
• 新的自定义检查器支持的复杂程度

供应商注意事项

选择正确的供应商与选择正确的工具一样重要。当组织获得工具时，他们即承诺与所选供应商建立关系。

在大多数成功的工具部署背后，有一家供应商致力于帮助组织实现业务目标，应对表面挑战并推动采用。

在整个评估过程中，必须考虑几层供应商资格和评估。此时，请考虑以下事项：

• 供应商对规模、增长和愿景的能力支持是否符合您的要求和目标？
• 供应商是否有一致的策略来在整个组织中进行部署，以及如何随着组织需求的变化而发展
• 供应商推荐使用其工具的“最佳做法”是什么？

了解供应商在市场中的声誉也很重要。回答这些问题：

• 哪些组织正在使用该工具？
• 案例研究揭示了其部署、使用和收益的哪些方面？
• 行业专家在评论、文章和奖项中怎么说？

质量与数量：关于覆盖范围

潜在客户的一个常见问题是：您的产品有几个检查器？

这个问题暗示着工具的质量取决于它所涵盖的不同错误的数量。对于任何工具（尤其是静态分析工具）而言，这都是很差的措施。

静态分析工具的用户应该真正关心每个工具覆盖不同错误类型，编码标准和分析深度的程度。一个常见的例子是每个供应商声称他们的工具声称CWE Top 25或OWASP Top 10或MISRA C/C++覆盖率。

看到供应商声称100％覆盖了流行的编码标准并不少见。通常会引起误解的说法。真正的问题应该是，而不是担心检查程序或规则的数量：工具覆盖您所关注的编码问题的程度如何？

示例：MISRA C，C++和CERT C覆盖范围

尽管像MISRA这样的编码标准已经扎根于汽车领域，但它们的采用正遍及其他对安全至关重要的领域。与市场需要的SEI CERT C一起使用，或用于降低软件开发的风险。无论用例如何，这些标准都不可避免地用于评估静态分析工具。

但是，由于每个标准的覆盖范围声明并未准确定义工具对覆盖范围的声明方式，因此可以解释。深入研究可能对您的用例重要的特定功能具有价值。例如，如果您的项目需要MISRA C，则应详细查看每种工具的功能。

考虑以下对各种开源和商业解决方案的评估，以评估它们对MISRA和CERT C标准的覆盖范围：

开源解决方案的覆盖率很差，这并不奇怪，因为它们的意图从未遵循这样的标准。但是，通常声称支持这些标准的各种商业工具并没有真正交付。在这里重要的真正评估标准是标准的覆盖范围，而不是支持该标准所需的检查人员数量。

但是，在使用测试套件衡量标准的覆盖率时，您还需要考虑测试套件本身的覆盖率。下图的Juliet CWE Top 25（2011）覆盖范围图像列出了通用弱点枚举（CWE）ID以及Juliet C/C++和Java测试套件中的任何测试是否涵盖了它们。您可以清楚地看到测试套件没有完全覆盖重要的CWE（前25名），这在许多测试套件中都是常见的。

开源解决方案

关于将静态分析解决方案使用开源工具的问题显而易见。FOSS需要牢记一些关键问题。评估需要包括缺少的重要功能，服务和支持的成本。

通常，这里提供有关FOSS成本和收益的详细信息，包括支持、项目活动和寿命以及可伸缩性等问题。如果行业标准很重要，并且外部审核是您业务的一部分，则FOSS解决方案可能不是一个选择。

需要回答的问题

在评估每个试点项目的结果时，评估和最终决策应归结为回答以下关键问题：

团队会真正采用并使用它吗？如果无法部署，开发人员不使用它，或者对项目进度造成太大干扰，那么世界上最好的工具将无法提供任何价值。要确定采用某项工具的程度，不仅需要对工具、检查器和集成进行全面评估，还需要对供应商，其支持、服务和培训进行全面评估。

它会解决组织和团队正在尝试解决的问题吗？部署新技术需要专注于要解决的问题，而不仅仅是期望静态分析将解决您的问题。

此外，对解决该问题的新技术的期望应该是现实的。量化成功和投资回报很重要。务必提前确定如何衡量成功：损失的时间，错过的发布或现场支持案例。

这是一个长期的解决方案吗？评估很耗时，需要团队投入。全面部署需要更多的时间和精力。选择一种“目前已经足够好”的工具可能会在短期内节省金钱，但从长期来看却非常昂贵。

总结

静态分析工具的评估通常最终会失败，在此过程中，每个工具都在同一段代码上进行测试并根据结果进行评估。尽管这是有用的并且技术评估很重要，但是评估人员还需要超越这些结果，以更大的眼光看待更长的时间。

评估人员需要考虑工具如何有效地管理结果，包括易于使用的可视化和报告。 团队应该清楚地了解每种工具如何支持在编码标准等领域提出的主张。