Open source component vulnerability scanning method, device, equipment and storage medium

Abstract

The application discloses an open source component vulnerability scanning method and device, equipment and a storage medium, relates to the technical field of open source component vulnerability scanning, and is used for improving the accuracy of open source component vulnerability scanning. The method finds the running memory space corresponding to the target application through the target process identifier of the target application, obtains a class set of open source components involved from all classes contained in the running memory space, determines whether the version of each class belongs to a vulnerability version based on the class file of the class, and finally obtains the vulnerability scanning result of the target application based on the determination result corresponding to each class, that is, whether the target application uses an open source component with a vulnerability version. The method is used for scanning the open source component in the production environment, can avoid the problem of incomplete scanning caused by deploying a program package or static code, and directly detects the vulnerability of each class from the memory space, thereby avoiding the problem caused by the indirect dependence between open source components.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to the field of vulnerability detection technology, providing an open-source component vulnerability scanning method, apparatus, device, and storage medium. Background Technology

[0002] Currently, many applications incorporate open-source components, necessitating security monitoring of these components. Open-source component vulnerability scanning refers to scanning for vulnerabilities in the open-source components included in an application to prevent runtime malfunctions and ensure normal application operation. Current open-source component vulnerability scanning methods typically rely on the application's deployment package or the configuration files referenced by the components to confirm whether the application has introduced defective open-source components.

[0003] However, scanning based on deployment packages cannot guarantee that the deployment packages submitted by developers or the static code containing configuration files of open-source components are the same as those actually used in the application deployed in the production environment, thus potentially leading to missed scans. Furthermore, many applications currently use open-source components that reference other open-source components, a situation known as indirect dependency. For example, an application might reference open-source component A, which in turn references open-source component B. If component B has a vulnerability, failing to identify this indirect dependency can easily result in the defect going undetected.

[0004] Therefore, current vulnerability scanning methods all suffer from inaccurate scanning results. Summary of the Invention

[0005] This application provides an open-source component vulnerability scanning method, apparatus, device, and storage medium to improve the accuracy of open-source component vulnerability scanning.

[0006] On the one hand, an open-source component vulnerability scanning method is provided, the method comprising:

[0007] Based on the target process identifier corresponding to the target application, determine the runtime memory space corresponding to the runtime of the target application;

[0008] From all the classes contained in the runtime memory space, determine the class set corresponding to each of the at least one open source component contained in the target application, and each class set contains at least one class corresponding to an open source component;

[0009] For all classes in at least one obtained class set, determine whether the version of each class is a vulnerable version based on the class file corresponding to each class;

[0010] Based on the determination results corresponding to each of the obtained classes, vulnerability scanning results of the target application are generated, and the vulnerability scanning results indicate whether the target application uses open source components with vulnerable versions.

[0011] On the one hand, an open-source component vulnerability scanning device is provided, the device comprising:

[0012] The application lookup unit is used to determine the runtime memory space of the target application based on the target process identifier corresponding to the target application.

[0013] The class acquisition unit is used to determine, from all classes contained in the runtime memory space, the class set corresponding to each of the at least one open source component contained in the target application, and each class set contains at least one class corresponding to an open source component;

[0014] The class detection unit is used to determine whether the version of each class is a vulnerable version based on the class file corresponding to each class in the obtained at least one class set.

[0015] The result generation unit is used to generate vulnerability scanning results for the target application based on the determination results corresponding to each of the obtained classes. The vulnerability scanning results indicate whether the target application uses open-source components with vulnerable versions.

[0016] In one possible implementation, the class detection unit is specifically used for:

[0017] The hash value is sent to the vulnerability detection platform device, and the vulnerability detection platform device returns the determination result after determining whether the hash value is located in the preset hash library.

[0018] In one possible implementation, the application lookup unit is specifically used for:

[0019] The target Hook class included in the target library is invoked to detect the running memory space of the application. The target Hook class is used to hook the running memory space of the application.

[0020] When the target Hook class detects the runtime memory space of the candidate application, it determines whether the candidate process identifier of the candidate application is the same as the target process identifier;

[0021] If they are the same, then the running memory space of the candidate application is determined to be the running memory space of the target application.

[0022] In one possible implementation, the class acquisition unit is specifically used for:

[0023] By using the proxy component, all classes contained in the runtime memory space are traversed, and the following steps are performed:

[0024] For a given class, determine whether the class belongs to the classes contained in the open-source component;

[0025] If the class belongs to an open-source component, the open-source component to which the class belongs is determined based on the class name of the class, and the class is added to the class collection of the corresponding open-source component.

[0026] In one possible implementation, the class acquisition unit is specifically used for:

[0027] Call the class name retrieval method to obtain the class name corresponding to the given class;

[0028] Determine whether the class name includes the name of any open-source component in the open-source component library;

[0029] If it is included, then it is determined that the class belongs to the classes contained in the open source component.

[0030] In one possible implementation, the class acquisition unit is specifically used for:

[0031] Inject the component archive file of the proxy component into the running memory space; the component archive file contains the component data required for the proxy component to run.

[0032] The component archive file is run in the running memory space to run the agent component in the running memory space.

[0033] In one possible implementation, the class acquisition unit is specifically used for:

[0034] By using the proxy component, all classes contained in the runtime memory space are traversed, and the following steps are performed:

[0035] For a given class, determine whether the class belongs to the classes contained in the open-source component;

[0036] If the class belongs to an open-source component, the open-source component to which the class belongs is determined based on the class name of the class.

[0037] For each identified open-source component, obtain the classes of the historically vulnerable versions of each open-source component, and generate a set of classes corresponding to each open-source component based on the classes of the historically vulnerable versions of each open-source component.

[0038] On one hand, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.

[0039] On the one hand, a computer storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0040] On one hand, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the methods described above.

[0041] In this embodiment, the target application's runtime memory space is located by identifying the target process of the target application. From all classes contained in the runtime memory space, a set of open-source component classes involved in the target application is obtained. Based on the class file of each class, it is determined whether the version of that class belongs to a vulnerable version. Finally, based on the determination results corresponding to each class, the vulnerability scan result of the target application is obtained, i.e., whether the target application uses open-source components with vulnerable versions. This embodiment performs the open-source component scanning process in a production environment, thereby avoiding the problem of missed scans caused by deploying packages or static code. Furthermore, since vulnerability detection is performed directly on each class from the memory space, there is no need to consider the indirect dependencies between open-source components, thus improving the accuracy of the vulnerability scan results. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0043] Figure 1 This is a schematic diagram illustrating an application scenario provided in the embodiments of this application;

