CN117744090A - 一种漏洞检测方法、装置及系统 - Google Patents

Abstract

本申请涉及终端安全领域，具体提供一种漏洞检测方法、装置及系统，该方法包括：获取待检测漏洞；判断漏洞检测脚本库中是否存在与待检测漏洞相匹配的漏洞检测脚本；当漏洞检测脚本库中存在漏洞检测脚本时，获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到漏洞检测结果；当漏洞检测脚本库中不存在漏洞检测脚本时，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果。可见，该方法、装置及系统能够提高漏洞检测的全面性，从而尽可能避免漏检的情况出现，进而提高Linux系统主机的应用安全性。

Description

一种漏洞检测方法、装置及系统

技术领域

本申请涉及终端安全领域，具体而言，涉及一种漏洞检测方法、装置及系统。

背景技术

随着Linux系统主机在服务器领域中的广泛应用，大量的开源软件和第三方组件也变的越来越多。然而，随着开源软件和第三方组件的应用变广，出现漏洞的可能性也在不断增加，从而导致漏洞检测的难度越来越高。目前，常用的漏洞检测方法在面对该种情况时，往往会出现较多的漏检，从而导致了Linux系统主机的应用安全性大幅降低。

发明内容

本申请实施例的目的在于提供一种漏洞检测方法、装置及系统，能够提高漏洞检测的全面性，从而尽可能避免漏检的情况出现，进而提高Linux系统主机的应用安全性。

本申请第一方面提供了一种漏洞检测方法，所述方法包括：

获取待检测漏洞；

判断漏洞检测脚本库中是否存在与所述待检测漏洞相匹配的漏洞检测脚本；

当所述漏洞检测脚本库中存在所述漏洞检测脚本时，获取所述漏洞检测脚本，并基于所述漏洞检测脚本对所述待检测漏洞进行检测，得到漏洞检测结果；

当所述漏洞检测脚本库中不存在所述漏洞检测脚本时，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果。

进一步地，所述通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果之后，所述方法还包括：

获取所述漏洞检测脚本，并基于所述漏洞检测脚本对所述待检测漏洞进行检测，得到深度检测结果；

基于所述深度检测结果，更新所述漏洞检测结果。

进一步地，所述通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果，包括：

采集与所述待检测漏洞相对应的Linux软件包信息、第三方依赖信息以及开源软件信息；

基于所述Linux软件包信息进行漏洞检测，得到第一检测结果；

基于所述第三方依赖信息进行漏洞检测，得到第二检测结果；

基于所述开源软件信息进行漏洞检测，得到第三检测结果；

结合所述第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果。

进一步地，所述基于所述Linux软件包信息进行漏洞检测，得到第一检测结果，包括：

确定与所述Linux软件包信息相对应的Linux发行版本；

确定与所述待检测漏洞相对应的漏洞补丁，并获取与所述漏洞补丁相对应的Linux修复版本范围；

判断所述Linux修复版本范围中是否包括所述Linux发行版本；

若所述Linux修复版本范围中不包括所述Linux发行版本，则判定所述第一检测结果为Linux软件包存在漏洞；所述Linux软件包与所述Linux软件包信息相对应。

进一步地，所述确定与所述待检测漏洞相对应的漏洞补丁，并获取与所述漏洞补丁相对应的Linux修复版本范围，包括：

获取OVAL文档，并在所述OVAL文档中确定与所述待检测漏洞相对应的漏洞补丁；

从所述OVAL文档中提取与所述漏洞补丁相对应的Linux修复版范围。

进一步地，所述基于所述第三方依赖信息进行漏洞检测，得到第二检测结果，包括：

确定关于所述第三方依赖信息相对应的第三方依赖文件；

基于预设的过滤规则和预设的检测白名单，滤除所述第三方依赖文件中的系统文件，得到待解析依赖文件；

对所述待解析依赖文件进行解析，得到信息文件；

从所述信息文件中获取所述待解析文件的第一Maven坐标；

解析所述信息文件中的依赖部分，得到解析结果；

根据所述解析结果确定所述待解析文件所依赖的第三方依赖包的第二Maven坐标；

汇总所述第一Maven坐标和所述第二Maven坐标得到目标Maven坐标；

基于所述目标Maven坐标，判断预设的第三方依赖漏洞数据源是否包括所述待检测漏洞；

若所述第三方依赖漏洞数据源包括所述待检测漏洞，则判定所述第二检测结果为所述待解析文件中存在所述待检测漏洞。

进一步地，所述基于所述开源软件信息进行漏洞检测，得到第三检测结果，包括：

识别与所述开源软件信息相对应的开源软件；

获取与所述开源软件相对应的进程信息；

基于所述进程信息确定所述开源软件的软件版本；

