背景技术:
1、软件包(例如,软件产品或应用)在几乎所有人类活动(例如,商业、娱乐、慈善、学术或其他类似的人类活动)的众多领域中普遍利用。在生活中,基于软件的工具之所以被广泛接受,其特点就是软件包的更新相对容易,而且可以被广泛采用。随着新功能被添加到应用中,软件包内的“错误”被检测并修复时,软件发布方可以向其用户分发应用更新。例如,许多应用(或“app”)根据需要定期更新,通过采用应用的新(或经更新的)版本。这些经更新的版本可以自动“推送”向执行应用的一个或多个(物理或虚拟)机器。在许多情况下,除非终端用户主动监视当前正在执行的应用版本,否则终端用户甚至可能根本不会意识到这些更新。然而,每一次更新应用和采用新版本时,都会出现有意或无意地在应用中插入安全威胁的机会。因此,除非终端用户勤奋地监视其软件的维护,否则终端用户可能不会意识到被插入到其基于软件的工具中的潜在的安全威胁。
2、鉴于现代软件开发的性质,这种经插入的安全威胁的可能性增加了。应用可以包括或至少基于许多组件、功能、子例程、模块、库、数据和计算对象/模型、数据库、代码库、子应用、分包等(统称为软件组件或简称组件)被开发。这样,应用现在经由供应商的“供应链”被例程地开发和维护,该供应商向应用的发布方提供各种组件的至少一部分。例如,软件发布方可以通过从供应链采购各种组件来开发应用。应用开发中经利用的每一个组件可以提供针对包含安全威胁的机会。因此,应用的安全性受其供应链中“最薄弱环节”(组件或为组件做出贡献的供应商)的影响。因此,每一个组件的每一次更新为将安全威胁插入到应用提供了机会。此外,供应链的组件(或组件供应商)之间的依赖关系可能是复杂和/或层级的。随着应用的架构细节不断趋于复杂,供应链内的漏洞的相互依赖关系和内部依赖关系也趋向于复杂。供应链的复杂和/或层级性质使得通过手动检查来检测和缓解此类安全漏洞变得困难。
3、传统上,通过“沙盒”或其他类似的受约束的测试环境,可以解决通过版本更新向应用中潜在插入安全威胁。然而,受约束的测试环境不能暴露许多潜在的安全威胁或漏洞。有些安全威胁只有在特定条件下才会显现,而任何特定沙盒都不太可能触发这些威胁。没有软件(手动或自动)测试人员能预测(从而模拟)终端用户在利用应用时会出现的每一种情况。因此恶意行为者(可以访问供应链的至少一部分)可能会故意设计安全威胁,这些威胁不太可能在测试沙盒中显现,但一旦应用被广泛采用,就很可能会显现。例如,时间-延迟可以被利用,使得安全威胁只有在安装后足够长的时间段过期后才会被触发。恶意行为者可能会调用其他隐蔽机制,故意从传统应用测试环境中隐藏将安全威胁插入到应用的供应链中。
技术实现思路
1、本公开所描述技术的各个方面通常涉及系统、方法和计算机存储介质,除其他外,用于对软件应用的供应链相关安全威胁的检测。一个示例性但非限制性的方法实施例可以是用于标识可疑应用更新方法。该方法可以包括标识经更新的源代码和先前源代码之间的至少一个差异。所述经更新的源代码与应用的经更新的版本相对应。所述先前源代码与所述应用的先前版本相对应。针对所述应用的所述经更新的版本确定风险得分。该风险得分可以基于机器学习(ml)风险模型。该ml风险模型可以分析经更新的源代码和先前源代码之间的一个或多个差异。该风险得分的值可以与应用的经更新的版本中包含和/或与之相关联的一个或多个潜在的安全威胁相对应。一个或多个潜在的安全威胁可能不被包含在应用的先前版本中和/或与之相关联。该风险得分可以被提供向一个或多个有关各方。
2、其他实施例涉及一种系统。该系统可以包含一个或多个硬件处理器,以及一个或多个其上承载有可执行指令的计算机可读介质。当可执行指令被一个或多个处理器执行时,该一个或多个硬件处理器可以执行用于标识可疑应用更新的动作、操作或步骤。该动作可以包含或包括标识经更新的源代码和先前源代码之间的至少一个差异。所述经更新的源代码与应用的经更新的版本相对应。所述先前源代码与所述应用的先前版本相对应。针对所述应用的所述经更新的版本确定风险得分。该风险得分可以基于机器学习(ml)风险模型。该ml风险模型可以分析经更新的源代码和先前源代码之间的一个或多个差异。该风险得分的值可以与应用的经更新的版本中包含和/或与之相关联的一个或多个潜在的安全威胁相对应。一个或多个潜在的安全威胁可能不被包含在应用的先前版本中和/或与之相关联。该风险得分可以被提供向一个或多个有关各方。
3、又一些实施例涉及非瞬态计算机可读存储介质。所述介质可以存储计算机可用指令,当被一个或多个计算设备使用时使所述一个或多个计算设备执行用于标识可疑应用更新的动作、操作和/或步骤。所述动作可以包括和/或包括标识经更新的源代码和先前源代码之间的至少一个差异。所述经更新的源代码与应用的经更新的版本相对应。所述先前源代码与所述应用的先前版本相对应。针对所述应用的所述经更新的版本确定风险得分。该风险得分可以基于机器学习(ml)风险模型。该ml风险模型可以分析经更新的源代码和先前源代码之间的一个或多个差异。该风险得分的值可以与应用的经更新的版本中包含和/或与之相关联的一个或多个潜在的安全威胁相对应。一个或多个潜在的安全威胁可能不被包含在应用的先前版本中和/或与之相关联。该风险得分可以被提供向一个或多个有关各方。
4、本
技术实现要素:
旨在以简化的形式介绍一些概念,这些概念将在下文的具体实施方式中被进一步描述。本发明内容无意标识权利要求主题的关键特征或基本特征,也无意用作确定权利要求主题范围的辅助工具。
1.一种用于标识可疑应用更新的计算机可实现的方法,所述方法包括:
2.根据权利要求1所述的方法,还包括:
3.根据权利要求1或2所述的方法,还包括:
4.根据权利要求1至3中任一项所述的方法,还包括:
5.根据权利要求1至4中任一项所述的方法,还包括:
6.根据权利要求1至5中任一项所述的方法,还包括:
7.根据权利要求1至6中任一项所述的方法,其中所述ml风险模型是基于经标记的训练数据训练得到的源代码分类模型,所述经标记的训练数据包括与针对至少一个其他应用的多个高风险更新相对应的经标记的高风险源代码和与针对所述至少一个其他应用的多个低风险更新相对应的经标记的低风险源代码。
8.根据权利要求1至7中任一项所述的方法,其中所述ml风险模型是基于规则的ml(rbml)模型。
9.根据权利要求1至8中任一项所述的方法,其中所述风险得分进一步基于所述经更新的源代码内的至少一个部分,所述至少一个部分与所述经更新的源代码和所述先前源代码之间的所述至少一个差异相关联。
10.根据权利要求1至9中任一项所述的方法,还包括:
11.一种系统,包括:
12.根据权利要求11所述的系统,其中所述操作还包括:
13.根据权利要求11或12所述的系统,其中所述操作还包括:
14.根据权利要求11至13中任一项所述的系统,其中所述操作还包括:
15.根据权利要求11至14中任一项所述的系统,其中所述操作还包括: