CN110383238A - 用于基于模型的软件分析的系统和方法 - Google Patents

Abstract

本文公开了涉及指导引擎的方法、系统和计算机程序产品。指导引擎被配置为向知识库查询关于软件应用的属性的指导。指导引擎从知识库接收基于属性的响应式查询。响应式查询通过执行关于软件应用程序属性的转换，向用户通知指导引擎如何解决软件应用内的漏洞。

Description

用于基于模型的软件分析的系统和方法

背景技术

计算机软件已成为人类生活许多方面不可或缺的工具。日常活动(例如，购物、银行业务、注册健康保险等)通常经由网络和移动应用进行。实际上，所有组织(公共组织和私人组织)都依赖软件应用来处理信息和管理操作。许多这些软件应用处理敏感信息，诸如个人财务记录、商业秘密、机密政府信息等。基础设施、运输、医药等中的安全关键系统越来越多地受到软件的控制。

每年，全球花费数万亿美元来开发和维护软件应用。然而，系统故障和数据泄露不断出现在新闻中。数十年的研究未能产生可扩展且准确的解决方案，以提高软件应用的可靠性和安全性。

附图说明

附图不一定按比例绘制。为清楚起见，并非每个组件都可能在每个附图中标记。

图1示出了根据一些实施例的用于软件验证的说明性系统100。

图2示出了根据一些实施例的可以使用一个或多个发现查询而建模的说明性的模型视图控制器(MVC)架构200。

图3示出了根据一些实施例的被编程为基于程序代码和一个或多个框架模型生成应用架构模型的说明性分析引擎300。

图4示出了根据一些实施例的说明性源程序400和说明性发现查询420。

图5示出了根据一些实施例的说明性源程序500和说明性属性查询510和515。

图6示出了根据一些实施例的可由分析引擎执行的说明性过程600。

图7示出了根据一些实施例的用于说明性程序705的说明性抽象语法树(AbstractSyntax Tree，AST)700。

图8示出了根据一些实施例的说明性查询语言的一些组件的巴科斯范式(BackusNormal Form，BNF)定义。

图9示出了根据一些实施例的说明性AST 900向转换后的AST 905的转换。

图10示出了根据一些实施例的说明性源程序1050和说明性属性查询1055。

图11示出了根据一些实施例的说明性属性查询1100。

图12示出了根据一些实施例的模块的说明性网络1200。

图13示出了根据一些实施例的示例性名词集合，其可以在查询语言中用于访问MVC架构中的组件。

图14示出了根据一些实施例的MVC组件的说明性层级1400。

图15示出了根据一些实施例的可用于促进对软件应用的分析的模型的说明性网络1500。

图16示出了根据一些实施例的说明性框架模型1600和1605。

图17示出了根据一些实施例的用于对分析引擎进行编程以执行字段(field)和类型分析的方法。

图18A示出了根据一些实施例的说明性应用1800和说明性组件模型1805和1810。

图18B示出了根据一些实施例的可由分析引擎检查的安全问题的说明性群组1815、1820和1825。

图18C-18E示出了根据一些实施例的安全责任的说明性分类法。

图18F-18G示出了根据一些实施例的从应用组件到安全责任的说明性映射。

图19示出了根据一些实施例的可由分析引擎使用以检查感兴趣的属性的模型的多个说明性类型。

图20示出了根据一些实施例的从属性类型到模型类型的说明性映射。

图21示出了根据一些实施例的用于选择属性模型的一种或多种类型并使用所选类型的属性模型来分析软件应用的说明性过程。

图22示出了根据一些实施例的说明性应用2200和应用2200的说明性分析。

图23示出了根据一些实施例的说明性程序代码2300和程序代码2300的说明性分析。

图24示出了根据一些实施例的说明性程序代码2400和程序代码2400的说明性分析。

图25示出了根据相同实施例的说明性应用架构模型2500。

图26A示出了根据一些实施例的应用2600中的路由功能的说明性应用2600和说明性实现方式2605。

图26B示出了根据一些实施例的说明性修订后的配置模型2625和说明性修订后的路由模型2635。

图27示出了根据一些实施例的用于向开发者提供指导的说明性系统2700。

图28示出了根据一些实施例的说明性知识图表(knowledge graph)2800。

图29示出了根据一些实施例的指导引擎的说明性实现方式。

图30示出了根据一些实施例的用于存储指导信息的说明性指导存储3000。

图31示出了根据一些实施例的可由指导引擎使用以确定向开发者呈现什么指导和/或如何呈现这种指导的说明性决策树3100。

图32示意性地示出了可以在其上实现本公开的任何方面的说明性计算机1000。

图33-36示出了根据一个实施例的向指导引擎提供和从指导引擎接收到的示例性基于图表的查询。

具体实施方式

发明人已经认识到并理解软件验证的现有方法的各种缺点。例如，发明人已经认识到并理解，一些现有方法仅关注于在系统开发生命周期的后期发生的测试，此时应用或模块在很大程度上已经实现。在该最后阶段，纠正诸如安全漏洞之类的问题可能不仅涉及重写直接引起识别出的问题的代码部分，还涉及代码的相关部分。在某些情况下，逆转在开发阶段做出的某些设计决策可能是不切实际的。结果，开发者可能被迫对识别出的问题采用次优解决方案。

因此，在一些实施例中，提供了用于在开发阶段期间检测潜在问题的技术，使得在编写依赖于有问题代码的附加代码之前可以纠正识别出的问题，并且开发者可以具有更大的自由度，以实现识别出的问题的最佳解决方案。例如，验证工具可以被构建到集成开发环境(IDE)中，并且可以被编程为在开发者编写代码时分析代码。可替选地或另外地，可以经由web用户界面访问验证工具。在任一情况下，验证工具可能能够足够快地(例如，在几分钟或几秒内)提供反馈，以在开发者仍在处理代码时允许开发者利用反馈。

发明人已经认识到并理解，一些软件验证的现有方法可能对软件开发者没有帮助。软件开发团队面临着在预算范围内按时交付产品的压力。当通过测试识别出问题时，开发者可能很少或根本没有给予指导如何解决问题。结果，开发者尝试修复可能无效，或甚至可能产生新问题。这种令人沮丧的过程可能会重复，直到开发者偶然发现正确的解决方案为止，通常是在花费宝贵的时间搜索在线资源和咨询同行之后。

因此，在一些实施例中，提供了用于集成训练和质量评估的技术。作为示例，验证工具可以被编程为将识别出的问题链接到一个或多个目标训练模块。作为另一示例，验证工具可以被编程为分析软件代码以理解开发者的意图并主动建议关于与该意图有关的常见问题的一个或多个训练模块。作为又一示例，验证工具可以被编程为，分析由开发者针对特定类型的质量问题(例如，特定安全漏洞)编写的代码(在开发者查看、读取或以其他方式完成关于该类型的质量问题的训练模块之后)。

在一些实施例中，提供了用于向软件开发者呈现验证结果的技术。发明人已经认识到并理解，可能有益的在于以简化的方式呈现验证结果，使得验证可以成为软件开发者工作的组成部分，而不是干扰。作为示例，验证工具可以被编程为递增地递送结果，例如，通过首先从简单检查(例如，语法模式匹配)递送结果，同时系统仍在执行深度分析(例如，模型检查)。以这种方式，开发者可以立即开始审查并解决来自简单检查的结果，而不必等待深度分析完成。

发明人进一步认识到并理解，可能有益的在于以不引人注目的方式呈现所建议的代码转换，使得软件开发者可以将验证工具视为有用的对等，而不仅仅是令人讨厌的问题-标记特征。例如，验证工具可以被编程为分析软件代码以理解开发者的意图并基于识别出的意图提供建议的代码修改。另外地或可替选地，验证工具可以允许开发者测试沙箱中的一段建议代码。

在一些实施例中，验证工具可以被编程为从各种不同模式中选择用于向软件开发者递送指导的适当模式。例如，验证工具可以从静态内容(例如，从内容存储检索的文本、视频等)、动态生成的内容(例如，基于当前代码上下文定制的内容)、编码建议(例如，对识别出的问题的所建议的修复，或基于识别出的意图的最佳实践提示)、要在沙箱中测试的代码的建议版本等中进行选择。

应当理解，上面介绍的和下面更详细讨论的技术可以以多种方式中的任何一种来实现，这是因为这些技术不限于任何特定的实现方式。本文提供的实现细节的示例仅用于说明目的。此外，本文公开的技术可以独立使用或以任何合适的组合使用，这是因为本公开的方面不限于任何特定技术或技术组合的使用。I.软件验证

已经开发了一些技术来自动分析关于诸如正确性、稳健性、安全性和活跃性的属性的程序行为。例如，已经开发了静态分析技术来在不执行代码的情况下分析程序代码，而已经开发了动态分析技术以通过观察代码的一个或多个执行来分析程序代码。一些软件验证工具使用静态和动态分析技术的组合。

静态分析技术的示例包括但不限于控制流分析、数据流分析、抽象解释、类型和效果分析以及模型检查。实施这些技术中的一个或多个的分析引擎可以接收程序代码和要检查的一个或多个属性作为输入，并且可以输出一个或多个结果(例如，指示属性被违反)。

模型检查技术最初是为了硬件验证而开发的，并且已经在某种程度上用于软件验证，尽管成功率较低，这是因为软件系统往往比硬件系统复杂得多。为了验证程序是否符合某个规范，可以构建程序的形式化模型，并且可以根据规范检查模型。例如，模型可以被公式化为有限状态机，并且属性可以以合适的逻辑表示为公式。可以探索有限状态机的状态空间以检查属性是否满足。

在一些实现方式中，可以明确地枚举有限状态机中的状态。可替选地或另外地，可以通过将状态集编码成相应的符号状态来以符号表示地枚举状态。在一些实现中，可以使用符号执行技术，其中解释器可以模拟程序如何执行并利用符号数据维持程序状态。

II.软件应用的可编程分析

许多软件应用复杂且难以分析。例如，应用可以包括数百个模块和数百万行代码，并且可以利用可能是或可能不是开源的外部组件(例如，框架、库、中间件等)。发明人已经认识到并理解，提供用于以关注一个或多个感兴趣的属性的方式使软件应用抽象化的技术可能是有益的，并且提供用于使框架或库抽象化的技术也是有益的。

发明人另外认识到并理解现有抽象的方法的各种缺点。例如，一些方法纯粹是语法，诸如使用像grep这样的实用工具来搜遍源代码以寻找正则表达式的匹配，或者依赖于简单的抽象，诸如执行数据流分析(例如，基于位传播)以使程序抽象化，并在抽象中对库函数进行布尔标记。发明人已经认识到并理解这些方法可能无法充分捕获程序语义，并且因此可能引起高度不准确性(例如，假阳性(false positive))。此外，对诸如框架和库之类的外部组件的行为建模可能很糟糕，如果有的话，并且可能不会考虑编写应用的编程语言的精确语义。

发明人进一步认识到并理解，一些软件验证工具依赖于用于指定要检查的属性的有限方法。例如，基于XML(可扩展标记语言)或JSON(JavaScript对象表示法)的规范方法可能使用起来很麻烦，并且可能仅允许有限的构造集合，因此不能表达许多关注的属性。此外，这些方法可能不允许用户指定对应用进行的修改，例如，当识别出某个问题时。

发明人已经认识到并理解，提供用于使应用和/或外部组件(诸如框架和库)抽象化以及用于指定要检查的属性和/或对应用进行的修改以满足属性的改进技术可能是有益的。在一些实施例中，可以提供统一方法以允许用户对软件分析引擎的上述方面中的任何一个或多个或全部进行编程。例如，可以提供通用查询语言以允许用户：(1)对包括由用户编写的代码和/或诸如框架和库的外部组件的软件组件进行建模，(2)指定要检查的属性，和/或(3)改变程序以满足属性。

图1示出了根据一些实施例的用于软件验证的说明性系统100。在该示例中，系统100包括分析引擎105和指导引擎110。分析引擎105可以接收要分析的软件应用的程序代码作为输入。在一些实施例中，输入的程序代码可以包括源代码。可替选地或另外地，输入的程序代码可以包括目标代码。分析引擎105还可以接收要检查的一个或多个属性作为输入，并且可以输出针对程序代码检查一个或多个属性的一个或多个结果。一个或多个结果可以包括指示属性是否被满足的发现、违反属性的输入的程序代码的一个或多个部分的标识，和/或对程序代码进行的以满足属性的建议修改。例如，如果程序代码不满足特定属性，则分析引擎105可以被编程为建议修改，使得修改后的程序代码将满足该属性。

在一些实施例中，分析引擎105还可以接收一个或多个框架模型作为输入。作为一个示例，分析引擎105可以被编程为选择和检索(例如，从数据库)一个或多个先前构建的框架模型。选择可以基于关于输入的程序代码的任何合适的信息，诸如编写输入的程序代码的一种或多种编程语言和/或由输入的程序代码使用的一个或多个外部组件(例如，框架、库和/或中间件)。作为另一示例，一个或多个框架模型可以由用户选择并由分析引擎105(例如，从数据库)检索。作为又一示例，一个或多个框架模型可以由用户构造并提供给分析引擎105。

在一些实施例中，框架模型可以包括以查询语言编写的一个或多个发现查询(discovery query)。发明人已经认识到并理解，对软件应用的深入理解(诸如应用的架构、架构中的各种组件的高级功能和/或组件当中的内在连接)可以促进对应用准确和有效的分析。因此，在一些实施例中，提供了用于自动发现软件应用的一个或多个方面的技术。例如，可以将发现查询应用于应用以发现对应于架构中的组件的代码的一个或多个部分、所发现的组件的一个或多个功能和/或所发现的组件如何与架构中的一个或多个其他组件交互。

在一些实施例中，发现查询可以由用户以查询语言编写。可替选地或另外地，可以预先开发特定外部组件(例如，框架、库和/或中间件)的发现查询，并且当要评估输入的程序代码时，根据需要(例如，从数据库)检索。

在一些实施例中，发现查询可以包括一个或多个语句，其指示分析引擎105如何寻找与特定分析相关的代码的一部分(例如，寻找一般的安全漏洞，或者一个或多个特定类型的安全漏洞)。另外地或可替选地，一旦代码的相关部分已被定位，发现查询就可以指示分析引擎105从程序代码中提取什么信息并存储在模型中。因此，发现查询可以是可执行程序，其将要分析的程序代码作为输入并且产生一个或多个模型作为输出。

在一些实施例中，分析引擎105可以被编程为解释以查询语言编写的发现查询。例如，分析引擎105可以根据查询语言的语义执行一个或多个发现查询，这可以致使分析引擎105从要分析的程序的源代码元素收集某些信息。然而，这不是必需的，这是因为在一些实施例中，可以将发现查询编译成机器代码，并且然后可以执行该机器代码。