判断所述漏洞通用枚举平台信息中是否包括所述软件版本；

若所述漏洞通用枚举平台信息中包括所述软件版本，则判定所述第三检测结果为所述开源软件存在所述待检测漏洞。

本申请第二方面提供了一种漏洞检测装置，所述漏洞检测装置包括：

获取单元，用于获取待检测漏洞；

判断单元，用于判断漏洞检测脚本库中是否存在与所述待检测漏洞相匹配的漏洞检测脚本；

检测单元，用于当所述漏洞检测脚本库中存在所述漏洞检测脚本时，获取所述漏洞检测脚本，并基于所述漏洞检测脚本对所述待检测漏洞进行检测，得到漏洞检测结果；

所述检测单元，还用于当所述漏洞检测脚本库中不存在所述漏洞检测脚本时，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果。

进一步地，所述漏洞检测装置还包括：

所述检测单元，还用于在通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果之后，获取所述漏洞检测脚本，并基于所述漏洞检测脚本对所述待检测漏洞进行检测，得到深度检测结果；

更新单元，用于基于所述深度检测结果，更新所述漏洞检测结果。

进一步地，所述检测单元包括：

采集子单元，用于采集与所述待检测漏洞相对应的Linux软件包信息、第三方依赖信息以及开源软件信息；

第一检测子单元，用于基于所述Linux软件包信息进行漏洞检测，得到第一检测结果；

第二检测子单元，用于基于所述第三方依赖信息进行漏洞检测，得到第二检测结果；

第三检测子单元，用于基于所述开源软件信息进行漏洞检测，得到第三检测结果；

生成子单元，用于结合所述第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果。

进一步地，所述第一检测子单元包括：

第一确定模块，用于确定与所述Linux软件包信息相对应的Linux发行版本；

所述第一确定模块，还用于确定与所述待检测漏洞相对应的漏洞补丁，并获取与所述漏洞补丁相对应的Linux修复版本范围；

第一判断模块，用于判断所述Linux修复版本范围中是否包括所述Linux发行版本；

第一判定模块，用于在所述Linux修复版本范围中不包括所述Linux发行版本时，判定所述第一检测结果为Linux软件包存在漏洞；所述Linux软件包与所述Linux软件包信息相对应。

进一步地，所述第一确定模块，具体用于获取OVAL文档，并在所述OVAL文档中确定与所述待检测漏洞相对应的漏洞补丁；

所述第一确定模块，具体还用于从所述OVAL文档中提取与所述漏洞补丁相对应的Linux修复版范围。

进一步地，所述第二检测子单元包括：

第二确定模块，用于确定关于所述第三方依赖信息相对应的第三方依赖文件；

过滤模块，用于基于预设的过滤规则和预设的检测白名单，滤除所述第三方依赖文件中的系统文件，得到待解析依赖文件；

解析模块，用于对所述待解析依赖文件进行解析，得到信息文件；

第一获取模块，用于从所述信息文件中获取所述待解析文件的第一Maven坐标；

所述解析模块，还用于解析所述信息文件中的依赖部分，得到解析结果；

所述第二确定模块，还用于根据所述解析结果确定所述待解析文件所依赖的第三方依赖包的第二Maven坐标；

汇总模块，用于汇总所述第一Maven坐标和所述第二Maven坐标得到目标Maven坐标；

第二判断模块，用于基于所述目标Maven坐标，判断预设的第三方依赖漏洞数据源是否包括所述待检测漏洞；

第二判定模块，用于在所述第三方依赖漏洞数据源包括所述待检测漏洞时，判定所述第二检测结果为所述待解析文件中存在所述待检测漏洞。

进一步地，所述第三检测子单元包括：

识别模块，用于识别与所述开源软件信息相对应的开源软件；

第二获取模块，用于获取与所述开源软件相对应的进程信息；

第三确定模块，用于基于所述进程信息确定所述开源软件的软件版本；

第三判断模块，用于判断所述漏洞通用枚举平台信息中是否包括所述软件版本；

第三判定模块，用于若所述漏洞通用枚举平台信息中包括所述软件版本时，判定所述第三检测结果为所述开源软件存在所述待检测漏洞。

本申请第三方面提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请第一方面中任一项所述的漏洞检测方法。

本申请第四方面提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请第一方面中任一项所述的漏洞检测方法。

本申请的有益效果为：提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种漏洞检测方法的流程示意图；

图2为本申请实施例提供的一种漏洞检测方法的举例流程示意图；

图3为本申请实施例提供的一种漏洞检测方法所采用的结构示意图；

图4为本申请实施例提供的另一种漏洞检测方法的流程示意图；

图5为本申请实施例提供的一种Linux软件包漏洞检测流程图；

图6为本申请实施例提供的又一种漏洞检测方法的流程示意图；

