欢迎关注微信公众号《白盒研修院》或专栏《SAST白盒审计之路》,那里我会把自己关于SAST所思所想第一时间与大家分析。
1.摘要
静态代码分析(SAST:Static application security testing)是在不实际运行代码的情况下进行软件分析。该术语通常适用于由自动化工具执行的分析,而人工分析通常被称为针对安全性(security-focused)代码审查。SAST的主要目标是了解软件的行为,通常旨在发现安全、隐私及代码质量上的问题。近年来,商业化SAST解决方案已经相当成熟,并且它们现在提供了支持各种开发流程与系统的集成方法:持续集成、漏洞追踪、版本控制、代码review等。然而,NCC Group发现经常存在无效或不理想的静态分析部署,这些部署要么无法满足安全开发生命周期(SDLC)的要求,要么给开发人员带来了巨大的负担,从而导致静态代码分析工具无法达到理想的效果。这些缺点会导致SAST解决方案无法达到其主要目的:提高软件安全性。在本文中,我们将评估和选择最适合你组织的静态代码分析解决方案,以及将成熟的安全开发生命周期中的解决方案与开发过程有效集成的最佳实践指南。但是,我们必须有意的避免推荐特定的SAST解决方案,因为根据我们的经验,没有“一刀切”的解决方案。
2.目的与动机
促使软件开发组织使用静态代码分析的主要动力是能够以较低的价格提供更高质量和更安全的产品。研究表明,自动静态代码分析最多可以检测到60%的安全问题。当考虑到单个故障可能导致广泛且昂贵的产品召回时,此指标就变得非常重要。例如:
-
美国国家标准技术研究院(NIST)在2002年表示,美国经济每年因软件缺陷造成的损失约为595亿美元;
-
2015年,Charlie Miller 和 Chris Valasek 发现了安全缺陷,导致召回了140万辆菲亚特.克莱斯勒汽车;
-
2011年,FDA指出 24% 的医疗设备召回可归因于软件缺陷。
因此,不难想象,对SAST进行少量的投资就能避免昂贵的召回和对产品打补丁。除了恐惧,还应该认识到静态代码分析并不是灵丹妙药,正如Forrester在2015年第二季度的应用程序安全报告中的总结:
SAST为客户提供了巨大的价值 – 它拥有可靠的可追踪的记录,并提供了广泛的收益。为了从SAST中获得最大效果,团队必须相对成熟,并且能够系统地进行补救。随着应用程序环境变得更加复杂并且其攻击面和风险状况发生变化,SAST将在未来5~10年继续取得重大成功。
换句话说,尽管商业静态代码分析解决方案已经开始成熟,但要获得SAST技术的全面成功,还是需要勤奋和精心的准备。需要一种早期且经常使用的方法,从一开始就强调工具的正确和安全的应用,在组织内部部署SAST时必须格外小心。
3.为什么SAST经常失败
SAST的成功与否取决于采用率和参与度。换句话说,如果开发人员不信任静态分析解决方案(例如误报率很高),则他们将不会使用它们。建立信任的最佳方法是证明解决方案可以提供价值。证明价值的最佳方法是证明工具的准确性、快速并且不会给开发人员带来负担。
首先,您应该寻找并消除开发人员与工具之间的摩擦,不断致力于改善SAST服务。如果可能的话,应该将SAST服务无缝集成到目前支持的开发系统中,例如漏洞跟踪系统、代码review工具、代码存储库及构建环境。这有助于减少每次用户需要与SAST服务之间交互时的开销。 其次,应该努力减少开发人员分类的负担。这可以通过减少误报及不相关的警告来实现。这不是一蹴而就的,需要不停的优化和改进。最后,当未将SAST作为强制使用工具或未将SAST度量标准纳入到产品发布标准时,SAST的有效性就会开始减弱。为了获得成功,您需要达成自上而下的协议,并进行必要的过程更改,从而使静态分析成为所有软件产品发布标准的必要组成部分,并作为KPI和预期的最低质量标准。否则,开发团队很容易忽略SAST报告的缺陷,并将它们添加到无限长的“for future fix”缺陷积压中。
4.方法论
NCC Group认为,成功进行静态代码分析部署有五个核心原则。我们相信,如果在评估SAST购买解决方案并将其部署到整个组织中时遵循这些原则,您将获得最大的成功,这些目标与安全开发生命周期的目标一致。
原则 |
目标 |
---|---|
自动化 | 自动化可以确保SAST可以扫描组织内编写的所有软件;SAST工具应该无处不在,并与现有的开发支持系统透明集成,例如漏洞跟踪器,版本控制器,持续集成和代码审查系统;由SAST发现的缺陷应立即自动推送给相关开发人员;自动化的SAST将通过降低昂贵的人工成本并提高速度,例如代码审查、软件测试、安全漏洞评估以及隐私审核。 |
分析精度 | SAST工具将通过准确识别质量、安全性和隐私缺陷来提供价值;尝试对积压的漏洞进行分类时,误报率的降低减少噪声以及消除“大海捞针”式问题;开发自定义规则,以丰富出现的安全缺陷类别,并及时响应影响您软件产品的安全事件(应急响应)。 |
指标驱动的决策 | 应该统计SAST缺陷趋势,并进行质量把控,确保没有未解决的严重缺陷;对SAST的合理性应当基于具体且可测量的数据,例如漏洞数量,严重性和平均修复时间。 |
持续优化 | 定期统计SAST工具的准确性,并采取措施提高结果的准确性;为了减少历史遗留漏洞,以减轻分流带来的负担。应当采用分类的方式处理(例如:首先是严重漏洞);为保证用户的方便性,应提供高水平的修复方案。 |
用户教育 | 应对用户进行有关SAST使用以及如何修复常见漏洞的培训。 |
5.与安全开发生命周期结合
根据上述最佳实践方法,明显的看出,成功的SAST部署必须在整个软件开发过程中集成。此外,必须在安全开发生命周期的每个阶段中进行SAST活动。作为经典SDLC的一部分,静态分析工具是开发人员实现阶段最常用的工具,但也可以在其他SDLC阶段有效使用,例如,在验证阶段由质量团队使用,或在部署期间由事件响应团队使用。遵循Microsofa用于安全开发生命周期的7种模型和结构,我们将说明何处以及如何将SAST用作SDLC每个阶段的基本要素。
培训 | 为开发、测试人员创建SAST培训计划。 |
---|---|
需求 | 建立与SAST相关的质量标准和漏洞记录。 |
设计 | 审查攻击面,并开发自定义SAST模型。 |
实现 | 将SAST与开发流程工具打通。 |
验证 | 对SAST漏洞进行分类,以方便区分遗留的或严重的漏洞。 |
发布 | 在发布准备阶段,检查SAST质量指标。 |
响应 | 使用SAST进行漏洞快速响应。 |
5.1 安全培训
通常,培训是将SAST集成到软件开发过程中的重要组成部分,工程师应该熟悉SAST解决方案的功能及其局限性。在相关漏洞修复前,开发人员紧急修复他们的代码是不够的。开发人员必须了解检测到漏洞类别的根本原因,并且能够开发适当的补丁程序。不完整的修复一次又一次的出现,例如最近 Android Stagefright 漏洞的修复,被证明是非常不完善的。在组织中部署SAST时,对开发人员和测试人员进行培训非常重要。培训的主题应涵盖:
-
什么是静态分析?
-
常见的缺陷类别有哪些?最佳的修复方案是什么?
-
解决误报的最佳实践是什么?
-
SAST如何与开发系统集成?
-
为适应SAST进行了哪些流程更改?
大多数SAST提供商都提供现场、网络或远程的培训,此外,大多数静态分析工具都附带有大量的在线文档、教程,你还可以要求定制培训内容,或寻求第三方的独立指导。
5.2 需求
在传统SDLC的需求阶段,通常需要建立质量把控和漏洞准则,这些公认的内部标准有助于定义在交付软件产品之前必须满足的严格的安全性、隐私以及质量标准。这些标准中应包括来自SAST的测试结果,例如,你可能希望在解决由SAST确定的所有关键漏洞解决之前,将不发布任何产品。对于遵循敏捷开发的团队,SAST指标应该成为获取用户的标准的一部分。
5.3 设计
在SDLC的设计阶段中,最佳实践表明应该建立设计要求,分析软件的攻击面并进行威胁建模,这些建模输出可以帮助确定产品中可能需要SAST给予更多关注的风险区域。例如,你可能发现使用了新技术、软件堆栈或第三方库,必须在静态分析引擎中对这些组件进行研究并充分建模,以确保产生最准确的结果。
5.4 实现
实施阶段是众所周知的难点,在此,应该在整个开发过程中集成SAST:集成开发环境、持续集成系统、代码审查系统、漏洞追踪器及版本控制系统。
通过这种广泛的集成,你的组织可以在产品开发周期的早期发现并解决安全、隐私和质量问题,此时这些缺陷是最容易修复的。实际上,你应该在开发人员引入软件缺陷时,甚至提交代码前确定漏洞。通过缩小在引入错误及解决错误之间的时间间隔,你可以减少质量保障、代码审查、漏洞评估及隐私审查相关的下游成本。最终目标应该是通过透明地与这些系统集成而使SAST无处不在,而不会在开发人员和工具之间造成摩擦,SAST应该分析每次提交,而且应该引入“没有新警告”的策略。
5.5 验证
不仅仅是开发团队使用静态分析工具,质量保障团队也需要承担责任,验证阶段是QA的闪亮时刻。在验证期间,QA团队应对SAST漏洞进行分类,识别在实现阶段可能被忽略或推迟的关键问题,在发布软件之前,不允许任何严重的缺陷被绕过。QA团队还应该分析SAST服务提出的总体缺陷趋势,这包括追踪代码中高于平均缺陷密度的典型缺陷,或隔离触发异常高的误报率的规则集。然后,QA应能够自定义分析引擎来抑制误报,或者编写自定义规则以检测新的缺陷类别。
5.6 发布
在典型的SDLC发布阶段,将进行最终的安全检查,以检查所执行的所有安全任务并确定软件是否已准备就绪。与其他任何质量指标一样,SAST应该成为此发布准备决策过程的一部分。您将要确保你的软件产品符合你在需求阶段之前建立的质量把控与漏洞准则。
5.7 响应与维持
作为SDLC阶段的一部分,必须准备通过执行产品事件响应计划来应对安全紧急情况,健康的事件响应过程将利用SAST工具和自动化。首先,应该考虑审核SAST报告,以了解外部报告的缺陷是否以前是工程团队已知的,如果是这样,那就太好了。但是现在又遇到了另一个问题:为什么他们不在发布前修复该问题?当在外部发现绕过的缺陷时,可能会很尴尬。从过程改进的角度来看,这些见解可能非常有价值。另一方面,如果SAST工具未发现漏洞,则必须采取纠正措施。事件响应调查过程的一部分应包括寻找缺陷的变体,在这里,静态分析是一项巨大而宝贵的资产。可以开发自定义规则集来对漏洞的模式和根本原因进行建模,并且应该使用该规则集扫描整个代码库。这种“发现一次、永久修复”的态度是整个安全开发生命周期中维护的重要思想。
6 评估与部署SAST解决方案
当SAST与各种开发支持系统透明的结合到一起时,其部署是最有效的。通过减少开发人员与工具之间的摩擦,这有助于提高使用率。高度的用户参与度是任何SAST部署成功与否的关键因素,并将促使SAST发现更多的安全、隐私及质量缺陷。NASA的《软件工程手册》中有关静态代码分析的部分有效的说明了部署SAST的问题:
在现有的开发过程中引入静态分析工具是个非常棘手的问题,即使软件团队相信此工具带来的好处,项目也会谨慎行事,并尽量避免引入静态分析。
本节将描述评估和选择最适合你的软件开发过程和所用支持系统的现成商用或开源的静态代码分析解决方案的标准。你将要考虑SAST工具是否支持多个编译器以及对多种编程语言的分析,该解决方案如何与你的开发支持系统集成,以及SAST分析引擎整体的准确性和可配置性。在进行任何购买之前,第一步必须是评估多个SAST解决方案,商业SAST供应商将很乐意为此目的而提供临时的许可证。你应该根据自己的评估而不是供应商演示来决定购买商业静态分析工具,获得试用许可证后,你可以根据以下概述的条件开始评估每个工具。
后文更精彩……
来源:freebuf.com 2020-05-13 01:30:18 by: nightmarelee
请登录后发表评论
注册