一种开源组件的漏洞检测方法及装置与流程

本发明实施例涉及金融科技(fintech)领域，尤其涉及一种开源组件的漏洞检测方法及装置。

背景技术：

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。

开源组件是一类可应用于软件应用程序开发的第三方组件，它具有开放性、多元性和便捷性的特点。开发人员基于开源组件来开发软件应用程序可减少开发时间，提高开发效率，能够更快速地开发出软件应用程序。基于开源组件的特点，开始将开源组件应用于金融科技领域，以便为金融企业的开发人员提供更为便利的服务。

随着开源组件的不断应用，尤其在金融科技领域，为了确保金融服务质量，如何在金融应用程序开发中及时有效地检测所使用的开源组件是否存在漏洞成为急需解决的问题。现有方案在对java项目中使用的开源组件进行漏洞检测时，首先通过扫描构建好的代码目录或直接分析java项目中配置开源组件依赖的文件来获取项目中实际使用的开源组件名称和版本号。再将每个开源组件名称以及对应的版本号与从外界获取的组件漏洞信息进行比对，确定该java项目是否使用了存在漏洞的开源组件，若是，则将存在漏洞的开源组件进行升级。但是，开源组件升级占用时间较长，或由于开源组件的升级导致了对java项目的停用，影响了金融服务质量。

综上，目前亟需一种开源组件的漏洞检测方法，用以提高java项目的研发效率，并可以确保java项目所在系统的稳定性。

技术实现要素：

本发明实施例提供了一种开源组件的漏洞检测方法及装置，用以提高java项目的研发效率，并可以确保java项目所在系统的稳定性。

第一方面，本发明实施例提供了一种开源组件的漏洞检测方法，包括：

获取java项目中各开源组件的开源组件信息；

针对每个开源组件，在确定所述开源组件的开源组件信息位于组件漏洞版本库中时，确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中；所述组件漏洞信息库中存储有各开源组件对应的类或函数的漏洞信息；

若是，则基于所述开源组件的漏洞修复优先度，对所述开源组件进行修复。

上述技术方案中，由于漏洞一般只发生于开源组件的某个功能中，倘若程序代码层面没有调用该开源组件对应的类或函数，则该java项目实际不受影响。因此本发明中的技术方案通过引入程序代码层面的扫描，即，在确定某个开源组件的开源组件信息位于组件漏洞版本库中时，将java项目的程序代码使用该开源组件时所调用的类或函数与组件漏洞信息库中的各类或各函数进行比对，可以及时有效地确定该java项目是否实际受漏洞影响。此外，在确定该java项目实际受漏洞影响后，基于各开源组件的漏洞修复优先度，对各开源组件进行修复，如此，可以及时准确地按照各开源组件的实际受影响程度来推动各开源组件的修复升级，并可以使得各开源组件的修复升级更具有针对性，从而可以提高java项目的研发效率，并可以确保java项目所在系统的稳定性，以便提升金融服务的质量，进而可以解决现有技术中存在无法准确地判断java项目是否实际受漏洞影响的问题。

可选地，所述开源组件信息包括开源组件的父组件信息；所述父组件信息用于指示开源组件为所述java项目的直接引入组件或间接引入组件；

在确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中之前，还包括：

确定所述开源组件为所述java项目的直接引入组件。

上述技术方案中，由于java项目所直接使用的某一个开源组件在运行时需要调用外部的开源组件来完成针对该java项目所直接使用的开源组件的调用执行过程，即，该开源组件需要依赖外部的开源组件来共同完成该java项目所直接使用的开源组件的调用，因此在确定java项目在使用开源组件时所调用的类或函数是否存在于组件漏洞信息库中之前，需要判断开源组件是否为java项目的直接引入组件，以便避免直接单独升级间接引入组件(外部的开源组件)容易出现与java项目不兼容的问题。

可选地，所述开源组件信息还包括开源组件的名称以及版本号；

所述确定所述开源组件的开源组件信息位于组件漏洞版本库中，包括：

将所述开源组件的名称、版本号与所述组件漏洞版本库中每个开源组件的名称、版本号进行比对，若一致，则确定所述开源组件的名称、版本号位于所述组件漏洞版本库中。

上述技术方案中，在开源组件的漏洞信息披露后，针对每个开源组件，即可将该开源组件的名称、版本号与组件漏洞版本库中每个开源组件的名称、版本号进行比对，可以及时准确地确定该版本号的开源组件是否存在漏洞，从而可以及时地确定该版本号的开源组件是否可能受漏洞影响，以便为后续确定使用该版本号的开源组件的java项目是否实际受漏洞影响提供支持。

可选地，所述开源组件信息还包括开源组件的组织标识；

所述方法还包括：

确定所述开源组件为所述java项目的间接引入组件；

若所述开源组件的父组件对应的组织标识为内部标识，则将所述开源组件的漏洞信息以及所述父组件发送给内部负责人；

若所述开源组件的父组件对应的组织标识为外部标识，则将所述开源组件的漏洞信息以及所述父组件发送给外部负责人。