图7为本申请实施例提供的一种第三方依赖漏洞检测流程图；

图8为本申请实施例提供的再一种漏洞检测方法的流程示意图；

图9为本申请实施例提供的一种开源软件漏洞检测流程图；

图10为本申请实施例提供的一种漏洞检测装置的结构示意图；

图11为本申请实施例提供的另一种漏洞检测装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

实施例1

请参看图1，图1为本实施例提供的一种漏洞检测方法的流程示意图。其中，该漏洞检测方法包括：

S101、获取待检测漏洞。

S102、判断漏洞检测脚本库中是否存在与待检测漏洞相匹配的漏洞检测脚本，若是，则执行步骤S103；若否，则执行步骤S104。

S103、获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到漏洞检测结果，并结束本流程。

S104、通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果，并结束本流程。

作为一种可选的实施方式，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果的步骤之后，该方法还包括：

获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到深度检测结果；

基于深度检测结果，更新漏洞检测结果。

本实施例中，该方法可以在Linux终端上部署一个代理程序，由该代理程序实施上述步骤。

具体的，由于漏洞中存在着一些较为复杂特殊的漏洞，因此该代理程序优先调用漏洞检测脚本库中对应的漏洞检测脚本，并在Linux终端上运行漏洞检测脚本来实现对待检测漏洞的漏洞检测，从而得到相应的漏洞检测结果。由此可见，该方法着力于通过漏洞检测脚本来对复杂特殊的漏洞进行检测，从而以此来保障漏洞检测的精确度。同时，在漏洞检测脚本不存在的时候，还可以采用资产版本匹配方式进行漏洞检测作为补充，从而避免检测脚本数据库不完备所带来的漏检问题，进而保障待检测漏洞都被检测到位。

其中，上述的资产版本匹配方式具体为：通过代理程序收集Linux终端中的各类信息，并将该些信息提交给漏洞检测服务器，以使漏洞检测服务器根据已知的漏洞信息和Linux终端中的各类信息进行漏洞存在性校验(如：判断Linux终端中的各类信息与已知的漏洞信息是否匹配)，从而判定Linux终端是否存在该漏洞(若Linux终端中的各类信息与已知的漏洞信息相匹配，则判定漏洞存在)。可见，该方法可以基于Linux终端中的各类信息直接确定漏洞的存在，从而在漏洞检测脚本不存在时，保障漏洞的正常检测，进而提高漏洞的检出率，提高整体的漏洞检测效果。

请参看图2，图2示出了一种漏洞检测方法的举例流程示意图。其中，图2与实施例1公开的步骤S101～S104相对应。具体的，步骤S103与图2中右半部分(图中漏洞检测流程部分)相对应，步骤S104与图2中左半部分(图中基于Linux软件包信息、第三方依赖信息和开源软件信息进行检测的流程部分)相对应。其中，

与步骤S103相对应的部分中，该方法可以把待检测漏洞发送给漏洞检测服务器，以使漏洞检测服务器在漏洞检测脚本库中检索遍历与待检测漏洞相对应的漏洞检测脚本，并在漏洞检测服务器在漏洞检测脚本库中遍历检索到与待检测漏洞相对应的漏洞检测脚本时，下发该漏洞检测脚本给漏洞检测系统(本方法的执行主体)，从而使得漏洞检测系统基于该漏洞检测脚本对待检测漏洞进行漏洞检测，进而得到漏洞检测结果。

与步骤S104相对应的部分中，该方法先采集Linux软件包信息、第三方依赖信息以及开源软件信息，并在采集完毕时，发送该些采集信息给漏洞检测服务器，以使漏洞检测服务器基于预设的漏洞库中的已知漏洞信息(即图中的漏洞库数据，该漏洞信息是漏洞检测服务器在漏洞库中拉取到的)对该些采集信息进行匹配性检测，并进一步基于该匹配性检测结果确定漏洞检测结果。

请参看图3，图3示出了一种漏洞检测方法所采用的结构示意图。图3中示出了，系统整体结构中包括目标终端(即Linux终端)和漏洞检测服务器，其中，目标终端上可以安装代理程序，该代理程序用于实时本实施例中提供的步骤。具体的，该代理程序可以用于负责漏洞检测所需终端信息的收集与上报，以及漏洞检测脚本的接收与执行。

至于漏洞检测服务器，该漏洞检测服务器独立在目标终端以外。该漏洞检测服务器主要用于接收目标终端上报的漏洞检测所需终端信息和拉取漏洞库数据，并对其进行处理；同时，还用于获取待检测漏洞，确定漏洞检测脚本存在与否，以及下发漏洞检测脚本。