在一些实施例中，分析引擎105可以被编程为将一个或多个发现查询应用于程序代码并输出特定于这种发现查询的程序代码的模型。因此，该模型仅表示与发现查询相关的程序代码的子集。然后，分析引擎105可以分析模型和/或程序代码的子集以确定是否满足某个感兴趣的属性。在一些实施例中，可以使用以用于发现查询的相同查询语言编写的属性查询来执行对模型和/或程序代码的子集的这种分析。

利用上述方法，可以通过模型来识别和表示与一个或多个感兴趣的问题(例如，安全性)相关的大型应用程序的特定部分，而可以忽略应用的不相关部分。然后可以使用与一个或多个感兴趣的问题有关的一个或多个属性查询来评估所得到的模型和/或使用所得到的模型来识别应该被评估的程序代码的相关部分。通过采用这种分而治之的方法，可以针对一个或多个特定的关注问题有效且高效地评估高度复杂的应用。

发明人已经认识到并理解，发现查询可以提供用于捕获关于编程语言、框架、库、中间件等的知识的便利方式。例如，理解编程语言(或框架、库、中间件等)的语义的用户可以编写发现查询，其帮助分析引擎105识别与正在执行的某个分析(其可以是、尽管不需要是安全性分析)相关的程序代码的部分。将发现查询应用于程序代码而得到的模型可以是关于正在执行的分析的程序代码的抽象。以这种方式，可以更有效地执行属性检查，这是因为许多程序代码可能与正在执行的分析无关，并且可以简单地被忽略。

发明人进一步认识到并理解，框架模型可以有利地作为可重用资产进行管理。例如，一旦用户为了对以某种编程语言(或使用某个框架、库、中间件等)编写的程序进行某种分析而编写了发现查询，该发现查询就可以被适当地索引和存储。以这种方式，当相同用户或另一用户希望对以相同编程语言(或使用相同框架、库、中间件等)编写的不同程序执行相同分析时，可以检索并应用先前编写的该发现查询。

返回到图1中示出的示例，由分析引擎105输出的一个或多个结果可以由指导引擎110消耗。发明人已经认识到并理解，当识别出问题时向开发者提供定制的和可行动的指导可能是有益的。因此，在一些实施例中，指导引擎110可以被编程为基于由分析引擎105输出的一个或多个结果来选择用于协助编写输入程序代码的用户的适当模态。另外地或可替选地，指导引擎110可以被编程为基于一个或多个结果从内容存储中选择适当的内容。例如，如果一个或多个结果包括指示安全漏洞的发现，则指导引擎110可以向用户呈现解释了漏洞的文本或视频消息、和/或深入的训练模块。另外地或可替选地，如果一个或多个结果包括对输入程序代码的建议修改，则指导引擎110可以向用户呈现解释了建议修改的文本或视频消息、和/或准备在沙箱中测试的修改后的程序代码。

在一些实施例中，指导引擎110可以自动确定并向用户呈现用于解决问题的建议技术。例如，指导引擎110可以基于用户偏好、软件应用的预期用途和/或关于软件应用的其他上下文信息来确定解决方案。

应当理解，系统100在图1中示出并且仅出于说明的目的在上面描述。体现本文描述的一个或多个发明方面的软件验证工具可以以多种方式中的任何一种来实现。例如，在一些实施例中，上面结合分析引擎105描述的一个或多个功能可以替代地由指导引擎110来实现，或反之亦然。在一些实施例中，软件验证工具可以用单个引擎来实现，该单个引擎被编程为分析程序代码并向开发者呈现指导。在一些实施例中，分析引擎105和指导引擎110可以独立地实现，每个都作为独立工具。本公开的方面不限于分析引擎105和指导引擎110两者的使用。

如上面讨论的，发明人已经认识到并理解对软件应用的深入理解(诸如应用的架构、架构中的各种组件的高级功能、和/或组件当中的内在连接)可以促进应用的准确和有效的分析。在一些实施例中，可以使用包括一个或多个发现查询的框架模型来表示软件架构。通过将这样的发现查询应用于程序代码，可以生成包括用于架构中的独立组件的模型的应用架构模型。然后，可以使用应用架构模型来促进关于一个或多个感兴趣的属性的程序代码的验证。

图2示出了根据一些实施例的可以使用一个或多个发现查询来建模的说明性模型视图控制器(MVC)架构200。MVC架构可用于构建包括具有单独责任的各种组件的web应用。在图2中示出的示例中，MVC架构200包括web服务器组件210、路由组件215、调度器组件220、控制器组件225、模型组件230、数据库组件235和视图组件240。web服务器组件210可以从浏览器205接收web请求，并且路由组件215可以将该请求映射到控制器组件225要采取的一个或多个动作。调度器组件220可以向控制器组件225通知要采取的一个或多个动作，并且控制器组件225可以发出要由模型组件230执行的一个或多个命令。模型组件230可以根据web应用的逻辑来执行一个或多个命令，并且可以管理存储在数据库组件235中的数据。控制器组件225可以从模型组件230接收执行结果，并且可以致使视图组件240基于执行结果生成更新后的视图。然后，控制器组件225可以致使web服务器组件210以更新后的视图响应浏览器205。

图3示出了根据一些实施例的被编程为基于程序代码和一个或多个框架模型生成应用架构模型的说明性分析引擎300。例如，分析引擎300可以是图1中示出的说明性分析引擎105的实现。

在图3中示出的示例中，分析引擎300包括模型构建组件305和属性检查组件340。模型构建组件305可以接收程序代码(其可以包括源代码和/或目标代码)和一个或多个框架模型作为输入。在一些实施例中，一个或多个框架模型可以包括一个或多个发现查询。

在一些实施例中，框架模型可以反映软件架构，诸如图2中示出的说明性MVC架构200。模型构建组件305可以被编程为使用框架模型来理解输入程序代码，例如，通过从输入程序代码中提取相关信息并将该信息存储在一个或多个模型中。在一些实施例中，模型可以对应于由框架模型捕获的软件架构中的组件。

例如，在图3中示出的示例中，模型构建组件305可以由MVC框架模型编程以生成应用架构模型310，该应用架构模型310包括控制器模型315、视图模型320、数据库模型325和路由模型330，其可分别对应于图2中示出的说明性MCV架构200的控制器组件225、视图组件240、数据库组件235和路由组件215。另外地或可替选地，应用架构模型310可以包括配置模型335，其可以不对应于说明性MCV架构200中的任何组件，但是可以存储从输入程序代码提取的配置信息。可以提取和存储的配置信息的示例包括但不限于web服务器代码中的会话和cookie配置。

应当理解，图2中示出的MVC架构200和图3中示出的应用架构模型310仅出于说明的目的而提供，这是因为本文描述的发明方面可用于对任何软件架构进行建模。

图4示出了根据一些实施例的说明性源程序400和说明性发现查询420。例如，源程序400可以是图3中示出的输入程序代码的一部分，并且发现查询420可以被包括在图3中示出的MVC框架模型中。

在图4示出的示例中，发现查询420包括具有WHEN子句的PERFORM语句。如果满足WHEN子句中指定的条件，则PERFORM语句可以指定要执行的一个或多个动作。在一些实施例中，WHEN子句可以指定模式，并且如果在输入程序代码中检测到WHEN子句中指定的模式，则可以执行PERFORM语句中指定的一个或多个动作。

例如，在图4示出的示例中，WHEN子句指定包括了用URL$1、HTTP方法$2和函数$f对@RequestMapping的调用的模式。模型构建组件(例如，图3中示出的说明性模型构建组件305)可以搜索输入程序代码以识别WHEN子句中指定的模式的匹配。如果找到匹配，则可以执行PERFORM语句以提取相关信息并将提取出的信息存储在模型中(例如，图3中示出的说明性路由模型330)。

例如，在图4示出的源程序400中，URL$1可以在405处与字符串“/database”匹配，HTTP方法$2可以在410处与字符串“get”匹配，并且函数$f可以在415处与injectableQuery的声明匹配。如435处示出的，模型构建组件可以执行PERFORM语句并在下面的结果模型中存储injectableQuery的声明。

_model.routes[“/database”][“get”].callbacks

以这种方式，模型构建组件经由发现查询而可以是可编程的(例如，发现查询420告诉模型构建组件在输入程序代码中寻找什么，并且一旦找到代码的相关部分，则提取什么信息)。例如，可以编写一个或多个发现查询(例如，图4中示出的说明性发现420)以对特定框架(例如，SpringMVC框架)如何解释程序注释(例如，@RequestMapping)进行建模。因此，一个或多个发现查询可以表示由特定框架给予这种注释的语义。然后，出于检查是否满足一个或多个属性的目的，通过应用一个或多个发现查询而构建的一个或多个模型(例如，图4中示出的说明性模型435)可以替换特定框架的源代码。

应当理解，发现查询420在图4中示出并且仅出于说明的目的在上面描述。在一些实施例中，除了语法模式匹配之外或代替语法模式匹配，可以指定其他类型的条件。此外，本公开的方面不限于在框架模型中的发现查询的使用。例如，在一些实施例中(例如，如图16中示出的和下面讨论的)，框架模型可以包括直接编写以替换框架源代码的模型。这种模型不必是应用一个或多个发现查询的结果。

返回到图3中示出的示例，可以由分析引擎300的属性检查组件340分析应用架构模型310，以确定是否满足一个或多个属性。可以使用一种或多种属性检查技术的任何合适组合，包括但不限于数据流分析、控制流分析和/或模型检查。然后，属性检查组件340可以输出一个或多个结果，其可以包括指示识别出的问题(例如，安全漏洞)的发现、用于修复识别出的问题的对输入程序代码的建议修改、属性检查组件340无法关于某个属性得出结论的指示、和/或任何其他感兴趣的观察。例如，基于属性检查组件340可用的信息，结果可以标记代码的一部分，其尚未构成问题但是值得进一步调查。在一些实施例中，由属性检查组件340输出的结果可以由指导引擎(诸如图1中示出的说明性指导引擎110)处理，以向用户提供适当的反馈建议。

图5示出了根据一些实施例的说明性源程序500和说明性属性查询510和515。例如，源程序500可以是图3中示出的输入程序代码的一部分，并且属性查询510和515可以被包括在图3中示出的要检查的属性中。

在图5中示出的示例中，属性查询505包括具有WHEN子句的PERFORM语句。如果满足WHEN子句中指定的条件，则PERFORM语句可以指定要执行的一个或多个动作。在一些实施例中，WHEN子句可以指定模式，并且如果在输入程序代码中检测到WHEN子句中指定的模式，则可以执行PERFORM语句中指定的一个或多个动作。

例如，在图5示出的示例中，WHEN子句指定了一种以下模式，其中变量$x的赋值包括对getStringParameter或getRawParameter的调用。属性检查组件(例如，图3中示出的说明性属性检查组件340)可以搜索输入程序代码以识别WHEN子句中指定的模式的匹配。如果找到匹配，则属性检查组件可以执行PERFORM语句以将名为tainted的字段添加到匹配的变量，并将该字段的值设置为true。以这种方式，属性检查组件经由属性查询可以是可编程的(例如，属性查询510告诉属性检查组件在程序代码中寻找什么，并且一旦找到代码的相关部分，要维持什么信息)。

例如，在图5中示出的源程序500中，变量$x可以与accountName匹配，这是因为在520处的accountName的赋值包括对getRawParameter的调用。这可能导致属性检查组件执行PERFORM语句，添加字段accountName.tainted并将该字段的值设置为true。

在一些实施例中，属性检查组件可以被编程为传播诸如accountName.tainted的添加字段的值。例如，在525处的源程序500中，变量accountName用于变量query的赋值。这可能会导致字段query.tainted被添加且该字段的值设置为true。因此，在该示例中，属性检查组件被编程为在语法上(例如，经由对getRawParameter的语法模式匹配)和语义上(例如，经由对字段tainted的数据流分析)分析源程序500。

在一些实施例中，属性检查组件可以被编程为检测和维持类型信息。例如，在530处的源程序500中，变量statement的赋值包括对connection.createStatement的调用。属性检查组件可以被编程为基于该赋值来确定类型信息，并将该类型信息与变量statement相关联。

在图5示出的示例中，属性查询515包括MATCH子句、WHERE子句和REWRITE子句。如果满足MATCH和WHERE子句指定的条件，则REWRITE子句可以指定对程序代码进行的一个或多个修改。

例如，在图5中示出的源程序500中，对象$o可以与535处的statement匹配，方法$f可以与540处的executeQuery匹配，并且参数$1可以与545处的变量query匹配。然后，属性检查组件可以使用与变量statement相关联的类型信息来确定与statement匹配的对象$o是java.sql.statement的实例。属性检查组件可以进一步确定与executeQuery匹配的方法$f的名称与正则表达式“execute.*”匹配，并且与变量query匹配的参数$1的tainted字段的值为true。由于满足WHERE子句中的所有条件，因此属性检查组件可以执行REWRITE子句，其可以用API.sanitize(query)来替换变量query，使得源程序500中的最后一行可以变为：

ResultSet results＝statement.executeQuery(API.sanitize(query))。

因此，在该示例中，属性查询515对属性检查组件进行编程以使用语法信息(例如，子串execute的存在)、数据流信息(例如，字段tainted的传播)和类型信息(例如，变量statement的类型)来确定是否对输入程序代码进行特定修改。

应当理解，属性查询510和515在图5中示出并且仅出于说明的目的在上面描述。本公开的方面不限于语法分析、数据流分析或类型分析的使用。此外，本公开的方面不限于REWRITE子句的使用，这是因为属性检查组件有时可以在没有建议对输入程序代码进行修改后的情况下报告了找到。

图6示出了根据一些实施例的可由分析引擎执行的说明性过程600。例如，过程600可以由图3中示出的说明性分析引擎300执行，以构建说明性应用架构模型310并检查一个或多个属性。

在动作605处，分析引擎可以将输入程序代码编译成合适的表示，诸如抽象语法树(AST)。图7示出了根据一些实施例的用于说明性程序705的说明性AST 700。发明人已经认识到并理解，AST可以用于捕获程序的结构并且促进诸如注释和/或修改之类的操作。然而，应当理解，本公开的方面不限于AST的使用或任何表示。可以代替AST或者除了AST之外所使用的表示的示例包括但不限于：字节代码、机器代码、控制流程图表、对语义建模的逻辑公式等。

在动作610处，分析引擎可以选择要应用于在动作605处构建的AST的一个或多个发现查询。例如，在一些实施例中，分析引擎可以被编程为选择和检索(例如，从数据库)先前构建的框架模型，其包括一个或多个发现查询。选择可以基于关于输入程序代码的任何合适的信息，诸如编写输入程序代码的一种或多种编程语言、和/或由输入程序代码使用的一个或多个外部组件(例如，框架、库和/或中间件)。另外地或可替选地，分析引擎可以被编程为基于要执行的分析类型(例如，寻找一般安全漏洞，或者一个或多个特定类型的安全漏洞)来选择和检索(例如，从数据库)一个或多个发现查询。

