如何处理静态域看这里!如何入门静态分析，还不会给团队带来压力？Parasoft教你一招

如果您最初没有花些时间来确保已经确定了为项目采取的正确策略，那么开始入门的话可能会非常棘手。

假设您的静态分析工具已经安装，并且已经设置好了初始配置。在那之后，如果您一开始没有花些时间确保已经确定好了为项目采取的正确策略，那么入门就可能会非常麻烦。在这里，我所说的“入门”是指更好地理解将静态分析集成到现有项目中的一般方法，以及如何提高静态分析随时间的投资回报。

什么是静态分析？

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

这意味着静态分析可用于部分完整的代码，库和第三方源代码。开发人员可以访问静态分析，用于编写或修改代码，或者应用于任意代码库。

支持安全的静态分析

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

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

静态分析工具也被强制性安全标准（如ISO 26262或EN 50128）强制要求（或在某些情况下可理解为“强烈推荐”），因为它们能够检测难以发现的缺陷并提高软件的安全性。当然，静态分析工具还可以帮助软件团队遵守主要用于验证安全编码的编码标准，例如CERT甚至MISRA。

将静态分析引入您的项目

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

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

从确定最终目标开始

为了充分利用静态分析，了解最终目标非常重要。例如，如果目标是更好的安全性，那将决定分析和补救的重点，或者如果目标是遵守MISRA C等编码标准，那么重点将变得满足编码标准，并根据需要向认证实体证明。

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

如果以安全为重点，请将重点放在提高安全性和减少其他类型警告的注意力上。当然，关键错误很重要，但它们不应该分散您对于主要目标的注意力。随着时间的推移，随着团队变得更加熟练，您将能够纳入其他次要目标，例如提高整体质量或实施编码标准。随着静态分析成为每个开发人员日常工作的一部分，他们将能够更快地分析结果并更有效地修复错误。在这个时候，将更有效地实现次要目标。

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

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

现有项目 - 当前发展

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

每个项目都可以选择在sprint开始时或在主要新功能更新开始时采用这些工具。实际上，软件团队总是在工作 - 即使一个产品“完成”，另一个版本或变体正在进行中。这种采用方案的关键方面是每天都有大量现有代码和新代码。推荐的集成方法被称为“一条界限”方法，这意味着在开发新代码时将其改进，同时将不太重要的警告作为技术债务推迟。我们马上谈谈这个问题。

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

对成熟产品采用静态分析可能与仍在开发中的项目有不同的目标。这是一个处于软件开发生命周期的长年中的产品，其中编写的新代码很少，只能修复挥之不去的错误和安全漏洞。对这些项目采用静态分析的主要方法称为“确认和推迟”。在这种方法中，由于开发的新代码很少，所有发现的错误和安全漏洞都会被添加到现有的技术债务中。

绿地项目（未开发的新项目）

虽然软件团队通常不会重新开始，但新产品和项目是将新工具和技术集成到开发过程中的理想点。

在这些项目中，几乎没有特定于项目的现有代码，但它仍然可能依赖于第三方和开源软件。开发人员可以从一开始就将静态分析集成到他们的开发环境中，从而在编写代码时确保高质量的标准。这允许采用编码标准并确保在出现时处理关键的静态分析警告，从而减少技术债务堆中的错误和漏洞。在这种情况下采用的方法恰当地命名为“绿地”。

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

一旦将静态分析工具安装到项目中，该工具通常会报告相当长的违规和警告报告。特别是在大型代码库中，因此如何直接管理这些初始报告会影响将工具集成到项目中的成功。

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

界限法

顾名思义，在这种方法中，开发人员决定在初步分析之后，他们不会让任何更严重的警告和违规进入代码库。换句话说，他们承诺分析每个关键警告以确定其准确性，如果它确实是一个错误，就及时修复。

团队还可能决定在现有代码中添加已发现的关键警告，以将其添加到其报告工具中的错误列表中。这些类型的警告的示例可能是严重的安全漏洞，如SQL注入，或严重的内存错误，如缓冲区溢出。在大多数情况下，可以推迟不太严重的警告以供之后分析。你可能会想，“这不是会增加我们的技术债务吗？”，说得没错！这些警告中的任何潜在错误都已经在技术债务堆中了。至少在现在，它们被识别出来并且以后更容易修复。

确认和推迟处理方法

如果产品已经处在市场上并且正在维护中，那么识别代码中的错误和安全漏洞仍然是需要的，但开发人员对所有这些警告都分析（更不用说修复）是不可行的。

在这种情况下，查看最重要的报告并确定行动方案才是最有意义的。其余的警告都得到了确认，因为软件团队认识到它们存在，但它们大多数都会被推迟处理。（这再次增加了该组织的技术债务，但如上所述，这些漏洞在技术上已经存在作为技术债务。）这种方法不同于界限方法，因为在确定关键警告后，您只需推迟其余的，没有任何分析。

绿地方法

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

在成熟的三个主要阶段采用静态分析，可以通过如何处理积压的警告来区分，如下图所示：

在成熟的三个主要阶段采用静态分析：在绿地项目中，大多数报告的警告都经过调查和修复，几乎没有进入技术债务堆。正在开发的项目往往会积压大量的警告，这些警告大部分都是推迟处理，只处理严重警告，维护中的产品往往会推迟大多数警告。

配置与过滤

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

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

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

总结

静态分析工具使软件组织能够检测和跟踪错误安全漏洞，而无需执行代码。这些工具可应用于现有，传统和第三方代码并提供质量保障。

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

在我的另一篇文章中《如何将静态分析集成到日常工作流程中？看Parasoft给您支招》，重点讨论将静态分析集成到您的日常工作流程中，推荐阅读。

---

点击下方“了解更多”查看Parasoft产品详情及其试用下载

↓↓↓