基于图3可知，该方法在Linux终端上安装一个代理程序，并基于该代理程序实现来实时本实施例中的步骤，从而能够从底层机制上避免使用网络发包检测的方式。同时，由于代理程序设置于Linux终端，因此该方法可以检测操作系统以及系统组件漏洞、第三方组件依赖漏洞以及开源软件漏洞，从而解决了传统方法只能检测具有网络监听服务的软件漏洞的问题。另外，该方法还可以通过漏洞检测脚本来实现批量的深度检测，从而使得该方法在面对利用方式复杂、前置条件苛刻或者已经采取缓解措施的漏洞时，也能够进行有效的漏洞检测，进而确保乐漏洞检测的准确率。

本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。

可见，实施本实施例所描述的漏洞检测方法，能够提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

实施例2

请参看图4，图4为本实施例提供的一种漏洞检测方法的流程示意图。其中，该漏洞检测方法包括：

S201、获取待检测漏洞。

S202、当漏洞检测脚本库中不存在与待检测漏洞相匹配的漏洞检测脚本时，采集与待检测漏洞相对应的Linux软件包信息、第三方依赖信息以及开源软件信息。

S203、确定与Linux软件包信息相对应的Linux发行版本。

本实施例中，该方法在确定与Linux软件包信息相对应的Linux发行版本的过程中，可以先确定Linux软件包格式，然后再基于Linux软件包格式确定与Linux软件包信息相对应的Linux发行版本。其中，Linux软件包格式包括rpm(RedHat Package Manager)和dpkg(Debian Package)。

在本实施例中，redhat/suse发行版本中通常采用rpm格式。其中，该方法可以通过调用rpm程序接口的方式或读取rpm数据库(rpm数据库的目录地址一般在/var/lib/rpm，以Berkeley DB格式存储)的方式来获取与Linux软件包信息相对应的Linux发行版本(同时还可以获取Linux软件包名，架构信息，安装时间以及描述信息等)。

在本实施例中，debian发明版本中通常采用dpkg格式。其中，该方法可以通过调用dpkg程序接口的方式或读取dpkg数据库(dpkg数据库的目录地址一般在/var/lib/dpkg，以文本文件格式存储)的方式来获取与Linux软件包信息相对应的Linux发行版本(同时还可以获取Linux软件包名，架构信息，安装时间以及描述信息等)。

S204、获取OVAL文档，并在OVAL文档中确定与待检测漏洞相对应的漏洞补丁。

本实施例中，该方法可以从不同的Linux发行版本获取OVAL(开放式漏洞评估语言)文档。其中，这些文档中包含了不同Linux发行版本推送的漏洞补丁以及漏洞补丁相关的Linux软件包信息。

S205、从OVAL文档中提取与漏洞补丁相对应的Linux修复版范围。

本实施例中，该方法可以在获取OVAL文档中提取漏洞补丁信息，并获取该漏洞补丁对应的Linux软件包修复版本范围。

S206、判断Linux修复版本范围中是否包括Linux发行版本。

本实施例中，该方法可以基于修复版本范围判断Linux发行版本是否落入其中。具体的，如果落入其中，则说明该漏洞已修改；反之，则说明该漏洞是存在的。

S207、若Linux修复版本范围中包括Linux发行版本，则判定第一检测结果为Linux软件包不存在漏洞；若Linux修复版本范围中不包括Linux发行版本，则判定第一检测结果为Linux软件包存在漏洞；Linux软件包与Linux软件包信息相对应。

请参看图5，图5示出了一种Linux软件包漏洞检测流程图，该流程图与步骤S203～S207相匹配。

S208、基于第三方依赖信息进行漏洞检测，得到第二检测结果。

S209、基于开源软件信息进行漏洞检测，得到第三检测结果。

S210、结合第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果。

作为一种可选的实施方式，结合第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果的步骤之后，该方法还包括：

获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到深度检测结果；

基于深度检测结果，更新漏洞检测结果。

本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。

可见，实施本实施例所描述的漏洞检测方法，能够提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

实施例3

请参看图6，图6为本实施例提供的一种漏洞检测方法的流程示意图。其中，该漏洞检测方法包括：

S301、获取待检测漏洞。

S302、当漏洞检测脚本库中不存在与待检测漏洞相匹配的漏洞检测脚本时，采集与待检测漏洞相对应的Linux软件包信息、第三方依赖信息以及开源软件信息。

S303、基于Linux软件包信息进行漏洞检测，得到第一检测结果。

S304、确定关于第三方依赖信息相对应的第三方依赖文件。

举例来说，当第三方依赖为Java软件时，该方法可以先获取Linux终端中全部正在运行的进程；然后，从全部正在运行的进程中筛选出Java进程；再后，从该些Java进程引用的文件描述符中获取到Java进程引用的jar包(该jar包为第三方依赖文件)。