在一些实施例中，分析引擎可以检索(例如，从数据库)用户选出的发现查询。另外地或可替选地，分析引擎可以经由用户界面接收由用户编写的发现查询。在一些实施例中，用户界面可以是IDE的一部分，但这不是必需的。

在动作615处，分析引擎可以将在动作610处选出的一个或多个发现应用于在动作605处构建的AST。发现查询的说明性应用在图4中示出并在上面讨论。

在一些实施例中，分析引擎可首先应用一个或多个发现查询以从动作605处构建的AST提取相关信息，从而构建简化的AST。然后，分析引擎可以将一个或多个发现查询应用于简化的AST以构建应用架构模型。可替选地或另外地，分析引擎可以将一个或多个发现查询直接应用于在动作605处构建的AST以构建应用架构模型。可以使用任何合适的方法来遍历AST。例如，在一些实施例中，可以基于控制流来访问AST节点，并且可以检查AST节点之间的关系以检查查询。在一些实施例中，可以在这种遍历期间维持分析状态。例如，当访问AST节点时，可以在分析状态中记录语义信息，这可以在处理下一个AST节点时可用。然后查询可以通过存储在分析状态中的信息进行检查。

在动作620处，分析引擎可以将一个或多个属性查询应用于在动作615处构建的应用架构模型。另外地或可替选地，分析引擎可以将一个或多个属性查询应用于在605处构建的AST、和/或在动作605处构建的任何简化的AST(例如，在605处构建的AST的部分、和/或在动作605处构建的任何简化的AST，其对应于在动作615处构建的应用架构模型中的组件模型)。属性查询的说明性应用在图5中示出并在上面讨论。

在动作625处，分析引擎可以确定在动作620处的一个或多个属性查询的应用是否导致任何感兴趣的观察。如果存在感兴趣的观察，则分析引擎可以在动作630处输出一个或多个结果。一个或多个结果可以包括对识别出的问题的指示(例如，安全漏洞)、用于修复识别出的问题的对输入程序代码的建议修改、分析引擎无法关于某个属性得出结论的指示、值得进一步调查的代码的一部分、和/或任何其他感兴趣的观察。

在动作635处，分析引擎可以确定在动作620处的一个或多个属性查询的应用是否已导致了对输入程序代码的建议修改。如果存在对输入程序代码的建议修改，则分析引擎可以在动作640处转换在动作605处构建的AST。例如，分析引擎可以执行变异查询(例如，使用REWRITE子句)以将代码的一部分(例如，图5的示例中的变量query)用代码的另一部分(例如，图5的示例中的API.sanitize(query))替换。

在动作645处，分析引擎可以使用转换的AST来修改输入程序代码并输出修改后的程序代码。在一些实施例中，可以提供用户界面以允许用户授权使用修改后的程序代码和/或在沙箱中测试修改后的程序代码。可替选地或另外地，可以在版本控制系统中为由分析引擎生成的修改后的程序代码创建分支。

在输出修改后的程序代码时，或者如果在动作635处确定出不存在对输入程序代码的建议修改，则分析引擎可以返回到动作625以确定是否存在任何额外感兴趣的观察。发明人已经认识到并理解，一些属性查询可能需要更多的计算时间来回答。因此，在一些实施例中，分析引擎可以被编程为递增地输出结果。例如，分析引擎可首先从简单检查(例如，语法模式匹配)递送结果，而分析引擎仍在执行深度分析(例如，模型检查)。以这种方式，用户可以立即开始审查并解决来自简单检查的结果，而不必等待深度分析完成。

应当理解，以上仅出于说明的目的描述了实现的细节，这是因为本公开的方面不限于任何特定的实现方式。例如，在一些实施例中，可以提供单独的指导引擎，其消耗分析引擎的输出并基于分析引擎的输出向开发者呈现指导。

III.查询语言

发明人已经认识到并理解，关于一个或多个感兴趣属性提供用于理解、建模、检查和/或修复软件应用的统一方法(例如，一般的安全漏洞、或者一种或多种特定类型的安全漏洞)可能是有益的。

在一些实施例中，可以提供查询语言以允许用户对软件验证的任何一个或多个方面编程，其可以包括但不限于：

-对由软件应用使用的一个或多个外部组件(例如，框架、库和/或中间件)建模；

-构建抽象掉(abstract away)无关信息(例如，与某种类型的分析诸如安全分析无关的信息)的应用的模型；

-指定要针对应用检查的一个或多个属性；

-指定如果识别出问题应如何修复应用；和/或

-控制分析引擎如何分析应用。

在一些实施例中，可以提供比现有技术更具表现力的查询语言以用于验证软件应用。例如，查询语言可以是完整的现实编程语言(例如，JavaScript)的超集。在一些实施例中，可以提供比现有技术更强大的查询语言以用于验证软件应用。例如，查询语言可用于定义程序和/或程序使用的外部组件(例如，框架、库和/或中间件)的语义抽象。另外地或可替选地，查询语言可用于查询程序语义。在一些实施例中，可以提供比现有技术更方便使用的查询语言以用于对软件应用建模。例如，查询语言可以具有简洁的语法并且可以允许模块化定义。

图8示出了根据一些实施例的说明性查询语言的一些组件的巴科斯范式(BNF)定义。例如，可以使用这种查询语言来编写图4中示出的说明性发现查询420和图5中示出的说明性属性查询510和515。

发明人已经认识到并理解，具有图8中示出的和/或本文描述的说明性构造的查询语言可以有利地提供用于软件验证的富有表现力、功能强大且方便的方法。例如，这些构造可以允许使用相同的查询语言来指定不同类型的分析(例如，静态扫描、数据流分析、模糊测试、动态扫描等)，从而可以将不同类型的分析以深入的方式组合在一起。此外，这些构造可以允许使用相同的查询语言来查询不同的数据源，从而可以集体评估关于不同数据源的查询结果。

然而，应当理解，本公开的方面不限于使用具有图8中示出的和/或本文描述的所有构造的查询语言。在各种实施例中，这些构造中的任何一个或多个和/或其他构造可以被包括在查询语言中。

A.语法匹配块

在一些实施例中，查询语言可以包括用于分析引擎的语法匹配块、流操作符、语义谓词、副作用语句和/或应用编程接口(API)函数的构造。

-语法匹配块可以基于任何一种或多种编程语言的源代码语法，诸如JavaScript、Java、C/C++/Objective-C、SWIFT、ASP.NET、Python、Ruby等。

-流操作符可用于连接语法匹配块以描述程序的不同部分之间的流。

-语义谓词可以使用一阶逻辑和/或原生构造(native construct)来构建，并且可以用于语义查询。

-副作用语句可用于指示分析引擎执行特定动作，诸如为程序构建模型和/或修改输入程序代码。

-API函数可用于访问分析引擎的内部状态和/或对分析引擎如何执行分析进行编程。

在一些实施例中，可以提供查询语言，其直接使用源语言语法进行语法匹配。例如，在图8示出的示例中，符号<{<source syntax>}>描述了用于匹配源语言中的语法元素的语法匹配块，其中如果找到匹配，则对自由变量赋值(其以“$”为前缀)。因此，该查询语言中的语法匹配可以取决于源语言的语法(例如，JavaScript、Java、C/C++/Objective-C、SWIFT、ASP.NET、Python、Ruby等)。

作为示例，如果在源语言中变量赋值由“＝”表示，则语法匹配块<{a＝$b}>可以匹配将值赋值给变量a的任何赋值语句。例如，语法匹配块<{a＝$b}>可以匹配语句a＝a+x，其中语法元素a+x可以被赋值给自由变量$b。

作为另一示例，以下语法匹配块可以特定于Java SpringMVC的语法。

<{@RequestMapping(value＝$1,method＝$2)

$f

}>

该语法匹配块可以将函数声明与路由信息的注释匹配，其中路由的URL可以被分配给自由变量$1，HTTP方法的名称可以被分配给自由变量$2，并且函数声明可以分配给自由变量$f。

在一些实施例中，语法匹配块可以包括OR作为语法操作符。例如，语法匹配块<{getStringParameter()OR getRawPammeter()}>可以匹配对getStringParameter或getRawParameter的函数调用。

在一些实施例中，语法匹配块可以包括用于“不关心”元素的字符(例如，“_”)。例如，只要for循环的主体匹配，以下模式就可以匹配任何for循环而不管条件如何。

在一些实施例中，语法匹配块可包括语法操作符AS。例如，语法匹配块<{$f(_,$2)}>AS$call可以匹配对两个参数的函数调用。当找到匹配时，函数名称可以分配给$f，并且第二个参数可以分配给$2，而第一个参数可能不存储。由于使用了AS操作符，因此整个函数调用信息(包括函数名、函数声明和/或一个或多个匹配的参数)可以存储在$call中。

在一些实施例中，语法匹配块可以包括多层静态作用域(scope)。例如，嵌套作用域可以使用大括号表示，并且可以根据源语言(例如，JavaScript、Java、C/C++/Objective-C、SWIFT、ASP.NET、Python、Ruby等)的语法进行匹配。作为示例，上面的说明性for循环模式可以在以下程序代码中具有两个匹配。

在第一个匹配中，语法元素x>A[i]被分配给$1，并且语法元素if(b[k])x＝1被分配给$2。在第二个匹配中，语法元素b[k]被分配给$1，并且语法元素x＝1被分配给$2。在两个匹配中，两个作用域(即，for循环和if分支)在语法上匹配。

B.流操作符

在一些实施例中，查询语言可以包括一个或多个流操作符，例如，用于描述语法元素之间的关系。例如，可以使用一个或多个时间操作符来描述语法元素如何流向另一个语法元素。在一些实施例中，分析引擎可以通过有限状态机算法来匹配流语句。例如，可以定义包括至少两个状态的有限状态机。在第一状态，分析引擎可以分析输入程序代码的部分，寻找第一语法元素。分析引擎可以保持在第一状态直到第一语法元素匹配。一旦第一语法元素匹配，分析引擎就可以移动到第二状态，其中分析引擎可以分析输入程序代码的另外部分，寻找第二语法元素。

在一些实施例中，可以使用基本流操作符(--＞)来表示语法元素在至少一个程序路径中后面跟随另一个语法元素。作为一个示例，如果一个函数调用在至少一个程序路径中后面跟随另一个函数调用(其中两个函数可以不同，但两个函数中的每个都具有信号参数)，则可以匹配流语句<{$f1($a1)--＞$f2($a2)}>。之前调用的函数的名称可以分配给$f1，并且该函数的参数可以分配给$a1，而稍后调用的函数的名称可以分配给$f2，并且该函数的参数可以分配给$a2。

作为另一示例，如果存在至少一个程序路径，其中对先前分配了对getStringParameter或getRawParameter的调用的返回值的变量调用对象的方法，则可以匹配随后的流语句。可以将变量的名称分配给$x，可以将对象的名称分配给$o2，并且可以将对象的函数名称分配给$f。

<{Sx＝_·getStringParameter()OR_·getRawParameter()--＞$o2.$f($x)}>

在一些实施例中，可以使用全路径流操作符(-AP-＞)来表示在所有程序路径中语法元素后面跟着另一个语法元素。例如，如果在所有程序路径中对具有第一个参数的第一个函数的调用后面跟着对具有第二个参数的第二个函数的调用，则可以匹配流语句<{$f1($a1)-AP-＞$f2($a2)}>。第一个函数的名称可以分配给$f1，并且第一个参数可以分配给$a1，而第二个函数的名称可以分配给$f2，并且第二个参数可以分配给$a2。

在一些实施例中，可以使用缺席操作符(MISSING)来表示在没有程序路径的情况下，第一语法元素在第二语法元素和第三语法元素之间发生。例如，如果存在第一个函数调用后面跟着第二个函数调用的程序路径，并且在两个函数调用之间没有对于第二个函数调用的参数的分配，则可以匹配流语句<{$f1($a1)--＞MISSING $a2＝_--＞$f2($a2)}>。

在一些实施例中，操作符FIRST和LAST可以分别用于匹配语法元素的第一次和最后一次出现。例如，如果在至少一个程序路径中对fl的第一次调用在对f2的最后一次调用之前(其中可以忽略该程序路径中对fl和f2的其他调用)，则可以匹配流语句<{FIRST f1($a1)--＞LASTf2($a2)}。

C.语义谓词

在一些实施例中，可以提供查询语言，其包括用于表达与变量值、类型等有关的属性的一个或多个语义谓词。与可以用于查询程序的语法的语法匹配块不同，语义谓词可用于查询程序的语义，诸如变量的值、变量的类型和/或变量之间的语义关系。

在一些实施例中，可以使用一阶逻辑和/或原生构造来构建语义谓词。用于构建语义谓词的操作符的示例包括但不限于：

-算术操作符(例如，+、-、*、/、％等)；

-关系操作符(例如，>＝、>、＝＝等)；

-命题逻辑操作符(例如，AND、OR、NOT、IMPLY等)；

-一阶逻辑量词(例如，EXIST、FORALL等)；

-特定于域的操作符(例如，RegExp.match、string.indexOf等)；

-类型操作符(例如，instanceof、ISCONSTANT等)；和/或

-流操作符(例如，USE、CALL等)。

在一些实施例中，如果在集合c中存在值v使得body中指定的条件为true，则存在量化的表达式EXIST v IN c：body可以求值为true。作为一个示例，表达式EXIST x IN[1,2]：x>0可以求值为true，这是因为在范围[1,2]中存在值x，使得x大于0。作为另一示例，如果参数集f.arguments中存在参数，使得参数的taint字段设置为true，则表达式EXIST argIN f.arguments:arg.taint＝＝true可以求值为true。

在一些实施例中，如果对于集合c中的每个值v，在body中指定的条件为true，则普遍量化的表达式FORALL v IN c:body可以求值为true。例如，如果对于对象_model.routes中的每个索引y，由y索引的路由_model.routes[y]不为null，则以下表达式可以求值为true。

FORALL y IN_model.routes:_model.routes[y]！＝null

在一些实施例中，数据流操作符USE可用于表示第二语法元素的值用于计算第一语法元素的值。例如，如果赋值给$input的语法元素的值用于计算赋值给$arg的语法元素的值，则表达式$arg USE$input可以求值为true。

在一些实施例中，控制流操作符CALL可用于表示对第一函数的调用包括对第二函数的调用。例如，如果对分配给$fl的函数的调用包括对分配给$f2的函数的调用，则表达式$fl CALL$f2可以求值为true。

D.副作用语句

在一些实施例中，可以提供包括一个或多个副作用构造的查询语言。例如，可以使用副作用构造来定义发现查询，诸如图4中示出的说明性发现查询420。

在一些实施例中，可以使用以下说明性副作用构造，其中如果满足WHEN子句中指定的条件，则PERFORM语句可以指定要执行的一个或多个动作。

PERFORM<statement>WHEN<syntax matching block>

