彩票走势图

这篇文章是我撰写的关于静态分析入门的第一篇文章，旨在帮助新用户在其开发过程中采用静态分析工具。如果您起初没有花时间来确保已确定适合项目的正确策略，那么上手入门可能会很棘手。

作为Parasoft的解决方案架构师，我们吸引了很多人在这一领域寻求帮助，所以知道您并不孤单！如果您想了解更多信息，可以下载并阅读我帮助编写的完整指南。

我假设您已安装了静态分析工具，并且已设置任何初始配置。此后，如果您起初没有花时间来确保已确定适合项目的正确策略，那么上手可能会很棘手。在这里，“入门”的意思是更好地理解将静态分析集成到现有项目中的一般方法，以及如何随着时间的推移增加静态分析的投资回报率。

什么是静态分析？

简单来说，静态分析是检查源代码和二进制代码而无需执行的过程，通常是为了查找错误或评估质量。与需要运行程序才能运行的动态分析（例如Parasoft Insure++）不同，静态分析可以在源代码上运行，而无需可执行文件。

这意味着可以对部分完整的代码、库和第三方源代码使用静态分析。开发人员可以使用静态分析，也可以在编写或修改代码时使用静态分析，也可以在任何任意代码基础上应用静态分析。

支持安全性的静态分析

在应用程序安全域中，静态代码分析用术语“静态应用程序安全性测试（SAST）”进行。静态分析可以支持安全漏洞检测以及错误检测、质量指标和编码标准一致性。

支持功能安全和编码标准的静态分析

诸如ISO 26262或EN 50128之类的功能安全标准还要求（或者在某些情况下，“强烈推荐”）静态分析工具，因为它们能够检测出难以发现的缺陷并提高软件的安全性。当然，这还涉及到安全性，因为静态分析工具还可以帮助软件团队符合主要用于验证安全编码的编码标准，例如CERT甚至是MISRA。

将静态分析引入您的项目

静态分析工具的一大优点是，可以在项目的任何阶段引入和使用它们，即使项目不完整且未部分编码，该工具仍然有效。引入静态分析的最大挑战是大量代码会产生大量警告。因此，将静态分析集成到项目中时，重点应放在使团队尽快变得高效上，并最大程度地减少团队被所有静态分析警告淹没的机会。这并不是要降低这些警告的重要性，但是大多数开发人员没有（至少不是立即）修复现有或遗留代码的奢侈手段。

重点应该是将工具集成到日常流程中，以便最大程度地访问和使用，然后处理最关键的错误和安全漏洞。一旦团队变得更加熟练，您就可以专注于优化工具和流程以提高投资回报率。

以终为始

为了充分利用静态分析，了解最终目标非常重要。例如，如果目标是更高的安全性，这将影响分析和补救的重点，或者目标是符合诸如MISRA C之类的编码标准，那么重点将成为满足编码标准并根据需要向认证实体证明。

初次采用静态分析时，很容易陷入陷阱，那就是越好越好（即，更多的分析和更多的警告意味着您将从工具中获得最大的价值）。这是一个常见的陷阱。相反，要专注于最终目标。

如果以安全为重点，则应将重点放在提高安全性上，并减少对其他类型警告的干扰。当然，关键的bug总是很重要，要找到它们，但是它们不应该偏离主要目标。随着时间的推移，随着团队的精通，您将能够纳入其他次要目标，例如提高整体质量或执行编码标准。随着静态分析成为每个开发人员日常工作的一部分，他们将能够更快地分析结果并更有效地修复错误。此时，次要目标将更有效地实现，而不是简单地被压倒。

在产品成熟度的每个阶段引入静态分析的策略

一旦了解了要关注的主要目标，就需要确定开发中产品的成熟度，因为它会影响采用静态分析的方式。考虑下面的主要开发阶段，并确定项目适合的位置，以便您了解哪种采用方法最适合您。

现有项目——当前开发中

最常见的情况是决定使用静态分析并将其推广到其当前项目的软件组织。

每个项目都可以选择在冲刺开始时或在重大新功能更新开始时采用这些工具。实际上，软件团队一直在工作——即使一个产品“完成”，另一个版本或变体也在开发中。这种采用方案的关键方面是每天都有大量的现有代码和新代码正在开发。推荐的集成方法被称为“行之有效”的方法，这意味着在开发新代码时会对其进行改进，同时将不太重要的警告延迟为技术债务。我们稍后再讨论。

现有项目——维护市场上的产品

对成熟的产品采用静态分析可能会与仍在开发的项目有不同的目标。这是一种产品，处于软件开发生命周期的较早阶段，仅编写很少的新代码即可解决遗留的错误和安全漏洞。对这些项目采用静态分析的主要方法称为“确认并推迟”。用这种方法，由于很少开发新代码，因此将所有发现的错误和安全漏洞添加到现有技术债务中。

未开发项目

尽管软件团队通常不会有一个崭新的起点，但是新产品和项目是将新工具和技术集成到开发过程中的理想点。

