WO2021217421A1 - Java开源组件的漏洞检测方法、装置及存储介质 - Google Patents

Java开源组件的漏洞检测方法、装置及存储介质 Download PDF

Info

Publication number
WO2021217421A1
WO2021217421A1 PCT/CN2020/087511 CN2020087511W WO2021217421A1 WO 2021217421 A1 WO2021217421 A1 WO 2021217421A1 CN 2020087511 W CN2020087511 W CN 2020087511W WO 2021217421 A1 WO2021217421 A1 WO 2021217421A1
Authority
WO
WIPO (PCT)
Prior art keywords
open source
java open
information
vulnerability
cpe
Prior art date
Application number
PCT/CN2020/087511
Other languages
English (en)
French (fr)
Inventor
汪杰
万振华
王颉
董燕
李华
吴钟良
洪二稳
Original Assignee
深圳开源互联网安全技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳开源互联网安全技术有限公司 filed Critical 深圳开源互联网安全技术有限公司
Priority to PCT/CN2020/087511 priority Critical patent/WO2021217421A1/zh
Priority to CN202080004869.7A priority patent/CN112868008B/zh
Publication of WO2021217421A1 publication Critical patent/WO2021217421A1/zh

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577Assessing vulnerabilities and evaluating computer system security

Definitions

  • the present invention relates to the technical field of software detection, in particular to a method, device, electronic equipment and storage medium for vulnerability detection of JAVA open source components.
  • Java is an object-oriented programming language. It not only absorbs the various advantages of C++ language, but also abandons concepts such as multiple inheritance and pointers that are difficult to understand in C++.
  • Java language as a representative of static object-oriented programming language, is implemented extremely well. The object-oriented theory allows programmers to perform complex programming in an elegant way of thinking. In recent years, the Java language has been widely used to write desktop applications due to its powerful, easy-to-use, object-oriented, distributed, robust, security, platform independence and portability, multi-threading, and dynamic characteristics. , Web applications, distributed systems and embedded system applications, etc.
  • JAVA open source components hereinafter referred to as JAVA open source components have also been extremely widely used.
  • the technical problem to be solved by the present invention is to provide a JAVA open source component vulnerability detection method, device, electronic equipment and storage medium, aiming to solve the existing market that has no mature technology and product related to the vulnerability detection of JAVA open source component The problem.
  • the first aspect of the embodiments of the present invention provides a method for detecting a vulnerability of a JAVA open source component.
  • the method includes the following steps:
  • the vulnerability data of the JAVA open source component to be detected is obtained.
  • the generated vulnerability database including vulnerability data of all JAVA open source components includes:
  • a vulnerability database is generated according to the successfully matched CPE information in the CPE database and the CVE information corresponding to the CPE information.
  • the related information of the JAVA open source component to be detected includes at least the hash code of the JAVA open source component to be detected, and any piece of vulnerability data in the vulnerability database includes at least the hash of the JAVA open source component corresponding to the piece of vulnerability data.
  • Code, CVE information, and matching the relevant information of the JAVA open source component to be detected with each piece of vulnerability data in the vulnerability database includes:
  • the successfully matched CPE information in the CPE database and the CVE information corresponding to the CPE information are stored in the vulnerability database.
  • the relevant information of all JAVA open source components includes at least the manufacturer, product name and version number respectively related to each JAVA open source component, and the acquisition of relevant information of all JAVA open source components includes:
  • the configuration files include manifest.mf file, pom.xml file, build .gradle file and build.xml file;
  • the project structure includes the component packages that make up each of the JAVA open source components.
  • any piece of CPE information in the CPE database includes at least the CVE information corresponding to the CPE information and the manufacturer, product name, and version number corresponding to the CVE information, and the comparison of all JAVA open source components
  • the relevant information of is matched with each piece of CPE information in the CPE database, including:
  • each priority of the manufacturer, product name, and version number associated with each of the JAVA open source components includes only one manufacturer or product name or version number. If so, it will be associated with each of the JAVA open source components.
  • the relevant manufacturer, product name and version number are matched with each piece of CPE information in the CPE database in order of priority levels, until the matching is successful.
  • the matching the relevant information of all the JAVA open source components with each piece of CPE information in the CPE database further includes:
  • the manufacturer or product name or version number corresponding to each priority of the manufacturer, product name, and version number associated with each of the JAVA open source components will be mixed and combined within the same priority. Then match each piece of CPE information in the CPE database until the manufacturer or product name or version number corresponding to each priority of the manufacturer, product name and version number associated with each JAVA open source component are all Until the combination is complete.
  • the related information of the JAVA open source component to be tested also includes at least the manufacturer, product name and version number related to the JAVA open source component to be tested, and any piece of vulnerability information in the vulnerability database also includes at least the current JAVA open source component information.
  • a second aspect of the embodiments of the present invention provides a vulnerability detection device for JAVA open source components, which includes:
  • Generation module used to generate vulnerability database including vulnerability data of all JAVA open source components
  • the first acquisition module is used to acquire relevant information of the JAVA open source component to be tested
  • the matching module is used to match the relevant information of the JAVA open source component to be detected with each piece of vulnerability data in the vulnerability database;
  • the second obtaining module is used to obtain the vulnerability data of the JAVA open source component to be detected when the relevant information of the JAVA open source component to be detected is successfully matched with a piece of vulnerability data in the vulnerability database.
  • a third aspect of the embodiments of the present invention provides an electronic device, which includes:
  • a storage device and one or more processors where the storage device is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more The processor executes the method described in the first aspect of the embodiment of the present invention.
  • the fourth aspect of the present invention provides a storage medium having executable instructions stored thereon, and when the executable instructions are executed, the method described in the first aspect of the embodiments of the present invention is executed.
  • the present invention first generates a vulnerability database including vulnerability data of all JAVA open source components; secondly, obtains relevant information of the JAVA open source component to be detected, and matches the relevant information of the JAVA open source component to be detected with each piece of vulnerability data in the vulnerability database; and finally If the matching is successful, the vulnerability data of the JAVA open source component to be detected will be obtained.
  • the present invention provides a mature JAVA open source component vulnerability detection method by constructing and using a vulnerability database including vulnerability data of all JAVA open source components.
  • the method of finding the CVE of JAVA open source components is a manual method to find the drawbacks one by one, which greatly saves manpower and time resources, and makes the vulnerability detection results more accurate.
  • FIG. 1 is a flowchart of a method for detecting a vulnerability of a JAVA open source component provided by the first embodiment of the present invention
  • Figure 2 is the detailed information of a certain CVE on a certain website provided by the first embodiment of the present invention
  • FIG. 3 is the structure of a certain CPE provided by the first embodiment of the present invention.
  • FIG. 4 is a flowchart of a method for detecting a vulnerability of a JAVA open source component provided by a second embodiment of the present invention
  • FIG. 5 is a schematic diagram of a multi-layer structure of a project constituting an open source component provided by a second embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a vulnerability database in the form of a table provided by the second embodiment of the present invention.
  • FIG. 7 is a block diagram of a module of a vulnerability detection device of a JAVA open source component provided by a third embodiment of the present invention.
  • FIG. 8 is a block diagram of a module of an electronic device provided by a fourth embodiment of the present invention.
  • FIG. 9 is a module block diagram of a storage medium provided by a fifth embodiment of the present invention.
  • Figure 1 is a flowchart of a method for detecting a vulnerability in a JAVA open source component provided by the first embodiment of the present invention
  • Figure 2 is a CVE on a website provided by the first embodiment of the present invention
  • Figure 3 shows the composition of the CPE provided by the first embodiment of the present invention.
  • the method for detecting a vulnerability of a JAVA open source component includes the following steps:
  • obtaining relevant information of the JAVA open source component to be detected is by obtaining the source code of the JAVA open source component to be detected, and analyzing the obtained source code.
  • a CVE may have multiple CPE configurations.
  • a CPE may also exist in multiple CVEs.
  • cpe in Figure 3 is the beginning format, 2.3 means that it uses the 2.3 version of the protocol (currently CPE basically uses the 2.3 version of the protocol), o means the os operating system (in addition to o, but also There are h and a, where h represents hardware and a represents application), redhat represents a certain manufacturer, enterprise_linux represents a certain product of the manufacturer, and 6.0 represents the version number of the product.
  • CPE CPE
  • the vulnerability detection method for JAVA open source components provided by the first embodiment of the present invention firstly generates a vulnerability database including vulnerability data of all JAVA open source components; secondly, obtains relevant information of the JAVA open source components to be tested, and relates to the JAVA open source components to be tested. The information is matched with each piece of vulnerability data in the vulnerability database; finally, if the matching is successful, the vulnerability data of the JAVA open source component to be detected is obtained.
  • the vulnerability detection method provides a mature vulnerability detection method for JAVA open source components by constructing and using a vulnerability database including vulnerability data of all JAVA open source components, which not only makes up for the shortcomings of the existing market, but also in the very To a large extent, the current method of searching for Java open source components for CVE is manually searching for the disadvantages of one by one, which greatly saves manpower and time resources, and makes the vulnerability detection results more accurate.
  • Figure 4 is a flowchart of a method for detecting a vulnerability of a JAVA open source component provided by a second embodiment of the present invention
  • Figure 5 is a diagram of a project that forms an open source component provided by the second embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a vulnerability database in the form of a table provided by the second embodiment of the present invention.
  • S110 specifically includes the following steps:
  • S115 Generate a vulnerability database according to the successfully matched CPE information in the CPE database and the CVE information corresponding to the CPE information.
  • the vulnerability of any open source component cannot be constant, for example, an open source component in 2019 is found to have a vulnerability in the open source component in 2020, and the vulnerability number may be It is CVE-2020-001, but the vulnerability CVE-2020-001 does not exist in the previous vulnerability database, so it is necessary to update the CPE database in real time. After that, you need to perform S113-S115 to change the vulnerability CVE-2020-001 And the information related to the vulnerability CVE-2020-001 is stored in the vulnerability database.
  • the relevant information of the JAVA open source component to be detected includes at least the hash code of the JAVA open source component to be detected, and any piece of vulnerability data in the vulnerability database includes at least the hash code and CVE information of the JAVA open source component corresponding to the piece of vulnerability data.
  • S130 specifically includes the following steps:
  • the related information of all JAVA open source components includes at least the manufacturer, product name and version number respectively related to each JAVA open source component, and as shown in Figure 4, S113 specifically includes the following steps:
  • S1132 respectively, analyze the project structure of all JAVA open source components, and obtain the manufacturer, product name and version number associated with each JAVA open source component, and the project structure includes the name and composition of the component package that composes each JAVA open source component.
  • any piece of CPE information in the CPE database includes at least the CVE information corresponding to the CPE information and the manufacturer, product name, and version number corresponding to the CVE information, and as shown in FIG. 4, S114 specifically includes the following steps :
  • S1142 Determine whether each priority of the manufacturer, product name, and version number related to each Java open source component includes only one manufacturer or product name or version number. If so, it will be related to each Java open source component. Vendor, product name and version number are matched with each piece of CPE information in the CPE database in order of priority level, until the match is successful;
  • the manufacturer or product name or version number corresponding to each priority of the manufacturer, product name and version number associated with each Java open source component will be mixed and combined within the same priority. Then match each piece of CPE information in the CPE database until the manufacturer or product name or version number corresponding to each priority of the manufacturer, product name, and version number associated with each Java open source component are all combined.
  • Implementation-Vendor-Id files -Title may indicate the product name of the open source component
  • Implementation-Version may indicate the version information of the open source component
  • Implementation-Vendor may indicate the manufacturer information of the open source component
  • Implementation-Vendor-Id may indicate The vendor information of the open source component, etc., that is to say, multiple sets of the same value are likely to appear.
  • Implementation-Vendor and Implementation-Vendor-Id may indicate the vendor of the open source component.
  • the vendor There may be two fields. Both values need to be stored here, but a priority needs to be defined.
  • Implementation-Vendor represents the vendor of the open source component more accurately than Implementation-Vendor-Id. Then, based on experience, it is believed that Implementation-Vendor-Id indicates that the priority of the vendor of the open source component is medium, and Implementation-Vendor indicates that the priority of the vendor of the open source component is high.
  • manifest.mf file some possible values of vendor, product, and version can be parsed and the priority of these values.
  • the parsed configuration file is the pom.xml file type (this file is a construction tool file used by JAVA open source components, and it records the dependent components used by the open source component and part of the dependent component information, which is of reference value )
  • this file is a construction tool file used by JAVA open source components, and it records the dependent components used by the open source component and part of the dependent component information, which is of reference value
  • Groupid may represent the vendor of the open source component, or it may represent the product of the open source component, and the priority of these two possibilities is high, and the artifactid can also represent the open source component Vendor and product, but relatively speaking, the priority of the vendor is high, and the priority of the product is low.
  • the parsed configuration file is the build.gradle file type (this file is a JAVA open source component built using gradle) or the build.xml file type (this file is a JAVA open source component built using ant), these two file types Similar to the pom.xml file type, it records the information of the open source component and the information of the dependent components of the open source component, but the format field and syntax are different, so I won't elaborate on it here.
  • the name of the general component package can basically directly represent the product and version of an open source component without malicious manual modification, such as dom4j-1.6. jar, here the possibility that dom4j is a product has a high priority, and the possibility that 1.6 is a version has a high priority.
  • the first layer structure after parsed includes cn, seczone, sca, data, api, etc., and then according to the number of parses, the value of vendor and product are determined according to experience For example, if the parsed path level (that is, the number parsed by "dot") is 2 (only cn, seconze), then the possibility that the first level cn is the vendor has a medium priority, and the second level seczone The priority of the possibility of being a product is also medium, and if the parsed path level is 3, the priority of the possibility that the first and second layers are vendors is medium, and the second and the third are the possibilities of product The priority is also medium and so on.
  • each priority of the manufacturer, product name, and version number respectively associated with each Java open source component includes only one manufacturer or product name or version number, you need to press
  • the priority level is from high to low, that is, the vendor, product, and version related to the open source component with the high priority are matched with each CPE information in the CPE database. If the match is consistent ("consistent" means related to the open source component
  • the vendor, product, and version of the CPE are the same as the vendor, product name, and version number in a CPE information in the CPE database. If the priority is medium and low, there is no need to match.
  • each priority of the vendor, product name, and version number associated with each Java open source component does not include only one vendor or product name or version number
  • vendors with high priority include cn and seczone, which have high priority.
  • Level products include seczone, sca, sdlc, and versions with high priority are 1.0 and 2.0, so each case needs to be mixed and matched.
  • vendor is cn product is seczone, and version is 1.0
  • the generated vulnerability database is a table form of vulnerability database, where sha1 in the second column is a hash code, which is a data encryption format.
  • the content of the open source component will be encrypted into a string of 40-bit random numbers and letters, and different open source components will have different hash codes.
  • the relevant information of the JAVA open source component to be tested also includes at least the manufacturer, product name and version number related to the JAVA open source component to be tested; any piece of vulnerability information in the vulnerability database also includes at least the current JAVA open source component The name of, the CPE information corresponding to the CVE information, and the manufacturer, product name, and version number corresponding to the CPE information.
  • the vulnerability database can be manually reviewed and the error information can be deleted.
  • the error information includes: multiple information with the same name of the open source component, the same priority, but different CPE, in this case, it needs to be manually reviewed and determined; the name of the open source component is the same, the CPE is the same, but the CVE is different.
  • manual review and confirmation is also required.
  • the name of each Java open source component needs to correspond to the unique CPE information corresponding to the CVE of the Java open source component.
  • the CPE database is updated in real time, which avoids the lack of CPE information in the CPE database, and further ensures the information integrity of the vulnerability database; , After analyzing the configuration files and/or project structure of all JAVA open source components, define the priority of the manufacturer, product name and version number related to each JAVA open source component, avoiding the Component-related manufacturers, product names, and version numbers are matched with each piece of CPE information in the CPE database.
  • the third aspect is to delete the wrong information in the vulnerability database through manual review and confirmation.
  • the fourth aspect is to match the hash code of the JAVA open source component to be detected with the vulnerability database and check whether the hash code of the JAVA open source component to be detected exists in the vulnerability database. If it exists, use it directly
  • the CVE information corresponding to the hash code of the JAVA open source component to be detected does not need to be repeatedly analyzed at this time, thereby saving the time spent repeatedly analyzing the JAVA open source component to be detected and improving the efficiency of vulnerability detection.
  • FIG. 7 is a block diagram of a module of a vulnerability detection device for a JAVA open source component provided by a third embodiment of the present invention.
  • the vulnerability detection apparatus 100 for JAVA open source components provided by the third embodiment of the present invention includes:
  • the generation module 101 is used to generate a vulnerability database including vulnerability data of all JAVA open source components
  • the first obtaining module 102 is used to obtain relevant information of the JAVA open source component to be tested;
  • the matching module 103 is used to match the relevant information of the JAVA open source component to be detected with each piece of vulnerability data in the vulnerability database;
  • the second obtaining module 104 is configured to obtain vulnerability data of the JAVA open source component to be detected when the relevant information of the JAVA open source component to be detected is successfully matched with a certain piece of vulnerability data in the vulnerability database.
  • FIG. 8 is a block diagram of a module of an electronic device according to a fourth embodiment of the present invention.
  • the electronic device 200 provided by the fourth embodiment of the present invention includes:
  • the storage device 201 and one or more processors 202 where the storage device 201 is used to store one or more programs, and when the one or more programs are executed by the one or more processors 202, the one or more processors 202 executes the vulnerability detection method of JAVA open source components as provided in the first embodiment and/or the second embodiment of the present invention.
  • the electronic device 200 further includes a bus 203 for connection between the storage device 201 and one or more processors 202.
  • FIG. 9 is a module block diagram of a storage medium provided by a fifth embodiment of the present invention.
  • the storage medium 300 provided by the fifth embodiment of the present invention stores executable instructions 301, and when executed, the executable instructions 301 are executed as provided in the first embodiment and/or the second embodiment of the present invention. Vulnerability detection method of JAVA open source components.
  • the method, device, electronic equipment, and storage medium for vulnerability detection of JAVA open source components provided by the present invention have the following beneficial effects:
  • the present invention first generates a vulnerability database including vulnerability data of all JAVA open source components; secondly, obtains relevant information of the JAVA open source component to be detected, and matches the relevant information of the JAVA open source component to be detected with each piece of vulnerability data in the vulnerability database; and finally If the matching is successful, the vulnerability data of the JAVA open source component to be detected will be obtained.
  • the present invention provides a mature JAVA open source component vulnerability detection method by constructing and using a vulnerability database including vulnerability data of all JAVA open source components.
  • the method of finding the CVE of JAVA open source components is a manual method to find the drawbacks one by one, which greatly saves manpower and time resources, and makes the vulnerability detection results more accurate.
  • the CPE database is updated in real time, avoiding the lack of CPE information in the CPE database, and further ensuring the information integrity of the vulnerability database;
  • the second aspect After analyzing the configuration files and/or project structure of all JAVA open source components, the obtained manufacturer, product name and version number related to each JAVA open source component are defined as priority, which avoids all the Java open source components.
  • the related manufacturer, product name, and version number are matched with each piece of CPE information in the CPE database.
  • the third aspect is to delete the wrong information in the vulnerability database through manual review and confirmation to further ensure
  • To detect the CVE information corresponding to the hash code of the JAVA open source component there is no need to repeat the analysis of the JAVA open source component to be tested, thereby saving the time spent repeatedly analyzing the JAVA open source component to be tested, and improving the efficiency of vulnerability detection.
  • the steps of the method or algorithm described in the embodiments disclosed in the present invention can be directly implemented by hardware, a software module executed by a processor, or a combination of the two.
  • the software module can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or all areas in the technical field. Any other known storage media.
  • the above embodiments it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software it can be implemented in the form of a computer program product in whole or in part.
  • the computer program product includes one or more computer instructions.
  • the computer program instructions When the computer program instructions are loaded and executed on the computer, the procedures or functions according to the present invention are generated in whole or in part.
  • the computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.
  • computer instructions may be transmitted from a website, computer, server, or data center through a cable (such as Coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) to transmit to another website site, computer, server or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media.
  • the usable medium can be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state hard disk). State Disk) and so on.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