[0044] Figure 2 A flowchart illustrating the open-source component vulnerability scanning method provided in this application embodiment;

[0045] Figure 3 A schematic diagram illustrating the traversal process of the Agent component provided in this application embodiment;

[0046] Figure 4 A schematic diagram of the class collection of open-source components provided in the embodiments of this application;

[0047] Figure 5A schematic diagram illustrating the result of judging the open-source component provided in an embodiment of this application;

[0048] Figure 6 A flowchart illustrating the vulnerability scanning process provided in this application embodiment;

[0049] Figure 7 A schematic diagram of the structure of the open-source component vulnerability scanning device provided in the embodiments of this application;

[0050] Figure 8 This is a schematic diagram of the composition structure of a computer device provided in an embodiment of this application;

[0051] Figure 9 This is a schematic diagram of the composition structure of another computer device using an embodiment of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0053] To facilitate understanding of the technical solutions provided in the embodiments of this application, some key terms used in the embodiments of this application will be explained below:

[0054] Process Identification (PID): In the operating system, a PID is created for each program opened. A PID uniquely identifies a process. A PID is temporarily unique to a process. If the process terminates, the PID is reclaimed and may be assigned to another new process. However, as long as no other program is successfully running, the PID will continue to be assigned to the currently running program. If a program runs successfully, and then another program is run, the system will automatically assign a different PID.

[0055] Target application (APP): refers to an application that contains open-source components. It can be an application deployed on the client side or an application deployed on the server backend, such as an application that provides backend services for web pages or clients.

[0056] Hooking is a technique that extends the original execution flow of an application by adding extra processing logic. When a specific system or application event is hooked, the corresponding application that hooked the event will receive a notification from the system once the hooked event occurs, and the application can then respond to the event immediately.

[0057] Runtime memory: Used to store data and program instructions currently used by an application during runtime. Different programming languages ​​may have different runtime mechanisms, resulting in different forms of runtime memory. For example, Java (an object-oriented programming language) requires a Java Virtual Machine (JVM) to run. The JVM is a virtual computer that executes the bytecode of Java programs. It simulates various computer functions on a real computer. With the JVM, Java applications do not need to be recompiled to run on different platforms. The JVM shields platform-specific information, allowing Java applications to run on multiple platforms without modification by simply generating bytecode that runs on the JVM.

[0058] Javassist utility library: A class library that allows dynamic editing of Java bytecode, enabling direct modification or addition of bytecode in the JVM.

[0059] A class, in object-oriented programming, is a construct in an object-oriented computer programming language. It is a blueprint for creating objects, describing the common attributes and methods of the created objects. It is a cohesive package composed of specific metadata that describes some behavioral rules for objects, and these objects are called instances of that class.

[0060] Class files: In Java, code that the JVM can understand is called bytecode, which is a file with the .class extension. It is not processor-specific, but only targets the JVM virtual machine. Through bytecode, the Java language retains, to some extent, the portability of interpreted languages. Java achieves platform independence through the relationship between bytecode files and the JVM; it compiles once and runs on all platforms.

[0061] The design concept of the embodiments of this application will be briefly introduced below.

[0062] Currently, methods that rely on application deployment packages or component reference configuration files to confirm whether an application has introduced defective open-source components are prone to missing key information.

[0063] In view of this, this application provides a vulnerability scanning method based on open source components. In this method, the target process identifier of the target application is used to find the runtime memory space corresponding to the runtime of the target application. From all classes contained in the runtime memory space, the class set of open source components involved in the target application is obtained. Based on the class file of each class, it is determined whether the version of the class belongs to the vulnerable version. Finally, based on the determination results corresponding to each class, the vulnerability scanning result of the target application is obtained, that is, whether the target application uses open source components with vulnerable versions. In other words, this application embodiment performs the open source component scanning process in a production environment, thereby avoiding the problem of missed scans caused by deploying program packages or static code. Furthermore, since vulnerability detection is performed directly on each class from the memory space, there is no need to consider the indirect dependencies between open source components, thereby improving the accuracy of the vulnerability scanning results.

[0064] Furthermore, in this embodiment, class files of classes with vulnerable versions are collected, hash values ​​are generated based on these class files, and stored in a database. Since vulnerable versions are usually fixed by modifying class files or adding code to them, the hash values ​​of different versions of class files are unique, allowing for identification. In other words, during actual scanning, hash values ​​are also generated for the class files of the scanned open-source components and compared with the hash values ​​in the database. If a match is found, it indicates that the application is using a vulnerable version of the class; otherwise, the application is not using a vulnerable version of the class.

[0065] The following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application are applicable. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0066] The solution provided in this application can be applied to most open-source component vulnerability scanning scenarios, such as open-source component vulnerability scanning scenarios for Java applications. Figure 1 The diagram shown is an application scenario provided by an embodiment of this application. In this scenario, it may include a vulnerability scanning device 101, a vulnerability detection platform device 102, and a terminal device 103.

[0067] The vulnerability scanning device 101 can be any device that has the target application to be scanned installed and running. It can be a mobile phone, tablet computer (PAD), laptop computer, desktop computer, smart TV, smart in-vehicle device, or smart wearable device, and can also be a backend server providing background services. The vulnerability scanning device 101 can install and execute a security application that performs the vulnerability scanning process for open-source components. The security application involved in this embodiment can be a software client, or a webpage, mini-program, or other client; the specific type of client is not limited.

[0068] The vulnerability detection platform device 102 can be a platform server that provides backend services for the security application installed on the vulnerability scanning device 101. It can determine whether the class of an open source component is a vulnerable version, thereby assisting in implementing the steps of the open source component vulnerability scanning method provided in the embodiments of this application.

[0069] Terminal device 103 can be the device corresponding to the maintenance personnel of the target application, which can be a mobile phone, PAD, laptop, desktop computer, smart TV, smart vehicle device and smart wearable device, etc.

