• 快捷搜索
  • 全站搜索

用软件语境分析降低业务风险

2018-01-24 16:48:27作者:卡特财团Peter Kaminski, TomlinCogg编辑:金融咨询网
近年来,软件系统变得非常复杂,往往包含数百万行代码和上千个依赖库,随之而来是更加多发的软件故障。从统计数据上来看,组件级层面存在更多的缺陷,但最严重的问题通常是由系统级缺陷引发的。已有的静态代码分析工具可以发现组件级的缺陷,但软件语境分析能将软件系统看作一个整体,从而规避潜在的系统级别风险。

现代软件系统通常非常复杂,包含数百万行代码,随之而来是更加多发的软件故障。从统计数据上来看,组件级层面存在更多的缺陷,但最严重的系统问题通常是由系统级缺陷引发的。已有的静态代码分析工具可以发现组件级的缺陷,但软件语境分析能将软件系统看作一个整体,从而更好地检测系统层存在的风险。这种强大的分析方法能帮助用户发布稳定、敏捷和安全可靠的应用程序,同时又能有效预防系统漏洞所造成的业务风险。这种创造性的软件分析思路,满足了用户对系统进行整体分析的需求,完善了软件分析的设计模式,填补了软件分析领域的空白。

一.日益复杂的软件系统存在很多漏洞

近年来,市场对软件的需求日渐增多,功能上的要求更加复杂。因此,现在的软件系统通常十分复杂,包括数百万行代码、数千个依赖项、数百个模块、多个编程语言和许多数据库,每个数据库有数百个实体(见图1)。

图片1.jpg
图一:软件系统样例

        这种错综复杂的系统结构往往会导致很多意想不到的问题,比如数据存储环节,一个数据库临时故障,调度算法未能正常响应,整个系统可能就无法运转。上述的例子只是软件系统故障中一种常见的故障,实际上,类似的软件系统故障频频发生,这给系统维护人员带来了巨大压力。

        一般,软件系统交付后,单单是系统的组件清单都难以维护,更不用说对程序和数据流的理解,以及了解组件以主动抑或是被动的方式进行交互。雪上加霜的是,受限于开发人员和软件工程师的效率及其工作量使得跟踪系统性的复杂问题更加棘手。随着系统的开发人员离职或不断更换,之前所采用的编码标准和架构标准都可能被误解或误用。而不同使用者对标准的不同理解可能导致使用软件时存在不当操作,技术进步也可能使旧的标准无效。所有这些因素都可能导致系统积累更多的风险。

        幸运的是,现在已经开发出可以帮助工程师解决大小型软件系统中混乱的自动化工具。这些工具能提供直观的图表和智能的解决方案,从而帮助交付团队了解阻碍系统满足非功能性目标(如上市时间,性能,安全性和弹性)的技术难点,同时大大降低软件风险,最终降低业务风险。这些系统可以被归类为面向局部(即提供单元级语法分析)或是面向内容(即进行系统级上下文软件分析)两大类。

二. 软件语境分析和传统方法的简单比较

        通常,在部署过程中,与组件级缺陷相比,系统级缺陷的数量更少。通过了传统软件分析方法测试的软件系统,实际运行时却仍然故障频频,这些问题往往都源自于正确的模块之间的错误交互方式。而寻找、理解和修复这些问题的复杂性要比修复模块或者组件本身的错误高得多。例如,李祖德(Zude Li)等人的研究结果表明涉及多个组件间交互的缺陷占所有软件缺陷的约30%,但却需要超过80%的修复工作。此外,严重的系统问题,例如安全漏洞或系统中断,通常是由系统级缺陷而不是组件级问题引起的。事实证明,与组件级问题相比,系统级问题涉及更多的业务风险。而这些系统层面的问题通过单元或模块测试很难发现,这也是传统软件分析方法被人诟病的地方。

        上述问题的出现迫使软件分析需要站在更高的角度。为此,专家们提出了软件语境分析的方法。

        为了便于理解软件语境分析的价值,我们不妨将其与软件的本地语法分析进行对比:

图2.jpg

        软件语境分析使用语言分析器按组件分解软件,然后使用分解结果来搭建整个系统的模型及其所有组件(代码和数据库)和依赖关系。一旦基于上下文的软件分析工具创建了系统的模型,它就可以在单元和系统级别检查整个系统(见图2)。