上述技术方案中，在确定开源组件为间接引入组件时，若直接单独升级间接引入组件(外部的开源组件)容易出现与java项目不兼容的问题，而且并不清楚父组件是如何调用间接引入组件的，因此需要通过升级间接引入组件的父组件来推动间接引入组件的升级，从而可以避免出现升级后的间接引入组件与java项目不兼容的情况，进而可以解决现有技术中存在简单根据版本号推动更新开源组件，可能会产生新版本的开源组件与java项目不兼容的问题。此外，针对父组件的升级也存在两种方式，即针对该父组件是属于内部开发的还是外部开发的，如此基于两种不同的升级方式可以使得父组件的升级具有针对性，并可以有助于提高研发效率和保证系统稳定性。

可选地，通过下述方式确定所述组件漏洞信息库：

从组件漏洞公开平台获取各开源组件对应的类或函数的漏洞信息；

将各开源组件对应的类或函数漏洞信息存储至所述组件漏洞信息库中；

所述确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中，包括：

从所述java项目的源代码中提取出使用所述开源组件时所调用的第一类或第一函数；

针对所述组件漏洞信息库中第二类或第二函数，确定所述第一类与所述第二类的匹配度，或所述第一函数与所述第二函数的匹配度；

基于所述匹配度与匹配阈值的大小关系，确定使用所述开源组件时所调用的第一类或第一函数是否存在于所述组件漏洞信息库中。

上述技术方案中，针对组件漏洞信息库中第二类或第二函数，将第一类与第二类进行比对，或者将第一函数与第二函数进行比对，并基于匹配度与匹配阈值的大小关系，即可及时准确地确定第一类或第一函数是否存在于组件漏洞信息库中，以便为及时地确定java项目是否实际受漏洞影响提供支持。

可选地，通过下述方式确定所述开源组件的漏洞修复优先度：

根据所述java项目是否受漏洞影响，确定出第一漏洞影响值；

根据所述java项目是否属于对外项目，确定出第二漏洞影响值；

根据使用所述开源组件时所调用的类或函数对应的漏洞是否有漏洞验证程序或漏洞利用程序，以及在确定有漏洞验证程序或漏洞利用程序时，确定是否可远程利用所述类或所述函数对应的漏洞进行攻击，确定出第三漏洞影响值；

根据所述类或所述函数对应的漏洞的危害程度，确定出第四漏洞影响值；

根据所述第一漏洞影响值、所述第二漏洞影响值、所述第三漏洞影响值以及所述第四漏洞影响值，确定出所述开源组件的漏洞修复优先度。

上述技术方案中，在判断java项目实际受漏洞影响后，通过对漏洞添加多个维度的评价，即通过第一漏洞影响值、第二漏洞影响值、第三漏洞影响值以及第四漏洞影响值来确定开源组件的漏洞修复优先度，有助于实现按照java项目的实际受影响程度来推动存在漏洞的开源组件的升级工作。

可选地，所述漏洞修复优先度对应的等级包括第一等级、第二等级以及第三等级；

所述基于所述开源组件的漏洞修复优先度，对所述开源组件进行修复，包括：

若确定所述开源组件的漏洞优先级度对应的等级为所述第一等级，则对所述开源组件进行优先修复；

若确定所述开源组件的漏洞优先级度对应的等级为所述第二等级，则对所述开源组件进行排期修复；

若确定所述开源组件的漏洞优先级度对应的等级为所述第三等级，则对所述开源组件保持观察。

上述技术方案中，通过基于各开源组件的漏洞修复优先度，确定出各开源组件对应的升级修复等级，并基于各开源组件对应的升级修复等级对各开源组件进行对应的升级修复，从而使得各开源组件的升级修复更具有针对性，并可以有助于提高研发效率和保证系统稳定性，进而可以解决现有技术中存在当java项目中的开源组件版本号受影响时即推动更新，会产生大量不必要的开源组件在升级时的工作量，降低研发效率的问题。

第二方面，本发明实施例还提供了一种开源组件的漏洞检测装置，包括：

获取单元，用于获取java项目中各开源组件的开源组件信息；

处理单元，用于针对每个开源组件，在确定所述开源组件的开源组件信息位于组件漏洞版本库中时，确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中；所述组件漏洞信息库中存储有各开源组件对应的类或函数的漏洞信息；若是，则基于所述开源组件的漏洞修复优先度，对所述开源组件进行修复。

可选地，所述开源组件信息包括开源组件的父组件信息；所述父组件信息用于指示开源组件为所述java项目的直接引入组件或间接引入组件；

所述处理单元还用于：

在确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中之前，确定所述开源组件为所述java项目的直接引入组件。

可选地，所述开源组件信息还包括开源组件的名称以及版本号；

所述处理单元具体用于：

将所述开源组件的名称、版本号与所述组件漏洞版本库中每个开源组件的名称、版本号进行比对，若一致，则确定所述开源组件的名称、版本号位于所述组件漏洞版本库中。

可选地，所述开源组件信息还包括开源组件的组织标识；

所述处理单元还用于：

确定所述开源组件为所述java项目的间接引入组件；

若所述开源组件的父组件对应的组织标识为内部标识，则将所述开源组件的漏洞信息以及所述父组件发送给内部负责人；

若所述开源组件的父组件对应的组织标识为外部标识，则将所述开源组件的漏洞信息以及所述父组件发送给外部负责人。

可选地，所述处理单元具体用于：

从组件漏洞公开平台获取各开源组件对应的类或函数的漏洞信息；

将各开源组件对应的类或函数漏洞信息存储至所述组件漏洞信息库中；

所述处理单元具体用于：

从所述java项目的源代码中提取出使用所述开源组件时所调用的第一类或第一函数；

