在SDLC中使用静态代码分析的最佳实践（三） – 作者:nightmarelee

欢迎关注微信公众号《白盒研修院》或专栏《SAST白盒审计之路》，那里我会把自己关于SAST所思所想第一时间与大家分析。

6.4.4 误报控制

除了规则集的敏感性，减少SAST结果噪音的另一种方法是彻底抑制由于产品和团队编码风格的攻击面或威胁模型而导致的误报或缺陷类别。特别是，查看该工具如何抑制误报至关重要，通常，你会看到四个抑制FP（误报）的选项，每个选项都有优缺点：

在命令行上将抑制标志传递给分析引擎；

通过分析服务器上的配置文件禁止警告；

通过分类GUI将单个缺陷设置为误报；

直接在代码中放置特殊格式的注释，以指示分析引擎忽略特定文件，函数或代码行的特定警告类型。

最好使用命令行或者配置文件来实现对整个缺陷类别的大范围抑制，此外，禁用规则的列表应归中央静态分析团队所有，因为将列表放在一个位置时更易于审核。业务最方便的方法是抑制SAST工具的内置GUI中的误报，这样，任何人都可以审核抑制设置，并为标记为FP的每个缺陷留下方便的记录。此外，开发人员通常无法访问服务的配置文件，也无法更改工具的命令行标志。通过添加代码级注释来抑制规则或警告会很快失去控制，在不知不觉中，你将面临维护方面的问题：这些抑制依然有效嘛？自添加注释以来，代码是否已重构？当代码已经使用了多年，或者主要开发人员已经离开团队时，这些问题几乎无法回答。为了避免滥用代码级禁用注释，应该恢复一个过程，要求在提交之前对所有这些注释进行review。部署SAST解决方案时，你必须考虑抑制误报的偏好，最佳实践通常指出需要使用抑制层次结构，在这种情况下，最好是使用代码级注释或分类视图GUI来抑制配置文件中的某些类型的警告，而在命令行抑制其他类型的警告，在组织中广泛部署SAST之前，建立这些标准很重要。

6.4.5 处理遗留缺陷

Walter W. Schilling在题为“将静态分析集成到软件开发中”的论文中很好地总结了处理遗留缺陷的问题：将静态分析应用于旧代码可能会非常困难，根据代码的年代，工程师的编码风格以及所使用的范例，如果不遵循严格的方法，则对现有代码进行静态分析的范围可能困难到几乎不可能。许多旧项目仅在工具第一次运行时产生10万个或更多警告时才采用静态分析来排除它，使用旧版代码，通常无法消除所有静态检测出来的问题。换句话说，你必须制定一种策略来处理遗留缺陷，你必须牢记，尽管其中许多缺陷是合理的，但是尝试开发补丁程序会带来风险。例如，可能有一些遗留代码的维护者离职，而其他软件组件可能由于软件测试覆盖范围不足而脆弱。所以你会怎么做？最佳实践有时指出，从开发团队的角度来看，所有遗留缺陷都应隐藏或消除，再次，尽管违反直觉，这是减轻普通开发人员的负担，并避免“大海捞针”这类问题。应该引入“零新缺陷”策略，该策略至少要求所有新软件在你的SAST工具中进行扫描。最后，质量保证或安全团队的任务应是搜寻遗留的缺陷，以隔离关键的安全漏洞，留下其他漏洞，这些策略应在整个组织中部署SAST之前建立。

6.4.6 创建自定义规则集

你必须考虑创建自定义规则集，这些规则集能够检测新的安全漏洞类别，或者仅捕获开发团队及其编码风格指南所特有的缺陷。当对之前看不见的安全缺陷（例如在安全事件期间披露的缺陷）作出反应时，这通常很重要。在这种情况下，你将需要检查新发现的有缺陷的编码模式是否在代码库中重复出现，例如，近期，商业SAST供应商发现“Heartbleed”和“Goto Fail”漏洞表现出了一般模式。每当你的组织遇到安全事件时，你将需要创建一个自定义的规则集并寻找潜在缺陷的变体，静态代码分析在一次发现，永久修复(find-it-once-fix-it-forever)安全漏洞响应方法方面非常有效。你需要了解如何定义自定义规则集，甚至尝试在评估期间自己编写一些规则，通常，规则可以通过以下两种方式编写：

1.通过使用SAST工具的分析引擎写一些小的C或Java程序的规则；

2.在XML或其他类型的文本中定义新规则文件。