图片2.jpg
图2: 分析范围分布示例

        (批注:Con….:软件语境分析着眼于整个系统,Local…:本地语法软件分析着眼于单个组件)
 
        系统级分析不但能发现单元级分析忽略的问题,随着组件之间相互作用的增加,它还可以抑制许多在句法软件分析中容易触发的误报。此外,软件语境分析在软件创新和可拓展方面也有建树。它不仅能发现漏洞,还能找到阻止系统开发人员以最佳方式实现系统的非功能性要求的诸多障碍,比如性能瓶颈、代码可扩展性以及可以改善软件健壮性的地方。与返回二进制结果的功能测试不同,软件语境分析重点指出有改进潜力的地方,这使得产品经理和工程师能够释放软件的潜力。因为有更大数量级的文件和路径要检查,软件语境分析的运行不能立即完成,所以这种分析通常放在软件开发生命周期中的系统集成阶段运行。即使这样,更深的分析深度仍使软件语境分析在降低软件风险方面非常有价值。

        本地语法软件分析使用组件级别的静态(不用运行代码)代码分析,包括查找重复代码、过于复杂的代码和可读性差、测试覆盖率不足或违反编码标准的代码。现有的大多数编程器和编译器已经集成了这类工具。语法软件分析能够侦测组件自身包含的问题,但它不具有分析系统级问题的能力,也不知道在组件内检查时所增加的语境信息。在某些情况下,额外的系统级语境会让语法分析器误报,此时,若开发人员不考虑语境直接对错误进行相关语法分析,必将会浪费时间和精力。

        无论是组件层次还是系统层次,其所进行的软件分析都是可行的,两个层次的分析恰好互补。软件语境分析具有整个系统的视图,因此可以发现组件交互方式的问题。但是,每次开发人员改变代码时,马上进行系统层分析需要太长时间,因此,为了持续反馈,当组件更改时,应立即进行语法软件分析,以便在组件级别出现某些错误时能立即提供反馈。

三.软件语境分析的工作机理

        软件语境分析必须筛选数百万行代码,而且这些代码通常以多种不同的编程语言分布在数千个组件上。接下来,它需要结合系统架构师、产品经理、软件开发人员和项目集成工程师有意无意制订的得分标准来“理解”分析结果。因为太复杂,人类几乎不可能完成,当然,这也就是用电脑来做的原因。这不是魔术,是科学。

        软件语境分析有三个步骤。第一步,使用特定的解析器将每个组件转换为抽象语法树,之后,系统可以将所有组件组合成一个基本上由一种语言构成的大型抽象语法树。第二步,即使可能有数百万个功能,跨越多个语言和层次,软件分析系统也可以检查程序结构、执行路径和数据流,进而查找到系统中与数百个软件开发者们普遍公认的模式相匹配的代码。第三步,要检查的内容包括在执行操作系统命令或数据库查询操作之前验证用户输入的数据;查找循环、重复访问系统的昂贵资源;或需要通过慢速网络连接访问的资源。你会发现这些检查仅在对整个系统进行分析时才有效,而仅对单元模块进行的分析并不能够帮助发现这些问题。

四.软件语境分析方法的应用

        下面这两个样例通过代码的语法检查难以甚至不可能找到,但是通过软件语境分析的方法可以直观地被发现。

        (一)资源密集型数据库查询

        假如有一个类似淘宝商城的网页,上面罗列了可供购买的产品,以及每个产品的详细信息。生成列表的代码可能会为每个项目创建多个数据库查询;每个查询都会通过额外的附加层从而倍增了对数据库的访问次数。在每一层中,代码可能在结构和语法上都是正确的,实际上,当集成在一起并且在轻负载下运行时,系统是仍然可以完美地运行,但在访问高峰时,数据库查询可能会使系统崩溃。在这种情况下,需要在系统级分析时才能看到这一问题。软件语境分析能预见到资源密集型访问操作集结在一起并重复调用的情况,因此工程师可以重点检查并解决访问量过大的问题。

        (二)用于SQL查询的连续输入数据

        在复杂的系统中,单个组件可能看不到复合SQL查询的所有组件。因此,即使每个组件都进行SQL输入验证,串联起来后的一系列查询命令就可能被SQL注入攻击。全面的SQL注入检测必须分析整个调用图,包括通过应用程序的各个层的所有事务,以及验证对数据库的最终访问以及发送给它的查询的文本。而软件语境分析很容易提供这种级别的系统检测。 

