安全工具箱必备技术之静态分析安全测试(SAST)

安全工具箱必备技术之静态分析安全测试(SAST)_第1张图片

有几种技术可以识别软件和系统的漏洞,聪明的组织把它们放在他们的“安全工具箱”中,并使用各种测试工具的组合,包括:

  • 静态分析安全测试(SAST)
  • 动态分析安全测试(DAST)
  • 源成分分析(SCA)
  • 漏洞扫描器
  • 渗透测试

通过自动化工具提高安全性的动机是将软件开发生命周期(SDLC)中尽早识别和修复漏洞的工作左移。当应用程序接近发布时,修复和补救变得更加复杂。图1显示了随着SDLC的进展,修复漏洞的成本如何急剧增加。

安全工具箱必备技术之静态分析安全测试(SAST)_第2张图片

图1:随着SDLC的进展,修复漏洞的成本增加。

要深入了解软件安全的经济性,请查看《安全软件的商业价值》白皮书。本篇文章主要介绍将静态分析安全测试作为组织安全实践的一部分。

静态分析安全测试

SAST工具不需要运行中的应用程序,因此可以在开发生命周期的早期使用,因为修复成本很低。在最基本的层面上,SAST的工作原理是分析源代码,并根据一套规则进行检查。SAST工具通常与识别漏洞相关,它为开发人员提供早期警报,提醒他们注意不良的编码模式,这些模式会导致漏洞、违反安全编码策略,或缺乏与工程标准的一致性,从而导致不稳定或不可靠的功能。

有两种主要的分析类型用于识别安全问题。

  • 流分析
  • 模式分析

流分析

在流分析中,工具对源代码进行分析,了解代码的底层控制流和数据流。

安全工具箱必备技术之静态分析安全测试(SAST)_第3张图片

图2:静态分析安全测试--流分析

其结果是应用程序的中间表示或模型。这些工具对该模型运行规则或检查器,以识别导致安全漏洞的编码错误。例如,在 C 或 C++ 应用程序中,规则可能会识别字符串副本,然后遍历该模型,以确定源缓冲区是否可能大于目标缓冲区。如果是这样,就会导致缓冲区溢出漏洞。

模式分析

在安全关键的代码中避免某些构造是现代软件工程标准的基础,如AUTOSAR C++14MISRA C 2012和联合攻击战斗机(JSF)。这些标准防止了误读、误解或错误地实现不可靠代码的可能性。

模式分析可以帮助开发人员在安全或保障的背景下使用更安全的开发语言子集,禁止使用首先允许漏洞发生的代码构造。一些规则可以通过检查语法来识别错误,就像文字处理器中的拼写检查器一样。一些现代工具可以检测与不良编码结构相关的微妙模式。

SAST的优势

每种测试方法都有其优势。许多组织过度关注DAST和渗透测试。但使用SAST比其他测试技术有几个优势

代码覆盖率

测试的代码量是软件安全的一个关键指标。漏洞可能存在于代码库的任何部分,未经测试的部分可能使应用程序暴露在攻击之下。

SAST工具,特别是那些使用模式分析规则的工具,可以提供比动态技术或手动流程高得多的代码覆盖率。它们可以访问应用程序的源代码和应用程序的输入,包括在用户界面中没有暴露的隐藏输入。

根源分析

SAST工具促进了漏洞的高效补救。静态分析安全测试可以轻松识别引入错误的精确代码行。与开发人员的集成开发环境的集成可以加速补救SAST工具发现的错误。

提高技能

开发人员在IDE中使用SAST工具时,会收到关于其代码的即时反馈。这些数据可以强化和教育他们的安全编码实践。

操作效率

开发人员在开发生命周期的早期使用静态分析,包括直接从IDE中对单个文件进行分析。在SDLC的早期发现错误,大大降低了补救的成本。它首先防止了错误的发生,因此开发人员不必在以后再去寻找和修复它们。

如何从SAST中获得最大收益

SAST是一种全面的测试方法,确实需要一些最初的努力和动机来成功地采用它。

尽早部署SAST

虽然团队可以在SDLC早期使用SAST工具,但有些组织选择将分析工作推迟到测试阶段。即使分析一个更完整的应用程序可以进行程序间的数据流分析,但使用SAST“左移”,直接从IDE中分析代码,可以发现漏洞,如输入验证错误。还可以让开发人员在提交代码进行构建之前进行简单的修正。这有助于避免后期周期性的安全变更。

在敏捷和CI/CD管道中使用SAST

SAST分析是被误解的。许多团队认为它很耗时,因为它要对整个项目的源代码进行深入分析。这可能导致组织认为SAST与快速开发方法论不兼容,这是没有根据的。静态分析安全测试的结果几乎是即时的,可以在开发人员的IDE中获得,提供即时反馈,并确保避免漏洞。现代SAST工具执行增量分析,只查看两次不同构建之间变化的代码的结果。

处理嘈杂的结果

传统的静态分析安全测试工具通常包括许多“信息”结果和围绕正确编码标准的低严重性问题。现代工具,如Parasoft提供的工具,允许用户选择使用哪些规则/检查器,并根据错误的严重程度过滤结果,隐藏那些不值得调查的结果。许多来自 OWASP、CWE、CERT 等的安全标准都有风险模型,有助于识别最重要的漏洞。你的SAST工具应该使用这些信息来帮助你关注最重要的东西。用户可以更多的根据其他背景信息来过滤发现,比如项目的元数据,代码的年龄,以及负责代码的开发人员或团队。像Parasoft这样的工具提供了使用这些信息与人工智能(AI)和机器学习(ML)来帮助进一步确定最关键的问题。

关注开发者

成功的部署通常以开发人员为中心。它们提供了开发人员在软件中构建安全所需的工具和指导。这在敏捷DevOps/DevSecOps环境中非常重要,因为在这种环境中,快速反馈对于保持速度至关重要。IDE集成允许直接从开发人员的工作环境中进行安全测试——在文件级、项目级,或者仅仅是评估已更改的代码。

使用智能规则配置

在分析软件的安全问题时,一个尺寸不适合所有组织。重要的是,规则/检查程序要解决对特定应用程序至关重要的特定问题。刚开始测试安全的组织可能希望将规则限制在最常见的安全问题上,如跨站点脚本和SQL注入。其他组织根据PCI DSS等法规有特定的安全要求。寻找允许符合你的特定需求的受控规则/检查器配置的解决方案,而不是通用配置。

预防胜于发现

将安全性构建到你的应用程序中。这比在SDLC结束时,通过在已完成的应用程序上栓上安全螺栓来确保应用程序的安全要有效得多。就像你不能在应用程序中测试质量一样,安全也是如此。SAST是早期检测的关键,通过从一开始就编写安全代码来防止安全漏洞。

SAST工具使组织能够从开发的早期阶段开始就接受软件安全,并为他们的软件工程师提供构建安全软件所需的工具和指导。

你可能感兴趣的:(软件测试,静态分析,安全,测试类型,软件测试,安全漏洞)