在这些项目中，几乎没有特定于该项目的现有代码，但它仍可能依赖于第三方和开源软件。开发人员可以从一开始就将静态分析集成到他们的开发环境中，以确保在编写代码时获得高质量的标准。这允许采用编码标准，并确保在出现严重的静态分析警告时对其进行处理，从而为技术债务增加了更少的错误和漏洞。在这种情况下，采用的方法恰当地称为“未开发的地区”。

静态分析采用方法：如何管理早期的静态分析报告

在将静态分析工具安装到项目中之后，通常会有相当长的关于该工具报告的违规和警告的报告。这可能是不堪重负的，尤其是在大型代码库中，因此，如何管理这些初始报告直接影响将工具集成到项目中的成功。

并非所有警告都至关重要，因此不需要立即处理所有问题。学习立即解决什么和推迟解决什么是成功的关键。如上所述，产品的成熟度和尺寸对方法有直接影响，下文将对此进行详细概述。

排沙法

顾名思义，通过这种方法，开发人员决定在进行初步分析后，他们不会再将任何严重的警告和违规行为输入代码库。换句话说，他们承诺分析每个严重警告，以决定其准确性，并在错误确实存在时及时实施修复。

团队还可以决定添加在现有代码中已经发现的严重警告，以将其添加到其报告工具中的错误列表中。这些类型的警告的示例可能是严重的安全漏洞（例如SQL注入）或严重的内存错误（例如缓冲区溢出）。在大多数情况下，不太严重的警告可以推迟到以后进行分析。您可能会想，“这不只是增加了我们的技术债务吗？”如果是，那是对的！但是在这个阶段，我们可以接受。这些警告中的任何潜在错误已在技术债务堆中。至少现在，它们已被识别，以后更容易修复。

确认和延迟法

如果产品已经投放市场并且正在维护中，则识别代码中任何遗留的错误和安全漏洞仍然是有益的，但是对于开发人员来说，分析（更不用说修复）所有这些警告是不可行的。

在这种情况下，查看最重要的报告并决定采取的措施是有意义的。其余警告被确认，因为软件团队认识到它们的存在，但是大多数情况下将它们推迟到以后。 （这再次增加了组织的技术负担，但是如上所述，这些错误在技术上已经以技术负担的形式存在。）此方法与“一线原则”方法的不同之处在于，在确定关键警告之后，您只需推迟其余的，无需任何分析。

新建项目法

现有代码很少的项目是进行静态分析的理想起点。在这种情况下，软件团队可以调查所有出现的警告并修复发现的错误。与其他方法不同，只有很少的警告需要管理，因此开发人员可以处理额外的工作量。这也是通过工具实施和实施编码标准的理想时机，因为可以在IDE中以及在将任何代码提交给版本控制之前（在这里描述的其他情况下也可以这样做）识别和修复违规情况。 。

静态分析在成熟度的三个主要阶段中的采用方式通过处理警告积压的方式有所不同，如下所示：

在三个主要的成熟阶段采用静态分析：在一个新建项目中，大多数报告的警告都得到了调查和修复，而很少涉及技术债务。正在开发的项目往往积压了大部分待处理的警告，而只处理关键警告，而维护中的产品往往会推迟大多数警告。

配置与过滤

开源或轻量级静态分析工具与商业高级静态分析工具之间的主要区别之一是能够配置启用了哪些检查程序集进行分析，以及根据警告类别、文件名、严重性和其他属性过滤出报告的结果。这有助于实现不被淹没的目标——开发人员可以仅关注他们感兴趣的警告类型，并减少在任何给定时间提供的信息量。

在配置检查器和过滤结果之间也需要注意一个差异。尽管最初似乎最好限制全局配置中的规则数量，但是应该经常使用过滤来限制报告的范围，而不是完全消除检查程序。如果在配置中关闭了后来证明很重要的规则，则警告存储库中将没有历史记录，因此您将无法找出错误是由于最近的更改引起的还是代码中已经存在的在采用静态分析之前。

我建议使用配置将规则集仅限制为可预见的对软件团队有用的规则。同样，从最终目标开始：如果提高安全性是关键目标，那么启用所有与安全性相关的规则，禁用次要的规则并启用诸如CERT C之类的内置安全编码标准是有意义的。然后，如果您使用的是诸如Parasoft C/C++test之类的高级静态分析解决方案，则可以利用其内置的管理工具来处理从静态分析报告生成的数据，并推动未来的发展重点。

总结

静态分析工具使软件组织无需执行代码即可检测和跟踪错误的安全漏洞。这些工具可以应用于现有的、遗留的和第三方代码并提供质量。

静态分析的采用在一定程度上根据项目的成熟度而有所不同。大量的代码确实会导致大量警告。这是完全可管理的，能否成功采用取决于团队决定如何处理结果。针对项目的每个主要成熟度级别引入了各种技术，以及如何将这些工具集成到开发人员、团队负责人和经理的日常工作流程中。

在我的下一篇文章中，我将讨论将静态分析集成到您的日常工作流程中，请继续关注！