在一些实施例中，WHEN子句可以指定模式，并且如果在输入程序代码中检测到WHEN子句中指定的模式，则可以执行PERFORM语句中指定的一个或多个动作。例如，PERFORM语句可以包括一段可执行代码，其中WHEN子句可以包括语法匹配块(其继而可以包括语义谓词)。在一些实施例中，查询语言可以是高级编程语言(例如，JavaScript)的语法的超集，因此PERFORM语句可以使用由高级编程语言提供的任何一个或多个构造。

例如，当由分析引擎执行时，以下发现查询可以致使分析引擎搜索输入程序代码以声明MVC架构中的路由函数，其中声明中的HTTP方法是RequestMethod对象的方法。路由的URL可以分配给自由变量$1，方法的名称可以分配给自由变量$2，路由函数的名称可以分配给自由变量$3，并且整个函数声明可以分配给自由变量$f(使用AS操作符)。PERFORM语句可以致使分析引擎将函数声明存储在路由模型中(例如，诸如图3中示出的说明性路由模型330)。

PERFORM_model.routes[$l][$2].callbacks＝[$f]

WHEN<{@RequestMapping(value＝$1,method＝RequestMethod.$2)

function$3(_){_}AS$f}>

另外地或可替选地，可以使用PERFORM语句将数据注入AST(例如，直接从输入程序代码编译的AST，或通过移除某些信息构建的简化的AST)。例如，在下面的说明性PERFORM语句中，WHEN子句可以指定以下一种模式，其中变量$x的赋值包括对getStringParameter或getRawParameter的调用。如果分析引擎找到此模式的匹配项，则分析引擎可以将名为tainted的字段添加到匹配变量，并将该字段的值设置为true。在一些实施例中，分析引擎可以被编程为传播tainted字段的值。

PERFORM$x.tainted＝true

WHEN<{$x＝getStringParameter()OR getRawParameter()}

在一些实施例中，在添加的字段中维持的数据可以用于促进属性检查和/或代码编辑。例如，以下说明性属性查询可用于检查对对象的方法的调用的参数是否是tainted，并且如果是，则将参数替换为参数的sanitized版本。

<{$o.$f($l)}>

WHERE$1.tainted＝＝true

REWRITE$1<＝SanitizerAPI.sanitize($l)

图9示出了根据一些实施例的说明性AST 900向转换后的AST 905的转换。例如，该转换可以由分析引擎在执行上面描述的说明性属性查询时执行，以在节点915处用不同的子树在语法上替换被分配给自由变量$1的子树910。新子树可以对应于将SanitizerAPI库中的sanitize函数应用于参数$1，并且可以通过将子树910附加到节点915作为SanitizerAPI.sanitize的参数来构造。

图10示出了根据一些实施例的说明性源程序1050和说明性属性查询1055。在该示例中，源程序1050可以实现两个比特串之间的逐位比较，其可以是加密摘要，诸如CRC(循环冗余校验)或UMAC(加密散列消息认证码)。该特定实现可能易受旁路攻击(side-channelattacks)，这是因为for循环的执行时间可能依赖于输入。例如，如果在比特串的早期检测到差异，则for循环可以提前退出，并且如果比特串相同，则可以遍历比特串的整个长度。这种比较有时被称为“快速失败(fail fast)”比较。

在一些实施例中，属性查询可以对分析引擎进行编程以检测“快速失败”比较。例如，在图10中示出的示例中，可以使用数据流操作符USE来编写属性查询1055，这可以致使分析引擎搜索具有两个字节数组作为参数($a和$b)的函数声明并且在for循环的主体中包括具有if语句的for循环，其中if语句的条件($1)取决于两个字节数组参数($USE$a AND$2USE$b)。因此，属性查询1055可以致使分析引擎执行语法匹配和数据流分析的组合以检测“快速失败”比较。

在一些实施例中，属性查询可以对分析引擎进行编程以移除由“快速失败”比较引起的漏洞。图11示出了根据一些实施例的说明性属性查询1100。与图10中示出的说明性属性查询1055类似，属性查询1100可以对分析引擎进行编程以检测“快速失败”比较。另外，属性查询1100可以致使分析引擎将对应于for循环的语法元素(例如，AST中的子树)分配给自由变量$body，例如，在1110处使用AS操作符。在1115处，属性查询1100可以使分析引擎用新主体1105替换分配给$body的语法元素，从而产生转换后的函数声明。即使检测到差异，转换后的for循环也可能不会提前退出，从而消除了针对旁路攻击的漏洞。

E.分析引擎API函数

在一些实施例中，可以提供查询语言，其包括用于访问分析引擎的内部状态和/或对分析引擎如何执行分析进行编程的一个或多个API函数。发明人已经认识到并理解分析引擎可以维护有用的信息，诸如AST(例如，直接从输入程序代码编译的AST，和/或通过移除某些信息而构建的简化的AST)、变量值、变量类型、分析结果、内部数据结构、内部数据之间的关系等。因此，查询语言可以实现用于暴露由分析引擎维护的一些或全部信息的协议。

例如，分析引擎可以将函数闭包(function closure)维持为AST中的函数的内部表示。该闭包可以包括诸如原始AST、父作用域、类型信息、函数体的主体内的成员声明等信息。在一些实施例中，可以使用API构造$f.ast来获得由分析引擎为分配给$f的语法元素存储的AST，并且API构造$f.ast.name可用于获得AST中的函数名。另外地或可替选地，语句FORALL v IN$f:v instance of String可用于枚举函数闭包中为String类型的所有数据成员。

F.别名(aliase)、宏(macro)和模块(module)

在一些实施例中，查询语言可以允许别名、宏和/或模块的定义。发明人已经认识到并理解，这些定义可用于增强可重用性和模块化。然而，应当理解，本公开的方面不限于使用任何别名、宏或模块。

在一些实施例中，关键字let可用于引入别名。示例如下。

let source＝getStringParameter()OR getRawParameter()

利用该说明性别名，以下查询是等同的。

-PERFORM$x.tainted＝true

WHEN<{$x＝source>}

-PERFORM$x.tainted＝true

WHEN<{$x＝getStringParameter()OR getRawParameter()>}

在一些实施例中，关键字DEFINE可用于引入宏。示例如下。

DEFINE isStatement(v){v instance of java.sql.Statement；}

使用此说明性宏，以下查询是等效的。

-MATCH<{$o.$f($l)}>

WHERE isStatement($o)

-MATCH<{$o.$f($l)}>

WHERE$o instance of java.sql.Statement；

在一些实施例中，关键字IMPORT可用于从查询源文件加载一个或多个查询定义。该构造可以有利地允许模块化查询定义。

图12示出了根据一些实施例的模块的说明性网络1200。网络1220可以包括对应于第一查询源文件1205的节点模块1、对应于第二查询源文件1210的节点模块2、以及对应于第三查询源文件1215的节点模块3。第一查询源文件1205可以包括用于MVC架构的框架模型，第二查询源文件1210可以包括用于Node.js运行时环境的框架模型，并且第三查询源文件1215可以包括用于Express框架的框架模型。

在图12示出的示例中，可以经由IMPORT语句将第一查询源文件1205导入到第二查询源文件1210中，使得Node.js框架模型中的查询可以利用MVC框架模型中的查询定义。类似地，可以经由IMPORT语句将第二查询源文件1210导入第三查询源文件1215，使得Express框架模型中的查询可以利用Node.js框架模型和/或MVC框架模型中的查询定义。

发明人已经认识到并理解，诸如图12中示出的模块的组织可以提高查询定义的可重用性。然而，应当理解，本公开的方面不限于使用模块来组织查询定义。

F.库和高级查询

发明人已经认识到并理解，将某些常用的查询定义存储在库中可能是有益的，从而可以通过简单地加载库来访问这些定义。例如，用于发现和/或操纵用于web应用的MVC组件的查询定义可以存储在库中，并且用于发现和/或操纵用于移动app(例如，用于Android^TM操作系统和/或iOS^TM操作系统)的MVC组件的定义可以存储在相同或不同的库中。

图13示出了根据一些实施例的示例性名词集合，其可以在查询语言中用于访问MVC架构中的组件。在一些实施例中，可以提供MVC库，其包括用于发现和/或操纵MVC组件的一个或多个预定义查询。MVC库可以允许用户使用图13中示出的名词作为查询语言中的高级关键字。

在一些实施例中，MVC库可以包括对分析引擎进行编程以构建MVC组件模型的一个或多个发现查询。例如，分析引擎可以对输入程序代码运行发现查询并构建以下说明性模型。

图14示出了根据一些实施例的MVC组件的说明性层级1400。例如，层级1400可以表示来自上述说明性模型的MVC组件，其中已经发现了针对控制器1(controller1)的两个动作(action)，但是还没有发现针对控制器2(controller2)的动作。

在一些实施例中，图13中示出的名词可用于访问MVC组件模型，诸如图14中示出的那些。任何合适的高级语言构造可用于查询MVC名词。例如，查询可以使用Xpath、Jquery或类似CSS的搜索，并且可以方便地返回一个或多个元素的集合。

作为一个示例，使用Xpath语法编写的以下高级查询可用于选择实现了GET请求的方法的所有路由。

//route[@method＝'get']

在一些实施例中，可以如下实现该高级查询。

作为另一示例，使用Xpath语法编写的以下高级查询可用于选择应用中的最后视图。低级实现可以类似于上面针对//route[@method＝'get']./app/view[last()]示出的说明性实现。

作为另一示例，使用Xpath语法编写的以下高级查询可用于选择AST中具有父级(parent)的所有视图，使得父级具有至少三个子节点。低级实现可以基于Xpath解释器如何处理这样的查询。

//view[@ast.parent.children.num>2]

在一些实施例中，名词之间的关系可以使用动词来表达，其中动词可以是用于低级实现的语法糖。作为一个示例，动词bound可以具有以下语法。

<View(v)>bound<Controller(_)>

该语句可以如下实现。

EXISTS c IN_model.controller:_model.controller[c].view＝＝v

作为另一示例，动词manipulate可具有以下语法。

<View Resolver(_)>manipulate<View(v)>

该语句可以如下实现。

EXISTS r IN_model.view[v]:_model.view[v][r].resolver！＝null

作为另一示例，动词call可具有以下语法。

<Request(r)>call<Function(f)>

该语句可以如下实现。

_model.request[r].handler＝f

作为另一示例，动词短语set...to...可以具有以下语法。

<Session>set<Field(f)>to<Value(v)>

该语句如下实现。

_model.session[f]＝v

发明人已经理解，在某些情况下，名词和动词可能比查询语言的基本构造更方便使用。然而，应当理解，本公开的方面不限于使用名词或动词来补充查询语言的语法。此外，这里描述的技术可以应用于除MVC之外的软件架构，这是因为本公开的方面不限于此。

IV.基于模型的软件应用的分析

复杂和大型软件应用的可扩展分析长期以来一直是一个挑战。应用可以包含许多组件，使用各种外部组件(例如，框架、库、中间件等)，并展示复杂的架构。发明人已经认识到并理解在可伸缩性和准确性之间可能存在折衷。准确的分析通常涉及详细的建模和严格的检查，这可以提供对应用的语义的深刻理解，但是可能需要大量的时间和精力(例如，用于人类制定分析，且用于机器执行分析)。因此，提供具有改进后的可扩展性和准确性的分析技术可能是有益的。

发明人已经认识到并理解，一些解决方案可能为了可伸缩性牺牲准确性，而其他解决方案可能为了准确性牺牲可伸缩性。例如，语法分析(例如，基于grep)可用于从源代码检索信息，并且数据流分析(例如，基于比特传播)可用于理解应用如何使用数据。发明人已经认识到并理解这些技术可能涉及过度近似，这可能导致误报。

另一方面，动态分析技术可以应用较少的近似(例如，关于组件之间的关系或关于变量值)，并且因此可以更准确。然而，发明人已经认识到并理解动态分析技术可能具有低覆盖率(例如，由于计算约束)，这可能导致假阴性。

发明人已经认识到并理解，随着诸如框架和库之类的更多外部组件被用于软件应用中，并且随着软件架构变得更加复杂，实现准确性和可伸缩性两者可能更加困难。尽管用户可以单独地对应用的各个部分进行建模和分析，但是这种特设方法不仅乏味，而且不可靠，这是因为可能无法充分地对单独建模的部分之间的交互进行建模。

因此，在一些实施例中，提供了用于实现可伸缩性和准确性之间的期望平衡的技术。例如，一条或多条信息、包括但不限于软件架构(例如，一个或多个组件和/或组件之间的连接的存在)、程序语义、领域知识(例如，关于一个或多个框架、库、中间件等)可以用于将分析引擎聚焦在与特定分析相关的应用的一个或多个部分上。在一些实施例中，可以在一个或多个模型中明确地记录这样的信息。

在一些实施例中，分析引擎可以被编程为构建用于软件应用的应用架构模型。应用架构模型可以包括架构中的独立组件的模型。给定某个感兴趣的属性，分析引擎可以选择一个或多个相关的组件模型。然后，分析引擎可以针对选出的组件模型检查感兴趣的属性。使用这种分而治之的方法，可以减少分析引擎分析的信息量，同时还可以减少丢失一些相关信息的风险，这是因为组件模型是基于应用架构的知识构建的。

在一些实施例中，分析引擎可以被编程为随着软件应用的发展而执行增量分析。例如，当修订或添加源代码的一部分时，分析引擎可以确定受影响的一个或多个组件模型，并且可以仅重新生成和/或重新分析受影响的组件模型。这可以显着改善分析引擎的响应时间，并且从而改善用户的接受度。

在一些实施例中，分析引擎可以被编程为自适应地分析应用。例如，给定某个感兴趣的属性，分析引擎可以选择可以适用于检查该属性的一种或多种类型的模型。然后，分析引擎可以构建和分析选出的类型的一个或多个模型。在一些实施例中，可以通过抽象掉与要检查的属性无关的信息来构建模型，从而提高分析引擎的效率。

图15示出了根据一些实施例的可用于促进软件应用的分析的模型的说明性网络1500。例如，图15中示出的说明性模型可以由分析引擎(例如，图1中示出的说明性分析引擎105)使用，以检查关于一个或多个感兴趣属性的输入程序代码1505。

在图15中示出的示例中，输入程序代码1505可以使用一个或多个外部组件1515。外部组件的示例包括但不限于框架、库、中间件等。针对外部组件1515的框架模型1520可以使用查询语言(例如，经由发现查询)构建，并且可以表示外部组件1515的抽象(例如，出于安全性分析的目的)和/或外部组件1515之间的交互。在一些实施例中，框架模型可以被索引并存储在数据库中，并且可以根据需要进行检索。

在一些实施例中，输入程序代码1505可以被编译成合适的表示，诸如AST1510。然后可以通过应用来自框架模型1520的一个或多个发现查询以从AST1510提取相关信息来构造简化的AST 1525。例如，发现查询可以用于识别和提取AST 1510中与安全性分析相关的信息，并且提取的信息可以存储在简化的AST 1525中。