扩展语言的灵活性至关重要，你将希望它支持多种规则类型，从简单的类似于grep模式匹配到完整的过程内或过程间数据流分析。对于你创建的每个自定义规则，你还应该考虑编写与Juliet和ITC测试套件具有相似目的的单元测试。每个测试都应是尝试匹配的模式的变体，这将有助于控制误报率和漏报率。当你希望了解是否保持了向后兼容性时，这些测试用例还将在评估SAST引擎的更新时为您提供帮助。分析引擎还希望能够覆盖任何默认或内置规则和模型，例如，假如你的公司已经开发了自己的自定义堆实现，在这种情况下，你必须训练引擎以识别自定义的mymalloc和myfree例程，否则它将永远不会在代码库中捕获任何堆溢出漏洞。能够自定义分析引擎是减少误报率和支持安全事件响应活动重要方面。

6.4.7 分析速度

多个SAST解决方案的比较还应考虑分析速度，一些打包和监视构建过程的工具会增加开销，有时会使构建事件增加两倍或更多。同样，分析的速度也很重要，这个变化的范围是巨大的，因为工具每秒分析的代码都是在成千上万行代码之间进行变化。SAST工具使用复杂的算法和分析方法，这些算法和分析方法的运行速度可能非常慢，或者会占用大量内存，这些因素将导致分析缓慢或内存耗尽问题，你将被迫做出SAST配置决策，以牺牲精度为代价。现在，许多商业化的SAST工具都支持并行分析，这对于加速流程有很大的帮助。商业SAST工具中即将出现的一个相对较新的功能称为“增量分析”，它也有助于加快分析时间。这可以通过缓存先前分析作业的中间输出工作，从而避免每次要分析代码时都需要执行整体清理构建过程。当开发人员在其台式机上本地运行SAST或使用代码审查系统集成时，速度是至关重要的。在针对自然和人工代码库进行实验时，你应该测量SAST工具的速度，衡量配置更改的效果也非常有用，打开或关闭某些规则集可能会对运行时产生重大影响，当你希望实施将性能目标传达给用户的SLA或要对广泛部署SAST工具所需的服务基础结构投资做出预测时，这很有用。

6.5 缺陷分类成熟度

比较SAST解决方案时，还应该仔细研究内置缺陷分类流程的成熟度，以了解它是否与你现有的程序兼容。繁琐或不灵活的分类工作流程可能会使用户采用或破坏采用方式。以下各节总结了需要研究的分类工作流的各个方面。

6.5.1 严重性

某些SAST允许更改规则的默认严重性，这很有用，因为你通常会不认同预定义的默认值。如果你希望创建诸如“在解决所有关键缺陷之前我们的产品将不发布”之类的策略，那么对于关键缺陷的实质含义，你必须与SAST工具保持一致，这一点很重要，以这种方式审计每个规则可能是一个繁琐的过程，但是值得这么做。

6.5.2 详细的跟踪和修复指南

影响分类诊断成熟度的另一个相关因素是SAST工具是否给出了详细且全面的缺陷信息，以及修复指南是否清晰且可操作，你将需要查看SAST解决方案的内置缺陷分类方法，以确保该指南的全面、紧凑和精确。关于缺陷追踪，某些系统不可避免地声明“Defect xxx in file YYY on line #ZZZ”，这有很多不足之处。最有效的工具将包括一个详细的追踪，该追踪描述了为了到达漏洞而使用的每个条件分支，包括追踪变量的值（或估值范围），细节越多越好。你应该将修复指南视为向开发人员介绍软件安全性的机会，因此，必须提供清晰且可操作的文档，每天使用SAST对他们的安全训练非常有帮助。一些工具还提供指向外部补充指导的链接，例如OWASP策略，这也可以使开发人员受益。最后，实际上很少有解决方案可让你修改修复指南，当你不同意预定的修复建议，或组织在修补某种类型的缺陷时希望工程师遵循额外的步骤时，这一点非常重要。

6.5.3 折叠类似的缺陷

当SAST系统将相似或相同的缺陷智能地合并为一个问题时，可以大大减少缺陷积压和分类工作量。通常，尤其是首次运行该工具之后，你会发现可以用一个单行修复程序消除数十个或数百个缺陷，首先，隔离和修复这些缺陷可以帮助减少初次使用SAST的用户经常遇到的麻烦。

6.5.4 支持多个分支