[0070] When both the vulnerability scanning device 101 and the vulnerability detection platform device 102 are servers, they can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, i.e., content delivery networks (CDN), as well as big data and artificial intelligence platforms, but are not limited to these.

[0071] The vulnerability scanning device 101 may include one or more processors 1011, a memory 1012, and an I / O interface 1013 for interacting with a terminal. Furthermore, the vulnerability scanning device 101 may be configured with a database 1014, which can be used to store hash values ​​of various vulnerability versions, etc. The memory 1012 of the vulnerability scanning device 101 may also store program instructions for the open-source component vulnerability scanning method provided in this application embodiment. When these program instructions are executed by the processor 1011, they can be used to implement the steps of the open-source component vulnerability scanning method provided in this application embodiment, thereby realizing the open-source component vulnerability scanning process.

[0072] For example, the security application in vulnerability scanning device 101 includes a hook component and an agent component. The hook can locate the running JVM of the target application using its PID (PID), and then inject the agent component to obtain the classes of open-source components contained in the JVM. For each class, a corresponding hash value is generated based on its class file and sent to vulnerability detection platform device 102. Vulnerability detection platform device 102 compares each hash value with its stored hash database to confirm whether each hash value matches the database. If a match is found, it indicates that the current version of the class corresponding to that hash value is a vulnerable version; otherwise, it is not. After obtaining the scan results for the target application, the scan results can be pushed to terminal device 103. Alternatively, when a vulnerable version of the target application is confirmed, a reminder message can be promptly pushed to terminal device 103 so that relevant maintenance personnel can perform timely remediation.

[0073] The vulnerability scanning device 101, the vulnerability detection platform device 102, and the terminal device 103 can communicate directly or indirectly through one or more networks 104. The network 104 can be a wired network or a wireless network. For example, the wireless network can be a mobile cellular network or a Wireless-Fidelity (WIFI) network. Of course, it can also be other possible networks, and this application embodiment does not limit this.

[0074] It should be noted that in this embodiment of the application, the number of vulnerability scanning devices 101 can be one or more. Similarly, the number of vulnerability detection platform devices 102 or terminal devices 103 can also be one or more. That is to say, there is no limit to the number of vulnerability scanning devices 101, vulnerability detection platform devices 102 or terminal devices 103.

[0075] Of course, the methods provided in the embodiments of this application are not limited to... Figure 1 The application scenarios shown can also be used in other possible scenarios, and this application embodiment does not impose any limitations. Figure 1 The functions that each device in the application scenario shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here.

[0076] It should be noted that the open-source component vulnerability scanning method in this application embodiment can be executed by the vulnerability scanning device 101 alone, or by the vulnerability scanning device 101 and the vulnerability detection platform device 102 together. For example, the vulnerability scanning device 101 determines the running memory space corresponding to the target application based on the target process identifier corresponding to the target application, and determines the class set corresponding to at least one open-source component contained in the target application from all classes contained in the running memory space. Each class set contains at least one class corresponding to an open-source component. Then, for all classes in the obtained at least one class set, it determines whether the version of the class is a vulnerable version based on the class file corresponding to each class. Based on the determination results corresponding to each class, the vulnerability scanning result of the target application is generated. The vulnerability scanning result indicates whether the target application uses an open-source component with a vulnerable version. That is to say, the process of determining whether a class is a vulnerable version is performed in the vulnerability scanning device 101. Alternatively, after the vulnerability scanning device 101 determines the class sets corresponding to each of the at least one open-source component contained in the target application, it triggers a detection request to the vulnerability detection platform device 102. The vulnerability detection platform device 102 then performs the process of determining whether the class is a vulnerable version, and finally, the vulnerability scanning device 101 outputs the final scan result. This application does not make specific limitations here; the following mainly uses the example of the vulnerability scanning device 101 and the vulnerability detection platform device 102 performing the same operation as an illustration.

[0077] The following describes the search result reordering method provided by the exemplary embodiments of this application in conjunction with the application scenarios described above and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this respect.

[0078] See Figure 2 The diagram shown is a flowchart of the open-source component vulnerability scanning method provided in this application embodiment. The specific implementation process of this method is as follows:

[0079] Step 201: Based on the target process identifier corresponding to the target application, determine the runtime memory space corresponding to the target application at runtime.

[0080] In this embodiment of the application, the target application refers to the application to be scanned for vulnerabilities in open-source components. It can be a single application or a collection of multiple applications.

[0081] In one possible implementation, when the vulnerability scanning device is a terminal device, a security application can be installed on the terminal device to monitor the vulnerabilities of various applications installed on the terminal device, and to promptly alert the user when a vulnerability is found.

[0082] For example, the vulnerability scanning process can be triggered by the user on the terminal device. For instance, after a user launches a security application, they select the target application to be scanned within that application and trigger the open-source component vulnerability scanning function, thus initiating the entire vulnerability scanning process. Alternatively, vulnerability scans can be performed periodically on currently running applications based on user settings.

[0083] In one possible implementation, when the vulnerability scanning application is a server, the server can be the backend server of the target application. This server hosts a backend application that provides backend services to the frontend of the target application. The target application to be scanned can then refer to this backend application. For example, the backend application could be a web server providing services to various pages of a banking app.

[0084] Similarly, vulnerability scanning for backend applications can be triggered by specified operations or performed periodically.

[0085] In this embodiment of the application, considering that the PID is a unique identifier for the application process at runtime, different applications will definitely have different PIDs at runtime, so the PID of the target application to be scanned can be used to find the running memory space of the target application. The running memory space is used to store the data required for the running of the target application, such as bytecode, class files or other running data, and then the open source components contained in the application can be obtained from the running memory space.

[0086] In one possible implementation, hooking operations on the target application's runtime memory space can be achieved by calling the Hook component.

[0087] Specifically, the target Hook class included in the target library can be called to detect the running memory space of the application. The target Hook class is used to hook the running memory space of the application. When the target Hook class detects the running memory space of a candidate application, it can determine whether the candidate process identifier of the candidate application is the same as the target process identifier. If they are the same, the running memory space of the candidate application is determined to be the running memory space of the target application.

[0088] Specifically, taking Java applications as an example, the target library can be the Hook JVM utility class contained in javassist. For example, VirtualMachine.attach(args[0]) can be called, where the PID of the target application can be assigned to args[0], so as to find the corresponding JVM of the target application.