一种JAVA开源组件的漏洞检测方法、装置及存储介质,其中,方法包括:生成包括所有JAVA开源组件的漏洞数据的漏洞数据库(S110);获取待检测JAVA开源组件的相关信息(S120);对待检测JAVA开源组件的相关信息与漏洞数据库进行匹配(S130);若匹配成功,则获取待检测JAVA开源组件的漏洞数据(S140)。该方法既弥补了现有市场的不足,又在很大程度上摒弃了目前寻找JAVA开源组件的CVE信息的方法是以人工方式逐个寻找的弊端,极大地节省了人力、时间资源,使得漏洞检测结果更加精准。

Description

JAVA开源组件的漏洞检测方法、装置及存储介质 技术领域
本发明涉及软件检测技术领域,尤其是指一种JAVA开源组件的漏洞检测方法、装置、电子设备及存储介质。
背景技术
Java是一门面向对象编程语言,不仅吸收了C++语言的各种优点,还摒弃了C++里难以理解的多继承、指针等概念,而Java语言作为静态面向对象编程语言的代表,极好地实现了面向对象理论,允许程序员以优雅的思维方式进行复杂的编程。近些年来,Java语言凭借其功能强大、简单易用、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点,被广泛应用于编写桌面应用程序、Web应用程序、分布式系统和嵌入式系统应用程序等,同时JAVA开源组件(以下简称JAVA开源组件)也得到了极其广泛的应用。
目前,软件开发人员广泛使用开源组件,事实上,据估计,每个应用程序的80-90%都是由开源组件组成的。Synopsys的研究显示,在软件应用程序中被使用的第三方组件,有一半已经过时,很可能存在安全隐患。另一份来自Black Duck的报告称,使用开源组件的所有应用程序中,超过60%包含已知的软件漏洞。那么分析每个开源组件的通用漏洞披露(Common Vulnerabilities & Exposures,简称CVE),将会给项目的组成分析(Service Oritented Architecture,简称SCA)提供有效的信息支持。然而,目前市场上还没有与JAVA开源组件的漏洞检测相关且成熟的技术和产品。
因此,有必要开发一种JAVA开源组件的漏洞检测方法、装置、电子设备及存储介质。
技术问题
本发明所要解决的技术问题是:提供一种JAVA开源组件的漏洞检测方法、装置、电子设备及存储介质,旨在解决现有市场上没有与JAVA开源组件的漏洞检测相关且成熟的技术和产品的问题。
技术解决方案
为了解决上述技术问题,本发明采用的技术方案为:
本发明实施例第一方面提供了一种JAVA开源组件的漏洞检测方法,该方法包括如下步骤:
生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;
获取待检测JAVA开源组件的相关信息;
对所述待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;
若匹配成功,则获取所述待检测JAVA开源组件的漏洞数据。
进一步地,所述生成包括所有JAVA开源组件的漏洞数据的漏洞数据库包括:
获取所有涉及CVE信息的网站中与所述CVE信息相对应的CPE信息;
根据所述CPE信息及CVE信息生成CPE数据库并实时更新;
获取所有JAVA开源组件的相关信息;
对所述所有JAVA开源组件的相关信息分别与CPE数据库中的每一条CPE信息进行匹配;
根据所述CPE数据库中匹配成功的CPE信息及与CPE信息相对应的CVE信息生成漏洞数据库。
进一步地,所述待检测JAVA开源组件的相关信息至少包括待检测JAVA开源组件的哈希码,所述漏洞数据库中的任一条漏洞数据至少包括该条漏洞数据所对应的JAVA开源组件的哈希码、CVE信息,且所述对所述待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配包括:
判断所述漏洞数据库中是否存在待检测JAVA开源组件的哈希码,若存在,则直接获取所述漏洞数据库中与待检测JAVA开源组件的哈希码相对应的CVE信息;
若不存在,则对所述待检测JAVA开源组件的相关信息与CPE数据库中的每一条CPE信息进行匹配;
将所述CPE数据库中匹配成功的CPE信息及与CPE信息相对应的CVE信息存储至漏洞数据库。
进一步地,所述所有JAVA开源组件的相关信息至少包括分别与每一JAVA开源组件相关的厂商、产品名称及版本号,且所述获取所有JAVA开源组件的相关信息包括:
分别对所述所有JAVA开源组件的配置文件进行分析,得到分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号,所述配置文件包括manifest.mf文件、pom.xml文件、build.gradle文件及build.xml文件;
分别对所述所有JAVA开源组件的项目结构进行分析,得到分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号,所述项目结构包括组成每一所述JAVA开源组件的组件包的名称及组成每一JAVA开源组件的项目的多层结构。
进一步地,所述CPE数据库中的任一条CPE信息至少包括与该CPE信息相对应的CVE信息及与该CVE信息相对应的厂商、产品名称及版本号,且所述对所述所有JAVA开源组件的相关信息分别与CPE数据库中的每一条CPE信息进行匹配包括:
对所述所有JAVA开源组件的配置文件和/或项目结构进行分析后,对所得到的分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号定义优先级;
判断分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号的每种优先级是否均只包括一个厂商或产品名称或版本号,若是,则将分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号按照优先级别由高至低依次与CPE数据库中的每一条CPE信息进行匹配,直至匹配成功为止。
进一步地,所述对所述所有JAVA开源组件的相关信息分别与CPE数据库中的每一条CPE信息进行匹配还包括:
若否,则将分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号的每种优先级所对应的厂商或产品名称或版本号,进行同种优先级内的混合组合后,再与所述CPE数据库中的每一条CPE信息进行匹配,直至分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号的每种优先级所对应的厂商或产品名称或版本号全部组合完成为止。
进一步地,所述待检测JAVA开源组件的相关信息至少还包括与待检测JAVA开源组件相关的厂商、产品名称及版本号,所述漏洞数据库中的任一条漏洞信息至少还包括当前JAVA开源组件的名称、与CVE信息相对应的CPE信息及与该CPE信息相对应的厂商、产品名称及版本号。
本发明实施例第二方面提供了一种JAVA开源组件的漏洞检测装置,该装置包括:
生成模块,用于生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;
第一获取模块,用于获取待检测JAVA开源组件的相关信息;
匹配模块,用于对所述待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;
第二获取模块,用于在所述待检测JAVA开源组件的相关信息与漏洞数据库中的某条漏洞数据匹配成功时,获取所述待检测JAVA开源组件的漏洞数据。
本发明实施例第三方面提供了一种电子设备,其包括:
存储装置及一个或多个处理器,所述存储装置用于存储一个或多个程序,其中,当所述一个或多个程序被一个或多个处理器执行时,使得所述一个或多个处理器执行如本发明实施例第一方面所述的方法。
本发明第四方面提供了一种存储介质,其上存储有可执行指令,该可执行指令被执行时执行如本发明实施例第一方面所述的方法。
有益效果
从上述描述可知,本发明提供的JAVA开源组件的漏洞检测方法、装置、电子设备及存储介质,其有益效果在于:
本发明首先生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;其次,获取待检测JAVA开源组件的相关信息,并对待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;最后,若匹配成功,则获取待检测JAVA开源组件的漏洞数据。本发明通过构建并利用包括所有JAVA开源组件的漏洞数据的漏洞数据库,提供了一种成熟的JAVA开源组件的漏洞检测方法,既弥补了现有市场的不足,又在很大程度上摒弃了目前寻找JAVA开源组件的CVE的方法是以人工方式逐个寻找的弊端,极大地节省了人力、时间资源,使得漏洞检测结果更加精准。
附图说明
下面结合附图详述本发明的具体内容
图1为本发明第一实施例提供的JAVA开源组件的漏洞检测方法的流程图;
图2为本发明第一实施例提供的某网站上某一个CVE的详细信息;
图3为本发明第一实施例提供的某一CPE的构成;
图4为本发明第二实施例提供的JAVA开源组件的漏洞检测方法的流程图;
图5为本发明第二实施例提供的组成开源组件的项目的多层结构的示意图;
图6为本发明第二实施例提供的表格形式的漏洞数据库的示意图;
图7为本发明第三实施例提供的JAVA开源组件的漏洞检测装置的模块方框图;
图8为本发明第四实施例提供的电子设备的模块方框图;
图9为本发明第五实施例提供的存储介质的模块方框图。
本发明的实施方式
为详细说明本发明的技术内容、构造特征、所实现目的及效果,以下结合实施方式并配合附图详予说明。
请参阅图1、图2以及图3,图1为本发明第一实施例提供的JAVA开源组件的漏洞检测方法的流程图,图2为本发明第一实施例提供的某网站上某一个CVE的详细信息,图3为本发明第一实施例提供的CPE的构成。
如图1所示,本发明第一实施例提供的JAVA开源组件的漏洞检测方法包括如下步骤:
S110、生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;
S120、获取待检测JAVA开源组件的相关信息;
S130、对待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;
S140、若匹配成功,则获取待检测JAVA开源组件的漏洞数据。
具体的,于本实施例中,获取待检测JAVA开源组件的相关信息是通过获取待检测JAVA开源组件的源码,并对获得的源码进行分析的方式。
需要说明的是,如图2所示,一个CVE可能有多种CPE配置,同样的道理,一个CPE也可能会存在于多种CVE里面。另外,如图3所示,图3中的cpe为开头格式,2.3表示是采用2.3版本协议的cpe(目前CPE基本都是采用2.3版本协议),o表示os操作系统(除了o之外,还有h和a,其中h表示硬件,a表示应用),redhat表示某一厂商,enterprise_linux表示该厂商的某一产品,6.0表示该产品的版本号。
下面对CPE的标准格式进行详细说明,如cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other,其中part表示目标类型,允许的值有a(应用程序)、h(硬件平台)、o(操作系统);vendor表示厂商;product表示产品名称;version表示版本号;update表示更新包;edition表示版本;language表示语言项。
本发明第一实施例提供的JAVA开源组件的漏洞检测方法,首先生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;其次,获取待检测JAVA开源组件的相关信息,并对待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;最后,若匹配成功,则获取待检测JAVA开源组件的漏洞数据。也就是说,该漏洞检测方法通过构建并利用包括所有JAVA开源组件的漏洞数据的漏洞数据库,提供了一种成熟的JAVA开源组件的漏洞检测方法,既弥补了现有市场的不足,又在很大程度上摒弃了目前寻找JAVA开源组件的CVE的方法是以人工方式逐个寻找的弊端,极大地节省了人力、时间资源,使得漏洞检测结果更加精准。
请参阅图4、图5以及图6,图4为本发明第二实施例提供的JAVA开源组件的漏洞检测方法的流程图,图5为本发明第二实施例提供的组成开源组件的项目的多层结构的示意图,图6为本发明第二实施例提供的表格形式的漏洞数据库的示意图。
与本发明第一实施例提供的JAVA开源组件的漏洞检测方法所不同的是,在本发明第二实施例中:
进一步地,如图4所示,S110具体包括如下步骤:
S111、获取所有涉及CVE信息的网站中与CVE信息相对应的CPE信息;
S112、根据CPE信息及CVE信息生成CPE数据库并实时更新;
S113、获取所有JAVA开源组件的相关信息;
S114、对所有JAVA开源组件的相关信息分别与CPE数据库中的每一条CPE信息进行匹配;
S115、根据CPE数据库中匹配成功的CPE信息及与CPE信息相对应的CVE信息生成漏洞数据库。
需要说明的是,于本实施例中,由于任意一个开源组件的漏洞不可能是不变的,比如一个2019年的开源组件,在2020年时被发现该开源组件存在一个漏洞,该漏洞编号可能是CVE-2020-001,然而之前的漏洞数据库中是不存在漏洞CVE-2020-001的,所以对CPE数据库进行实时更新是有必要的,之后需要进行S113-S115,将漏洞CVE-2020-001及与漏洞CVE-2020-001相关的信息存入漏洞数据库中。
进一步地,待检测JAVA开源组件的相关信息至少包括待检测JAVA开源组件的哈希码,漏洞数据库中的任一条漏洞数据至少包括该条漏洞数据所对应的JAVA开源组件的哈希码、CVE信息,且如图4所示,S130具体包括如下步骤:
S131、判断漏洞数据库中是否存在待检测JAVA开源组件的哈希码,若存在,则直接获取漏洞数据库中与待检测JAVA开源组件的哈希码相对应的CVE信息;
S132、若不存在,则对待检测JAVA开源组件的相关信息与CPE数据库中的每一条CPE信息进行匹配;
S133、将CPE数据库中匹配成功的CPE信息及与CPE信息相对应的CVE信息存储至漏洞数据库。
进一步地,所有JAVA开源组件的相关信息至少包括分别与每一JAVA开源组件相关的厂商、产品名称及版本号,且如图4所示,S113具体包括如下步骤:
S1131、分别对所有JAVA开源组件的配置文件进行分析,得到分别与每一JAVA开源组件相关的厂商、产品名称及版本号,且配置文件包括manifest.mf文件、pom.xml文件、build.gradle文件及build.xml文件;
S1132、分别对所有JAVA开源组件的项目结构进行分析,得到分别与每一JAVA开源组件相关的厂商、产品名称及版本号,且项目结构包括组成每一JAVA开源组件的组件包的名称及组成每一JAVA开源组件的项目的多层结构。
进一步地,CPE数据库中的任一条CPE信息至少包括与该CPE信息相对应的CVE信息及与该CVE信息相对应的厂商、产品名称及版本号,且如图4所示,S114具体包括如下步骤:
S1141、对所有JAVA开源组件的配置文件和/或项目结构进行分析后,对所得到的分别与每一JAVA开源组件相关的厂商、产品名称及版本号定义优先级;
S1142、判断分别与每一JAVA开源组件相关的厂商、产品名称及版本号的每种优先级是否均只包括一个厂商或产品名称或版本号,若是,则将分别与每一JAVA开源组件相关的厂商、产品名称及版本号按照优先级别由高至低依次与CPE数据库中的每一条CPE信息进行匹配,直至匹配成功为止;
S1143、若否,则将分别与每一JAVA开源组件相关的厂商、产品名称及版本号的每种优先级所对应的厂商或产品名称或版本号,进行同种优先级内的混合组合后,再与CPE数据库中的每一条CPE信息进行匹配,直至分别与每一JAVA开源组件相关的厂商、产品名称及版本号的每种优先级所对应的厂商或产品名称或版本号全部组合完成为止。
具体的,如解析的配置文件为manifest.mf文件类型(此文件定义了与扩展和包相关的数据)中的Implementation-Title、Implementation-Version、mplementation-Vendor及Implementation-Vendor-Id文件,那么Implementation-Title可能表示的是该开源组件的产品名称,Implementation-Version可能表示的是该开源组件的版本信息,Implementation-Vendor可能表示的是该开源组件的厂商信息,Implementation-Vendor-Id可能表示的是该开源组件的厂商信息等等,也就是说,很可能会出现多组相同的值,例如前面所提到的Implementation-Vendor和Implementation-Vendor-Id都可能表示该开源组件的厂商,此时vendor字段就可能有两个,在这里需要将这两个值都存起来,但是需要定义一个优先级,例如根据经验认为Implementation-Vendor比Implementation-Vendor-Id要更准确地表示该开源组件的vendor,那么根据经验认为Implementation-Vendor-Id表示该开源组件的vendor的可能性的优先级为中,Implementation-Vendor表示该开源组件的vendor的可能性的优先级为高。通过manifest.mf文件可以解析出一些vendor,product和version可能对应的值以及这些值对应的优先级。
具体的,如解析的配置文件为pom.xml文件类型(此文件是JAVA开源组件使用的构建工具文件,且记录了该开源组件所使用的依赖组件以及该依赖组件的部分信息,是具有参考价值的)中的Groupid及artifactid文件,那么 Groupid可能表示该开源组件的vendor,也可能表示该开源组件的product,且这两个可能性的优先级都是高的,artifactid也同时可以表示该开源组件的vendor和product,但相对而言,表示vendor的优先级是高,而表示product的优先级是低。
具体的,如解析的配置文件为build.gradle文件类型(此文件是使用gradle构建的JAVA开源组件)或build.xml文件类型(此文件是使用ant构建的JAVA开源组件),这两种文件类型和pom.xml文件类型相似,均记录了该开源组件的信息及该开源组件的依赖组件的信息,但表示的格式字段和语法不一样,这里就不再做详细阐述了。
具体的,如对组成开源组件的组件包的名称进行分析,一般组件包的名称在不进行恶意人工修改的前提下,都基本能直接地表示一个开源组件的product和version,例如dom4j-1.6.jar,此处的dom4j是product的可能性优先级为高,1.6是version的可能性优先级也为高。
具体的,如图5所示,在对组成开源组件的项目的多层结构进行分析时,取第一层结构,该第一层结构是vendor的可能性优先级为高,此时,需要把所有的路径都按“点号”解析,关于解析后的第一层结构就有cn、seczone、sca、data、api等等,然后根据解析出来的个数,按照经验进行vendor,product的取值,例如解析的路径层级(也就是按“点号”解析后的个数)为2的话(只有cn、seconze),那么第一层cn则为vendor的可能性优先级为中,第二层seczone为product的可能性优先级也为中,又如解析的路径层级为3的话,第一层及第二层为vendor的可能性优先级为中,第二层及第三层为product的可能性优先级也为中等等。
需要说明的是,于本实施例中,若分别与每一JAVA开源组件相关的厂商、产品名称及版本号的每种优先级均只包括一个厂商或产品名称或版本号,此时,需要按优先级别从高至低,即从优先级别为高的与开源组件相关的vendor、product和version与CPE数据库中的每一条CPE信息进行匹配,如果匹配一致(“一致”的意思是与开源组件相关的vendor、product和version与CPE数据库中某一CPE信息中的厂商、产品名称及版本号一致),优先级别为中和低的就不需要进行匹配了。若分别与每一JAVA开源组件相关的厂商、产品名称及版本号的每种优先级并非均只包括一个厂商或产品名称或版本号,比如具有高优先级的vendor有cn、seczone,具有高优先级的product有seczone、sca、sdlc,具有高优先级的version有1.0、2.0,那么每种情况都需要进行混合匹配,例如vender为cn,product为seczone,version为1.0时,检测CPE数据库中是否存在vender为cn,product为seczone,version为1.0的cpe,若不存在则继续匹配,若存在,继续试用该高优先级的其他组合与CPE数据库中的每一条CPE信息进行匹配,直到所有组合尝试结束为止。
还需要说明的是,于本实施例中,如图6所示,所生成的漏洞数据库为表格形式的漏洞数据库,其中,第二列的sha1为哈希码,其是一种数据加密格式,会将该开源组件的内容加密成40位的随机数字和字母的字符串,且不同的开源组件会有不同的哈希码。
另外,于本实施例中,待检测JAVA开源组件的相关信息至少还包括与待检测JAVA开源组件相关的厂商、产品名称及版本号;漏洞数据库中的任一条漏洞信息至少还包括当前JAVA开源组件的名称、与CVE信息相对应的CPE信息及与该CPE信息相对应的厂商、产品名称及版本号。
在本实施例提供的JAVA开源组件的漏洞检测方法的基础上,在根据与CPE信息对应的CVE生成漏洞数据库后,可对漏洞数据库进行人工复核,并删除错误信息。其中,错误信息包括:开源组件的名称相同,优先级别相同,但CPE不同的多个信息,此时,需要人工复核确定;开源组件的名称相同,CPE相同,但CVE不同的多个信息,此时,也需要人工复核确认。总之,在人工复核确认之后,每一个JAVA开源组件的名称需要对应唯一的与该JAVA开源组件的CVE对应的CPE信息。
本发明第二实施例提供的JAVA开源组件的漏洞检测方法,第一方面,对CPE数据库进行实时更新,避免了CPE数据库中CPE信息的缺失,进一步保证了漏洞数据库的信息完整性;第二方面,在对所有JAVA开源组件的配置文件和/或项目结构进行分析后,对所得到的分别与每一JAVA开源组件相关的厂商、产品名称及版本号定义优先级,避免了在所有与JAVA开源组件相关的厂商、产品名称及版本号分别与CPE数据库中的每一条CPE信息进行匹配的过程中匹配紊乱的问题;第三方面,通过人工复核确认的方式,删除漏洞数据库中的错误信息,进一步保证了漏洞数据库的精准性;第四方面,将待检测JAVA开源组件的哈希码与漏洞数据库进行匹配并检测漏洞数据库中是否存在待检测JAVA开源组件的哈希码,若存在,则直接利用待检测JAVA开源组件的哈希码所对应的CVE信息,此时不需要重复对待检测JAVA开源组件进行分析,从而节省了重复分析待检测JAVA开源组件所花费的时间,提高了漏洞检测的效率。
请参阅图7,图7为本发明第三实施例提供的JAVA开源组件的漏洞检测装置的模块方框图。
如图7所示,与本发明第一实施例提供的JAVA开源组件的漏洞检测方法相对应的,本发明第三实施例提供的JAVA开源组件的漏洞检测装置100包括:
生成模块101,用于生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;
第一获取模块102,用于获取待检测JAVA开源组件的相关信息;
匹配模块103,用于对待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;
第二获取模块104,用于在待检测JAVA开源组件的相关信息与漏洞数据库中的某条漏洞数据匹配成功时,获取待检测JAVA开源组件的漏洞数据。
请参阅图8,图8为本发明第四实施例提供的电子设备的模块方框图。
如图8所示,本发明第四实施例提供的电子设备200包括:
存储装置201及一个或多个处理器202,其中存储装置201用于存储一个或多个程序,且当一个或多个程序被一个或多个处理器202执行时,使得一个或多个处理器202执行如本发明第一实施例和/或第二实施例提供的JAVA开源组件的漏洞检测方法。
需要了解的是,于本实施例中,电子设备200还包括总线203,用于存储装置201与一个或多个处理器202之间的连接。
请参阅图9,图9为本发明第五实施例提供的存储介质的模块方框图。
如图9所示,本发明第五实施例提供的存储介质300上存储有可执行指令301,该可执行指令301被执行时执行如本发明第一实施例和/或第二实施例提供的JAVA开源组件的漏洞检测方法。
综上所述,本发明提供的JAVA开源组件的漏洞检测方法、装置、电子设备及存储介质,其有益效果在于:
本发明首先生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;其次,获取待检测JAVA开源组件的相关信息,并对待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;最后,若匹配成功,则获取待检测JAVA开源组件的漏洞数据。本发明通过构建并利用包括所有JAVA开源组件的漏洞数据的漏洞数据库,提供了一种成熟的JAVA开源组件的漏洞检测方法,既弥补了现有市场的不足,又在很大程度上摒弃了目前寻找JAVA开源组件的CVE的方法是以人工方式逐个寻找的弊端,极大地节省了人力、时间资源,使得漏洞检测结果更加精准。
另外,通过本发明提供的几个实施例可知,本发明第一方面,对CPE数据库进行实时更新,避免了CPE数据库中CPE信息的缺失,进一步保证了漏洞数据库的信息完整性;第二方面,在对所有JAVA开源组件的配置文件和/或项目结构进行分析后,对所得到的分别与每一JAVA开源组件相关的厂商、产品名称及版本号定义优先级,避免了在所有与JAVA开源组件相关的厂商、产品名称及版本号分别与CPE数据库中的每一条CPE信息进行匹配的过程中匹配紊乱的问题;第三方面,通过人工复核确认的方式,删除漏洞数据库中的错误信息,进一步保证了漏洞数据库的精准性;第四方面,将待检测JAVA开源组件的哈希码与漏洞数据库进行匹配并检测漏洞数据库中是否存在待检测JAVA开源组件的哈希码,若存在,则直接利用待检测JAVA开源组件的哈希码所对应的CVE信息,此时不需要重复对待检测JAVA开源组件进行分析,从而节省了重复分析待检测JAVA开源组件所花费的时间,提高了漏洞检测的效率。
结合本发明中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid  State Disk)等。
需要说明的是,本发明内容中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于产品类实施例而言,由于其与方法类实施例相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
还需要说明的是,在本发明内容中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明内容。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本发明内容中所定义的一般原理可以在不脱离本发明内容的精神或范围的情况下,在其它实施例中实现。因此,本发明内容将不会被限制于本发明内容所示的这些实施例,而是要符合与本发明内容所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

  1. 一种JAVA开源组件的漏洞检测方法,其特征在于,包括如下步骤:
    生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;
    获取待检测JAVA开源组件的相关信息;
    对所述待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;
    若匹配成功,则获取所述待检测JAVA开源组件的漏洞数据。
  2. 如权利要求1所述的JAVA开源组件的漏洞检测方法,其特征在于,所述生成包括所有JAVA开源组件的漏洞数据的漏洞数据库包括:
    获取所有涉及CVE信息的网站中与所述CVE信息相对应的CPE信息;
    根据所述CPE信息及CVE信息生成CPE数据库并实时更新;
    获取所有JAVA开源组件的相关信息;
    对所述所有JAVA开源组件的相关信息分别与CPE数据库中的每一条CPE信息进行匹配;
    根据所述CPE数据库中匹配成功的CPE信息及与CPE信息相对应的CVE信息生成漏洞数据库。
  3. 如权利要求2所述的JAVA开源组件的漏洞检测方法,其特征在于,所述待检测JAVA开源组件的相关信息至少包括待检测JAVA开源组件的哈希码,所述漏洞数据库中的任一条漏洞数据至少包括该条漏洞数据所对应的JAVA开源组件的哈希码、CVE信息,且所述对所述待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配包括:
    判断所述漏洞数据库中是否存在待检测JAVA开源组件的哈希码,若存在,则直接获取所述漏洞数据库中与待检测JAVA开源组件的哈希码相对应的CVE信息;
    若不存在,则对所述待检测JAVA开源组件的相关信息与CPE数据库中的每一条CPE信息进行匹配;
    将所述CPE数据库中匹配成功的CPE信息及与CPE信息相对应的CVE信息存储至漏洞数据库。
  4. 如权利要求2所述的JAVA开源组件的漏洞检测方法,其特征在于,所述所有JAVA开源组件的相关信息至少包括分别与每一JAVA开源组件相关的厂商、产品名称及版本号,且所述获取所有JAVA开源组件的相关信息包括:
    分别对所述所有JAVA开源组件的配置文件进行分析,得到分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号,所述配置文件包括manifest.mf文件、pom.xml文件、build.gradle文件及build.xml文件;
    分别对所述所有JAVA开源组件的项目结构进行分析,得到分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号,所述项目结构包括组成每一所述JAVA开源组件的组件包的名称及组成每一JAVA开源组件的项目的多层结构。
  5. 如权利要求4所述的JAVA开源组件的漏洞检测方法,其特征在于,所述CPE数据库中的任一条CPE信息至少包括与该CPE信息相对应的CVE信息及与该CVE信息相对应的厂商、产品名称及版本号,且所述对所述所有JAVA开源组件的相关信息分别与CPE数据库中的每一条CPE信息进行匹配包括:
    对所述所有JAVA开源组件的配置文件和/或项目结构进行分析后,对所得到的分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号定义优先级;
    判断分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号的每种优先级是否均只包括一个厂商或产品名称或版本号,若是,则将分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号按照优先级别由高至低依次与CPE数据库中的每一条CPE信息进行匹配,直至匹配成功为止。
  6. 如权利要求5所述的JAVA开源组件的漏洞检测方法,其特征在于,所述对所述所有JAVA开源组件的相关信息分别与CPE数据库中的每一条CPE信息进行匹配还包括:
    若否,则将分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号的每种优先级所对应的厂商或产品名称或版本号,进行同种优先级内的混合组合后,再与所述CPE数据库中的每一条CPE信息进行匹配,直至分别与每一所述JAVA开源组件相关的厂商、产品名称及版本号的每种优先级所对应的厂商或产品名称或版本号全部组合完成为止。
  7. 如权利要求1-6任一项所述的JAVA开源组件的漏洞检测方法,其特征在于:所述待检测JAVA开源组件的相关信息至少还包括与待检测JAVA开源组件相关的厂商、产品名称及版本号,所述漏洞数据库中的任一条漏洞信息至少还包括当前JAVA开源组件的名称、与CVE信息相对应的CPE信息及与该CPE信息相对应的厂商、产品名称及版本号。
  8. 一种JAVA开源组件的漏洞检测装置,其特征在于,包括:
    生成模块,用于生成包括所有JAVA开源组件的漏洞数据的漏洞数据库;
    第一获取模块,用于获取待检测JAVA开源组件的相关信息;
    匹配模块,用于对所述待检测JAVA开源组件的相关信息与漏洞数据库中的每一条漏洞数据进行匹配;
    第二获取模块,用于在所述待检测JAVA开源组件的相关信息与漏洞数据库中的某条漏洞数据匹配成功时,获取所述待检测JAVA开源组件的漏洞数据。
  9. 一种电子设备,包括:存储装置及一个或多个处理器,所述存储装置用于存储一个或多个程序,其中,当所述一个或多个程序被一个或多个处理器执行时,使得所述一个或多个处理器执行如权利要求1-7任一项所述的方法。
  10. 一种存储介质,其上存储有可执行指令,该可执行指令被执行时执行如权利要求1-7任一项所述的方法。