针对所述组件漏洞信息库中第二类或第二函数，确定所述第一类与所述第二类的匹配度，或所述第一函数与所述第二函数的匹配度；

基于所述匹配度与匹配阈值的大小关系，确定使用所述开源组件时所调用的第一类或第一函数是否存在于所述组件漏洞信息库中。

可选地，所述处理单元具体用于：

根据所述java项目是否受漏洞影响，确定出第一漏洞影响值；

根据所述java项目是否属于对外项目，确定出第二漏洞影响值；

根据使用所述开源组件时所调用的类或函数对应的漏洞是否有漏洞验证程序或漏洞利用程序，以及在确定有漏洞验证程序或漏洞利用程序时，确定是否可远程利用所述类或所述函数对应的漏洞进行攻击，确定出第三漏洞影响值；

根据所述类或所述函数对应的漏洞的危害程度，确定出第四漏洞影响值；

根据所述第一漏洞影响值、所述第二漏洞影响值、所述第三漏洞影响值以及所述第四漏洞影响值，确定出所述开源组件的漏洞修复优先度。

可选地，所述漏洞修复优先度对应的等级包括第一等级、第二等级以及第三等级；

所述处理单元具体用于：

若确定所述开源组件的漏洞优先级度对应的等级为所述第一等级，则对所述开源组件进行优先修复；

若确定所述开源组件的漏洞优先级度对应的等级为所述第二等级，则对所述开源组件进行排期修复；

若确定所述开源组件的漏洞优先级度对应的等级为所述第三等级，则对所述开源组件保持观察。

第三方面，本发明实施例提供一种计算设备，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行上述第一方面任意所述的开源组件的漏洞检测方法。

第四方面，本发明实施例提供一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述第一方面任意所述的开源组件的漏洞检测方法。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种系统架构的示意图；

图2为本发明实施例提供的一种开源组件的漏洞检测方法的流程示意图；

图3为本发明实施例提供的另一种开源组件的漏洞检测方法的流程示意图；

图4为本发明实施例提供的一种开源组件的漏洞检测装置的结构示意图；

图5为本发明实施例提供的一种计算设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

下面首先对本发明实施例中涉及的部分用语进行解释说明，以便于本领域技术人员进行理解。

(1)maven：一个开源软件项目管理及自动构建工具。是可通过一小段描述信息来管理项目的构建，报告和文档的项目管理工具软件。

(2)gradle：一个基于jvm的构建工具，是一款通用灵活的开源项目自动化构建工具，支持maven、ivy仓库，支持传递性依赖管理，而不需要远程仓库或者是pom.xml和ivy.xml配置文件，基于groovy，build脚本使用groovy编写。

(3)maven仓库：用来存放生成的构建和各种依赖，供构建过程中使用。

(4)dos攻击(denialofserviceattack，拒绝服务)：是指恶意的攻击网络协议实现的缺陷或直接通过野蛮手段残忍地耗尽被攻击对象的资源，目的是让目标计算机或网络无法提供正常的服务或资源访问，使目标系统服务系统停止响应甚至崩溃，而在此攻击中并不包括侵入目标服务器或目标网络设备。

(5)ddos攻击(distributeddenialofserviceattack，分布式拒绝服务攻击)：是指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动ddos攻击，从而成倍地提高拒绝服务攻击的威力。通常，攻击者使用一个偷窃帐号将ddos主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。比如，利用大量合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。

如上介绍了本发明实施例中涉及的部分用语，下面对本发明实施例涉及的技术特征进行介绍。

图1为本发明实施例提供的一种系统架构。如图1所示，该系统架构可以为服务器100，包括处理器110、通信接口120和存储器130。

其中，通信接口120用于与终端设备进行通信，收发该终端设备传输的信息，实现通信。

处理器110是服务器100的控制中心，利用各种接口和线路连接整个服务器100的各个部分，通过运行或执行存储在存储器130内的软件程序/或模块，以及调用存储在存储器130内的数据，执行服务器100的各种功能和处理数据。可选地，处理器110可以包括一个或多个处理单元。

存储器130可用于存储软件程序以及模块，处理器110通过运行存储在存储器130的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器130可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据业务处理所创建的数据等。此外，存储器130可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。

基于上述描述，图2示例性的示出了本发明实施例提供的一种开源组件的漏洞检测方法的流程，该流程可以由开源组件的漏洞检测装置执行。

如图2所示，该流程具体包括：

步骤201，获取java项目中各开源组件的开源组件信息。

步骤202，针对每个开源组件，在确定所述开源组件的开源组件信息位于组件漏洞版本库中时，确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中。

步骤203，若确定所述java项目在使用所述开源组件时所调用的类或函数存在于组件漏洞信息库中，则基于所述开源组件的漏洞修复优先度，对所述开源组件进行修复。

上述步骤201中，开源组件信息可以包括开源组件的名称、版本号、组织标识、项目标识以及父组件信息等。其中，开源组件可以包括fastjson、jackson-databind、xstream等；父组件信息用于指示开源组件为java项目的直接引入组件或间接引入组件。示例性地，针对开源组件的父组件信息，比如java项目存在有开源组件1和开源组件2，但该开源组件1需要调用外部的开源组件3，而该开源组件2不需要调用外部的开源组件，因此开源组件1为开源组件3的父组件，则开源组件1和开源组件2为java项目的直接引入组件，开源组件3为java项目的间接引入组件。