[0089] If the target application's corresponding JVM can be successfully attached, the subsequent scanning process can continue. If the target application's corresponding JVM cannot be attached, the system can output "Access Denied" and disconnect from the target VM, or obtain information such as the exception name and reason.

[0090] Step 202: From all classes contained in the runtime memory space, determine the class set corresponding to each of the at least one open source component contained in the target application, and each class set contains at least one class corresponding to an open source component.

[0091] In this embodiment of the application, in order to avoid the problem of scanning results caused by the inconsistency between the application in the actual production environment and the deployment package, vulnerability scanning is performed directly in the production environment. That is, after finding the running memory space of the target application, the classes involved in the open source components used by the target application are found from the running memory space.

[0092] Specifically, when the target application is running, the data required for its operation is stored in its runtime memory space. Since the vulnerability scanning method in this application embodiment is based on the classes of open source components, it is possible to detect the classes contained in the runtime memory space to determine whether they are classes contained in the open source components.

[0093] In one possible implementation, in order to ensure the sequential execution of the above processes, this application embodiment performs the process by injecting an Agent component. That is, when the Hook component hooks into the runtime memory space of the target application, the Agent component is injected so that the Agent component can run in the runtime memory space.

[0094] Specifically, when hooking into the target application's runtime memory space, the component archive file of the Agent component is injected into that runtime memory space. The component archive file contains the component data required for the Agent component to run, and then the component archive file is run in the runtime memory space to run the Agent component.

[0095] Furthermore, a proxy component can be used to traverse all classes contained in the runtime memory space. Since the traversal process for each class is similar, this section will primarily use a single class as an example to illustrate the steps involved in the traversal. See also... Figure 3 The diagram shown illustrates the traversal process of the Agent component, taking one of the classes, A, as an example.

[0096] Step 2021: Determine whether class A is a class contained in the open-source component.

[0097] In one possible implementation, the name of the component to which class A belongs can be determined based on the dependency relationship of class A, and then it can be determined whether the component is an open source component. If it is, then class A is determined to belong to the class contained in the open source component.

[0098] Specifically, you can call the class name retrieval method to get the class name corresponding to class A, and then determine whether the class name includes the component name of any open source component in the open source component library. If it does, then class A belongs to the class contained in the open source component; if it does not, then class A does not belong to the class contained in the open source component.

[0099] For example, the class name retrieval method can be "getName()", as shown in the example below, which can retrieve the class name "com.alibaba.fastjson.JSONObject", from which "fastjson" can be extracted. Since it is the name of an open-source component, this class is a class contained in the open-source component.

[0100] Example: c.getName().equals("com.alibaba.fastjson.JSONObject")

[0101] In one possible implementation, the component to which class A belongs can be determined based on the calling relationship of class A, or the component to which class A belongs can be determined based on the description information in the class file of class A, and then it can be determined whether the component is an open source component, thereby determining whether class A is a class contained in an open source component.

[0102] Step 2022: If the result of step 2021 is yes, then class A belongs to the classes contained in the open source component.

[0103] Step 2023: Based on the class name of class A, determine the open source component to which class A belongs, and add class A to the class collection of the corresponding open source component.

[0104] If class A is a class contained in an open-source component, then relevant prompts will be output indicating that class A matches, i.e., it is a class contained in an open-source component.

[0105] Specifically, for classes that belong to open-source components, they can be categorized into the corresponding open-source components based on their open-source component names. See [link to relevant documentation]. Figure 4 As shown, a class collection can be created for each open-source component. Then, when a class belongs to that open-source component, it can be added to that class collection, thus achieving... Figure 4As shown, open source component 1 contains classes 11 to 1m, open source component 2 contains classes 21 to 2m, and open source component n contains classes n1 to nm. Of course, the number of classes contained in each open source component is not the same, that is, the value of m corresponding to each open source component can be different.

[0106] Step 2024: If the result of step 2021 is negative, that is, class A does not belong to the classes contained in the open source component, then the judgment process of class A ends and jumps to the judgment process of the next class.

[0107] In this embodiment of the application, information such as the name of open source components can be collected in advance to form an open source component library. When determining whether a component is an open source component, the judgment can be based on the open source component library, thereby improving the efficiency of the vulnerability scanning process.

[0108] In this embodiment of the application, after obtaining the class set of each open source component, the class set can be filtered. Since each class in each open source component may not necessarily have a historical vulnerable version, if it does not exist, there is no need to match it. Therefore, for each open source component, its historical vulnerable versions can also be collected, so that the class set of the final open source component only includes its historical vulnerable versions. Then the subsequent matching process will only be performed on these historical vulnerable versions.

[0109] Please continue reading below. Figure 2 .

[0110] Step 203: For all classes in the obtained at least one class set, determine whether the version of the class is a vulnerable version based on the class file corresponding to each class.

[0111] In this embodiment of the application, for all classes in the at least one class set obtained above, it is necessary to verify whether the class belongs to the vulnerable version. Since the verification process for each class is similar, class A will be used as an example for explanation here.

[0112] In one possible implementation, the version number of class A can be obtained and compared with the version number corresponding to the vulnerable version to confirm whether class A is a vulnerable version.

[0113] In one possible implementation, considering that vulnerability versions are typically patched by modifying class files or adding fix code to them, the hash values ​​of different versions of class files are unique, and the class file of class A is more easily accessible in the runtime memory space. Therefore, it is possible to identify whether a version is vulnerable based on the content of the class file of class A. In the runtime memory space, the class file of class A can be considered as the bytecode that implements the functionality of class A.

[0114] Specifically, you can directly compare the class file with the class file of the vulnerable version to determine whether class A is a vulnerable version.

[0115] Alternatively, to reduce the workload during comparison, the class files can be converted before comparison.

[0116] In one possible implementation, for class A, after obtaining the class file corresponding to class A, a hash operation is performed on the class file of class A to obtain the corresponding hash value, and then it is determined whether the hash value is located in the preset hash library to obtain the corresponding determination result.

[0117] If the result indicates that the hash value is in the hash database, then version A is determined to be a vulnerable version; conversely, if the result indicates that the hash value is not in the hash database, then version A is determined to be a non-vulnerable version.

