安全漏洞修复的方法、装置、计算机设备和存储介质
技术领域
本公开涉及网络信息安全领域,具体而言,涉及一种安全漏洞修复的方法、装置、计算机设备和存储介质。
背景技术
开源对软件开发的发展可以说具有深远的意义,它帮助开发人员共享成果,重复使用其他人开发的软件库,让开发人员能够专注于自己的创新,推进了技术的快速发展。
很多企业都在使用开源,但是开源依赖(亦称为第三方依赖)在开发时很少进行安全性测试,造成第三方依赖存在一定的安全隐患,从而导致基于此开发的应用存在一定的安全漏洞。
因此,如何对由于使用第三方依赖造成的应用安全漏洞进行修复成为现有技术中亟待解决的技术问题之一。
发明内容
本公开实施例至少提供一种安全漏洞修复的方法、装置、计算机设备和存储介质,用以查找和定位第三方依赖漏洞,针对查找到的漏洞生成修复方案,提高应用安全性。
第一方面,本公开实施例提供了一种安全漏洞修复的方法,包括:
获取依赖配置文件,基于所述依赖配置文件确定待检测应用所依赖的各依赖包之间的依赖关系信息和依赖描述信息;
根据记录的各依赖包的漏洞修复信息,确定存在安全漏洞的第一目标依赖包;
根据所述第一目标依赖包和所述依赖关系信息,确定包含所述第一目标依赖包的至少一条目标依赖链;
针对第一目标依赖包,根据所述第一目标依赖包的第一漏洞修复信息生成漏洞修复方案;
针对所述目标依赖链上除第一目标依赖包以外的第二目标依赖包,根据所述第一目标依赖包的第一漏洞修复信息和所述第一目标依赖包与所述第二目标依赖包之间的依赖描述信息生成漏洞修复方案。
一种可选的实施方式中,获取依赖配置文件,基于所述依赖配置文件确定待检测应用所依赖的各依赖包之间的依赖关系信息,具体包括:
从依赖配置文件中,读取所述待检测应用所依赖的各依赖包之间的依赖关系数据;
根据读取的依赖关系数据生成依赖树;
确定所述依赖树为待检测应用所依赖的各依赖包之间的所述依赖关系信息。
一种可选的实施方式中,获取依赖配置文件,基于所述依赖配置文件确定待检测应用所依赖的各依赖包之间的依赖关系信息,包括:
从依赖配置文件中,读取所述待检测应用所依赖的各依赖包之间的依赖关系数据;
根据读取的依赖关系数据生成依赖树;
合并所述依赖树中的重复依赖包,生成所述依赖树对应的双向依赖图;
确定所述双向依赖图为待检测应用所依赖的各依赖包之间的所述依赖关系信息。
一种可选的实施方式中,根据所述第一目标依赖包和所述依赖关系信息,确定包含所述第一目标依赖包的至少一条目标依赖链,具体包括:
根据所述依赖关系信息,从第一目标依赖包开始冒泡查找依赖于所述第一目标依赖包的第三目标依赖包;
确定所述第一目标依赖包和查找到的第三目标依赖包,组成目标依赖链。
一种可选的实施方式中,所述各个依赖包之间的依赖描述信息包括各个依赖包之间的版本依赖描述信息;以及
针对所述目标依赖链上除第一目标依赖包以外的第二目标依赖包,根据所述第一目标依赖包的第一漏洞修复信息和所述第一目标依赖包与所述第二目标依赖包之间的依赖描述信息生成漏洞修复方案,包括:
从所述目标依赖链中包含的各个依赖包之间的依赖描述信息中,获取所述第二目标依赖包与所述第一目标依赖包之间的版本依赖描述信息;
根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本不低于当前版本的情况下,针对所述第一目标依赖包,生成根据所述第一漏洞修复信息进行修复的漏洞修复方案。
一种可选的实施方式中,根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本等于当前版本的情况下,判断是否存在所述第二目标依赖包的第二漏洞修复信息;
如果存在,则针对所述第二目标依赖包,生成根据所述第二漏洞修复信息进行修复的漏洞修复方案,以及针对所述第一目标依赖包,生成根据所述第一漏洞修复信息进行修复的漏洞修复方案;如果不存在,则针对第一目标依赖包,生成保持当前版本不变的漏洞修复方案。
一种可选的实施方式中,在针对第一目标依赖包和第二目标依赖包生成漏洞修复方案之后,还包括:
缓存针对第一目标依赖包和第二目标依赖包生成漏洞修复方案;以及
在判断出需要针对所述第一目标依赖包和所述第二目标依赖包再次生成漏洞修复方案的情况下,复用缓存的、针对第一目标依赖包和第二目标依赖包生成漏洞修复方案。
第二方面,本公开实施例还提供一种安全漏洞修复的装置,包括:
第一确定单元,用于获取依赖配置文件,基于所述依赖配置文件确定待检测应用所依赖的各依赖包之间的依赖关系信息和依赖描述信息;
第二确定单元,用于根据记录的各依赖包的漏洞修复信息,确定存在安全漏洞的第一目标依赖包;
第三确定单元,用于根据所述第一目标依赖包和所述依赖关系信息,确定包含所述第一目标依赖包的至少一条目标依赖链;
第一生成单元,用于针对第一目标依赖包,根据所述第一目标依赖包的第一漏洞修复信息生成漏洞修复方案;
第二生成单元,用于针对所述目标依赖链上除第一目标依赖包以外的第二目标依赖包,根据所述第一目标依赖包的第一漏洞修复信息和所述第一目标依赖包与所述第二目标依赖包之间的依赖描述信息生成漏洞修复方案。
一种可选的实施方式中,所述第一确定单元,具体用于从依赖配置文件中,读取所述待检测应用所依赖的各依赖包之间的依赖关系数据;根据读取的依赖关系数据生成依赖树;确定所述依赖树为待检测应用所依赖的各依赖包之间的所述依赖关系信息。
一种可选的实施方式中,所述第一确定单元,具体用于从依赖配置文件中,读取所述待检测应用所依赖的各依赖包之间的依赖关系数据;根据读取的依赖关系数据生成依赖树;合并所述依赖树中的重复依赖包,生成所述依赖树对应的双向依赖图;确定所述双向依赖图为待检测应用所依赖的各依赖包之间的所述依赖关系信息。
一种可选的实施方式中,所述第三确定单元,具体用于根据所述依赖关系信息,从第一目标依赖包开始冒泡查找依赖于所述第一目标依赖包的第三目标依赖包;确定所述第一目标依赖包和查找到的第三目标依赖包,组成目标依赖链。
一种可选的实施方式中,所述各个依赖包之间的依赖描述信息包括各个依赖包之间的版本依赖描述信息;以及
所述第二生成单元,用于从所述目标依赖链中包含的各个依赖包之间的所述依赖描述信息中,获取所述第二目标依赖包与所述第一目标依赖包之间的版本依赖描述信息;根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本不低于当前版本的情况下,针对所述第一目标依赖包,生成根据所述第一漏洞修复信息进行修复的漏洞修复方案。
一种可选的实施方式中,所述第二生成单元,还用于根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本等于当前版本的情况下,判断是否存在所述第二目标依赖包的第二漏洞修复信息;如果存在,则针对所述第二目标依赖包,生成根据所述第二漏洞修复信息进行修复的漏洞修复方案,以及针对所述第一目标依赖包,生成根据所述第一漏洞修复信息进行修复的漏洞修复方案;如果不存在,则针对第一目标依赖包,生成保持当前版本不变的漏洞修复方案。
一种可选的实施方式中,缓存单元,用于在所述生成单元针对第一目标依赖包和第二目标依赖包分别生成漏洞修复方案之后,缓存针对第一目标依赖包和第二目标依赖包生成漏洞修复方案;
复用单元,用于在判断出需要针对所述第一目标依赖包和所述第二目标依赖包再次生成漏洞修复方案的情况下,复用所述缓存单元缓存的、针对第一目标依赖包和第二目标依赖包生成漏洞修复方案。
第三方面,本公开实施例还提供一种计算机设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当计算机设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
第四方面,本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
关于上述安全漏洞修复的装置、计算机设备及存储介质的效果描述参见上述安全漏洞修复的方法说明,这里不再赘述。
本公开实施例提供的安全漏洞修复的方法、装置、计算机设备及存储介质,根据依赖配置文件获取各个依赖包之间的依赖关系信息,并据此生成依赖链,在判断出某一依赖包存在安全漏洞时,基于包含该依赖包的依赖链查找该依赖包关联的其他依赖包,进而根据依赖配置文件中记录的各个依赖包之间的依赖描述信息针对各个依赖包生成漏洞修复方案,由此提高了使用第三方依赖的应用的安全性。
进一步,本公开实施例提供的安全漏洞修复的方法、装置、计算机设备及存储介质,通过从依赖配置文件读取各依赖包之间的依赖关系数据,根据读取的依赖关系数据生成依赖树,将生成的依赖树作为待检测应用所依赖的各依赖包之间的依赖关系信息,采用树型结构来表示各个依赖包之间的依赖关系,通过遍历依赖树快速生成对应漏洞依赖包的目标依赖链,提高了目标依赖链生成效率。
进一步,本公开实施例提供的安全漏洞修复的方法、装置、计算机设备及存储介质,还可以通过合并依赖树中的重复依赖包,将依赖树转化为双向依赖图的方式,进一步缩短生成对应漏洞依赖包的目标依赖链所需时间,缩短了后续漏洞修复所需时间。
进一步,本公开实施例提供的安全漏洞修复的方法、装置、计算机设备及存储介质,通过对已生成漏洞修复方案进行实时缓存,后续通过复用已生成漏洞修复方案,缩短了安全漏洞修复所需时间,提高了安全漏洞修复效率。
为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本公开实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,此处的附图被并入说明书中并构成本说明书中的一部分,这些附图示出了符合本公开的实施例,并与说明书一起用于说明本公开的技术方案。应当理解,以下附图仅示出了本公开的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本公开实施例所提供的一种安全漏洞修复方法的流程图;
图2示出了本公开实施例所提供的一种安全漏洞修复方法中,一种依赖树的结构图;
图3示出了本公开实施例所提供的一种安全漏洞修复方法中,双向依赖图;
图4示出了本公开实施例所提供的一种安全漏洞修复装置的示意图;
图5示出了本公开实施例所提供的一种计算机设备的结构示意图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
另外,本公开实施例中的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。
在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
经研究发现,在开源系统中,第三方依赖安全性测试不规范,导致其系统存在安全漏洞,泄露重要信息。
基于上述研究,本公开提供了一种安全漏洞修复的方法、装置、计算机设备和存储介质,通过确定依赖链,针对漏洞依赖包和依赖链上直接或者间接依赖漏洞依赖包的其他依赖包分别生成漏洞修复方案的方式,提高使用第三方依赖的应用的安全性;通过建立数据结构模型,将项目依赖树转化成双向依赖图,进一步降低漏洞依赖链漏洞修复复杂度,缩短后续漏洞依赖链漏洞修复所需时间;另外,对生成的修复方案实时缓存,缩短安全漏洞修复所需时间,提高安全漏洞修复效率。
针对以上方案所存在的缺陷,均是发明人在经过实践并仔细研究后得出的结果,因此,上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案,都应该是发明人在本公开过程中对本公开做出的贡献。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
为便于对本实施例进行理解,首先对本公开实施例所公开的一种安全漏洞修复的方法进行详细介绍,本公开实施例所提供的安全漏洞修复的方法的执行主体一般为具有一定计算能力的计算机设备,该计算机设备例如包括:终端设备或服务器或其它处理设备,终端设备可以为用户设备(User Equipment,UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字处理(Personal Digital Assistant,PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中,该安全漏洞修复的方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。
需要说明的是,本公开实施例提供的一种安全漏洞修复的方法,既适用于客户端侧业务开发,也可以用于服务器侧的业务开发。
下面以执行主体为计算机设备为例对本公开实施例提供的安全漏洞修复的方法加以说明。
实施例一
为了提高使用第三方依赖的应用的安全性,本公开实施例一提供了一种安全漏洞修复的方法,参见图1所示,包括以下步骤:
S101:获取依赖配置文件,基于依赖配置文件确定待检测应用所依赖的各依赖包之间的依赖关系信息和依赖描述信息。
本步骤中,可以通过管理客户端将待检测应用的第三方依赖配置文件上传到服务端,获取依赖配置文件;服务端通过读取待检测应用的依赖配置文件,以确定该项目所依赖的各个依赖包之间的依赖关系信息和依赖描述信息。其中,依赖配置文件中包括各依赖包的当前版本信息,以及各个依赖包之间的依赖关系数据。
例如,从某一待检测应用N的依赖配置文件中获取各个依赖包之间的依赖关系数据如下:{A{B,C},B{C,D1},E{D2},F},根据依赖关系数据可以确定各个依赖包之间的依赖关系,本例中,根据获取的依赖关系数据可以确定待检测应用所依赖的依赖包包括A,B,E和F,其中,各个依赖包之间A依赖B和C,B依赖C和D1,E依赖D2。在一个实施例中,可以将读取的依赖关系数据直接作为各个依赖包之间的依赖关系信息。
在依赖配置文件中还包括各依赖包A、B、C、D1、E、D2和F的当前版本信息,以及该待检测应用各个依赖包之间的依赖描述信息,其中,依赖描述信息包括各个依赖包之间的版本依赖描述信息,例如,B的1.0.0版本对C的依赖是C>=1.0.0版本,或者,B的1.0.0版本对C的依赖是C=1.0.0版本等。
服务器通过读取依赖配置文件,可以获取各个依赖数据包之间的依赖关系信息和依赖描述信息。
S102:根据记录的各依赖包的漏洞修复信息,确定存在安全漏洞的第一目标依赖包。
本步骤中,可以根据安全漏洞数据库中记录各依赖包的漏洞修复信息,确定存在安全漏洞的第一目标依赖包。其中,漏洞修复信息可以为存在安全漏洞的依赖包需要更新的修复版本信息。
具体实施时,针对待检测应用所依赖的每一依赖包,将依赖配置文件中记录的该依赖包的当前版本信息与系统的安全漏洞数据库中记录的各个依赖包的漏洞修复信息进行对比,以判断安全漏洞数据库中是否存在该依赖包的修复版本,如果发现该安全漏洞数据库中存在该依赖包的漏洞修复信息,则确定该依赖包存在安全漏洞,并将此依赖包标记为第一目标依赖包,重复上述过程,直至遍历待检测应用依赖的全部依赖包为止。
S103:根据第一目标依赖包和依赖关系信息,确定包含第一目标依赖包的至少一条目标依赖链。
本步骤中,以依赖关系信息为{A{B,C},B{C,D1},E{D2},F}为例,假设步骤S102中确定出的第一目标依赖包为C,则从C开始反向查找到如下几条直接或者间接依赖C的目标依赖链:第一条目标依赖链为N->A->B->C,第二条目标依赖链为N->A->C,第三条目标依赖链为N->B->C。
S104:针对第一目标依赖包,根据第一目标依赖包的第一漏洞修复信息生成漏洞修复方案。
具体实施时,针对第一目标依赖包,可以根据第一目标依赖包在系统安全漏洞数据库中记录的修复版本,生成漏洞修复方案。例如,存在第一目标依赖包C的版本是1.0.0,对应的修复版本是1.0.1,则生成的漏洞修复方案就是将C的版本更新为1.0.1。
S105:针对目标依赖链上除第一目标依赖包以外的第二目标依赖包,根据第一目标依赖包的第一漏洞修复信息和第一目标依赖包与第二目标依赖包之间的依赖描述信息生成漏洞修复方案。
具体实施时,针对步骤S103中确定出的至少一条目标依赖链,可以任意选取其中一条目标依赖链,以第一目标依赖包为起点,逐级反向查找直接或者间接依赖于第一目标依赖包的第二目标依赖包,需要说明的是,本公开实施例中,第二目标依赖包可以包括目标依赖链上除第一目标依赖包以外的所有依赖包。
本步骤中,根据步骤S101中获取的各个依赖包之间的依赖描述信息,第二目标依赖包生成漏洞修改方案。
在一个实施例中,可以从目标依赖链中包含的各个依赖包之间的依赖描述信息中,获取第二目标依赖包与第一目标依赖包之间的版本依赖描述信息;根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本不低于当前版本的情况下,针对第一目标依赖包,生成根据第一漏洞修复信息进行修复的漏洞修复方案。
延续上例,可以任意选取其中一条目标依赖链N->A->B->C,以第一目标依赖包C为起点,反向查找直接或者间接依赖C的第二目标依赖包为A和B;其中,第一目标依赖包C版本为1.0.0,其漏洞修复版本为1.0.1,如果第二目标依赖包B对第一目标依赖包C的依赖是C>=1.0.0版本,在这种情况下,只需更新第一目标依赖包C的版本到漏洞修复版本1.0.1即可,保持B当前版本不变。
在另一实施例中,如果根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本等于当前版本的情况下,判断安全漏洞数据库中是否存在第二目标依赖包的第二漏洞修复信息;如果存在,则针对第二目标依赖包,生成根据第二漏洞修复信息进行修复的漏洞修复方案,以及针对所述第一目标依赖包,生成根据第一漏洞修复信息进行修复的漏洞修复方案;如果不存在,则针对第一目标依赖包,生成保持当前版本不变的漏洞修复方案。
延续上例,如果第二目标依赖包B对第一目标依赖包C的依赖是C=1.0.0版本,这种情况下,如果C存在安全漏洞将C升级为新版本1.0.1,但是,由于B的当前版本对C的依赖是C=1.0.0,因此,对于C的升级将导致B的依赖异常,这种情况下,可以首先判断安全漏洞数据库中是否存在B的漏洞修复信息,如果存在,则可以首先将依赖包B升级到1.0.1版本,之后,再将依赖C升级到1.0.1版本。如果安全漏洞数据库中不存在B的漏洞修复信息,则保持C当前版本不变。
另外,需要说明的是,如果对B进行了修复,还需要进一步根据A和B之间的依赖描述信息生成A的修复方案,其具体实施,与上述根据依赖包C和B之间的依赖描述信息生成B的修复方案类似,这里不再赘述。
根据本公开实施例提供的安全漏洞修复的方法,通过读取依赖配置文件,获取各个依赖包之间的依赖关系信息和依赖描述信息,针对存在安全漏洞的第一目标依赖包,根据获取的依赖关系信息生成包含该第一目标依赖包的目标依赖链,针对目标依赖链上包含的第一目标依赖包和第二目标依赖包根据获取的依赖描述信息生成安全漏洞修复方案,由此,提高了使用第三方依赖的应用的安全性。
实施例二
在一种实施方式中,在针对第一目标依赖包和第二目标依赖包生成漏洞修复方案之后,还包括:缓存针对第一目标依赖包和第二目标依赖包生成漏洞修复方案;以及在判断出需要针对第一目标依赖包和所述第二目标依赖包再次生成漏洞修复方案的情况下,复用缓存的针对第一目标依赖包和第二目标依赖包生成漏洞修复方案。
具体实施时,在生成漏洞修复方案之后,可以实时缓存生成的漏洞修复方案,在后续寻找到相同漏洞的依赖包,需要针对此漏洞依赖包生成漏洞修复方案时,可以重复调用之前缓存的漏洞修复方案,简化了查找依赖链的逻辑和时间。
实施例三
针对步骤S101依赖配置文件,确定待检测应用所依赖的各依赖包之间的依赖关系信息,在本公开实施例提供了一个实施方式,将待检测应用中依赖包转化成数据结构模式,建立依赖树。延续步骤S101中的例子,如图2所示,提供了一种依赖树结构图。
具体实施时,从依赖配置文件中,读取待检测应用所依赖的各依赖包之间的依赖关系数据;根据读取的依赖关系数据生成依赖树;确定依赖树为待检测应用所依赖的各依赖包之间的依赖关系信息。
在这种实施方式中,根据依赖关系信息,从第一目标依赖包开始冒泡查找依赖于第一目标依赖包的第三目标依赖包;确定第一目标依赖包和查找到的第三目标依赖包,组成目标依赖链。
具体实施时,依赖链的生成方式可以为,找到项目起点,在此项目起点之下至少包含一个依赖于本项目起点的第一级依赖包,在第一级依赖包下,找到依赖于第一级依赖包的至少一个第二级依赖包,以此类推,将得到该项目所有的依赖链。
本步骤具体实施时,延续步骤S101中的例子,如果依赖包C为存在安全漏洞依赖包,即C为第一目标依赖包;以第一目标依赖包C为起点开始冒泡查找,按照如图2所示的依赖关系信息,确定包含第一目标依赖包C的目标依赖链为N->A->B->C、N->A->C和N->B->C。
根据本公开实施例提供的安全漏洞修复方法中的一种依赖树结构,通过遍历依赖树快速生成对应漏洞依赖包的目标依赖链,进而生成此漏洞依赖包的修复方案,由此,增加了寻找目标依赖链的效率,进而减少了生成漏洞依赖包的修复方案的时间。
实施例四
针对步骤S101依赖配置文件,确定待检测应用所依赖的各依赖包之间的依赖关系信息,在本公开实施例提供了另一个实施方式中,将依赖树转化成双向依赖图。延续步骤S101中的例子,如图3所示,提供了双向依赖图。
具体实施时,从依赖配置文件中,读取待检测应用所依赖的各依赖包之间的依赖关系数据;根据读取的依赖关系数据生成依赖树;合并依赖树中的重复依赖包,生成依赖树对应的双向依赖图;确定双向依赖图为待检测应用所依赖的各依赖包之间的依赖关系信息。
本步骤具体实施时,延续步骤S101中的例子,如果依赖包C为存在安全漏洞依赖包,即C为第一目标依赖包;以第一目标依赖包C为起点开始冒泡查找,按照如图3所示的依赖关系信息,确定包含第一目标依赖包C的目标依赖链为N->A->B->C、N->A->C和N->B->C。
进一步的,本公开实施例提供的一种数据结构,将项目依赖包转换成依赖树的结构模式,简化了后续查找依赖链的逻辑,并缩短了查找时间。
本公开实施例提供的将项目依赖树转化成双向依赖图,进一步简化了后续寻找漏洞和依赖链的逻辑和时间。
根据本公开实施例提供的安全漏洞修复方法中的一种双向依赖图的结构,通过合并依赖树中的重复依赖包,将依赖树转化为双向依赖图的方式,进一步缩短生成对应漏洞依赖包的目标依赖链所需时间,进而减少了生成漏洞依赖包的修复方案的时间。
本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思,本公开实施例中还提供了与安全漏洞修复的方法对应的安全漏洞修复的装置,由于本公开实施例中的装置解决问题的原理与本公开实施例上述安全漏洞修复的方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
实施例五
参照图4所示,为本公开实施例五提供的一种安全漏洞修复装置的示意图,该装置包括:第一确定单元401、第二确定单元402、第三确定单元403、第一生成单元404和第二生成单元405;其中,
第一确定单元401,用于获取依赖配置文件,基于所述依赖配置文件确定待检测应用所依赖的各依赖包之间的依赖关系信息和依赖描述信息;
第二确定单元402,用于根据记录的各依赖包的漏洞修复信息,确定存在安全漏洞的第一目标依赖包;
第三确定单元403,用于根据所述第一目标依赖包和所述依赖关系信息,确定包含所述第一目标依赖包的至少一条目标依赖链;
第一生成单元404,用于针对第一目标依赖包,根据所述第一目标依赖包的第一漏洞修复信息生成漏洞修复方案;
第二生成单元405,用于针对所述目标依赖链上除第一目标依赖包以外的第二目标依赖包,根据所述第一目标依赖包的第一漏洞修复信息和所述第一目标依赖包与所述第二目标依赖包之间的依赖描述信息生成漏洞修复方案。
一种可能的实施方式中,所述第一确定单元401,具体用于从依赖配置文件中,读取所述待检测应用所依赖的各依赖包之间的依赖关系数据;根据读取的依赖关系数据生成依赖树;确定所述依赖树为待检测应用所依赖的各依赖包之间的所述依赖关系信息。
一种可能的实施方式中,所述第一确定单元401,具体用于从依赖配置文件中,读取所述待检测应用所依赖的各依赖包之间的依赖关系数据;根据读取的依赖关系数据生成依赖树;合并所述依赖树中的重复依赖包,生成所述依赖树对应的双向依赖图;确定所述双向依赖图为待检测应用所依赖的各依赖包之间的所述依赖关系信息。
一种可能的实施方式中,所述第三确定单元403,具体用于根据所述依赖关系信息,从第一目标依赖包开始冒泡查找依赖于所述第一目标依赖包的第三目标依赖包;确定所述第一目标依赖包和查找到的第三目标依赖包,组成目标依赖链。
一种可能的实施方式中,所述各个依赖包之间的依赖描述信息包括各个依赖包之间的版本依赖描述信息;以及
所述第二生成单元405,用于从所述目标依赖链中包含的各个依赖包之间的所述依赖描述信息中,获取所述第二目标依赖包与所述第一目标依赖包之间的版本依赖描述信息;根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本不低于当前版本的情况下,针对所述第一目标依赖包,生成根据所述第一漏洞修复信息进行修复的漏洞修复方案。
一种可能的实施方式中,所述第二生成单元405,还用于根据获取的版本依赖描述信息,在第二目标依赖包对第一目标依赖包的依赖是第一目标依赖包的版本等于当前版本的情况下,判断所述安全漏洞数据库中是否存在所述第二目标依赖包的第二漏洞修复信息;如果存在,则针对所述第二目标依赖包,生成根据所述第二漏洞修复信息进行修复的漏洞修复方案,以及针对所述第一目标依赖包,生成根据所述第一漏洞修复信息进行修复的漏洞修复方案;如果不存在,则针对第一目标依赖包,生成保持当前版本不变的漏洞修复方案。
一种可能的实施方式中,缓存单元,用于在所述生成单元针对第一目标依赖包和第二目标依赖包分别生成漏洞修复方案之后,缓存针对第一目标依赖包和第二目标依赖包生成漏洞修复方案;
复用单元,用于在判断出需要针对所述第一目标依赖包和所述第二目标依赖包再次生成漏洞修复方案的情况下,复用所述缓存单元缓存的、针对第一目标依赖包和第二目标依赖包生成漏洞修复方案。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
实施例六
基于同一技术构思,本申请实施例还提供了一种计算机设备。参照图5所示,为本申请实施例提供的计算机设备的结构示意图,包括处理器501、存储器502、和总线503。其中,存储器502用于存储执行指令,包括内存5021和外部存储器5022;这里的内存5021也称内存储器,用于暂时存放处理器501中的运算数据,以及与硬盘等外部存储器5022交换的数据,处理器501通过内存5021与外部存储器5022进行数据交换,当计算机设备运行时,处理器501与存储器502之间通过总线503通信,使得处理器501在执行上述方法实施例中所提及的执行指令
本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法实施例中所述的安全漏洞修复方法的步骤。其中,该存储介质可以是易失性或非易失的计算机可读取存储介质。
本公开实施例还提供一种计算机程序产品,该计算机程序产品承载有程序代码,所述程序代码包括的指令可用于执行上述方法实施例中所述的安全漏洞修复方法的步骤,具体可参见上述方法实施例,在此不再赘述。
其中,上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,所述计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,计算机程序产品具体体现为软件产品,例如软件开发包(Software Development Kit,SDK)等等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应所述以权利要求的保护范围为准。