具体地，通过使用持续化集成工具(比如jenkins、buddy、teamcity、cruisecontrol等)对接gitlab等代码仓库来实现针对带有开源组件的项目目录的自动化构建，并通过扫描构建好的项目目录收集java项目所使用的开源组件的名称和版本号。再通过项目构建工具生成每个项目的依赖树，并基于依赖树提取出每个开源组件的名称、groupid、artifactid、版本号、父组件信息。然后，将通过扫描项目目录所获取的各开源组件的名称和版本号以及基于依赖树所提取出的每个开源组件的名称、groupid、artifactid、版本号、父组件信息进行整合处理，即可得到整合后的各开源组件的开源组件信息，并将整合后的各开源组件的开源组件信息存储到数据库中，以便为后续确定java项目是否受实际漏洞影响提供数据支持。

上述步骤202中，针对java项目中每个开源组件，在确定开源组件的开源组件信息位于组件漏洞版本库中时，确定java项目在使用开源组件时所调用的类或函数是否存在于组件漏洞信息库中。其中，组件漏洞信息库中存储有各开源组件对应的类或函数的漏洞信息，具体地，从组件漏洞公开平台获取各开源组件对应的类或函数的漏洞信息，将各开源组件对应的类或函数漏洞信息存储至组件漏洞信息库中。

具体地，在开源组件的漏洞信息披露后，针对java项目中各开源组件中每个开源组件，将开源组件的名称、版本号与组件漏洞版本库中每个开源组件的名称、版本号进行比对，若一致，则确定开源组件的名称、版本号位于组件漏洞版本库中。如此，可以及时准确地确定该版本号的开源组件是否存在漏洞，从而可以及时地确定该版本号的开源组件是否可能受漏洞影响，以便为后续确定使用该版本号的开源组件的java项目是否实际受漏洞影响提供支持。

由于java项目所直接使用的某一个开源组件在运行时需要调用外部的开源组件来完成针对该java项目所直接使用的开源组件的调用执行过程，即，该开源组件需要依赖外部的开源组件来共同完成该java项目所直接使用的开源组件的调用，因此在确定开源组件位于组件漏洞版本库中后，需要判断开源组件是否为java项目的直接引入组件，以便避免直接单独升级间接引入组件(外部的开源组件)容易出现与java项目不兼容的问题。然后，在确定该开源组件为java项目的间接引入组件后，从java项目的源代码中提取出使用开源组件时所调用的第一类或第一函数。针对组件漏洞信息库中第二类或第二函数，确定第一类与第二类的匹配度，或第一函数与第二函数的匹配度，并基于匹配度与匹配阈值的大小关系，即可及时准确地确定使用开源组件时所调用的第一类或第一函数是否存在于组件漏洞信息库中，以便为及时地确定java项目是否实际受漏洞影响提供支持。其中，匹配阈值可以根据本领域技术人员的经验或者可以根据实际应用场景进行设置，本发明实施例对此并不作限定。

需要说明的是，在确定开源组件为java项目的间接引入组件时，可以采用下述方式对该间接引入组件进行升级修复：若开源组件(间接引入组件)的父组件对应的组织标识为内部标识，则将开源组件的漏洞信息以及父组件发送给内部负责人，以使内部负责人对父组件进行升级修复。若开源组件的父组件对应的组织标识为外部标识，则将开源组件的漏洞信息以及父组件发送给外部负责人，以使外部负责人对父组件进行升级修复。如此，在确定开源组件为间接引入组件时，若直接单独升级间接引入组件(外部的开源组件)容易出现与java项目不兼容的问题，而且并不清楚父组件是如何调用间接引入组件的，因此需要通过升级间接引入组件的父组件来推动间接引入组件的升级，从而可以避免出现升级后的间接引入组件与java项目不兼容的情况，进而可以解决现有技术中存在简单根据版本号推动更新开源组件，可能会产生新版本的开源组件与java项目不兼容的问题。此外，针对父组件的升级也存在两种方式，即针对该父组件是属于内部开发的还是外部开发的，如此基于两种不同的升级方式可以使得父组件的升级具有针对性，并可以有助于提高研发效率和保证系统稳定性。

上述步骤203中，在确定java项目在使用开源组件时所调用的类或函数存在于组件漏洞信息库中时，基于开源组件的漏洞修复优先度，对开源组件进行修复。

具体地，可以通过下述方式确定每个开源组件的漏洞修复优先度：根据java项目是否受漏洞影响，确定出第一漏洞影响值；根据java项目是否属于对外项目，确定出第二漏洞影响值；根据使用开源组件时所调用的类或函数对应的漏洞是否有漏洞验证程序或漏洞利用程序，以及在确定有漏洞验证程序或漏洞利用程序时，确定是否可远程利用类或函数对应的漏洞进行攻击，确定出第三漏洞影响值；根据类或函数对应的漏洞的危害程度，确定出第四漏洞影响值；根据第一漏洞影响值、第二漏洞影响值、第三漏洞影响值以及第四漏洞影响值，确定出开源组件的漏洞修复优先度。如此，判断java项目实际受漏洞影响后，通过对漏洞添加多个维度的评价，即通过第一漏洞影响值、第二漏洞影响值、第三漏洞影响值以及第四漏洞影响值来确定开源组件的漏洞修复优先度，有助于实现按照java项目的实际受影响程度来推动存在漏洞的开源组件的升级工作。