S305、基于预设的过滤规则和预设的检测白名单，滤除第三方依赖文件中的系统文件，得到待解析依赖文件。

本实施例中，当第三方依赖文件为jar包时，该方法可以基于检测白名单对jar包中进行过滤，得到待解析的pom.xml文件。其中，该白名单过滤的规则是：过滤掉Java进程引用的系统jar包，避免该些jar包参与第三方依赖jar包的漏洞检测流程。

S306、对待解析依赖文件进行解析，得到信息文件。

本实施例中，当待解析文件为pom.xml文件时，该方法可以对pom.xml文件进行解析，得到pom.xml文件中的dependencies块，并将其作为信息文件。

在本实施例中，pom.xml文件，是Maven工程(jar包的打包工具)的基本工作单元，该文件包含了项目的基本信息，用于描述项目如何构建，声明项目依赖等等。

S307、从信息文件中获取待解析文件的第一Maven坐标。

本实施例中，该方法可以对解析得到的对每一个dependency块再次进行解析，得到包括groupId，artifactId和version的第一Maven坐标。其中，该第一Maven坐标为jar包(即上述第三方依赖文件)的Maven坐标，这个坐标用来唯一的确定这个jar包的信息。

S308、解析信息文件中的依赖部分，得到解析结果。

S309、根据解析结果确定待解析文件所依赖的第三方依赖包的第二Maven坐标。

本实施例中，该方法可以解析pom.xml文件中的依赖部分，以得到当前jar包(即上述第三方依赖文件)所依赖的第三方依赖包的第二Maven坐标。其中，该Maven坐标包括第三方依赖包的groupId，artifactId和version。

S310、汇总第一Maven坐标和第二Maven坐标得到目标Maven坐标。

S311、基于目标Maven坐标，判断预设的第三方依赖漏洞数据源是否包括待检测漏洞。

本实施例中，该方法可以利用groupId，artifactId先确定比较主体的一致性，然后再用version信息比较其版本是否相同，从而以此来确定第三方依赖漏洞数据源是否包括待检测漏洞。其中，如果当前jar包或者jar包所依赖的第三方依赖包是有漏洞的，则直接确认待解析文件存在待检测漏洞；反之，则认为待解析文件不存在待检测漏洞。

S312、若第三方依赖漏洞数据源包括待检测漏洞，则判定第二检测结果为待解析文件中存在待检测漏洞；若第三方依赖漏洞数据源不包括待检测漏洞，则判定第二检测结果为待解析文件中不存在待检测漏洞。

请参看图7，图7示出了一种第三方依赖漏洞检测流程图。具体的，图7示出的是一种Java软件漏洞检测的流程示意图。其中，该流程图与步骤S304～S312相匹配。

S313、基于开源软件信息进行漏洞检测，得到第三检测结果。

S314、结合第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果。

作为一种可选的实施方式，结合第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果的步骤之后，该方法还包括：

获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到深度检测结果；

基于深度检测结果，更新漏洞检测结果。

本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。

可见，实施本实施例所描述的漏洞检测方法，能够提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

实施例4

请参看图8，图8为本实施例提供的一种漏洞检测方法的流程示意图。其中，该漏洞检测方法包括：

S401、获取待检测漏洞。

S402、当漏洞检测脚本库中不存在与待检测漏洞相匹配的漏洞检测脚本时，采集与待检测漏洞相对应的Linux软件包信息、第三方依赖信息以及开源软件信息。

S403、基于Linux软件包信息进行漏洞检测，得到第一检测结果。

S404、基于第三方依赖信息进行漏洞检测，得到第二检测结果。

S405、识别与开源软件信息相对应的开源软件。

S406、获取与开源软件相对应的进程信息。

本实施例中，该方法可以先获取Linux终端中全部正在运行的进程，并从全部正在运行的进程中筛选出开源软件进程，例如：MySQL服务进程，Apache HTTPD服务进程，ApacheTomcat服务进程等。

S407、基于进程信息确定开源软件的软件版本。

本实施例中，该方法可以通过开源软件进程获取到开源软件的版本信息。其中，获取方式根据不同的开源软件而不同。举例来说：

(1)在面对静态的开源软件时，该方法可以通过读取进程文件中的版本信息；

(2)在面对动态的开源软件时，该方法可以通过动态运行开源软件进程文件的相关version参数来获取版本信息。

S408、判断漏洞通用枚举平台信息中是否包括软件版本。

本实施例中，该方法可以获取与待检测漏洞相匹配的CPE信息，并基于该CPE信息中是否包括上述开源软件的软件版本。如果包括，则说明该开源软件存在漏洞；反之，则说明该开源软件不存在漏洞。