[0118] Considering that searching in the hash library may consume a certain amount of computing power, increase the processing burden on the processor, and potentially affect the normal operation of the target application, after obtaining various hash values, the hash values ​​can also be sent to the vulnerability detection platform device. This allows the vulnerability detection platform device to compare the hash values ​​with the hash values ​​corresponding to the vulnerability versions and return the final determination result to the vulnerability scanning device.

[0119] In this embodiment, each hash value in the hash library is generated based on the class file corresponding to the vulnerable version of the class. To improve the efficiency of vulnerability scanning, the class files corresponding to each vulnerable version of the class can be collected in advance to generate the corresponding hash values ​​and stored in the hash library for comparison when needed later.

[0120] In this embodiment of the application, after adding each class to the corresponding class set, the comparison can be performed by component to reduce the amount of computation during the comparison and thus improve the efficiency of vulnerability scanning.

[0121] Specifically, the generated hash library can also manage each hash value separately according to different open-source components. That is, an open-source component can create a collection, which stores the hash values ​​corresponding to the vulnerable versions of classes involved in that open-source component. Then, after obtaining the above-mentioned class collection, for a class in the class collection, a comparison and matching can be performed in the hash value collection corresponding to the relevant open-source component. If the hash value collection does not contain the hash value of the class, it is considered that the class does not have a vulnerable version. Similarly, if the hash value collection contains the hash value of the class, it is considered that the class is a vulnerable version.

[0122] Step 204: Based on the determination results corresponding to each class, generate the vulnerability scan results of the target application. The vulnerability scan results indicate whether the target application uses open source components with vulnerable versions.

[0123] In this embodiment of the application, the final vulnerability scanning result of the target application can be obtained by comprehensively statistically analyzing the determination results of each category.

[0124] In one possible implementation, for each open-source component, it is confirmed whether each of its classes uses the vulnerable version. If so, it can be confirmed that the open-source component uses the vulnerable version.

[0125] The above class set only includes classes with historically existing vulnerable versions. If only one class has a historical vulnerability, then as long as that class is ultimately confirmed as a vulnerable version, the corresponding open-source component is also a vulnerable version. However, if multiple classes have historical vulnerabilities, it is necessary to consider whether all of these classes are vulnerable versions. If so, then it can be confirmed that the open-source component uses a vulnerable version. See also... Figure 5 As shown, if the classes of open source component 1 that have historical vulnerabilities are classes 11 to 1m, then if classes 11 to 1m are all vulnerable versions, then open source component 1 is a vulnerable version.

[0126] Furthermore, considering that different classes may have vulnerabilities in the same version, matching can be performed separately according to the different versions of the vulnerability. That is, for an open source component, the classes with vulnerabilities in each version can be counted, and then the comparison can be performed according to the version.

[0127] For example, if version 1.1 of an open-source component has a vulnerability in class A, and version 1.2 of the same component has a vulnerability in class B, then when making a comparison, the hash values ​​of classes A and B of the open-source component can be collected and compared with the hash values ​​of versions 1.1 and 1.2 respectively. If they match version 1.2, it indicates that the open-source component is using the vulnerable version 1.2; if they match version 1.1, it indicates that the open-source component is using the vulnerable version 1.1; and if they do not match either, it indicates that the open-source component is using the normal version, i.e., the version without vulnerabilities.

[0128] Specifically, the hash values ​​of each class in the class collection of an open-source component can be arranged in a certain array format, and then the array can be matched with the hash value of the component in the hash library. If a match is found, it indicates that the open-source component is a vulnerable version.

[0129] In one possible implementation, if the detection of the aforementioned vulnerability version is performed by a vulnerability detection platform device, the vulnerability detection platform device can store the vulnerability scan results in a database and return the vulnerability scan results to the vulnerability scanning device, or return the vulnerability scan results to the vulnerability scanning device when a class of vulnerability versions exists.

[0130] In one possible implementation, if the detection of the aforementioned vulnerability version is performed by a vulnerability scanning device, after obtaining the vulnerability scanning results, in addition to storing the vulnerability scanning results locally and outputting them to relevant personnel, the vulnerability scanning device can also upload the vulnerability scanning results to a vulnerability detection platform device for storage on the vulnerability detection platform device.

[0131] Furthermore, after obtaining the scan results for the target application, the scan results can be pushed to the terminal device. Alternatively, when a vulnerable version of the target application is confirmed, a timely alert can be pushed to the terminal device so that the relevant maintenance personnel can perform timely remediation. Maintenance personnel can also view the corresponding vulnerability scan results by checking the scan logs or logging into the vulnerability detection platform.

[0132] The technical solution of this application embodiment will now be described using a specific example. See also... Figure 6 The diagram illustrates a vulnerability scanning process using a Java application as an example. In this scenario, a client-side tool for vulnerability scanning can be run on a production server to examine the JVM memory space of the application. This tool can determine the version of the open-source component used by the application by calculating a hash based on the bytecode of the open-source component's class.

[0133] Step 601: Collect the hash values ​​of the classes involved in the vulnerable versions of the open-source component, and build a hash database of the classes related to the vulnerable versions of the open-source component.

[0134] Vulnerabilities in open-source components are often fixed by adding fix code to one or several classes. Therefore, the bytecode of the vulnerable version of the class and the fixed version of the class are different. For an open-source component with a vulnerability, the class that caused the vulnerability is unique. The bytecode of these vulnerable classes, i.e., the class file, is hashed to obtain a hash value, which is then stored as the characteristic value of the vulnerability version.

[0135] See Table 1 for an example of the specific structure of a hash database for a vulnerability version-related class of an open-source component.

[0136]

[0137] Table 1

[0138] CVE-2019-1181 represents the vulnerability's ID code. When a component involves multiple vulnerability classes, they can be organized in the form of an array. Correspondingly, the hash values ​​of its vulnerability-related classes can also be organized in the form of an array with the same order as the aforementioned array.

[0139] Step 602: Use the HOOK utility class in Javassist to hook the corresponding JVM based on the PID to find the JVM of the running Java application.

[0140] Specifically, Java development tools can provide the functionality to gain access to the JVM of a Java application in memory, allowing manipulation of the JVM—essentially code injection—to dynamically modify or collect the code of a running Java application. Javassist is a component that provides this functionality.