在确定出各开源组件的漏洞修复优先度后，为各开源组件设置对应的升级修复等级。具体地，若确定开源组件的漏洞优先级度对应的等级为第一等级，则对开源组件进行优先修复；若确定开源组件的漏洞优先级度对应的等级为第二等级，则对开源组件进行排期修复；若确定开源组件的漏洞优先级度对应的等级为第三等级，则对开源组件保持观察。示例性地，比如某个开源组件的漏洞修复优先度为7.5分，则需要对该开源组件进行优先修复；如果开源组件的漏洞修复优先度为6.5分，则需要对该开源组件进行排期修复；如果开源组件的漏洞修复优先度为3.5分，则可先对该开源组件保持观察。如此，通过基于各开源组件的漏洞修复优先度，确定出各开源组件对应的升级修复等级，并基于各开源组件对应的升级修复等级对各开源组件进行对应的升级修复，从而使得各开源组件的升级修复更具有针对性，并可以有助于提高研发效率和保证系统稳定性，进而可以解决现有技术中存在当java项目中的开源组件版本号受影响时即推动更新，会产生大量不必要的开源组件在升级时的工作量，降低研发效率的问题。

基于此，下面结合图3，对本发明实施例中开源组件的漏洞检测方法的实施过程进行具体描述。其中，图3为本发明实施例提供的另一种开源组件的漏洞检测方法的流程示意图。

step1：收集java项目中各开源组件的开源组件信息。

具体地，首先通过基于代码仓库构建出带有开源组件的项目目录。即，将java项目的源代码所依赖的开源组件信息放入到项目目录里，即可构建出带有开源组件的项目目录。其中，该项目目录里本身就存储有源代码。需要说明的是，为了节省存储空间，项目目录预先不存储开源组件信息。再通过扫描构建好的项目目录收集java项目所使用的各开源组件的名称和版本号。

然后，通过项目构建工具生成java项目的依赖树，并基于该依赖树提取出每个开源组件的名称、组织标识(groupid)、项目标识(artifactid)、版本号、父组件信息。针对java项目的任一开源组件，如果该开源组件有父组件，则说明该开源组件是java项目的间接引入组件；如果该开源组件没有父组件，则说明该开源组件是java项目的直接引入组件。需要说明的是，针对确定某个开源组件有父组件，则可以通过基于该开源组件进一步遍历依赖树，以便追溯出java项目所直接引入的开源组件。示例性地，针对开源组件的父组件信息，比如java项目存在有开源组件a和开源组件b，但该开源组件a需要调用外部的开源组件c，而开源组件b不需要调用外部的开源组件，因此开源组件a为开源组件c的父组件，则开源组件a和开源组件b为java项目的直接引入组件，开源组件c为java项目的间接引入组件。

最后，将通过扫描构建好的项目目录所获取的各开源组件的名称和版本号以及通过项目构建工具生成java项目的依赖树所提取出的每个开源组件的名称、组织标识、项目标识、版本号、父组件信息进行整合处理，即可得到整合后的开源组件信息，并将该整合后的开源组件信息存储到数据库中。其中，针对该数据库，开发人员、运维人员或其它数据库管理人员等可在日常工作中进行维护。如此，若有新的开源组件漏洞信息出现，则可直接在该数据库中进行查询，以便确定java项目所使用的各开源组件中是否有存在漏洞的开源组件，从而可以有效地提高开源组件漏洞响应和排查的效率。

示例性地，本发明实施例可以使用持续化集成工具对接gitlab等代码仓库即可实现针对带有开源组件的项目目录的自动化构建，并通过扫描构建好的项目目录收集java项目所使用的开源组件的名称和版本号。再通过maven、gradle等工具生成每个项目的依赖树，并基于依赖树提取出每个开源组件的名称、groupid、artifactid、版本号、父组件信息。然后，将通过扫描项目目录所获取的各开源组件的名称和版本号以及基于依赖树所提取出的每个开源组件的名称、groupid、artifactid、版本号、父组件信息进行整合处理，即可得到整合后的各开源组件的开源组件信息，并将整合后的各开源组件的开源组件信息存储到数据库中。

需要说明的是，由于源代码检查一般针对的是java项目直接引入的开源组件，所以可以不通过构建带有开源组件的项目目录以及不通过项目构建工具生成java项目的依赖树，直接通过扫描和解析代码目录(即不存储有开源组件的项目目录)中的pom.xml、build.gradle等配置文件，来获取java项目所使用的各开源组件的开源组件信息，即，收集各开源组件的名称、groupid、artifactid、版本号等信息，并将收集的各开源组件的开源组件信息存储到数据库中。

step2：扫描java项目的源代码，检查该java项目是否实际使用了存在漏洞的类或函数。