在图15示出的示例中，框架模型1520和简化的AST 1525用于构建应用架构模型1530。应用架构模型1530可以包括高级信息，诸如软件架构(例如，一个或多个组件和/或组件之间的连接)、程序语义和/或领域知识(例如，关于一个或多个框架、库、中间件等)。例如，应用架构模型1530可以包括用于软件架构中的独立组件的模型，诸如图15中示出的组件模型1、组件模型2、组件模型3等。

在图15中示出的示例中，网络1500还包括属性模型1535。在一些实施例中，分析引擎可以接收属性查询1540作为输入，其可以捕获感兴趣的属性(例如，某些安全属性)的语义。基于属性查询1540，分析引擎可以选择适当的属性模型类型并构造选出的类型的属性模型。例如，属性模型1535可以是选出的类型，并且可以由分析引擎从简化的AST 1525和/或应用架构模型1530导出。然后，分析引擎可以检查属性模型1535以确定感兴趣的属性是否满足。

在一些实例中，应用架构模型1530可以包括足够的高级信息以允许分析引擎在不分析低级源代码的情况下确定是否满足某个属性。这可以允许分析引擎更快地产生结果，从而改善用户体验。例如，配置参数的值可以从输入程序代码中提取，并且可以存储在应用架构模型1530中(例如，在表格中)。当需要一个或多个这样的值时，分析引擎可以简单地从应用架构模型1530检索一个或多个所需值，而不必在输入程序代码中寻找这样的值。然而，应当理解，本公开的方面不限于在应用架构模型中存储配置参数值。

应当理解，实施的细节在图15中示出并且仅出于说明的目的在上面描述，这是因为本公开的方面不限于任何特定的实施方式。例如，本公开的方面不限于使用任何简化的AST。在一些实施例中，AST 1510而不是简化的AST 1525可以用于生成应用架构模型1530。

图16示出了根据一些实施例的说明性框架模型1600和1605。框架模型1600和1605可以由分析引擎(例如，图3中示出的说明性分析引擎300)使用以生成应用架构模型(例如，图3中示出的说明性应用架构模型310)。

发明人已经认识到并理解，软件应用(例如，框架、库、中间件等)使用的外部组件可以包括大量代码。例如，Express框架的源代码包括大约12000行JavaScript代码。因此，可能期望以简明的方式提供表示资源的语义的抽象。在没有这样的抽象的情况下，分析引擎可能无法足够快地分析资源以实时递送结果。

在一些实施例中，框架模型可以包括关于资源的相关信息的规范。例如，可以使用具有一个或多个构造(诸如图8中示出的和上面讨论的说明性构造)的查询语言来定义框架模型。

在图16示出的示例中，框架模型1600和1605分别表示Express框架和ExpressSession中间件的语义。例如，框架模型1600可以反映如何定义路由。另外地或可替选地，框架模型1600可以定义框架API。在一些实施例中，框架模型1600可以包括大约100行代码，这与Express框架的实际大小(大约12000行)相比显着减少。

图16示出了使用Express框架和Express Session中间件的说明性源代码片段1610。在一些实施例中，分析引擎可以被编程为用对相应框架模型的引用来替换对Express框架和Express Session中间件的引用，从而产生说明性代码片段1615。以这种方式，可以加载框架模型(例如，图6中示出的说明性框架模型1600和1605)，而不是Express框架和Express Session中间件的源代码。

图16还示出了使用HTTP中间件和Path中间件的说明性源代码片段1620。发明人已经认识到并理解一些外部组件可能与感兴趣的属性无关，并且因此不需要定义或加载这种资源的模型。这可以降低复杂性，并且从而提高分析引擎的性能。

在一些实施例中，可能感兴趣的是以下属性中的一种或多种。

1.会话cookie中的httpOnly标志是否设置为true？

2.在与/users有关的任何路由中，是否存在JavaScript注入？

3.在与用户注册有关的任何路由中，是否正确检查了用户名？

对于这些属性，会话cookie和路由可能是相关的，而诸如HTTP和Path的其他中间件可能不相关。因此，在一些实施例中，分析引擎可以被编程为忽略对HTTP中间件和Path中间件的引用，以及与HTTP中间件和Path中间件有关的所有后续代码。例如，可以基于领域知识来定义属性类型和相关中间件之间的映射，并且可以对分析引擎进行编程以使用该映射来识别可以被忽略的中间件。

图17示出了根据一些实施例的用于对分析引擎进行编程以执行字段和类型分析的方法。例如，可以使用查询语言对分析引擎进行编程以执行字段和类型分析。在一些实施例中，查询语言可以包括一个或多个构造，诸如图8中示出并在上面讨论的说明性构造。

在一些实施例中，查询语言可用于对分析引擎进行编程以跟踪对象中的字段的名称和类型、和/或对象中的成员函数的名称和类型。这些名称和类型可以与已知签名匹配，以使用该对象推断对象的角色和/或函数的角色。

例如，Express框架中的路由功能可以具有以下签名，并且可以使用查询语言来对分析引擎进行编程以确定函数是否匹配该签名。

function test(req,res,...)

请求对象req可以包含以下字段中的一个或多个：

-body

-session

-等等

响应对象res可以包含以下函数中的一个或多个：

-render，具有参数类型String×Object

-session，具有参数类型String

-等等

图17示出了说明性函数声明1700、1705和1710。在一些实施例中，分析引擎可以被编程为确定在说明性声明1700中，login函数具有两个参数，req和res，其中对象res具有带有参数类型String×Object的成员函数render。这可以匹配上述签名，并且分析引擎可以推断出login可能是路由函数。即使没有完美的匹配，也可以做出这样的推断。例如，即使对象req不包含任何字段，分析引擎也可以推断出login是路由函数。

在一些实施例中，分析引擎可以被编程为确定在说明性声明1705中，signup函数具有三个参数，req、res和next，其中req具有字段body，并且res具有参数类型为String×Object的成员函数render和参数类型为String的成员函数redirect。这可能与上述签名匹配(即使名称redirect与名称session不匹配也是如此)。因此，分析引擎可以推断signup是路由函数。

在一些实施例中，分析引擎可以被编程为确定在说明性声明1710中，test函数具有三个参数，req、res和next，其中req具有字段body，但res没有成员函数。因此，分析引擎可以确定出test不太可能是路由函数。

以下是可用于对分析引擎进行编程以执行字段和类型分析(例如，通过执行语法模式匹配)的查询的示例。

-寻找形式的函数f(req*,res*)。

PERFORM_model.routes['/UNKNOWN']['UNKNOWN']＝f

WHEN function f($l,$2)

WHERE$1.ast.name.startsWith(‘req’)AND$2.ast.name.startsWith('res')

-寻找具有拥有成员函数session、body或params的第一个参数或者拥有成员函数render或redirect的第二个参数的函数。

PERFORM_model.routes['/UNKNOWN']['UNKNOWN']＝f

WHEN function f($l,$2)

{$1.session OR$l.body OR$1.params OR$2.render OR$2.redirect}

在一些实施例中，分析引擎可以由框架模型编程以执行字段和类型分析以使用该对象推断对象的角色和/或函数的角色。框架模型可以包括以查询语言编写的一个或多个查询。对象(或函数)的推断角色可以与该对象(或函数)相关联地存储在应用架构模型中。例如，一个或多个发现的路由可以存储在路由模型中。

图18A示出了根据一些实施例的说明性应用1800和说明性组件模型1805和1810。在该示例中，使用Express框架编写应用1800。在一些实施例中，分析引擎可以被编程为应用Express框架的框架模型(例如，图16中示出的说明性框架模型1600)以构建应用1800的应用架构模型。应用架构模型可以包括一个或多个组件模型，诸如图18A中示出的组件模型1805和1810。组件模型1805可以是配置模型，并且组件模型1810可以是路由模型。例如，在一些实施例中，可以使用图16中示出的说明性框架模型1600和1605来生成组件模型1805和1810。例如，分析引擎可以将框架模型1600和1605解释为源代码1800，从而生成组件模型1805和1810作为输出。

图18B示出了根据一些实施例的可由分析引擎检查的安全问题的说明性群组1815、1820和1825。发明人已经认识到并理解，通过构建架构中的独立组件的模型，分析引擎可以能够快速识别要分析的相关信息并安全地忽略无关信息。作为一个示例，为了检查诸如跨站点请求伪造(CSRF)、配置、安全传输、会话cookie安全等的配置相关问题1815，分析引擎可以聚焦于配置模型1805。作为另一示例，检查每个路由问题1825，诸如无效重定向、SQL注入、JavaScript注入等，分析引擎可以聚焦于路由模型1810。相比之下，配置模型1805和路由模型1810两者都可能与群组1820中的安全问题相关，因此分析引擎可以在检查来自群组1820的问题时分析两个模型。

在一些实施例中，可以基于领域知识来定义属性类型和相应组件之间的映射，并且可以将分析引擎编程为使用映射来为要检查的特定属性选择一个或多个相关组件。以这种方式，可以减少由分析引擎分析的信息量，这可以提高分析引擎的性能，同时还可以减少丢失一些相关信息的风险，这是因为组件模型是基于应用架构的知识构建的。

图18C-图18E示出了根据一些实施例的安全责任的说明性分类法。这种分类法可以由安全专家创建，并且可以用于表征各种框架中的组件的功能责任。

图18F-图18G示出了根据一些实施例的从应用组件到安全责任的说明性映射。例如，图18F-图18G中示出的映射可以由安全专家基于特定框架(例如，MVC框架)的知识来创建，并且可以将框架中的每个组件映射到一个或多个安全责任(例如，图18C-图18E中示出的一个或多个说明性安全责任)。在一些实施例中，这种映射可以用于为要检查的特定安全属性选择一个或多个相关组件。

应当理解的是，在图18C-图18E示出的分类法和图18F-图18G中示出的映射仅仅是为了说明的目的而提供，这是因为本公开的方面不限于安全责任的任何特定的分类法、或将应用组件与分类法对齐的任何特定方法。

图19示出了根据一些实施例的可由分析引擎使用以检查感兴趣属性的属性模型的多个说明性类型。例如，分析引擎可以被编程为确定哪一种或多种类型的属性模型适合用于检查特定的感兴趣属性。另外地或可替选地，分析引擎可以被编程为针对软件应用生成选出类型的属性模型，并分析属性模型以确定软件应用是否满足感兴趣属性。

发明人已经认识到并理解不同类型的属性模型可能适合于调查不同类型的属性。作为一个示例，可以使用调用图表(call graph)来捕获函数调用关系，而可以使用数据流图表来捕获数据依赖信息(例如，如何传播tainted值)。作为另一个示例，类型系统可以用于记录变量和对象的类型。作为另一示例，抽象数值估计可用于估计数值变量的可能值，而字符串值估计可用于估计字符串变量的可能值。作为另一示例，堆(heap)形状模型可用于捕获堆中的组件之间的指针关系。作为另一个示例，谓词抽象可以用于捕获变量值之间的关系。图20示出了根据一些实施例的从属性类型到属性模型类型的说明性映射。

发明人进一步认识到并理解，不同类型的属性模型可以提供不同的优点。例如，如图19示出的，顶部的属性模型类型(例如，调用图表、数据图表和类型系统)可能更抽象，因此更容易计算但不太精确。相比之下，底部的属性模型类型(例如，抽象数值估计和字符串值估计)可能更详细，并且因此更精确但更难计算。因此，提供用于选择适当类型的属性模型以在效率和准确性之间实现期望平衡的技术可能是有益的。

图21示出了根据一些实施例的用于选择一个或多个属性模型类型并使用选出的类型的属性模型来分析软件应用的说明性过程。例如，在图21中示出的过程可以由分析引擎(例如，图1中示出的说明性的分析引擎105)使用以检查相对于感兴趣的一个或多个属性的输入程序代码。例如，可以从属性查询中检索关键字的集合。然后，对于每个关键字，可以分析一个或多个相关组件模型的集合以生成一个或多个属性模型。

图21示出了说明性的应用架构模型2100。在一些实施例中，应用架构模型2100可以通过将一个或多个框架模型应用于输入程序代码来构建(例如，如上面结合图15所讨论的)。应用架构模型2100可以包括高级信息，诸如软件架构(例如，一个或多个组件和/或组件之间的连接)、程序语义、和/或领域知识(例如，关于一个或多个框架、库、中间件等)。例如，应用架构模型2100可以包括用于软件架构中的独立组件的模型，诸如图21中示出的组件模型A和组件模型B。

图21还示出了说明性查询1和说明性查询2，其可以每个定义要检查的属性。在一些实施例中，分析引擎可以被编程为针对诸如查询1或查询2的查询选择一个或多个属性模型类型。例如，可以使用具有一个或多个构造(诸如图8中示出的和上面讨论的说明性构造)的查询语言来定义查询。分析引擎可以被编程为基于查询语言的语法来解析查询，并从查询中识别一个或多个语义谓词。在图21中示出的示例中，从查询1中提取语义关键字集合1，从查询2中提取语义关键字集合2，等等。

在一些实施例中，分析引擎可以基于识别出的语义谓词来选择一个或多个属性模型类型。例如，分析引擎可以使用识别出的语义谓词来将查询与图20中示出的说明性属性类型之一进行匹配，并且然后使用图20中示出的说明性映射来确定属性模型的适当类型。

在一些实施例中，针对应用架构模型2100中的组件模型(例如，组件模型A或组件模型B)分析引擎可以识别组件模型所相关于的一个或多个属性模型类型。例如，分析引擎可以针对每个查询和与所述查询相关联的每个属性模型类型确定组件模型是否与属性模型类型相关(例如，使用上面结合图18A-图18B描述的一种或多种技术)。如果组件模型被确定为与属性模型类型相关，则可以基于该组件模型来构建该类型的属性模型，并且可以分析该属性模型。可以输出该分析的结果作为查询的结果。在一些实施例中，分析引擎可以对来自检查各种属性模型的分析结果进行分组和/或优先级排序。然而，这不是必需的，这是因为在一些实施例中，分组和/或优先级排序可以由指导引擎执行，或者可以根本不执行。

发明人已经认识到并理解，图21中示出的说明性过程可以有利地用于提高分析引擎的效率。作为一个示例，如果从查询识别出的语义谓词仅涉及某些变量的类型和布尔/数值，则可以仅执行类型系统分析和数值估计，以及仅针对所涉及的变量。

发明人进一步认识到并理解，如果使用更抽象的模型来反驳属性，则可能不需要构建和分析更详细的模型。因此，在一些实施例中，可以对分析引擎进行编程以自适应地执行分析，例如，从更抽象的模型开始并且仅在需要时使用更详细的模型。

图22示出了根据一些实施例的说明性应用2200和应用2200的说明性分析。在该示例中，使用Express框架编写应用2200。在一些实施例中，分析引擎可以被编程为应用Express框架的框架模型(例如，图16中示出的说明性框架模型1600)以构建应用2000的应用架构模型。应用架构模型可以包括一个或更多组件模型，诸如图22中示出的说明性配置模型2215。

