静态应用程序安全测试
来自维基百科,自由的百科全书
静态应用程序安全测试(Static application security testing)简称SAST,是透过审查程式源代码来识别漏洞,提升软件安全性的作法。早在电脑问世时,就已有静态程式分析的作法。自从1998年起,SQL注入的攻击方式开始出现在公众的讨论中,而网络应用程序整合了JavaScript及Adobe Flash Player,因此从90年代末开始,用静态程式分析进行安全测试的作法也开始普及。
静态应用程序安全测试的作法和动态应用程序安全测试(DAST)的黑盒测试工具不同,DAST是针对应用程序的功能,而SAST是白盒测试,着重在应用程序的程式码本身。 SAST工具会扫描应用程序以及其元件的程式码,确认其软件及架构中是否有安全漏洞。 静态分析工具约可侦测到50%程式的安全漏洞[1]。
在软件开发过程中,静态应用程序安全测试可以在开发过程的早期,在程式码阶段进行,也可以在所有的程式码及软件元件放在一致的测试环境时再测试。此一技术也用在软件品质保证上[2],不过会产生许多的假警报,因此也让软件开发者不愿导入此一测试[3]
SAST工具可以整合到开发流程中,帮助开发团队,让他们主要专注在开发及交付对应需求规格的软件[4]。SAST工具像其他的安全工具一様,着重在减少应用程序无法正常运作的风险,也避免应用程序中储存的隐私资料不会被破坏或是泄漏。
简介
应用程序的安全测试可以分为三种:除了静态应用程序安全测试(SAST)外,还有动态应用程序安全测试(DAST),以及合并上述两者的互动式应用程序安全测试(IAST)[5]。
静态分析工具会以语法来检查程式码,在源代码中依固定模式或是公式来确认。理论上,静态分析工具也可以检查编释后的程式。其技术是以程式的instrumentation为基础,会比对编释后的元件以及元件的源代码,以识别问题。 静态分析可以人工进行,像是为了代码审查或是为了不同目的(包括软件安全)的软件稽核审查,但相当花时间[6]。
SAST工具的准确度会受到分析的范围,识别漏洞的技术而定。以下是几种不同层次的分析:
分析的范围会决定其准确度,以及用上下文资讯侦测漏洞的能力[7]。
在函式层级的常见技术,是创建控制资料流动程式的抽象语法树[8]。
从1990年代后期开始,商业模式的变化也让软件开发开始转向元件化[9],开发团队的组织和流程也促使这样的转变[10]。随着资料流在应用程序的各元件之间(或是各应用程序之问)流动,就需要在呼叫程式时加入特定程序来“消毒”,也要避免程式中的资料被污染[11][12]。
网页应用程序的兴起,更突显了测试的重要性。Verizon Data Breach 2016年指出,40%的资料泄露是和网页应用程序的漏洞有关[13]。网络安全的威胁有来自外部的,目前也开始关注内部的威胁。Clearswift Insider Threat Index(CITI)指出,2015年的问卷的回复者中,有92%在过去一年内曾遭受过IT事件或是网络安全事件,而有72%的资料外泄是由公司或组织内部人士发起[14]。Lee Hadlington将内部威胁分为三类:恶意、意外及未蓄意。手机软件的爆炸性成长,因此需要在开发早期加入应用程序的安全机制,以减少恶意程式码的散布[15]。
优点
漏洞在在软件开发生命周期中的越早期进行修正,所花的成本越小。在开发阶段修正的成本约是测试阶段修正成本的十分之一,是量产阶段修正成本的百分之一[16]。 不论是在程式码层次或是应用程序层次的SAST工具,都会自动执行,不需要与其互动。若将SAST工具整合在CI/CD(持续整合/持续发布)流程内, 在SAST工具识别到严重的漏洞时,可以自动停止整合流程[17]。
SAST工具会扫描所有的程式码,程式码的覆盖率是100%。而DAST(动态应用程序安全测试)工具覆盖了执行到的部分,应用程序中可能有些部分不会扫描到[5],也有可能在组态档案中有些不安全的组态。
SAST工具会有品质测试或是架构测试的副加功能,软件品质和安全性之间有直接的相关性。若软件品质不好,其安全性也不会好[18]。
缺点
即使软件开发者都对SAST工具的使用有正面的回应,在导入时仍有许多不同的挑战[4]。
若是使用敏捷软件开发,开发者一开始会注重在产品特征以及产品交付,不会一开始就考虑安全性,因此早期导入SAST工具会出现许多的错误[19]。
用SAST工具扫描较大的程式,可能会有上百个甚至成千个的漏洞警告,SAST工具会产生许多是伪阳性的假警报,增加分析的时间,并且降低程序员对此工具的信任。若有些漏洞的上下文是工具侦测不到的,那此一问题就更加严重了[3]。
相关条目
参考资料
Wikiwand - on
Seamless Wikipedia browsing. On steroids.