如何挑选静态应用安全测试（SAST）解决方案

若要保护公司开发的应用，静态应用安全测试（SAST）解决方案无疑是全面应用安全策略的重要一环。SAST能够保护软件，更加安全地支持业务，削减成本，降低风险，加速任务关键型应用的开发、交付和部署。

SAST在开发过程早期扫描代码，所以公司应用安全（AppSec）团队无需赶在计划大规模发布之前修复意外漏洞。公司可以避免因带风险延迟向客户发布或将之投入生产所带来的惊吓。

但如果考虑将SAST融入AppSec平台，希望能在软件开发生命周期（SDLC）各个阶段增加安全，某些SAST解决方案明显优于其他。

01

清楚该重点关注什么

市场上卖家云集，各有其宣称的卖点，选择SAST解决方案的时候很容易搞不清重点该放在哪里。所以，很有必要了解卖家宣传背后的真相，看看是否属实。

有时候，公司最初选择的解决方案并不适应公司的成长，或者在其他团队开始使用这个解决方案的时候会出现问题。

因此，真正的问题是，“最适合本公司的SAST解决方案是哪种？”

02

适合你的AppSec计划

全面应用安全平台能够简化安全，应用代码、开源依赖项、供应链、IaC、API、容器等等，所有一切的安全都始于一次扫描。这种平台可以快速提供准确的相关结果，加速修复进程。

挑选SAST解决方案的时候，如果该方案可融入统一AppSec平台，便可为保护现代应用带来最佳价值。一个完整的平台应该能集中管理SAST、SCA、SCS、API安全、DAST、IaC安全和容器安全。

这个平台还应该能够随着需求变化而成长。比较基于平台的AppSec方法时，要确保这些方法能关联不同扫描引擎的扫描结果，如此你才能够获得跨项目和应用的整体风险评估，而不是费时费力地人工聚合各个独立SAST解决方案的结果。

03

灵活性很关键

应用各不相同，不同利益相关者——例如CISO、应用安全团队和开发人员，也有各自不同的需求。

有时候他们需要概览应用中的种种风险，进行“全面扫描”，有时候又需要“深度扫描”应用的特定部分，或者探测非常专门的风险。

拥有深度扫描和全面扫描的灵活性就能覆盖几乎所有用例。提供灵活性，企业就能在覆盖所有用例的单个平台上实现标准化。

预设（也称为规则集）是一组现成的扫描规则，可应用于各种扫描。SAST解决方案应预先打包一系列预设以支持主要用例，包括“全面”概览其代码的风险和漏洞，以及确保合规。

有时候，无论涵盖多么广泛，预先打包的规则集都是不足以满足需求的，企业希望能够编辑或创建定制规则集，这有助于提高准确性和尽可能地减少误报。

04

SAST的准确性很重要

SAST只有够准确才有用。

提到SAST，“误报”——也就是标记了并非真风险的项目，是避免不了的话题。灵活预设和定制查询规则是减少误报的方法之一。

但更令人担忧的是“漏报”，也就是代码中的风险被忽视了，SAST扫描器没有识别出来。存在漏报，企业就会在不知不觉中发布带漏洞的软件，甚至都没有机会找出并修复漏洞，根本就是在盲飞。

减少漏报的一种方法是采用“以应用为中心”的解决方案，这种解决方案了解你的应用是如何运行的。此类解决方案能够跟踪代码中的数据流，用符号输入执行代码，探索代码中的所有路径，从而找出任何可利用的那些漏洞。尽管依靠基于正则表达式的工具或许听起来挺便利的，毕竟轻巧快捷，但如果公司因发布脆弱代码遭到在野漏洞利用而上了新闻，情况就不是那么回事儿了。

另一种解决方案是使用正确的代码库配置文件并在需要时创建定制查询。举个例子，如果企业开发了自己的定制内存检测工具，通过调整查询告诉SAST存在这么个工具就可以消除误报。拥有可定制的查询语言是减少误报的同时不产生漏报的关键。

05

寻找适用于开发人员的SAST解决方案

如上所述，从根源上解决问题，而不是简单地修复语法错误，长远来看才更快、更省钱。快速扫描不了解代码与应用的关联，会错过漏洞，所以不是我们的目标。但迫使已经很赶时间的开发人员仔仔细细检查每一个错误同样不是我们的目标。