在一些实施例中，可以基于以下属性来指定查询，并且可以对分析引擎进行编程以从查询中识别语义谓词，诸如图22中示出的说明性语义谓词2205。

-在会话cookie中将httpOnly标志设置为true？

-查询语言中的说明性语义谓词：

○model.setting.cookie.httpOnly＝＝true

在一些实施例中，分析引擎可以基于语义谓词2205来选择属性模型的一种或多种类型。例如，分析引擎可以在2210处确定出(例如，使用结合图21描述的一种或多种技术)针对会话cookie中的字段执行布尔值或数值估计。分析引擎可以进一步确定出(例如，使用结合图21描述的一种或多种技术)配置模型2215与会话cookie中的字段的布尔值或数值估计相关。然后，分析引擎可以针对配置模型2215上的会话cookie中的字段执行布尔值或数值估计，并输出结果：在会话cookie中未将httpOnly标志设置为true。

图23示出了根据一些实施例的说明性程序代码2300和程序代码2300的说明性分析。程序代码2300可以是图22中示出的说明性应用2200的实现。

在一些实施例中，可以基于以下属性来指定查询，并且分析引擎可以被编程为从查询中识别语义谓词，诸如图23中示出的说明性语义谓词2305。

-在与/users有关的任何路由中，是否存在JavaScript注入？

-查询语言中的说明性语义谓词：

○<{eval($l)}>WHERE$1.tainted＝true

在一些实施例中，分析引擎可以基于语义谓词2305选择属性模型的一种或多种类型。例如，分析引擎可以在2310处确定出(例如，使用结合图21描述的一种或多种技术)要执行数据流分析以计算与/user有关的路由功能的“tainted”值。然后，分析引擎可以分析程序代码2300(或程序代码2300的AST)并构建数据流图表2315。使用数据流图表2315，分析引擎可以确定出在eval(body.preTax)和eval(body.afterTax)处存在JavaScript注入，并可相应地在2320处输出结果。

图24示出了根据一些实施例的说明性程序代码2400和程序代码2400的说明性分析。程序代码2400可以是图22中示出的说明性应用2200的实现。

在一些实施例中，可以基于以下属性来指定查询，并且可以对分析引擎进行编程以从查询中识别语义谓词，诸如图24中示出的说明性语义谓词2405。

-在与用户注册有关的任何路由中，是否正确检查了用户名(例如，当用户名用于重定向页面时用户名是否可以为空)？

-查询语言中的说明性语义谓词：

○<{$0.redirect(_+$2)}>WHERE$2＝＝‘’。

在一些实施例中，分析引擎可以基于语义谓词2405选择属性模型的一种或多种类型。例如，分析引擎可以在2410处确定出(例如，使用结合图21描述的一种或多种技术)要对userName执行变量值估计。然后，分析引擎可以对userName执行变量值估计，并输出结果：用户名必须包含1到20个字符。

图25示出了根据相同实施例的说明性应用架构模型2500。与图15中示出的说明性应用架构模型1530类似，图25的示例中的应用架构模型2500包括用于软件架构中的独立组件的模型。在一些实施例中，应用架构模型2500可以是应用架构模型1530的更新版本。例如，分析引擎可以被编程为基于代码改变来更新应用架构模型1530以生成应用架构模型2500。

发明人已经认识到并理解，当开发者修改程序代码(例如，通过修订现有代码和/或添加新代码)时，重新生成整个应用架构模型1530可能涉及不必要的计算。例如，代码改变可以仅影响应用架构模型1530中的一些但不是全部组件模型。发明人已经认识到并理解，重新生成未受影响的组件模型可以导致相同的组件模型。因此，在一些实施例中，提供了以下技术，其用于识别受某些变化影响的一个或多个组件模型并仅重新生成受影响的组件模型，这可以显着改善分析引擎的响应时间。

发明人进一步认识到并理解，当开发者修改程序代码时(例如，通过修订现有代码和/或添加新代码)，重新检查不受代码改变影响的属性可能涉及不必要的计算。因此，在一些实施例中，提供了以下技术，其用于确定属性是否受某些代码改变影响。分析引擎可以仅重新检查受影响的属性，这也可以显着改善分析引擎的响应时间。

在图25中示出的示例中，代码改变包括代码修订2505。分析引擎可以被编程为识别受代码修订2505影响的一个或多个组件模型(例如，组件模型2)。例如，如果代码修订2505仅涉及对特定函数的改变，并且该函数涉及路由定义，则分析引擎可以仅重新分析该路由。与未改变的代码有关的先前结果可能仍然有效。

在图25中示出的示例中，代码改变包括新代码2510。在一些实施例中，分析引擎可以被编程为确定新代码2510是否将组件添加到正在分析的软件应用。如果确定出新代码2510将组件添加到正在分析的软件应用，则分析引擎可以生成新的组件模型N，如图25中示出的。分析引擎可以进一步编程以确定是否有任何属性受新组件模型N的存在影响。如果确定属性受新组件模型N的存在影响，则分析引擎可以重新检查该属性。

在一些实施例中，可以使用一个或多个增量分析技术(诸如结合图25描述的那些)来异步地构造应用架构模型。例如，软件应用中的不同组件可能在不同时间变得可用。每当新组件变得可用时，可以为该组件生成新的组件模型，并且可以重新检查受影响的属性。以这种方式，分析引擎可能能够在每个增量步骤处快速返回结果，而不是在所有组件已变得可用之后进行所有计算。

图26A示出了根据一些实施例的说明性应用2600和应用2600中的路由函数的说明性实现2605。在该示例中，应用2600包括在2610处对变量b的赋值的修订，并且实现2605包括在2615处对两个变量(preTax和afterTax)的赋值的修订，以及在2620处的新路由函数logout。

图26B示出了根据一些实施例的说明性修订后的配置模型2625和说明性修订后的路由模型2635。例如，分析引擎可以被编程为确定出图26A的2610处的修订仅影响配置模型，并且生成修订后的配置模型2625以在2630处反映对变量b的赋值的修订。此外，分析引擎可以被编程为确定出仅属性2650受配置模型的改变的影响。因此，分析引擎可以仅针对修订后的配置模型2625检查属性2650。

类似地，分析引擎可以被编程为确定出图26A的2615和2620处的修订仅影响路由模型，并且生成修订后的路由模型2635以在2640处反映新的路由函数logout以及在2645处对preTax和afterTax的赋值的修订。此外，分析引擎可以被编程为确定出仅属性2655受到路由模型的变化的影响。因此，分析引擎可以针对修订后的路由模型2635仅检查属性2655。

V.软件应用的基于模型的分析

在一些实施例中，分析引擎输出的一个或多个结果可以被指导引擎消耗，该指导引擎被编程为在识别出问题时向开发者提供定制的和可操作的指导。例如，指导引擎可以被编程为基于由分析引擎输出的一个或多个结果来选择用于帮助编写输入程序代码的用户的适当模态。另外地或可替选地，指导引擎可以被编程为基于一个或多个结果从内容存储中选择适当的内容。例如，如果一个或多个结果包括指示安全漏洞的发现，则指导引擎可以向用户呈现解释漏洞的文本或视频消息、和/或深入的训练模块。另外地或可替选地，如果一个或多个结果包括对输入程序代码的建议修改，则指导引擎可以向用户呈现解释建议修改的文本或视频消息、和/或准备好在沙箱中测试的修改后的程序代码。

图27示出了根据一些实施例的用于向开发者提供指导的说明性系统2700。在该示例中，系统2700包括指导引擎2705、知识库2710、信息存储库2715、分析引擎2720和用户简档2725。在一些实施例中，指导引擎2705可以是图1中示出的说明性指导引擎110的实现，并且分析引擎2720可以是图1中示出的说明性分析引擎105的实现。

在一些实施例中，知识库2710可以存储关于软件开发的信息的收集。例如，知识库2710可以存储关于某些安全漏洞的信息和/或这些漏洞如何在不同类型的软件(例如，使用不同语言、框架、库等编写的软件)中表现的信息。另外地或可替选地，知识库2710可以存储指示如何修补某些安全漏洞的信息(例如，建议的代码转换以修复识别出的问题)。然而，应当理解，除了安全属性之外或代替安全属性，本文描述的技术可用于提供与任何合适类型的属性(例如，正确性、健壮性、安全性、活跃性等)有关的指导。

存储在知识库2710中的信息可以以任何合适的方式表示。例如，在一些实施例中，知识库2710可以包括具有一个或多个节点和/或一个或多个边的知识图表。每个节点可以表示某个概念，诸如代码转换、条件、框架、一段元数据、约束(例如，在修复识别出的问题时要保留的功能)等。每个边可以表示在源节点和目标节点之间的关系，其中目标节点可以与源节点不同或相同。

例如，知识图表中的一个或多个节点可以分别对应于查询语言中的一个或多个名词(例如，图13中示出的说明性名词)。边可以对应于表达两个名词之间的关系的动词。然而，应当理解，本公开的方面不限于使用具有名词和动词的知识图表。

图28示出了根据一些实施例的说明性知识图表2800。在该示例中，知识图表2800包括两个节点2805和2810。节点2805可以表示软件开发框架(例如，版本1.0的框架X)，并且节点2810可以表示另一个软件开发框架(例如，版本1.1的框架X)。知识图表2800还可以包括从节点2805到节点2810的边2815。边2815可以表示“替换”关系。例如，边2815可以指示如果识别出某个模式(例如，漏洞Y)，则由节点2805表示的框架(例如，版本1.0的框架X)应该被由节点2810表示的框架(例如，版本1.1的框架X)替换。

应当理解，知识图表2800在图28中示出并且上面仅出于说明的目的进行讨论，这是因为本公开的方面不限于使用任何特定知识图表或任何知识图表。

返回到图27的示例，在一些实施例中，指导引擎2705可以被编程以向知识库2710提交问题，并且知识库2710可以被编程为向指导引擎2提供答案。例如，指导引擎2705可以提交查询，诸如，“如果使用版本1.0的框架X，如何修复漏洞Y？”，知识库2710可以返回答案，诸如“更新到版本1.1的框架X”。

在一些实施例中，知识库2710可以基于存储在知识图表(例如，图28中示出的说明性知识图表2800)中的信息来回答查询。例如，知识库2710可以被编程为将查询中提供的信息(例如，正在使用的版本1.0的框架X、被识别出的漏洞Y等)与一个或多个相关节点(例如，图28中示出的说明性节点2805)和/或一个或多个相关边(例如，图28中示出的说明性边2815)相匹配。

在一些实施例中，可以动态更新知识库2710。例如，指导引擎2705可以被编程为向知识库2710提供反馈，这可以使知识库2710添加、删除和/或修改一条或多条存储的信息。这种反馈可以以任何合适的方式生成，例如，基于从开发者接收到的输入(例如，以某种方式修复某个漏洞的指令)。可替选地或另外地，知识库2710可以由一个或多个专家(例如，安全专家)基于新知识(例如，新发现的漏洞)来更新。

在图27的示例中，指导引擎2705被编程为经由信息存储库2715接收输入。例如，在一些实施例中，指导引擎2705和信息存储库2715可以使用黑板架构来实现。例如，信息存储库2715可以包括用于存储问题、解决方案、建议和/或其他信息的黑板组件，而指导引擎2705可以包括被编程为从信息存储库2715的黑板组件中提取信息和/或将信息推送到信息存储库2715的黑板组件上的一个或多个工作器(worker)。

在一些实施例中，信息存储库2715可以包括从除指导引擎2705之外的一个或多个源接收到的信息。例如，信息存储库2715可以存储从分析引擎2720接收到的信息。这样的信息的示例包括但不限于一个或多个分析结果、源代码的一个或多个部分和/或其表示(例如，抽象语法树)、一个或多个模型(例如，应用架构模型、属性模型等)等。

另外地或可替选地，信息存储库2715可以存储来自一个或多个用户简档2725的信息。这样的信息的示例包括但不限于开发者的一个或多个偏好和/或与软件应用相关联的上下文信息。可以存储任何合适的上下文信息，诸如对开发软件应用的行业的指示、软件应用是否处理个人财务信息(例如，信用卡号)等。在一些实施例中，指导引擎2705可以使用这样的信息来确定是否存在问题、和/或如何修复问题。例如，如果软件应用处理个人财务信息，则指导引擎2705可以检查是否遵照相关规则使用适当的加密算法。

图29示出了根据一些实施例的指导引擎2705的说明性实现。在该示例中，指导引擎包括调节器(moderator)2800，其被编程为缓和多个工作器的活动，诸如事件工作器2905、知识工作器2910、影响工作器2915等。例如，调节器2800可以被编程为控制每个工作器何时从信息存储库2715访问信息和/或向信息存储库2715添加贡献。以这种方式，调节器2800可以促进工作器共同解决问题的过程(例如，识别安全漏洞和/或提供指导以解决安全漏洞)。根据实施例，调节器还被配置为确定从任何专家接收到的结果是否相对于由专家使用以获得该结果的数据是陈旧的(stale)-调节器能够拒绝这种陈旧的结果。

在一些实施例中，工作器可以被编程为处理问题的特定方面。作为一个示例，事件工作器2905可以被编程为从信息存储库2715识别与特定模式匹配的事件。例如，事件工作器2905可以被编程为识别与指示漏洞Y的模式匹配的事件。如果识别出这样的事件，则事件工作器2905可以将新事件添加到信息存储库2715，以指示漏洞Y被识别出。在一些实施例中，新事件可以包括关于漏洞Y如何在源代码的一部分中表现的信息(例如，引起漏洞的函数声明、变量赋值、配置参数值等)。

作为另一示例，知识工作器2910可以被编程为分析来自信息存储库2715的事件并且制定(formulate)要提交给知识库2710的查询。例如，知识工作器2910可以被编程为分析指示在某个软件应用中识别出某个漏洞(例如，漏洞Y)的事件。知识工作器2910可以被编程为识别使用其来实现软件应用的框架(例如，版本1.0的框架X)，并且基于识别出的框架来制定查询(例如，“如果使用版本1.0的框架X，则如何修复漏洞Y？”)。知识工作器2910可以将查询提交给知识库2710并接收答案(例如，“更新到版本1.1的框架X”)。然后，知识工作器2910可以将答案添加到信息存储库2715。

作为另一个示例，冲突工作器(impact worker)2915可以被编程为分析所建议的代码转换并识别潜在的冲突和/或缓解策略。例如，如果建议的代码转换包括使用新算法加密用户凭证，则冲突工作器2915可以确定出先前存储的凭证应该被解密并且然后使用新算法重新加密，或者现有用户可能无法登录。然后，冲突工作器2915可以将识别出的冲突和/或缓解策略添加到信息存储库2715。