具体地，在获取到披露的开源组件漏洞信息后，将step1中数据库存储的各开源组件的名称以及版本号与该披露的开源组件漏洞信息中各开源组件的名称以及版本号进行比对。即，针对数据库存储的各开源组件中每个开源组件，将该开源组件的名称以及版本号与开源组件漏洞信息中各开源组件的名称以及版本号进行匹配，确定出多个匹配度，若该多个匹配度中的最大匹配度大于等于第一匹配阈值，则确定该版本号的开源组件受漏洞影响，否则确定该版本号的开源组件不受漏洞影响。在确定该版本号的开源组件受漏洞影响后，从国内外漏洞披露平台获取公布的漏洞数据，即获取各开源组件的版本号对应的类或函数的漏洞信息，并将该获取的各开源组件的版本号对应的类或函数的漏洞信息存储到组件漏洞信息库中。然后，扫描java项目的源代码，可获取到java项目使用该版本号的开源组件时所调用的类或函数，并将java项目使用该版本号的开源组件时所调用的类与组件漏洞信息库中各开源组件的版本号对应的类进行匹配，确定出多个匹配度，若该多个匹配度中的最大匹配度大于等于第二匹配阈值，则说明该版本号的开源组件调用了存在漏洞的类，即可说明java项目实际使用了存在漏洞的类，从而可以说明java项目实际受漏洞影响。或者，将java项目使用该版本号的开源组件时所调用的函数与组件漏洞信息库中各开源组件的版本号对应的函数进行匹配，确定出多个匹配度，若该多个匹配度中的最大匹配度大于等于第二匹配阈值，则说明该版本号的开源组件调用了存在漏洞的函数，即可说明java项目实际使用了存在漏洞的函数，从而可以说明java项目实际受漏洞影响。其中，第一匹配阈值和第二匹配阈值可以根据本领域技术人员的经验或者可以根据实际应用场景进行设置，本发明实施例对此并不作限定。

下面对检查该java项目是否实际使用了存在漏洞的类或函数的具体实施过程进行描述。

步骤a、在针对开源组件的漏洞信息披露后，获取该披露的开源组件漏洞信息，并将该披露的开源组件漏洞信息存储到组件漏洞版本库中。然后，针对step1中数据库存储的任一开源组件，将该开源组件的名称以及版本号与组件漏洞版本库中各开源组件的名称以及版本号进行比对，即可确定该版本号的开源组件是否受漏洞影响。若确定该版本号的开源组件受漏洞影响，则可执行步骤b。

步骤b、在确定某一版本号的开源组件受漏洞影响后，基于该版本号的开源组件的父组件信息，确定该版本号的开源组件是否为直接引入组件。若该版本号的开源组件为直接引入组件，则可执行步骤c；若该版本号的开源组件不为直接引入组件，即，该版本号的开源组件为间接引入组件，则可执行步骤step4。

步骤c、在确定该版本号的开源组件为直接引入组件后，收集各开源组件的版本号对应的类或函数的漏洞信息，并将各开源组件的版本号对应的类或函数的漏洞信息存储至组件漏洞信息库中。即，可从国内外漏洞披露平台获取公布的漏洞数据，即获取漏洞开源组件名称、漏洞开源组件版本号、漏洞类或函数信息、漏洞详细内容等漏洞数据。比如从cve(commonvulnerabilitiesandexposures，公共漏洞和暴露)、cnnvd(chinanationalvulnerabilitydatabaseofinformationsecurity，中国国家信息安全漏洞库)、cnvd(chinanationalvulnerabilitydatabase，中国国家信息安全漏洞共享平台)等漏洞披露平台获取公布的漏洞数据。

步骤d、扫描并检查java项目的源代码，确定java项目的源代码是否使用了存在漏洞的类或函数。

具体地，在扫描java项目的源代码的过程中，针对组件漏洞信息库中每个类或函数，将该类与java项目的源代码中所使用的各类进行匹配，确定出多个匹配度，若该多个匹配度中的最大匹配度大于等于第一匹配阈值，则确定java项目的源代码使用了存在漏洞的类，即可说明java项目实际受漏洞影响。或者，将该函数与java项目的源代码中所使用的各函数进行匹配，确定出多个匹配度，若该多个匹配度中的最大匹配度大于等于第二匹配阈值，则确定java项目的源代码使用了存在漏洞的函数，即可说明java项目实际受漏洞影响。

需要说明的是，在具体实施过程中，确定java项目的源代码是否使用了存在漏洞的类或函数的处理过程是自动化进行的，在扫描java项目的源代码的过程中传入对应的类名或函数名作为关键字匹配即可实现。

step3：确定存在漏洞的开源组件的漏洞修复优先度。

本发明实施例在引入代码片段扫描检查后，即可判断java项目是否实际受漏洞影响。如此，通过代码层检查并确认java项目使用了开源组件中存在漏洞的类或函数后，即可判断java项目实际受漏洞影响。而且，在判断java项目实际受漏洞影响后，可通过对漏洞添加多个实用维度的评价，即可实现按照java项目的实际受影响程度来推动存在漏洞的开源组件的升级工作。

具体地，可以通过下述方式确定每个开源组件的漏洞修复优先度：根据java项目是否受漏洞影响，确定出第一漏洞影响值；根据java项目是否属于对外项目，确定出第二漏洞影响值；根据使用开源组件时所调用的类或函数对应的漏洞是否有漏洞验证程序或漏洞利用程序，以及在确定有漏洞验证程序或漏洞利用程序时，确定是否可远程利用类或函数对应的漏洞进行攻击，确定出第三漏洞影响值；根据类或函数对应的漏洞的危害程度，确定出第四漏洞影响值；根据第一漏洞影响值、第二漏洞影响值、第三漏洞影响值以及第四漏洞影响值，确定出开源组件的漏洞修复优先度。

示例性地，假设漏洞总评分为10分，则评价漏洞的影响程度的维度可以分为：