在本实施例中，CPE信息是一种以标准化方式为软件应用程序、操作系统及硬件命名的方法。通常情况，当NVD(国家漏洞数据库)发布漏洞相关CVE信息(CommonVulnerabilities and Exposures，公共漏洞和暴露)时，都会一起发布漏洞CVE所影响的CPE信息。

S409、若漏洞通用枚举平台信息中包括软件版本，则判定第三检测结果为开源软件存在待检测漏洞；若漏洞通用枚举平台信息中不包括软件版本，则判定第三检测结果为开源软件不存在待检测漏洞。

请参看图9，图9示出了一种开源软件漏洞检测流程图，该流程图与步骤S405～S409相匹配。

S410、结合第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果。

作为一种可选的实施方式，结合第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果的步骤之后，该方法还包括：

获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到深度检测结果；

基于深度检测结果，更新漏洞检测结果。

本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。

可见，实施本实施例所描述的漏洞检测方法，能够提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

实施例5

该实施例提供了一种漏洞检测方法的举例流程，具体如下：

S501、搭建环境。

具体的，选择两台Linux终端主机(A终端主机和B终端主机)，一台漏洞检测服务器。A终端主机安装Ubuntu 22.04.3LTS(Jammy Jellyfish)操作系统，上面存在policykit-1软件包，该软件包版本为0.105-31，同时使用springboot构建一个包含log4j2第三方依赖的jar包，使用log4j2的版本为2.14.0；B终端主机不限制Linux操作系统发行版，上面部署安装Apache HTTPD服务，安装版本为2.4.49，同时安装Apache Activemq，安装版本为5.11.0，关闭Activemq中的Fileserver web application(文件服务WEB应用)。

S502、使用代理程序分别在A，B两台终端主机采集信息。

具体的，A终端主机用于采集Linux软件包信息和第三方依赖信息；

B终端主机用于采集开源软件信息。

S503、采集调度分析。

具体如下：(1)判断A终端主机是属于debian发行版，A终端主机通过dpkg程序接口或者/var/lib/dpkg数据库获取到policykit-1软件包信息，获取到包名，架构，版本和描述信息。

(2)A终端主机获取全部运行进程，从中筛选出Java进程，获取该进程文件描述符引用的jar包文件，通过白名单过滤，过滤出引用的springboot构建的可执行jar包，解析jar包中的POM文件，提取其中的dependency信息，获取该jar包依赖log4j2组件，且获取该依赖的groupId，artifactId和version。

(3)A终端主机获取全部运行进程，筛选出开源软件服务进程：Apache HTTPD，Apache Activemq，获取开源软件版本信息。

S504、得到采集结果。

采集结果如表1所示。

表1采集结果

S505、拉取漏洞库信息。

具体的，漏洞库信息可以参见表2。

表2数据库信息

S506、进行漏洞检测。

具体如下：(1)A终端主机上软件包policykit-1版本为0.105-31，小于0.105-31.1，所以存在漏洞CVE-2021-4034。

(2)A终端主机上第三方依赖log4j-core版本为2.14.0，在区间[2.13.0,2.15.0)中，所以存在漏洞CVE-2021-44228。

(3)B终端主机上开源软件Apache HTTPD版本为2.4.49，符合漏洞CPE中描述的资产，所以存在漏洞CVE-2021-41773。

(4)B终端主机上开源软件Apache Activemq版本为5.11.0，符合漏洞CPE中描述的资产，所以存在漏洞CVE-2016-3088。

S507、检索漏洞检测脚本库。

具体如下；(1)在漏洞检测服务器上检测漏洞检测脚本，发现存在CVE-2016-3088的漏洞检测脚本。

(2)下发到B终端主机上，通过代理程序运行。

(3)漏洞检测脚本运行时发现B终端主机上漏洞CVE-2016-3088所影响的ApacheActivemq中的Fileserver web application(文件服务WEB应用)被关闭，导致该漏洞的关键条件不满足，该漏洞不存在。

(4)代理程序将结果上报到漏洞检测脚本库。

S508、漏洞检测脚本库综合上述检测结果的输出可以得到最终结果。

具体如下：(1)A终端主机存在漏洞CVE-2021-4034和CVE-2021-44228；

(2)B终端主机存在漏洞CVE-2021-41773。

本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。

在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。

可见，实施本实施例所描述的漏洞检测方法，能够提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

实施例6

请参看图10，图10为本实施例提供的一种漏洞检测装置的结构示意图。如图10所示，该漏洞检测装置包括：

获取单元610，用于获取待检测漏洞；

判断单元620，用于判断漏洞检测脚本库中是否存在与待检测漏洞相匹配的漏洞检测脚本；

检测单元630，用于当漏洞检测脚本库中存在漏洞检测脚本时，获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到漏洞检测结果；

检测单元640，还用于当漏洞检测脚本库中不存在漏洞检测脚本时，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果。