PCT/CN2020/087511 2020-04-28 2020-04-28 Java开源组件的漏洞检测方法、装置及存储介质 WO2021217421A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2020/087511 WO2021217421A1 (zh) 2020-04-28 2020-04-28 Java开源组件的漏洞检测方法、装置及存储介质
CN202080004869.7A CN112868008B (zh) 2020-04-28 2020-04-28 Java开源组件的漏洞检测方法、装置及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/087511 WO2021217421A1 (zh) 2020-04-28 2020-04-28 Java开源组件的漏洞检测方法、装置及存储介质

Publications (1)

Publication Number Publication Date
WO2021217421A1 true WO2021217421A1 (zh) 2021-11-04

Family

ID=76001788

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/087511 WO2021217421A1 (zh) 2020-04-28 2020-04-28 Java开源组件的漏洞检测方法、装置及存储介质

Country Status (2)

Country Link
CN (1) CN112868008B (zh)
WO (1) WO2021217421A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113297583B (zh) * 2021-07-27 2021-11-09 深圳开源互联网安全技术有限公司 漏洞风险分析方法、装置、设备及存储介质
CN113449306A (zh) * 2021-09-02 2021-09-28 湖南省佳策测评信息技术服务有限公司 一种基于软件源代码分析的安全漏洞预警方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140237603A1 (en) * 2013-02-20 2014-08-21 International Business Machines Corporation Rule matching in the presence of languages with no types or as an adjunct to current analyses for security vulnerability analysis
CN106357635A (zh) * 2016-09-09 2017-01-25 浪潮软件集团有限公司 一种基于同源框架的漏洞对比分析方法
CN108182365A (zh) * 2017-12-18 2018-06-19 北京天融信网络安全技术有限公司 基于cpe的漏洞检测方法、设备和计算机可读存储介质
CN110543767A (zh) * 2019-08-10 2019-12-06 苏州浪潮智能科技有限公司 一种针对开源组件漏洞自动化监控方法及系统
CN110795346A (zh) * 2019-10-22 2020-02-14 苏州浪潮智能科技有限公司 产品监控方法、装置、设备及可读存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9667643B2 (en) * 2014-02-20 2017-05-30 Digital Defense Incorporated Apparatus, system, and method for correlating security vulnerabilities from multiple independent vulnerability assessment methods
CN108092962B (zh) * 2017-12-08 2020-11-06 奇安信科技集团股份有限公司 一种恶意url检测方法及装置
CN110222510A (zh) * 2019-06-13 2019-09-10 江苏亨通工控安全研究院有限公司 一种漏洞检测方法、装置及计算机系统
CN110806978A (zh) * 2019-10-31 2020-02-18 吉林亿联银行股份有限公司 一种第三方组件的缺陷管理方法及装置
CN110855678A (zh) * 2019-11-15 2020-02-28 杭州安恒信息技术股份有限公司 一种工控系统的漏洞检测方法、系统及相关装置
CN110941831B (zh) * 2019-11-22 2024-03-26 上海工业自动化仪表研究院有限公司 基于分片技术的漏洞匹配方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140237603A1 (en) * 2013-02-20 2014-08-21 International Business Machines Corporation Rule matching in the presence of languages with no types or as an adjunct to current analyses for security vulnerability analysis
CN106357635A (zh) * 2016-09-09 2017-01-25 浪潮软件集团有限公司 一种基于同源框架的漏洞对比分析方法
CN108182365A (zh) * 2017-12-18 2018-06-19 北京天融信网络安全技术有限公司 基于cpe的漏洞检测方法、设备和计算机可读存储介质
CN110543767A (zh) * 2019-08-10 2019-12-06 苏州浪潮智能科技有限公司 一种针对开源组件漏洞自动化监控方法及系统
CN110795346A (zh) * 2019-10-22 2020-02-14 苏州浪潮智能科技有限公司 产品监控方法、装置、设备及可读存储介质