(1)、判断java项目是否实际受漏洞影响，占比55％。如果java项目实际受漏洞影响，则记录5.5分，否则记录0分。

(2)、判断java项目是否属于对外项目，占比15％。如果java项目属于对外项目，则记录1.5分，否则记录0分。

(3)、判断java项目使用的开源组件所存在的漏洞是否有公开的poc(proofofconcept，漏洞验证程序)或exp(exploit，漏洞利用程序)，占比15％。具体地，判断java项目使用的某一版本号的开源组件所存在的漏洞是否有公开的poc或exp，可以到开源的代码托管平台(比如github.com)或专业的公开exp收录网站(比如www.exploit-db.com)进行搜索。如果开源组件所存在的漏洞有公开的poc或exp，且确定攻击者可远程利用漏洞攻击java项目所在服务器，则记录1.5分。如果开源组件所存在的漏洞有公开的poc或exp，且确定攻击者不能远程利用漏洞攻击java项目所在服务器，则记录1分，比如，可以通过利用java项目所在本地服务器的账号密码进行远程登录该本地服务器，并利用漏洞直接在本地进行攻击该本地服务器，或者，可以通过利用java项目所在本地服务器的账号密码进行本地登录该本地服务器，并利用漏洞直接在本地进行攻击该本地服务器。

(4)、根据漏洞自身的危害程度，即可对漏洞所造成的影响进行分类和评估，占比15％。其中，漏洞所造成的影响可分为：

a)、如果漏洞造成部署该java项目的服务器中的命令执行、权限提升(比如修改管理使用权限，将低权限修改为高权限等)或者用户敏感数据泄露，则记录1.5分。

b)、如果漏洞造成服务不可用，则记录1分，即，使得计算机或网络无法提供正常的服务，比如dos攻击漏洞和ddos攻击漏洞。

c)、其它对系统可用性无严重影响的漏洞，则记录0.5分。

综合上述各维度，将存在漏洞的开源组件在各维度的分数进行相加，并将相加后的结果记为x，如此即可确定出存在漏洞的开源组件的修复优先度：

a、若x≥7，则需要优先对该存在漏洞的开源组件进行紧急升级修复。

b、若5.5<x<7，则需要对该存在漏洞的开源组件进行排期修复。

c、若0≤x≤5.5，则可先对该存在漏洞的开源组件保持关注并等待更多细节披露。

step4：推动存在漏洞的开源组件进行升级。

下面通过两种实现方式对推动存在漏洞的开源组件进行升级的实施过程进行具体描述。

第一种实现方式：若开源组件为直接引入组件，且通过代码片段扫描检查确认java项目实际受漏洞影响后，即可开始着手推动研发侧对存在漏洞的开源组件进行升级。具体地，可以根据开源组件的漏洞修复优先度，对开源组件进行升级修复。如果开源组件的漏洞修复优先度较高，则开源组件升级修复的期限等要求应提高；如果开源组件的漏洞修复优先度相对较低，则可结合版本排期安全升级修复。示例性地，比如某个开源组件的漏洞修复优先度为8分，则需要优先对该开源组件进行紧急升级修复；如果开源组件的漏洞修复优先度为6分，则需要对该开源组件进行排期修复；如果开源组件的漏洞修复优先度为5分，则可先对该开源组件保持关注并等待更多细节披露。

第二种实现方式：若开源组件为间接引入组件，则确定该开源组件的父组件的组织标识groupid是否为内部标识。具体地，如果该开源组件的父组件的组织标识为内部标识，则可通知内部的相关团队或相关负责人进行升级修复，即，将开源组件的漏洞信息以及父组件发送给内部的相关团队或相关负责人，比如可通过给对应的代码仓库提交问题或者内部流程工具自动化通知升级。在等sdk修复后更新sdk的版本即可。如果该开源组件的父组件的组织标识为外部标识，一般情况下需等待引入的父组件升级，或者可以向父组件所对应的外部的相关负责人或外部的相关团队发送升级修复通知消息，同时会将开源组件的漏洞信息以及父组件发送给外部的相关负责人或外部的相关团队。比如可以到开源社区提出问题或者提交代码审查的请求pr(pullrequest，开源项目中作出贡献修改代码后，发出的合并代码的请求)来推动升级。需要说明的是，针对开源组件为间接引入组件的情况，若是在内部项目中直接单独升级间接引入组件容易出现兼容性问题，所以需要通过升级间接引入组件的父组件来推动间接引入组件的升级，以避免出现升级后的间接引入组件与java项目不兼容的情况。其中，该间接引入组件的父组件是java项目直接引入的组件。

基于此，通过上述两种实现方式可以使得实际推动开源组件漏洞升级修复时更具有针对性，并可以有助于提高研发效率和保证系统稳定性。

上述实施例表明，由于漏洞一般只发生于开源组件的某个功能中，倘若程序代码层面没有调用该开源组件对应的类或函数，则该java项目实际不受影响。因此本发明中的技术方案通过引入程序代码层面的扫描，即，在确定某个开源组件的开源组件信息位于组件漏洞版本库中时，将java项目的程序代码使用该开源组件时所调用的类或函数与组件漏洞信息库中的各类或各函数进行比对，可以及时有效地确定该java项目是否实际受漏洞影响。此外，在确定该java项目实际受漏洞影响后，基于各开源组件的漏洞修复优先度，对各开源组件进行修复，如此，可以及时准确地按照各开源组件的实际受影响程度来推动各开源组件的修复升级，并可以使得各开源组件的修复升级更具有针对性，从而可以提高java项目的研发效率，并可以确保java项目所在系统的稳定性，以便提升金融服务的质量，进而可以解决现有技术中存在无法准确地判断java项目是否实际受漏洞影响的问题。