[0141] Step 603: By injecting data, search for the classes in the JVM of the Java application to determine the open-source components used by the Java application.

[0142] Specifically, the Agent component's corresponding JAR file is run, which then obtains the JVM of the target Java application. The system then iterates through all the classes in the JVM and identifies the open-source components used by each class based on its name.

[0143] As shown in the example in Table 1, you can determine whether a class name contains "fastjson" to see if it uses the fastjson component.

[0144] Step 604: After determining the open-source components used by the Java application, perform hash calculations on the classes with vulnerabilities in each version of the component to obtain the hash value of their bytecode.

[0145] Specifically, after determining the type of open-source component, the hash value of the relevant vulnerability class is calculated. For example, the hash calculation method that can be used is SHA-256. Of course, other calculation methods can also be used, and this application embodiment does not limit this.

[0146] Step 605: Send the hash values ​​of these classes in the JVM of the Java application to the vulnerability detection platform for comparison with the hash values ​​of the classes corresponding to the vulnerability versions on the vulnerability detection platform.

[0147] Since the open-source component vulnerability hash library has a large amount of data, the hash library and comparison work can be placed on a dedicated server. The agent only needs to send the hash value and class name to the vulnerability detection platform.

[0148] Step 606: Compare the hash values ​​of these classes in the JVM of the Java application with the hash values ​​of the vulnerable versions stored locally.

[0149] Alternatively, you can use the hash library included in the agent for local comparison, which avoids interaction with the vulnerability detection platform and enables local detection, making it more convenient.

[0150] Step 607: If the hash values ​​of all vulnerability-related classes match the hash value of the vulnerability version, then the Java application is using an open-source component with a vulnerable version.

[0151] See the example below. "c509d8685c9351cebd4344b38d5e30473f3159a93bd8311988bfa06437d062127" is the hash value of the class collection of the vulnerable version of the fastjson component (i.e., the hash value calculated after arranging the bytecode of at least one class in a certain array format). When the hash value of the class collection involved in the currently used fastjson matches this, the result of fastjson being the vulnerable version is output. That is, in the example below, "FindCVE-2019-1181!" means that the output of fastjson is the vulnerable version "CVE-2019-1181".

[0152] if (new BigInteger(1,

[0153] md.digest()).toString(16)).equals("c509d8685c9351cebd4344b38d5e30473f3159a93bd831198bfa06437d062127")){

[0154] System.out.println("Find CVE-2019-1181!")

[0155] Step 608: The Agent component of the vulnerability detection platform can output the vulnerability scan results to the local application server.

[0156] Step 609: Upload the vulnerability scan results to the vulnerability detection platform using the code in the Agent component on the production server.

[0157] Testers can then view the vulnerability scan results by checking the logs recorded by the Agent component on the server or by logging into the vulnerability detection platform.

[0158] In summary, this application embodiment uses Hook technology to process the open-source component classes of the JVM of Java applications in the production environment to determine whether they have vulnerabilities. Compared with traditional open-source component vulnerability scanning technology, scanning directly in the production environment can more accurately discover vulnerabilities, avoid the problem of missed detections caused by version inconsistencies, and because it directly searches for vulnerable classes in the JVM, it can exclude many open-source component references that cannot be found in static vulnerability scanning, thus effectively solving the problem of indirect dependencies.

[0159] Please see Figure 7 Based on the same inventive concept, this application also provides an open-source component vulnerability scanning device 70, which includes:

[0160] The application lookup unit 701 is used to determine the runtime memory space of the target application based on the target process identifier corresponding to the target application.

[0161] The class acquisition unit 702 is used to determine, from all classes contained in the runtime memory space, the class sets corresponding to at least one open source component contained in the target application, and each class set contains at least one class corresponding to an open source component;

[0162] The class detection unit 703 is used to determine whether the version of a class is a vulnerable version based on the class file corresponding to each class in the obtained at least one class set.

[0163] The result generation unit 704 is used to generate vulnerability scanning results for the target application based on the determination results corresponding to each class. The vulnerability scanning results indicate whether the target application uses open source components with vulnerable versions.

[0164] In one possible implementation, the class detection unit 703 is specifically used for:

[0165] For each class, perform the following steps:

[0166] For a given class, perform a hash operation on the class file corresponding to that class to obtain the corresponding hash value;

[0167] Determine whether the hash value is located in the preset hash library and obtain the corresponding determination result; wherein, each hash value contained in the hash library is generated based on the class file corresponding to the class of the vulnerability version;

[0168] If the result indicates that the hash value is in the hash library, then the version of a class is identified as the vulnerable version.

[0169] If the result indicates that the hash value is not in the hash library, then the version of a class is determined to be a non-vulnerable version.

[0170] In one possible implementation, the class detection unit 703 is specifically used for:

[0171] The hash value is sent to the vulnerability detection platform device, and the vulnerability detection platform device returns a confirmation result after determining whether the hash value is in the preset hash library.

[0172] In one possible implementation, the lookup unit 701 is specifically used for:

[0173] The target Hook class included in the target library is called to detect the running memory space of the application. The target Hook class is used to hook the running memory space of the application.

[0174] When the target Hook class detects the runtime memory space of the candidate application, it determines whether the candidate process identifier of the candidate application is the same as the target process identifier.

[0175] If they are the same, then the runtime memory space of the candidate application is determined to be the runtime memory space of the target application.

[0176] In one possible implementation, the class acquisition unit 702 is specifically used for:

[0177] By using the proxy component, we can iterate through all classes contained in the runtime memory space and perform the following steps:

[0178] For a given class, determine whether the class belongs to the classes contained in the open-source component;

[0179] If the class belongs to an open-source component, the open-source component to which the class belongs is determined based on the class name, and the class is added to the class collection of the corresponding open-source component.

[0180] In one possible implementation, the class acquisition unit 702 is specifically used for:

[0181] Call the class name retrieval method to get the class name corresponding to a class;

[0182] Determine whether the class name includes the name of any open-source component from the open-source component library;

[0183] If included, then a class is determined to belong to the classes contained in the open-source component.

[0184] In one possible implementation, the class acquisition unit 702 is specifically used for:

[0185] Inject the proxy component's component archive file into the runtime memory space. The component archive file contains the component data required for the proxy component to run.

[0186] Run the component archive file in the running memory space to run the agent component in the running memory space.

[0187] In one possible implementation, the class acquisition unit 702 is specifically used for:

[0188] By using the proxy component, we can iterate through all classes contained in the runtime memory space and perform the following steps:

[0189] For a given class, determine whether the class belongs to the classes contained in the open-source component;

[0190] If the class belongs to an open-source component, the open-source component to which the class belongs is determined based on the class name of the class.

[0191] For each identified open-source component, obtain the classes of the historically vulnerable versions of each open-source component, and generate a set of classes corresponding to each open-source component based on the classes of the historically vulnerable versions of each open-source component.

[0192] The aforementioned device can use Hook technology to process the open-source component classes of the JVM in production Java applications to determine whether they have vulnerabilities. Compared with traditional open-source component vulnerability scanning technology, scanning directly in the production environment can more accurately discover vulnerabilities, avoid the problem of missed detections caused by version inconsistencies, and because it searches for vulnerable classes directly in the JVM, it can exclude many open-source component references that cannot be found in static vulnerability scanning, thus effectively solving the problem of indirect dependencies.

[0193] This device can be used to execute the methods shown in the various embodiments of this application. Therefore, the functions that each functional module of this device can achieve can be referred to the description of the foregoing embodiments, and will not be repeated here.

[0194] Please see Figure 8 Based on the same technical concept, embodiments of this application also provide a computer device. In one embodiment, the computer device can be... Figure 1 The vulnerability scanning device shown can be, for example, a server, or a computer device such as... Figure 8 As shown, it includes a memory 801, a communication module 803, and one or more processors 802.

[0195] The memory 801 is used to store computer programs executed by the processor 802. The memory 801 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0196] Memory 801 may be volatile memory, such as random-access memory (RAM); memory 801 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 801 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 801 may be a combination of the above-described memories.