本实施例中，对于漏洞检测装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。

可见，实施本实施例所描述的漏洞检测装置，能够提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

实施例7

请参看图11，图11为本实施例提供的一种漏洞检测装置的结构示意图。如图11所示，该漏洞检测装置包括：

获取单元610，用于获取待检测漏洞；

判断单元620，用于判断漏洞检测脚本库中是否存在与待检测漏洞相匹配的漏洞检测脚本；

检测单元630，用于当漏洞检测脚本库中存在漏洞检测脚本时，获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到漏洞检测结果；

检测单元640，还用于当漏洞检测脚本库中不存在漏洞检测脚本时，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果。

作为一种可选的实施方式，漏洞检测装置还包括：

检测单元640，还用于在通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果之后，获取漏洞检测脚本，并基于漏洞检测脚本对待检测漏洞进行检测，得到深度检测结果；

更新单元650，用于基于深度检测结果，更新漏洞检测结果。

作为一种可选的实施方式，检测单元640包括：

采集子单元641，用于采集与待检测漏洞相对应的Linux软件包信息、第三方依赖信息以及开源软件信息；

第一检测子单元642，用于基于Linux软件包信息进行漏洞检测，得到第一检测结果；

第二检测子单元643，用于基于第三方依赖信息进行漏洞检测，得到第二检测结果；

第三检测子单元644，用于基于开源软件信息进行漏洞检测，得到第三检测结果；

生成子单元645，用于结合第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果。

作为一种可选的实施方式，第一检测子单元642包括：

第一确定模块，用于确定与Linux软件包信息相对应的Linux发行版本；

第一确定模块，还用于确定与待检测漏洞相对应的漏洞补丁，并获取与漏洞补丁相对应的Linux修复版本范围；

第一判断模块，用于判断Linux修复版本范围中是否包括Linux发行版本；

第一判定模块，用于在Linux修复版本范围中不包括Linux发行版本时，判定第一检测结果为Linux软件包存在漏洞；Linux软件包与Linux软件包信息相对应。

作为一种可选的实施方式，第一确定模块，具体用于获取OVAL文档，并在OVAL文档中确定与待检测漏洞相对应的漏洞补丁；

第一确定模块，具体还用于从OVAL文档中提取与漏洞补丁相对应的Linux修复版范围。

作为一种可选的实施方式，第二检测子单元643包括：

第二确定模块，用于确定关于第三方依赖信息相对应的第三方依赖文件；

过滤模块，用于基于预设的过滤规则和预设的检测白名单，滤除第三方依赖文件中的系统文件，得到待解析依赖文件；

解析模块，用于对待解析依赖文件进行解析，得到信息文件；

第一获取模块，用于从信息文件中获取待解析文件的第一Maven坐标；

解析模块，还用于解析信息文件中的依赖部分，得到解析结果；

第二确定模块，还用于根据解析结果确定待解析文件所依赖的第三方依赖包的第二Maven坐标；

汇总模块，用于汇总第一Maven坐标和第二Maven坐标得到目标Maven坐标；

第二判断模块，用于基于目标Maven坐标，判断预设的第三方依赖漏洞数据源是否包括待检测漏洞；

第二判定模块，用于在第三方依赖漏洞数据源包括待检测漏洞时，判定第二检测结果为待解析文件中存在待检测漏洞。

作为一种可选的实施方式，第三检测子单元644包括：

识别模块，用于识别与开源软件信息相对应的开源软件；

第二获取模块，用于获取与开源软件相对应的进程信息；

第三确定模块，用于基于进程信息确定开源软件的软件版本；

第三判断模块，用于判断漏洞通用枚举平台信息中是否包括软件版本；

第三判定模块，用于若漏洞通用枚举平台信息中包括软件版本时，判定第三检测结果为开源软件存在待检测漏洞。

本实施例中，对于漏洞检测装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。

可见，实施本实施例所描述的漏洞检测装置，能够提高漏洞检测的全面性，使其不仅仅能够通过网络发包检测具有网络服务的应用软件漏洞，还能够通过在终端主机上采集漏洞检测必要信息来进行漏洞检测，从而使得漏洞检测的范围和种类更广，灵活性更高。同时，还能够使用漏洞检测脚本来进行下发到终端主机运行，从而针对部分拥有漏洞利用前置条件或者漏洞检测较为复杂的更精准的来检测漏洞，进而提高漏洞检测的准确性。最后，还能够基于检测出来的漏洞在终端主机上定位到当初采集到的对应的必要信息，从而实现有效定位漏洞点的效果，进而便于及时修复。

本申请实施例提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本申请实施例1或实施例2中的漏洞检测方法。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本申请实施例1或实施例2中的漏洞检测方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种漏洞检测方法，其特征在于，所述方法包括：