随着GIT的兴起，分支变得容易，并已成为日常工作。你将要了解SAST工具如何支持多个分支以及它是否与你组织的分支策略兼容，许多SAST工具最近都尝试解决多个分支的问题，但是这些功能尚未完全成熟。值得提出的问题是：如何确保我的SAST工具分析了所有分支？该工具是否会在分支之间合并相同代码的重复缺陷？如果缺陷在一个分支中得到修复，是否仍在其他分支中报告？

6.5.5 分类工作流和多用户协作

成熟的SAST解决方案将提供基于Web的GUI，该GUI充当缺陷数据库之上的表示层。此GUI将强制执行一个分类工作流，该工作流可能与你团队的缺陷分类兼容亦或不兼容。如果你发现此工作流程不兼容，则应该尝试了解该工具的数据库架构或报告生成API，因为你可能需要将缺陷数据库导出到备用工作追踪系统中。如果你决定使用内置的分类处理的工作流程，了解多个用户是否可以交互并针对单个缺陷发表评论将很有用。除了允许工程师进行协作，就像在Gerrit这样的代码审查系统一样，当以后对结果进行审核时，它还增加了有意义的可追踪性，这样可以确保重要的对话不会产生离线问题。

6.5.6 隔离用户与开发者

并非所有用户每次登录SAST Web界面时都希望看到存储库中的每个缺陷，实际上，看到每个缺陷对于某些开发人员来说都是不知所措，SAST工具应提供用户仅查看其负责的架构域中的缺陷信息。将目录映射到团队的另一个好处是，你可以基于哪些团队使用SAST服务参与度高或缺陷数量最低的团队生成指标，注意与用户共享这些度量标准，因为它们可能会充当不正当的诱因，从而触发有利于玩统计数据但不利于提高软件安全性的真正目标的行为。

6.5.7 报告生成

仅部署SAST解决方案还不够好，你将希望仔细测量该工具是否有效运行以及是否达到预期目的，很可能不是，因为会存在一些参与度低的团队，或误报率特别高的代码区域。您可能希望按严重程度或团队衡量用户参与度和采用率，以及误报率和缺陷趋势。通过仔细测量这些数据点，您的组织可以识别SAST部署中的问题，并迅速采取纠正措施。这种持续改进行为是敏捷方法论的核心宗旨。SAST解决方案必须支持生成报告的功能，尽管该工具很可能不支持你感兴趣的所有类型的报告的生成。因此另一个关键功能是能够导出原始数据，以便你可以进行自己的分析，以下是一些示例报告，根据NCC Group的经验，这些报告已被证明是有效的。

用户参与度、采用率和感知度

还可以考虑定期向组织的员工发送调查，调查应征求有关感知、参与等方面的详细信息。这种方法对于消除由于SAST如何影响日常工作的挫败感方面非常有效。所有答复都应认真对待，记住，SAST成功的唯一方法是赢得开发人员，而最好方法是消除开发人员与工具之间的摩擦。

安全和代码质量指标

服务水平协议

你必须向用户保证，该工具将在需要时可用，并且为纠正误报会采取各种纠正措施。

6.6 供应商RoadMap

一个好的商业SAST供应商应该能够向您展示其产品的路线图。优秀的供应商将制定路线图，并将其延伸到未来几年。糟糕的或不愿意分享的路线图可能表明该工具愿景不佳。毕竟，你将要在SAST解决方案的评估和部署上投入大量的金钱和时间，因此这些事情很重要。你希望确保在以后几年可以继续使用该工具，而不会被迫切换。你还应该要求查看最近几个发行版的变更日志。如果供应商进程破坏向后兼容性，很少提供客户更新，或者很少改进缺陷检测功能或分析引擎，则不建议使用。

7.结束语

本文介绍了作者在使用众多静态代码分析工具方面的十年经验。在大型软件开发组织中广泛部署SAST是一项艰巨的任务，并且从一开始就应在整个部署过程中格外小心。解决方案必须快速，准确，并且最重要的是，它不应给要求使用该工具作为日常工作的开发人员带来负担。这些问题并非不可克服，但他们确实需要警惕的规划和创造性解决问题，因为每个组织都有其软件开发过程的独特方法。换句话说，没有任何一种商业SAST解决方案能一劳永逸。NCC Group相信，遵循此处概述的指导和最佳实践，您更有可能在组织内使用静态代码分析取得成功。

来源：freebuf.com 2020-05-13 01:34:30 by: nightmarelee