[0197] Processor 802 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 802 is used to implement the above-mentioned open-source component vulnerability scanning method when calling computer programs stored in memory 801.

[0198] The communication module 803 is used to communicate with terminal devices and other servers.

[0199] This application embodiment does not limit the specific connection medium between the memory 801, communication module 803, and processor 802 described above. This application embodiment... Figure 8 The memory 801 and the processor 802 are connected via a bus 804, and the bus 804 is in Figure 8 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. The 804 bus can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 8 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0200] The memory 801 stores a computer storage medium, which stores computer-executable instructions. The computer-executable instructions are used to implement the open-source component vulnerability scanning method of the embodiments of this application, and the processor 802 is used to execute the open-source component vulnerability scanning methods of the above embodiments.

[0201] In another embodiment, the computer device can also be a terminal device; that is, the vulnerability scanning device can be implemented through a terminal device. In this embodiment, the structure of the computer device can be as follows: Figure 9 As shown, it includes components such as: communication component 910, memory 920, display unit 930, camera 940, sensor 950, audio circuit 960, Bluetooth module 970, and processor 980.

[0202] The communication component 910 is used to communicate with the server. In some embodiments, it may include a Circuit-Based Wireless Fidelity (WiFi) module. WiFi is a short-range wireless transmission technology, and computer devices can use WiFi modules to help users send and receive information.

[0203] The memory 920 can be used to store software programs and data. The processor 980 executes various functions of the terminal device and data processing by running the software programs or data stored in the memory 920. The memory 920 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. The memory 920 stores an operating system that enables the terminal device to run. In this application, the memory 920 can store the operating system and various applications, and may also store code that executes the open-source component vulnerability scanning method of the embodiments of this application.

[0204] The display unit 930 can also be used to display information input by the user or information provided to the user, as well as various menus of the terminal device, forming a graphical user interface (GUI). Specifically, the display unit 930 may include a display screen 932 disposed on the front of the terminal device. The display screen 932 may be configured as a liquid crystal display, a light-emitting diode, or the like. The display unit 930 can be used to display the vulnerability scanning results page in the embodiments of this application.

[0205] The display unit 930 can also be used to receive input digital or character information and generate signal inputs related to user settings and function control of the terminal device. Specifically, the display unit 930 may include a touch screen 931 disposed on the front of the terminal device, which can collect touch operations of the user on or near it, such as clicking a button, dragging a scroll box, etc.

[0206] The touchscreen 931 can be placed on top of the display screen 932, or the touchscreen 931 and the display screen 932 can be integrated to realize the input and output functions of the terminal device. After integration, it can be referred to as a touch display screen. In this application, the display unit 930 can display the application program and the corresponding operation steps.

[0207] Camera 940 can be used to capture still images, which users can then post comments on via an application. There can be one or multiple cameras 940. An object is projected onto a photosensitive element through a lens, generating an optical image. This photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then transmitted to a processor 980 to be converted into a digital image signal.

[0208] The terminal device may also include at least one sensor 950, such as an accelerometer 951, a proximity sensor 952, a fingerprint sensor 953, and a temperature sensor 954. The terminal device may also be equipped with other sensors such as a gyroscope, barometer, hygrometer, thermometer, infrared sensor, light sensor, and motion sensor.

[0209] Audio circuitry 960, speaker 961, and microphone 962 provide an audio interface between the user and the terminal device. Audio circuitry 960 converts received audio data into electrical signals, which are then transmitted to speaker 961, where they are converted into sound signals for output. The terminal device can also be equipped with volume buttons for adjusting the volume of the sound signal. Conversely, microphone 962 converts collected sound signals into electrical signals, which are then received by audio circuitry 960, converted back into audio data, and output to communication component 910 for transmission to, for example, another terminal device, or to memory 920 for further processing.

[0210] The Bluetooth module 970 is used to interact with other Bluetooth devices that also have a Bluetooth module via the Bluetooth protocol. For example, a terminal device can establish a Bluetooth connection with a wearable computer device (such as a smartwatch) that also has a Bluetooth module through the Bluetooth module 970, thereby exchanging data.

[0211] The processor 980 is the control center of the terminal device, connecting various parts of the terminal through various interfaces and lines. It executes software programs stored in the memory 920 and calls data stored in the memory 920 to perform various functions and process data. In some embodiments, the processor 980 may include one or more processing units; the processor 980 may also integrate an application processor and a baseband processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the baseband processor mainly handles wireless communication. It is understood that the baseband processor may not be integrated into the processor 980. In this application, the processor 980 can run the operating system, applications, user interface display and touch response, as well as the open-source component vulnerability scanning method of this application embodiment. Furthermore, the processor 980 is coupled to the display unit 930.