快速修复问题很关键。而做到这一点的方法是提供“最佳修复位置”。开发人员可凭此找到修复漏洞的确切位置，节省出时间和精力。一般情况下，在最佳修复位置修改代码，往往可以一次修复就可以清除多个漏洞，减少所需的代码修正次数。

大多数开发人员都不是安全专家，但优秀的SAST解决方案可以将他们变身为安全大神。

你要找寻的解决方案应该能够向开发人员展示如何修复漏洞，解释漏洞的含义与影响，并帮助开发人员在未来编写更加安全的代码。有些解决方案可以交付或集成编码培训功能，教开发人员如何识别并编写安全的高质量代码。

短小精悍的游戏化编码安全培训可以让开发人员轻松快速地学会安全编码，提高其采用率，而且这种方法甚至有助于留住员工。

有了合适的SAST解决方案，公司的开发人员就不用去Stack Overflow或者Reddit寻找如何修复问题的建议了。

06

SAST能支持现有软件开发生命周期

语言和框架变化更迭。你的SAST解决方案却不应该变来变去。因此，选择的SAST有必要能紧跟最近的语言更新并支持最新的语言。这样你才能支持开发人员，无论他们选择了何种语言和框架。

广泛的语言支持对于以一个解决方案实现企业内跨团队标准化也十分关键。

比如说，如果身处金融行业，企业可能需要支持COBOL之类的老旧语言——很多银行交易仍然依托这种语言，也需要支持Flutter这样的新兴移动应用开发语言。尽管不同开发人员可能同时使用这两种组件，但企业可以通过在单个应用安全平台上实现标准化来最大限度地提升效率，而不是诉诸于多家供应商大乱炖。

07

发现源代码中的API

近期多起重大数据泄露事件提高了对API成为应用潜在入口点的认知。开放式Web应用程序安全项目（OWASP）甚至发布了“十大API安全漏洞”，列出了注入、安全错误配置和受损对象级授权等API遭破坏的几种典型途径。

现今大多数API安全解决方案存在的一个问题是：全都是安全右移的。例如，WAF保护运行时环境，而DAST测试编译好的应用。虽然可以说“好安全始于好代码”，但API在一定程度上检验了这句格言，因为API各不相同，且都存在自己独有的安全挑战。现有解决方案还要求开发人员记录自己的API，好方便WAF和DAST解决方案知道要保护和测试什么。然而，开发人员在API文档记录方面往往没标准格式，会导致产生影子API。

好的方面是，应用的每个API都写在代码中。至少，SAST解决方案应该能够发现代码中定义的API端点并记录下来。但理想情况下，你的SAST解决方案还应该能够显示每个API中存在的漏洞，让你可以根据API的业务价值来确定待修复漏洞的优先级。

08

单个平台上综合SAST和DAST功能

如果一直从事软件开发或者负责保护构成现代应用的数百万行代码，就很清楚扫描和测试应用有许多行业公认的方法。SAST扫描代码是为了检测可能产生可利用漏洞的编码错误——大家都清楚易遭攻击的代码就是现今所有已知安全事件的源头。但同时使用SAST和DAST工具的价值在于，它们能发现不同的漏洞。

然而，如果使用迥然不同的工具，就意味着需要通过不同的接口分别管理它们，不得不在不同的地方查看检测到的漏洞，也不得不用不同的方式分析和分类漏洞，已修复漏洞跟踪也必须分别进行。

在同一平台集成SAST和DAST则意味着可以在同一个地方查看漏洞，可以经由单个工作流程/过程管理和分类漏洞，并将漏洞发给开发人员通过相同的工作流程加以修复。而且，你还可以用一组通用集成在SDLC不同阶段集成SAST和DAST。

此外，如果你的SAST能够发现并盘点源代码中的API，找出未记录的API，那你也可以通过DAST来测试这些未记录的API。这有助于发挥出SAST解决方案的更大价值，将其发现以1+1=3的方式改善其他领域的安全结果。

09

SAST解决方案应能助力铺开安全

挑选SAST解决方案的时候，你肯定会听到很多供应商承诺可以左移AppSec。但这已经满足不了需求了。现代应用开发实践越来越多地使用API、开源代码和其他创新，新的风险也随之而来。如今，万物皆应用。你现在需要铺开应用安全，令安全遍布各处。

— 【 THE END 】—

更多推荐

原文始发于微信公众号（数世咨询）：如何挑选静态应用安全测试（SAST）解决方案