获取待检测漏洞；

判断漏洞检测脚本库中是否存在与所述待检测漏洞相匹配的漏洞检测脚本；

当所述漏洞检测脚本库中存在所述漏洞检测脚本时，获取所述漏洞检测脚本，并基于所述漏洞检测脚本对所述待检测漏洞进行检测，得到漏洞检测结果；

当所述漏洞检测脚本库中不存在所述漏洞检测脚本时，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果。

2.根据权利要求1所述的漏洞检测方法，其特征在于，所述通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果之后，所述方法还包括：

获取所述漏洞检测脚本，并基于所述漏洞检测脚本对所述待检测漏洞进行检测，得到深度检测结果；

基于所述深度检测结果，更新所述漏洞检测结果。

3.根据权利要求1所述的漏洞检测方法，其特征在于，所述通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果，包括：

采集与所述待检测漏洞相对应的Linux软件包信息、第三方依赖信息以及开源软件信息；

基于所述Linux软件包信息进行漏洞检测，得到第一检测结果；

基于所述第三方依赖信息进行漏洞检测，得到第二检测结果；

基于所述开源软件信息进行漏洞检测，得到第三检测结果；

结合所述第一检测结果、第二检测结果以及第三检测结果，生成漏洞检测结果。

4.根据权利要求3所述的漏洞检测方法，其特征在于，所述基于所述Linux软件包信息进行漏洞检测，得到第一检测结果，包括：

确定与所述Linux软件包信息相对应的Linux发行版本；

确定与所述待检测漏洞相对应的漏洞补丁，并获取与所述漏洞补丁相对应的Linux修复版本范围；

判断所述Linux修复版本范围中是否包括所述Linux发行版本；

若所述Linux修复版本范围中不包括所述Linux发行版本，则判定所述第一检测结果为Linux软件包存在漏洞；所述Linux软件包与所述Linux软件包信息相对应。

5.根据权利要求4所述的漏洞检测方法，其特征在于，所述确定与所述待检测漏洞相对应的漏洞补丁，并获取与所述漏洞补丁相对应的Linux修复版本范围，包括：

获取OVAL文档，并在所述OVAL文档中确定与所述待检测漏洞相对应的漏洞补丁；

从所述OVAL文档中提取与所述漏洞补丁相对应的Linux修复版范围。

6.根据权利要求3所述的漏洞检测方法，其特征在于，所述基于所述第三方依赖信息进行漏洞检测，得到第二检测结果，包括：

确定关于所述第三方依赖信息相对应的第三方依赖文件；

基于预设的过滤规则和预设的检测白名单，滤除所述第三方依赖文件中的系统文件，得到待解析依赖文件；

对所述待解析依赖文件进行解析，得到信息文件；

从所述信息文件中获取所述待解析文件的第一Maven坐标；

解析所述信息文件中的依赖部分，得到解析结果；

根据所述解析结果确定所述待解析文件所依赖的第三方依赖包的第二Maven坐标；

汇总所述第一Maven坐标和所述第二Maven坐标得到目标Maven坐标；

基于所述目标Maven坐标，判断预设的第三方依赖漏洞数据源是否包括所述待检测漏洞；

若所述第三方依赖漏洞数据源包括所述待检测漏洞，则判定所述第二检测结果为所述待解析文件中存在所述待检测漏洞。

7.根据权利要求3所述的漏洞检测方法，其特征在于，所述基于所述开源软件信息进行漏洞检测，得到第三检测结果，包括：

识别与所述开源软件信息相对应的开源软件；

获取与所述开源软件相对应的进程信息；

基于所述进程信息确定所述开源软件的软件版本；

判断所述漏洞通用枚举平台信息中是否包括所述软件版本；

若所述漏洞通用枚举平台信息中包括所述软件版本，则判定所述第三检测结果为所述开源软件存在所述待检测漏洞。

8.一种漏洞检测装置，其特征在于，所述漏洞检测装置包括：

获取单元，用于获取待检测漏洞；

判断单元，用于判断漏洞检测脚本库中是否存在与所述待检测漏洞相匹配的漏洞检测脚本；

检测单元，用于当所述漏洞检测脚本库中存在所述漏洞检测脚本时，获取所述漏洞检测脚本，并基于所述漏洞检测脚本对所述待检测漏洞进行检测，得到漏洞检测结果；

所述检测单元，还用于当所述漏洞检测脚本库中不存在所述漏洞检测脚本时，通过资产版本匹配的方式进行漏洞检测，得到漏洞检测结果。

9.一种电子设备，其特征在于，所述电子设备包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行权利要求1至7中任一项所述的漏洞检测方法。

10.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行权利要求1至7任一项所述的漏洞检测方法。