基于相同的技术构思，图4示例性的示出了本发明实施例提供的一种开源组件的漏洞检测装置，该装置可以执行开源组件的漏洞检测方法的流程。

如图4所示，该装置包括：

获取单元401，用于获取java项目中各开源组件的开源组件信息；

处理单元402，用于针对每个开源组件，在确定所述开源组件的开源组件信息位于组件漏洞版本库中时，确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中；所述组件漏洞信息库中存储有各开源组件对应的类或函数的漏洞信息；若是，则基于所述开源组件的漏洞修复优先度，对所述开源组件进行修复。

可选地，所述开源组件信息包括开源组件的父组件信息；所述父组件信息用于指示开源组件为所述java项目的直接引入组件或间接引入组件；

所述处理单元402还用于：

在确定所述java项目在使用所述开源组件时所调用的类或函数是否存在于组件漏洞信息库中之前，确定所述开源组件为所述java项目的直接引入组件。

可选地，所述开源组件信息还包括开源组件的名称以及版本号；

所述处理单元402具体用于：

将所述开源组件的名称、版本号与所述组件漏洞版本库中每个开源组件的名称、版本号进行比对，若一致，则确定所述开源组件的名称、版本号位于所述组件漏洞版本库中。

可选地，所述开源组件信息还包括开源组件的组织标识；

所述处理单元402还用于：

确定所述开源组件为所述java项目的间接引入组件；

若所述开源组件的父组件对应的组织标识为内部标识，则将所述开源组件的漏洞信息以及所述父组件发送给内部负责人；

若所述开源组件的父组件对应的组织标识为外部标识，则将所述开源组件的漏洞信息以及所述父组件发送给外部负责人。

可选地，所述处理单元402具体用于：

从组件漏洞公开平台获取各开源组件对应的类或函数的漏洞信息；

将各开源组件对应的类或函数漏洞信息存储至所述组件漏洞信息库中；

所述处理单元402具体用于：

从所述java项目的源代码中提取出使用所述开源组件时所调用的第一类或第一函数；

针对所述组件漏洞信息库中第二类或第二函数，确定所述第一类与所述第二类的匹配度，或所述第一函数与所述第二函数的匹配度；

基于所述匹配度与匹配阈值的大小关系，确定使用所述开源组件时所调用的第一类或第一函数是否存在于所述组件漏洞信息库中。

可选地，所述处理单元402具体用于：

根据所述java项目是否受漏洞影响，确定出第一漏洞影响值；

根据所述java项目是否属于对外项目，确定出第二漏洞影响值；

根据使用所述开源组件时所调用的类或函数对应的漏洞是否有漏洞验证程序或漏洞利用程序，以及在确定有漏洞验证程序或漏洞利用程序时，确定是否可远程利用所述类或所述函数对应的漏洞进行攻击，确定出第三漏洞影响值；

根据所述类或所述函数对应的漏洞的危害程度，确定出第四漏洞影响值；

根据所述第一漏洞影响值、所述第二漏洞影响值、所述第三漏洞影响值以及所述第四漏洞影响值，确定出所述开源组件的漏洞修复优先度。

可选地，所述漏洞修复优先度对应的等级包括第一等级、第二等级以及第三等级；

所述处理单元402具体用于：

若确定所述开源组件的漏洞优先级度对应的等级为所述第一等级，则对所述开源组件进行优先修复；

若确定所述开源组件的漏洞优先级度对应的等级为所述第二等级，则对所述开源组件进行排期修复；

若确定所述开源组件的漏洞优先级度对应的等级为所述第三等级，则对所述开源组件保持观察。

基于相同的技术构思，本发明实施例还提供了一种计算设备，如图5所示，包括至少一个处理器501，以及与至少一个处理器连接的存储器502，本发明实施例中不限定处理器501与存储器502之间的具体连接介质，图5中处理器501和存储器502之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。

在本发明实施例中，存储器502存储有可被至少一个处理器501执行的指令，至少一个处理器501通过执行存储器502存储的指令，可以执行前述的开源组件的漏洞检测方法中所包括的步骤。

其中，处理器501是计算设备的控制中心，可以利用各种接口和线路连接计算设备的各个部分，通过运行或执行存储在存储器502内的指令以及调用存储在存储器502内的数据，从而实现数据处理。可选的，处理器501可包括一个或多个处理单元，处理器501可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理下发指令。可以理解的是，上述调制解调处理器也可以不集成到处理器501中。在一些实施例中，处理器501和存储器502可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器501可以是通用处理器，例如中央处理器(cpu)、数字信号处理器、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合开源组件的漏洞检测方法实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器502作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器502可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(randomaccessmemory，ram)、静态随机访问存储器(staticrandomaccessmemory，sram)、可编程只读存储器(programmablereadonlymemory，prom)、只读存储器(readonlymemory，rom)、带电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、磁性存储器、磁盘、光盘等等。存储器502是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器502还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

基于相同的技术构思，本发明实施例还提供了一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述开源组件的漏洞检测方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。