五.软件语境分析工具概述

        本节概述了目前市场上一些主流的语境分析工具软件。

        CAST智能应用平台(CAST AIP)

        它能依据系统架构和编码标准分析包含多个层次、多种技术的企业应用程序的技术漏洞。为了使测量结果便于比较和理解,它采用行业标准(包括CISQ、OMG和CWE)进行相关的分析。

        主要用户:分管软件风险的IT主管;验收项目和检查代码规范的架构师和技术负责人;发现和填补漏洞的开发人员。

        支持的语言、技术和框架:ABAP, Web Dynpro for ABAP, BusinessObjects, .NE, ASP.NET, VB.NET,C#, .NET Frameworks, LINQ to Objects, LINQ to DataSets, C ,C++, Visual C, IBM DB2 SQC/SQC++, Cobol ANSI 85, JCL z/OS, IMS/DB,CICS, Oracle Forms/Reports, PowerBuilder, Java JDK, Java Server Faces, JSP,Struts Framework, Hibernate, JPA, EJB, Spring IoC, WSDL, CDI, JavaScript, HTML,XHTML, ASP, Microsoft VB, IBM DB2, SQL-PSM for z/OS , SQL-PSM for OS/390, T-SQL,Oracle PL/SQL, Sybase T-SQL.
 
        Checkmarx CxSAST

        它能通过扫描企业代码库来识别安全漏洞。

        主要用户:寻找安全漏洞的安全专员; 发现和填补漏洞的开发人员。

        支持的语言:Android(Java),Apex,ASP(VBScript),ASP.NET,C#(.NET),C / C ++,Groovy,Java,JavaScript,Objective-C,Perl,PHP,PL / SQL,Python,Ruby ,Scala,Swift,VB.NET,Visual Basic.

        Synopsys架构风险分析器

        它能识别系统设计中的缺陷进而提高您的安全状态。

        主要用户:分管软件风险的IT主管;验收项目和检查代码规范的架构师和技术负责人;发现和填补漏洞的开发人员。

        支持的语言:C,C ++,Java.

        HP / Micro Focus Fortify

        它能通过扫描企业代码库识别安全漏洞。

        它支持各种开发环境,语言,平台和框架,以在集成开发和生产环境中实现安全评估。它一般通过确定漏洞优先级来提供详细准确的行动计划以及风险的排名和分类问题。

        主要用户:寻找安全漏洞的安全专员; 发现和填补漏洞的开发人员。

        支持的语言包括:ABAP / BSP,ActionScript/ MXML(Flex),Android(Java),ASP(VBScript),ASP.NET,C#(.NET),C / C ++,COBOL,ColdFusion CFML,Java,JavaScript,JSP, Objective-C,PHP,PL / SQL,Python,Ruby,T-SQL,VB.NET,VBScript,Visual Basic,XML.

        Rogue Wave Klocwork

        它能在遵守系统架构和编码的前提下分析技术漏洞的企业代码库。

        主要用户:QA和寻找漏洞的整合工程师; 发现和填补漏洞的开发人员。

        支持的语言:C,C ++,C#,Java
 
        无参考文献
 
        Peter Kaminski简介

        Peter Kaminski是Cutter敏捷产品管理与软件工程卓越实践的高级顾问。他曾担任六家互联网创业公司的技术共同创始人,包括和维基企业协作的Socialtext,以及和以太网企业城域网服务运营商合作的Yipes Communications。 他作为硅谷的老牌企业家,为产品和服务开发与运营的讨论提供了智慧和独到的见解。他还拥有30多年的交互式消费者和企业软件应用经验。 Kaminski先生拥有创业背景和丰富的知识和技能,从底层代码网络和数据表示细节到团队动态,从敏捷开发和业务/技术协作到整体技术架构战略协调,以及高层次业务和市场战略他都有涉猎。邮箱为pkaminski@cutter.com

(文章来源:金融电子化杂志) 

扫码即可手机
阅读转发此文

本文评论

相关文章