[0212] Based on the same inventive concept, embodiments of this application also provide a storage medium storing a computer program that, when run on a computer, causes the computer to perform the steps in the open-source component vulnerability scanning method according to various exemplary embodiments of this application described above.

[0213] In some possible implementations, various aspects of the open-source component vulnerability scanning method provided in this application can also be implemented in the form of a computer program product, which includes a computer program that, when run on a computer device, causes the computer device to perform the steps in the open-source component vulnerability scanning method according to various exemplary embodiments of this application described above. For example, the computer device can perform the steps of the various embodiments.

[0214] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0215] The program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on a computer device. However, the program product of this application is not limited thereto. In this application, the readable storage medium may be any tangible medium that contains or stores a program, and the computer program included therein may be used by or in conjunction with a command execution system, apparatus, or device.

[0216] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0217] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0218] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages.

[0219] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0220] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0221] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0222] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0223] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for scanning vulnerabilities in open-source components, characterized in that, The method includes: Based on the target process identifier corresponding to the target application, determine the runtime memory space corresponding to the runtime of the target application; The proxy component iterates through all classes contained in the runtime memory space to determine the class set corresponding to each of the at least one open-source component contained in the target application, and each class set contains at least one class corresponding to an open-source component. For all classes in at least one obtained class set, determine whether the version of each class is a vulnerable version based on the class file corresponding to each class; Based on the determination results corresponding to each of the obtained classes, vulnerability scanning results of the target application are generated, and the vulnerability scanning results indicate whether the target application uses open source components with vulnerable versions. When traversing all classes contained in the runtime memory space, the following steps are performed: For a given class, determine whether the class belongs to a class contained in an open-source component; if it does, determine the open-source component to which the class belongs based on its class name, and add the class to the class collection of the corresponding open-source component; or, For a given class, determine whether the class belongs to a class contained in an open-source component; if it does, determine the open-source component to which the class belongs based on the class name; for each determined open-source component, obtain the classes of the historically vulnerable versions of each open-source component, and generate a set of classes corresponding to each open-source component based on the classes of the historically vulnerable versions of each open-source component.

2. The method as described in claim 1, characterized in that, For all classes in at least one obtained class set, determine whether the version of each class is a vulnerable version based on the class file corresponding to each class, including: For each of the aforementioned classes, the following steps shall be performed respectively: For a given class, perform a hash operation on the class file corresponding to that class to obtain the corresponding hash value; Determine whether the hash value is located in a preset hash library and obtain the corresponding determination result; wherein, each hash value contained in the hash library is generated based on the class file corresponding to the class of the vulnerability version; If the determination result indicates that the hash value is located in the hash library, then the version of the class is determined to be a vulnerable version; If the determination result indicates that the hash value is not in the hash library, then the version of the class is determined to be a non-vulnerable version.

3. The method as described in claim 2, characterized in that, The step of determining whether the hash value is located in a preset hash database and obtaining the corresponding determination result includes: The hash value is sent to the vulnerability detection platform device, and the vulnerability detection platform device returns the determination result after determining whether the hash value is located in the preset hash library.

4. The method according to any one of claims 1 to 3, characterized in that, Based on the target process identifier corresponding to the target application, determine the runtime memory space corresponding to the runtime of the target application, including: The target Hook class included in the target library is invoked to detect the running memory space of the application. The target Hook class is used to hook the running memory space of the application. When the target Hook class detects the runtime memory space of the candidate application, it determines whether the candidate process identifier of the candidate application is the same as the target process identifier; If they are the same, then the running memory space of the candidate application is determined to be the running memory space of the target application.

5. The method as described in claim 1, characterized in that, Determining whether a class belongs to the classes contained in an open-source component includes: Call the class name retrieval method to obtain the class name corresponding to the given class; Determine whether the class name includes the name of any open-source component in the open-source component library; If it is included, then it is determined that the class belongs to the classes contained in the open source component.

6. The method as described in claim 1, characterized in that, Before traversing all classes contained in the runtime memory space via the proxy component, the method further includes: Inject the component archive file of the proxy component into the running memory space; the component archive file contains the component data required for the proxy component to run. The component archive file is run in the running memory space to run the agent component in the running memory space.

7. An open-source component vulnerability scanning device, characterized in that, The device includes: The application lookup unit is used to determine the runtime memory space of the target application based on the target process identifier corresponding to the target application. The class acquisition unit is used to traverse all classes contained in the runtime memory space through the proxy component to determine the class set corresponding to each of the at least one open source component contained in the target application, and each class set contains at least one class corresponding to an open source component; The class detection unit is used to determine whether the version of each class is a vulnerable version based on the class file corresponding to each class in the obtained at least one class set. The result generation unit is used to generate vulnerability scanning results for the target application based on the determination results corresponding to each of the obtained classes. The vulnerability scanning results indicate whether the target application uses open-source components with vulnerable versions. When the class acquisition unit traverses all classes contained in the runtime memory space, it performs the following steps: For a given class, determine whether the class belongs to a class contained in an open-source component; if it does, determine the open-source component to which the class belongs based on its class name, and add the class to the class collection of the corresponding open-source component; or, For a given class, determine whether the class belongs to a class contained in an open-source component; if it does, determine the open-source component to which the class belongs based on the class name; for each determined open-source component, obtain the classes of the historically vulnerable versions of each open-source component, and generate a set of classes corresponding to each open-source component based on the classes of the historically vulnerable versions of each open-source component.

8. The apparatus as claimed in claim 7, characterized in that, The detection unit is specifically used for: For each of the aforementioned classes, the following steps shall be performed respectively: For a given class, perform a hash operation on the class file corresponding to that class to obtain the corresponding hash value; Determine whether the hash value is located in a preset hash library and obtain the corresponding determination result; wherein, each hash value contained in the hash library is generated based on the class file corresponding to the class of the vulnerability version; If the determination result indicates that the hash value is located in the hash library, then the version of the class is determined to be a vulnerable version; If the determination result indicates that the hash value is not in the hash library, then the version of the class is determined to be a non-vulnerable version.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

11. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

Images