Also Published As

Publication number Publication date
CN112868008A (zh) 2021-05-28
CN112868008B (zh) 2021-12-24

Similar Documents

Publication Publication Date Title
US9910743B2 (en) Method, system and device for validating repair files and repairing corrupt software
US9160762B2 (en) Verifying application security vulnerabilities
US9880832B2 (en) Software patch evaluator
US20120137138A1 (en) Package audit tool
US10068093B2 (en) Machine-checkable code-annotations for static application security testing
US8949812B2 (en) System and method for updating hard-coded dependencies
US20200133823A1 (en) Identifying known defects from graph representations of error messages
US11853422B2 (en) Detecting malicious components using commit histories
WO2021217421A1 (zh) Java开源组件的漏洞检测方法、装置及存储介质
Duarte et al. An empirical study of docker vulnerabilities and of static code analysis applicability
US9779014B2 (en) Resilient mock object creation for unit testing
Zhang et al. Open problems in fuzzing restful apis: A comparison of tools
CN111782526A (zh) 一种接口测试方法、装置、电子设备及存储介质
Chen et al. Bootstrapping automated testing for RESTful web services
WO2019200808A1 (zh) 测试案例推荐方法、电子装置及可读存储介质
CN111008017B (zh) 一种基于oclint的待提交文件预审方法及相关组件
CN112926060A (zh) 一种检测.net项目组件及其漏洞的方法和装置
Lu et al. A hybrid interface recovery method for Android kernels fuzzing
WO2022222626A1 (zh) 一种增量源码获取方法、装置、电子设备及存储介质
US11748246B2 (en) Crowd-sourced QA with trusted compute model
Pöll et al. Automating the Quantitative Analysis of Reproducibility for Build Artifacts derived from the Android Open Source Project
US20210303689A1 (en) Transport security in business applications
CN117112435B (zh) 一种漏洞联动检测结果的融合方法、存储介质及电子设备
Ramirez Empirical Study of Third-Party Library Detection in iOS and Android Applications
CN115408368A (zh) Cve漏洞安全数据库的生成方法、装置、介质及电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20933663

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20933663

Country of ref document: EP

Kind code of ref document: A1