图34示出了根据实施例的由指导引擎2705提交给知识库2710的示例性查询的视觉表示。根据实施例，这些查询是根据SPARQL(SPARQL协议和RDF查询语言)语言构造来提供的，但是本领域技术人员将理解，可以替换可用于查询的任何语言。如上面借由非限制性示例所讨论的，可以由诸如图29的知识工作器2910的工作器提交图34的查询。根据实施例，图33、图35和图36示出了缓解策略(包括代码转换)响应于图34的查询的可视表示。根据实施例，图33、图35和图36的响应式缓解策略本身呈现为SPARQL查询。

根据实施例(包括SPARQL)，查询被提供作为基于图表的查询。该查询指定图表的一部分，包括知识库2710的查询引擎将需要填写以响应查询的洞。相关领域的技术人员将理解，可以使用其他结构来呈现图33-图36的查询，并且借由非限制性示例提供其中示出的基于图表的查询构造的使用。

在图33-图36中，实线被用于必须存在于匹配结果中的图表的部分。虚线被用于示出可以匹配和返回的查询元素。图中的节点表示概念，并且节点之间的边是这些概念之间的关系(例如，图34中的应用“_:Prg”3410与框架“Angular”3412具有关系“usesFramework”)。根据实施例，关系确定使用哪种类型的工作器(例如，知识、事件等)以便解析基于图表的查询。如果节点的标签以下划线“_”为前缀，则这意味着图表中该点处的匹配不精确——已知存在维护该空间以及与周围节点的关系的对象，但其特定的标签或名称是未知的。如果节点的标签带有问号“？”，则不仅名称是变量，而且名称期望是响应于查询提供的图表的一部分。根据实施例，边也可以遵循用于查询中的变量匹配的类似常规并且包括在响应图表中。查询的解决方案(所需的转换集合)借由双线箭头在图中示出。

借由非限制性示例，图表可以跨越多个概念域(notional domain)。例如，在图34中示出的图表中，该查询考虑了三个单独的域。在查询的示例性实施例中，这些包括HTML域(例如，_:Page、Translate指令和loadsApp关系及其他)、建模域(例如，像_:Prg这样的程序，使用像Angular这样的框架、和框架提供的服务)和静态分析域(例如，JSON对象和成员的概念、与这些成员相关联的值、以及支持该值赋值的AST)。根据实施例，查询能够跨越任何数量的域，包括与源代码、配置文件和专家信息有关的域，以便提供适当的指导。

这些查询的示例性结构允许以非常特定的方式关于事物(例如，图表的边和节点)的模糊性，以便完全响应于查询。借由非限制性示例，可以在几个位置中找到“_:Prg”的匹配，诸如在<script></script>代码块中，或者借由非限制性示例，在单独的JavaScript文件中定义并且从HTML文件引用。从检测问题的查询或在查询中纠正问题的角度来看，这种区别无关紧要，并且将程序表示为匹配“_:Prg”允许该查询在任一实例中都是响应式的。然而，在从数据存储写回程序的点上，该区别确实很重要，其表示根据实施例的单独的专家。

以这种方式划分匹配程序的识别以及如何校正问题提高了新的检查器或修复器如何插入到过程中的效率，这通过跨越多个相关域的能力来使能。例如，如果寻找“定义由Angular框架提供的sanitizer策略的代码”，则查询将包含sanitizer策略的所有实现，而无需专门枚举模式的集合作为查询的一部分进行搜索，这是有益的。

图34示出了根据实施例的借由示例性查询的附加知识域之间的相互作用。例如，图34的查询结构(选择查询)在“_:Page”3402上寻找任何匹配，其包含TranslateDirective3404和与任何匹配的程序“_:Prg”3410的“loadsApp”关系。在该示例中，translate指令具有任何(通配符)目标3406，具有为“UserControlled”3408的属性(hasProp)。TranslateProvider 3416必须支持TranslateDirective 3404。回到“_:Prg”3410中匹配的程序，匹配必须使用Angular框架3412，其具有匹配“？ver”3414的版本。

如前面讨论的，因为“？ver”3414用问号表示，这指示出查询应该解析并提供给用户的节点。

分别地，如果查询解析引擎可以解析从translateProvider 3416到SanitizerStrategy 3418的hasMember关系(跟随先前的关系)，则它寻找这样的响应，并且还可选地寻找匹配值“_:Sanitizer”3420。如果找到这些匹配，则查询解析引擎获得(如果可能的话)并返回匹配的“？src”源代码3422，其定义匹配的“_:Sanitizer”3420。

图35示出了根据实施例的提供版本转换的响应指导图表。在图34的示例之后，查询返回由匹配应用“_:Prg”3410使用的Angular框架3412的版本号3414，作为响应图表的一部分。响应指导图表示出了存在由节点3502表示的Angular框架的返回版本号之间的关系，其中版本号是“1.0”，如由与节点3504“1.0”的“is”关系表示。然后指导指示(由双箭头表示)框架的版本号应在节点3506处转换为版本“1.1”。

图36示出了根据实施例的由指导引擎提供的附加响应指导图表。在图34的示例之后，如果关于定义匹配sanitizer“_:Sanitizer”3420的源代码“？src”3422的信息可用，则进一步检查来自指导引擎的指导(由“？src”之前的问号“？”表示)。如果在此可选步骤中找到匹配的源代码，则这意味着已根据预期方法实施匹配的sanitizer策略，使得指导引擎可以考虑该策略。在图36中，假设找到由节点3602表示的匹配的源代码，则工作器寻找由与节点3604的“is”关系表示的作为函数声明“FunDecl:uuid”的源代码。如果在节点3602的源代码中找到节点3604的此函数声明，则指导引擎在节点3606处将转换(由双箭头表示)推荐到函数声明“FunDecl:uuid’”的不同版本。

图33示出了根据实施例的由指导引擎提供的另一响应指导图表。实际上由图33的指导图表提供的指导类似于图36的指导图表，并且同样遵循图34的示例，其中如果关于定义了匹配sanitizer“_:Sanitizer”3420的源代码“？src”3422的信息是可用的，则进一步检查来自指导引擎的指导(如由“？src”之前的问号“？”表示)。如果在此可选步骤中找到匹配的源代码，则这意味着已根据预期方法实现匹配的sanitizer策略，使得指导引擎可以考虑该策略。在图33中，假设找到由节点3302表示的匹配的源代码，则工作器寻找符号关系3304，该符号关系3304是源代码3302中的“Assign：”3306赋值的左侧。在图33的示例中，符号“uuid”3304是被赋予了由“Assign：”3306赋值的右侧表示的值的变量。响应指导图表指示出应该用新的函数声明“FunDecl:uuid”3308替换赋值(如由通配符“_:_”指示出的)。

图36描述了内联(in-line)代码的转换，用FunDecl:uuid’3606的代码替换了FunDecl:uuid 3604的代码，而图33通过用全新函数3308替换对函数的引用来描述类似函数的转换。取决于实现代码(在这种情况下是sanitizer代码)的方式，这些单独的方法可以每个由指导引擎适当地返回。在某些情况下，内联代码替换是可行的，而在其他情况下，通过让函数指针引用新代码来替换整个源代码是适当的实现。

发明人已经认识到并理解黑板架构的各种优点。例如，在一些实施例中，可以重用存储在信息存储库2715中的指导信息，使得指导引擎2705能够在将来更快地响应类似问题。例如，如果在第一应用中识别出某个问题并且使用某个补丁来修复问题，则当在为类似类型的组织开发的第二应用中识别出类似问题时，指导引擎2705可以建议类似的补丁。

应当理解，如图27-图29和图33-图36示出的并且在上面描述的实现细节仅出于说明的目的，这是因为本公开的方面不限于任何特定的实现方式。例如，本公开的方面不限于黑板架构的使用。在一些实施例中，指导引擎可以直接从诸如分析引擎的各种源接收输入。此外，本公开的方面不限于图29中示出的工作器的特定示例。可以使用任何合适的工作器来提供任何合适的专业知识。在一些实施例中，一个或多个工作器可以是同一软件代理的不同实例。另外地或可替选地，可以使用微服务架构来实现一个或多个工作器。这样的工作器本身可以包括具有不同专业知识的多个工作器。

在一些实施例中，指导引擎可以使用面向方面的编程(AOP)语言来指定何时向开发者呈现一条建议。例如，可以使用AOP语言来编写切入点表达式以指定多个连接点，其中每个连接点可以对应于相应的模式。指导引擎可以被编程为执行这样的切入点表达式，并在所有模式匹配时将该条建议递送给开发者。

图30示出了根据一些实施例的用于存储指导信息的说明性指导存储3000。在一些实施例中，指导引擎(例如，图27中示出的说明性指导引擎2705)可以访问指导存储300以确定向开发者呈现什么指导和/或如何呈现这样的指导。另外地或可替选地，分析引擎(例如，图27中示出的说明性分析引擎2720)可以访问指导存储300以检索要在软件应用上运行的一个或多个查询。在一些实施例中，代替诸如图27中示出的说明性知识库2710的知识库或者除了其之外，可以使用指导存储3000。

在图30示出的示例中，指导存储3000包括一个或多个指导工件(guidanceartifact)，其中指导工件可以包括触发规范和/或对应的指导规范。例如，在图30中示出的示例中，指导工件3005包括触发规范3010和指导规范3020。在一些实施例中，触发规范3010可以包括一段或多段软件代码，当由分析引擎执行时(例如，图27中示出的说明性分析引擎2720)致使分析引擎在软件应用中寻找特定问题。触发规范3010可以用任何合适的语言编写，诸如JavaScript和/或具有图8中示出的和上面描述的一个或多个说明性结构的查询语言。

在一些实施例中，指导规范3020可以包括一段或多段软件代码，当由指导引擎(例如，图27中示出的说明性指导引擎2705)执行时，致使指导引擎为开发者提供指导。例如，响应于通过执行触发规范3010识别出的问题，指导引擎可以被编程为执行指导规范3020并提供关于如何修复问题的指导。

在一些实施例中，指导工件3005可以包括用于测试触发规范3010的测试工具(test harness)3015和用于指导规范3020的测试工具3025。测试工具3015可以包括用于测试触发规范3010的任何合适的软件代码和/或测试数据。类似地，测试工具3025可以包括用于测试指导规范3020的任何合适的软件代码和/或测试数据。然而，应当理解，本公开的方面不限于用于触发规范的测试工具的使用，也不限于用于指导规范的测试工具的使用。

应当理解，指导工件3005在图30中示出并且仅出于说明的目的在上面描述，这是因为本公开的方面不限于使用任何特定类型的指导工件或任何指导工件。例如，在一些实施例中，在没有指导规范的情况下指导工件可以仅包括触发规范。在执行触发规范时识别出的发现可以被记录(例如，在黑板组件上)以作为感兴趣的观察。当收集更多确认存在问题的信息时，指导引擎可以提供指导，或者最终可以确定该发现并不指示问题。

图31示出了根据一些实施例的说明性决策树3100，其可由指导引擎使用以确定向开发者呈现什么指导和/或如何呈现这样的指导。例如，决策树3100可以表示由图30中示出的说明性指导规范3020实现的程序逻辑。

在图31示出的示例中，决策树3100包括多个决策节点，诸如节点3105、3115和3125，以及多个动作节点，诸如节点3110、3120和3130。在每个决策节点处，指导引擎(例如，图27中示出的说明性指导引擎2705)可以被编程为评估一个或多个条件。作为一个示例，在决策节点3105处，指导引擎可以确定是否声明了参数InitBinder。如果声明了参数InitBinder，则指导引擎可以前进到下一个决策节点。否则，指导引擎可以前进到动作节点3010以设置沙箱来测试参数InitBinder的Create函数。

作为另一示例，在决策节点3115处，指导引擎可确定是否使用黑名单。如果使用黑名单，则指导引擎可以前进到动作节点3120以建议开发者阅读关于白名单与黑名单的使用的文章(例如，通过呈现文章的链接)。如果未使用黑名单，则指导引擎可以前进到不同的动作节点。

作为另一示例，在决策节点3125处，指导引擎可以确定白名单中的一个或多个丢失字段是否敏感。如果白名单中没有丢失敏感字段，则指导引擎可以前进到动作节点3130以向开发者通知一个或多个丢失字段。如果至少一个丢失字段是敏感的，则指导引擎可能不呈现任何指导。

在一些实施例中，指导引擎可以被编程为分析软件应用的源代码以评估决策节点处的条件。例如，触发规范(例如，图30中示出的说明性触发规范3010)可以致使分析引擎将源代码的相关部分存储在共享存储库(例如，图27中示出的说明性信息存储库2715)中。然后，指导引擎可以从共享存储库检索代码并基于检索到的代码评估条件。另外地或可替选地，分析引擎可以共享一个或多个分析结果，并且指导引擎可以基于一个或多个分析结果来评估条件。

应当理解，决策树3100在图31中示出并且仅出于说明的目的在上面描述，这是因为本公开的方面不限于使用任何特定决策树或任何决策树。例如，本公开的方面不限于遍历通过决策树的单个路径以达到单条指导。在一些实施例中，单个触发器可以致使多条指导以不同的形式呈现。

发明人已经认识到并理解，确定用于呈现与特定问题有关的指导的适当时机可能是有益的。如果过早地向开发者呈现指导，则开发者可能会忽略该指导，这是因为开发者可能需要解决更紧急的问题。另一方面，如果指导过晚，则问题的影响足迹可能会增加，并且可能需要更多努力来纠正问题。因此，在一些实施例中，提供了用于测量问题的重要性和/或紧迫性的技术。指导引擎可以使用这种测量结果来确定何时呈现什么指导和/或如何呈现这种指导。

在一些实施例中，针对特定漏洞的优先级测量结果可以基于漏洞的严重性测量结果。继而，严重性测量结果可能基于两个测量结果：利用漏洞的潜在影响，以及漏洞实际被利用的可能性。可以以任何合适的方式确定这些测量结果。在一些实施例中，影响测量结果可以基于以下中的一个或多个：

-机密性

○此测量结果可以指示出成功利用此漏洞可能影响用户机密性的程度。例如，测量结果为0可以指示不暴露机密信息，测量结果为5可以指示可以暴露某些用户信息(例如，姓名、电子邮件地址、电话号码等)，并且测量结果为10可以指示可以暴露关键的个人身份信息(PII)(例如，社会安全号码、员工标识符、密码等)。

-完整性

○此测量结果可以指示成功利用此漏洞可能影响数据完整性的程度。例如，测量结果为0可以指示任何曝光可能限于只读数据，测量结果为5可以指示某些数据可以被改变但是影响的范围可能不是关键的，并且测量结果为10可以指示所有数据都可能受到损害。

-可用性

○此测量结果可以指示成功利用此漏洞可能影响可用性的程度。例如，测量结果为0可以指示对服务没有影响，测量结果为5可以指示一些非关键服务可能变得不可用，并且测量结果为10可以指示所有服务的不可恢复的停机时间。

在一些实施例中，可能性测量结果可以基于以下中的一个或多个：

-可访问性

○此测量结果可以指示可以多轻松地利用漏洞。

例如，测量结果为0可以指示由于诸如物理位置的约束(例如，USB驱动器必须物理地插入到安全数据中心中的服务器中)而难以利用该漏洞，测量结果为5可以指示攻击者可能需要克服一些限制来利用漏洞(例如，经由网络钓鱼电子邮件、点击攻击等)，并且测量结果为10可以指示可能存在很少或没有约束来防止利用(例如，经由偷渡式下载、跨站点脚本等)。

-复杂性

○此测量结果可以指示成功利用可能有多复杂。例如，测量结果为0可以指示成功利用漏洞可能需要很少或根本不需要应用的技能或知识(例如，使用全自动工具、脚本小子(script-kiddies)等)，测量结果为5可以指示可能需要某种水平的技能和/或应用、框架和/或环境的知识(例如，使用一些工具、自定义脚本、社会工程等)，并且测量结果为10可以指示可能需要对该应用、框架和环境以及高水平的技能的充分理解(例如，没有自动开发或发现工具、许多自定义脚本、现场社会工程(in-person social engineering)、物理折衷等)。

-认证

○此测量结果可以指示成功利用所需的身份验证级别。例如，测量结果为0可以指示攻击者可能需要作为系统或管理用户进行身份验证，并且可能仅针对其他系统或管理级用户利用此漏洞，测量结果为0可以指示攻击者可能需要是经过身份验证的用户，并且可能会针对任何其他经过身份验证的用户利用此漏洞，并且测量结果为10可以指示该漏洞可能针对任何用户进行匿名利用。

在一些实施例中，除了严重性之外或代替严重性，针对特定漏洞的优先级测量结果可以基于开发者优先级的测量结果。开发者优先级测量结果可以基于以下一个或多个：

-功能性

○此测量结果可以指示缺陷修复可能对应用的一个或多个功能有多大影响。

例如，以明文形式存储密码可能是不安全的，并且潜在的修复可能是用对应的密码散列替换密码。此修复可能会阻止现有用户登录，除非对登录功能进行对应的更改以计算用户输入的密码的适当加密哈希。

-复杂性

ο此测量结果可以指示实现缺陷修复可能涉及多大复杂性。这可能包括技术和/或业务复杂性。例如，为了实现新的密码存储策略，开发者可能需要咨询系统架构师、数据库管理员、产品经理、业务开发者和/或高级管理人员。另外地或者可替选地，开发者可能需要编写代码以检查自新存储策略推出以来用户的密码是否已被更改，如果不是，则强制用户重置密码。

-稳定性

○此测量结果可以指示缺陷修复可能对应用或应用的一个或多个部分的性能有多大影响。例如，对密码进行散列可能会在每次登录时增加数百毫秒。

对于大多数应用来说，这种降级可能并不重要。然而，一些应用(例如，电子交易)可能对时间非常敏感，因此每次认证丢失数百毫秒可能是不可接受的。

-可测性

○此测量结果可以指示旨在修复缺陷的解决方案有多容易被测试，以确定解决方案是否实际修复了缺陷。例如，如果自动化测试是可用的，则可以更容易地采用解决方案。

因此，在一些实施例中，可以如下计算优先级测量结果，其中average可以是用于组合多个测量结果的任何合适的函数。

应当理解，仅出于说明的目的提供priority的上述定义，这是因为可以以任何合适的方式计算优先级测量结果。例如，不需要使用相同的average函数来计算priority、impact、likelihood和friction。此外，代替priority的上述定义中使用的说明性参数或除了其之外，可以使用一个或多个参数的任何合适组合来计算这些测量中的任何一个。

在一些实施例中，可以使用一个或多个加权平均函数来组合测量结果。例如，可以如下计算加权优先级测量结果。

在一些实施例中，指导引擎可以被编程为对测量结果impact、likelihood和friction应用合适的加权，例如，经由上面的说明性定义weighted_priority中的函数guidance.weight。

另外地或可替选地，可以经由上面的说明性定义weighted_priority中的函数orgprofile.weight将加权应用于测量结果impact、likelihood和friction。这样的加权可以反映为了其开发应用的组织可能如何评估这些测量结果。

另外地或可替选地，可以经由上面的说明性定义weighted_priority中的函数userprofile.weight将加权应用于测量结果impact、likelihood和friction。这样的加权可能反映了从事于应用的开发者可能如何评估这些测量结果。例如，加权可以反映开发者对摩擦的理解、针对开发者定制的安全编码指导、和/或开发者的声誉。

另外地或可替选地，可以经由对函数weighted_priority的递归调用将进一步的加权应用于测量结果impact、likelihood和friction。这种递归调用可以捕获自上一轮计算以来可能已经变得相关的任何附加信息。任何合适的退出标准可以用于递归。例如，当没有更多相关信息被捕获时，递归可能会停止。

应当理解，可以以任何合适的方式确定加权。在一些实施例中，可以基于应用生命周期阶段确定一个或多个权重。例如，随着应用通过实验、概念证明、alpha、beta和一般可用性的进展，安全性可能变得越来越重要，并且可以将增加的权重应用于这些阶段(例如，分别地0、1、3、5和10)。

另外地或可替选地，可基于一个或多个环境条件确定一个或多个权重。例如，可以基于诸如负载均衡器、身份提供商等的一个或多个透明环境控制的存在来确定一个或多个权重。

图32示意性地示出了可以在其上实现本公开的任何方面的说明性计算机1000。在图32中示出的实施例中，计算机1000包括具有一个或多个处理器的处理单元1001和可以包括例如易失性和/或非易失性存储器的非暂时性计算机可读存储介质1002。存储器1002可以存储一个或多个指令以对处理单元1001进行编程以执行本文描述的任何功能。除了系统存储器1002之外，计算机1000还可以包括其他类型的非暂时性计算机可读介质，诸如存储器1005(例如，一个或多个磁盘驱动器)。存储1005还可以存储一个或多个应用程序和/或应用程序使用的外部组件(例如，软件库)，其可以被加载到存储器1002中。

计算机1000可以具有一个或多个输入装置和/或输出装置，诸如图32中示出的装置1006和1007。除了其他方面，这些装置可以用于呈现用户界面。可用于提供用户界面的输出装置的示例包括打印机或用于输出的视觉呈现的显示屏和用于输出的可听呈现的扬声器或其他声音生成装置。可以用于用户界面的输入装置的示例包括键盘和指示装置，诸如鼠标、触摸板和数字化平板电脑。作为另一示例，输入装置1007可以包括用于捕获音频信号的麦克风，并且输出装置1006可以包括用于可视地呈现识别出的文本的显示屏、和/或用于可听地呈现识别出的文本的扬声器。

如图32中示出的，计算机1000还可以包括一个或多个网络接口(例如，网络接口1010)，以使能经由各种网络(例如，网络1020)的通信。网络的示例包括局域网或广域网，诸如企业网络或因特网。这样的网络可以基于任何合适的技术，并且可以根据任何合适的协议操作，并且可以包括无线网络、有线网络或光纤网络。

已经如此描述了至少一个实施例的若干方面，应当理解，本领域技术人员将容易想到各种改变、修改和改进。这些改变、修改和改进旨在落入本公开的精神和范围内。因此，前面的描述和附图仅是借由示例的。

本公开的上面描述的实施例可以以多种方式中的任何一种来实现。例如，可以使用硬件、软件或其组合来实现实施例。当在软件中实现时，软件代码可以在任何合适的处理器或处理器的收集上执行，无论是在单个计算机中提供还是在多个计算机当中分布。

此外，本文概述的各种方法或过程可以被编码为在采用各种操作系统或平台中的任何一个的一个或多个处理器上可执行的软件。另外，这样的软件可以使用许多合适的编程语言和/或编程工具或脚本工具中的任何一种来编写，并且还可以编译为在框架或虚拟机上执行的可执行机器语言代码或中间代码。

在这方面，本文公开的概念可以体现为非暂时性计算机可读介质(或多个计算机可读介质)(例如，计算机存储器、一个或多个软盘、压缩磁盘、光盘、磁带、闪速存储器、现场可编程门阵列或其他半导体装置中的电路配置、或其他非暂时性、有形计算机存储介质)，其编码有一个或多个程序，当在一个或多个计算机或其他处理器上执行时，执行实现上面讨论的本公开的各种实施例的方法。一种或多种计算机可读介质可以是可运输的，使得存储在其上的一个或多个程序可以被加载到一个或多个不同的计算机或其他处理器上，以实现如上面讨论的本公开的各个方面。

这里使用的术语“程序”或“软件”是指可用于对计算机或其他处理器进行编程以实现如上面讨论的本公开的各个方面的任何类型的计算机代码或计算机可执行指令集。另外地，应当理解，根据该实施例的一个方面，一个或多个计算机程序在执行本公开的方法时不需要驻留在单个计算机或处理器上，而是可以在多个不同的计算机或处理器当中以模块化方式分发，以实现本公开的各个方面。

计算机可执行指令可以是以许多形式，诸如由一个或多个计算机或其他装置执行的程序模块。通常，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。典型地，在各种实施例中，可以根据需要组合或分发程序模块的功能。

此外，数据结构可以以任何合适的形式存储在计算机可读介质中。为了简化说明，数据结构被可以示出为具有通过数据结构中的位置相关的字段。这种关系同样可以通过为具有计算机可读介质中的位置的字段分配存储来实现，所述计算机可读介质传达字段之间的关系。然而，可以使用任何合适的机制来建立数据结构的字段中的信息之间的关系，包括通过使用指针、标签或建立数据元素之间的关系的其他机制。

本公开的各种特征和方面可以单独使用、以两种或更多种的任何组合使用、或者在前面描述的实施例中未具体讨论的各种布置中使用，并且因此不限于其应用于在前面的描述中阐述的或在附图中示出的组件的细节和布置。例如，一个实施例中描述的方面可以以任何方式与其他实施例中描述的方面组合。

此外，这里公开的概念可以体现为一种方法，已经提供了该方法的示例。作为该方法的一部分执行的动作可以以任何合适的方式排序。因此，可以构造这样的实施例，其中以不同于示出的顺序执行动作，其可以包括同时执行一些动作，即使在示例性实施例中示出为顺序动作。

在权利要求中使用诸如“第一”、“第二”、“第三”等的序数术语来修饰权利要求元素本身并不意味着一个权利要求元素优先于另一个权利要求元素的任何优先权、优先级或顺序、或执行方法的动作的时间顺序，而仅用作标签以将具有特定名称的一个权利要求元素与具有相同名称的另一个元素(但是用于使用序数术语)区分，以区分权利要求元素。

此外，这里使用的措辞和术语是出于描述的目的，而不应被视为限制。本文中“包括”、“包含”、“具有”、“含有”、“涉及”及其变化形式的使用旨在涵盖其后列出的项目及其等同物以及附加项目。

Claims (20)

1.一种方法，包括：

由一个或多个处理装置制定指示出软件应用的多个属性之间的关系的基于图表的请求查询，其中所述请求查询请求关于所述多个属性的指导属性的指导；

由所述一个或多个处理装置将所述请求查询提交给知识库；并且

由所述一个或多个处理装置响应于所述请求查询从所述知识库接收基于所述指导属性的并且通过操纵所述请求查询而生成的基于图表的响应式查询。

2.根据权利要求1所述的方法，其中，所述响应式查询包括关于所述多个属性中的属性的转换。

3.根据权利要求2所述的方法，其中，所述转换包括对软件应用的源代码的内联替换或通过引用新函数的对软件应用的函数的替换。

4.根据权利要求1所述的方法，其中，所述指导属性是所述多个属性的可选属性，所述方法还包括：

基于关于所述可选属性的可选关系存在于所述软件应用中的确定，将关于所述可选属性的可选关系包括在所述请求查询内。

5.根据权利要求1所述的方法，其中，所述请求查询包括位于第一概念域中的指导属性与位于第二概念域中的所述多个属性的附加属性之间的关系。

6.根据权利要求1所述的方法，还包括：

分析指示出来自信息存储库的漏洞的事件；并且

基于所述漏洞来选择所述指导属性。

7.根据权利要求6所述的方法，还包括：

将所述响应式查询添加到所述信息存储库。

8.一种系统，包括：

存储器，其被配置为存储被配置为执行以下操作的模块，所述操作包括：

制定指示出软件应用的多个属性之间的关系的基于图表的请求查询，其中所述请求查询请求关于所述多个属性的指导属性的指导，

将所述请求查询提交给知识库，并且

响应于所述请求查询从所述知识库接收基于所述指导属性的并且通过操纵所述请求查询而生成的基于图表的响应式查询；以及

一个或多个处理器，其被配置为处理所述模块。

9.根据权利要求8所述的系统，其中，所述响应式查询包括关于所述多个属性中的属性的转换。

10.根据权利要求9所述的系统，其中，所述转换包括对软件应用的源代码的内联替换或通过引用新函数的对软件应用的函数的替换。

11.根据权利要求8所述的系统，其中，所述指导属性是所述多个属性的可选属性，所述操作还包括：

基于关于所述可选属性的可选关系存在于所述软件应用中的确定，将关于所述可选属性的可选关系包括在所述请求查询内。

12.根据权利要求8所述的方法，其中，所述请求查询包括位于第一概念域中的指导属性与位于第二概念域中的所述多个属性的附加属性之间的关系。

13.根据权利要求8所述的系统，所述操作还包括：

分析指示来自信息存储库的漏洞的事件；并且

基于所述漏洞来选择所述指导属性。

14.根据权利要求13所述的系统，所述操作还包括：

将所述响应式查询添加到所述信息存储库。

15.一种计算机可读存储装置，其上存储有指令，由计算装置执行所述指令使得所述计算装置执行包括以下操作：

制定指示出软件应用的多个属性之间的关系的基于图表的请求查询，其中所述请求查询请求关于所述多个属性的指导属性的指导；

将所述请求查询提交给知识库；并且

响应于所述请求查询从所述知识库接收基于所述指导属性的并且通过操纵所述请求查询而生成的基于图表的响应式查询。

16.根据权利要求15所述的计算机可读存储装置，其中，所述响应式查询包括关于所述多个属性中的属性的转换。

17.根据权利要求16所述的计算机可读存储装置，其中，所述转换包括对软件应用的源代码的内联替换或通过引用新函数的对软件应用的函数的替换。

18.根据权利要求15所述的计算机可读存储装置，其中，所述指导属性是所述多个属性的可选属性，所述操作还包括：

基于关于所述可选属性的可选关系存在于所述软件应用中的确定，将关于所述可选属性的可选关系包括在所述请求查询内。

19.根据权利要求15所述的计算机可读存储装置，其中，所述请求查询包括位于第一概念域中的指导属性与位于第二概念域中的所述多个属性的附加属性之间的关系。

20.根据权利要求15所述的计算机可读存储装置，所述操作还包括：

分析指示来自信息存储库的漏洞的事件；并且

基于所述漏洞来选择所述指导属性。