Vulnerability detection method and device, equipment and storage medium
By analyzing the external listening ports and components of Java applications, and combining this with a security vulnerability list, the problem of detecting deserialization vulnerabilities in third-party components of Java applications was solved. This enabled the detection of security risks in runtime and the marking of risky components, thereby improving the security of the system.
Patent Information
- Application Number
- CN202511871896.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-11
- Publication Date
- 2026-02-06
AI Technical Summary
Existing technologies are insufficient to effectively detect and resolve deserialization vulnerabilities in third-party components of Java applications during the application development phase, leading to runtime security risks.
By analyzing all external listening ports of the system, the set of processes providing services to the outside world is identified. Files and instructions of these processes are parsed to extract component information. Risk analysis is then conducted in conjunction with a security vulnerability list to mark risky components.
It enables precise security risk detection of running Java applications, allowing for timely discovery and limitation of potential security risks, thereby improving system security.
Smart Images
Figure CN121479792A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer network security, and in particular to a vulnerability detection method and device, equipment and a storage medium. BACKGROUND
[0002] Java is a popular program development language, and Java deserialization is a process of restoring serialized byte streams into original Java objects, which is the inverse operation of serialization. Java deserialization problems have become a core security problem of Java application programs, and deserialization problems not only occur in the application itself, but also occur in third-party components on which the software depends, such as: various components on which Java applications depend have exploitable vulnerabilities. Whether it is a distributed application built with Java language, a data analysis and artificial intelligence platform developed with Python language, or a bottom-layer driver and embedded program written in C language, all highly depend on components of third-party libraries.
[0003] Third-party libraries contain a large number of complex components, and the method call logic of these components can be spliced into a vulnerability exploit chain (gadget) to become a key carrier of deserialization attacks. Attackers trigger the preset method call chain in the third-party library by maliciously constructing byte streams, and finally execute malicious code. After the target application introduces third-party components, it may unknowingly inherit security risks.
[0004] Currently, software component analysis is usually used to solve security risks during the application development stage. However, not all developers will perform software component analysis during the development stage, resulting in risks during the runtime of the target application.
[0005] Therefore, how to realize security risk detection of the target application in a running state is a problem to be solved by those skilled in the art. SUMMARY
[0006] The purpose of the embodiments of the present application is to provide a vulnerability detection method, device, equipment and storage medium, which can realize security risk detection of the target application in a running state.
[0007] The present application provides a vulnerability detection method, comprising:
[0008] According to all external listening ports of the system, a second target process set providing services externally is determined from a first target process set; wherein the first target process set comprises a plurality of first target processes in a running state;
[0009] The second target process set is parsed to determine a component to be checked and component information of the component to be checked;
[0010] Risk analysis is performed according to the component information of the component to be checked to determine a risk component.
[0011] On the one hand, the second target process set is parsed to determine the components to be investigated and their component information, including:
[0012] The second target process set is parsed to determine the component information that matches the preset list from the second target process set.
[0013] On the one hand, the second target process set is parsed to determine the component information that matches the preset list from the second target process set, including:
[0014] Files are parsed for each second target process in the second target process set, and the target component name and component version that match the security vulnerability list in the first parsing result are stored;
[0015] And / or, perform instruction parsing on each second target process in the second target process set, and store the target component name that matches the security vulnerability list in the second parsing result and the component version corresponding to the target component name.
[0016] On the one hand, file parsing is performed on each second target process in the second target process set, and the target component names and component versions that match the security vulnerability list in the first parsing result are stored, including:
[0017] Extract the deployment file from the second target process; wherein, the second target process is any one of the second target processes contained in the set of second target processes;
[0018] The deployment files are decompressed to locate the metadata information directory;
[0019] Parse the configuration files in the metadata information directory to determine the target component name and component version;
[0020] If the target component name and version match the security vulnerability list, record the target component name and version.
[0021] On the one hand, the instructions of each second target process in the second target process set are parsed, and the target component names that match the security vulnerability list in the second parsing results, as well as the component versions corresponding to the target component names, are stored, including:
[0022] Traverse the set of second target processes to determine the execution instructions corresponding to each second target process;
[0023] Parse the target execution instruction to determine the dependent library fields; where the target execution instruction is any one of all execution instructions.
[0024] Determine whether the parameter following the dependency library field in the second target process contains a target component name that matches the security vulnerability list;
[0025] If the parameter following the dependency library field in the second target process contains the name of a target component that matches the security vulnerability list, the component version is extracted from the target execution instruction using regular expression extraction, and the target component name and component version are recorded.
[0026] On the one hand, based on all external listening ports of the system, the second set of target processes providing external services is determined from the first set of target processes, including:
[0027] Get all external listening ports of the system and the processes corresponding to all external listening ports;
[0028] Match all processes corresponding to external listening ports with each of the first target processes in the first target process set to determine the second target process set that provides services to the outside world.
[0029] On the one hand, after conducting risk analysis based on the component information of the components to be investigated to identify the risky components, it also includes:
[0030] Mark the second target process corresponding to the risk component as a risk process.
[0031] This application embodiment also provides a vulnerability detection device, including a determination unit, a parsing unit, and an analysis unit;
[0032] The determining unit is used to determine, based on all external listening ports of the system, a second target process set that provides services to the outside world from the first target process set; wherein, the first target process set includes multiple first target processes that are in a running state;
[0033] The parsing unit is used to parse the second target process set to determine the component to be investigated and its component information.
[0034] The analysis unit is used to perform risk analysis based on the component information of the component to be investigated, so as to identify the risky components.
[0035] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described vulnerability detection methods when executing the computer program.
[0036] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described vulnerability detection methods.
[0037] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described vulnerability detection methods.
[0038] As can be seen from the above technical solution, considering that target applications with open ports and in operation have a higher probability of generating risks, a second set of target processes providing services can be determined from the first set of target processes based on all external listening ports of the system. The first set of target processes contains multiple running first target processes. To analyze whether the third-party components relied upon by the second target processes pose risks, the second set of target processes can be parsed to identify the components to be investigated and their component information; the components to be investigated can be components that frequently exhibit security vulnerabilities. After identifying the components to be investigated and their component information, further risk analysis can be performed on the component information to identify risky components. In this technical solution, by filtering target processes that are running and have open ports, target applications that can actually generate risks can be accurately located. By parsing the second set of target processes, component information that frequently exhibits security vulnerabilities can be extracted, and then risk analysis can be performed on the component information to more accurately determine the potential security risks of running target processes, thus achieving security risk detection for running target applications. Attached Figure Description
[0039] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0040] Figure 1 A flowchart illustrating a vulnerability detection method provided in an embodiment of this application;
[0041] Figure 2 A flowchart illustrating a method for parsing files of a second target process, provided in an embodiment of this application;
[0042] Figure 3 A flowchart illustrating a method for parsing instructions of a second target process, provided in an embodiment of this application;
[0043] Figure 4 This is a schematic diagram of the structure of a vulnerability detection device provided in an embodiment of this application. Detailed Implementation
[0044] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0045] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.
[0046] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0047] Next, a vulnerability detection method provided by the embodiments of this application will be described in detail. Figure 1 A flowchart of a vulnerability detection method provided in this application embodiment, the method including:
[0048] S101: Based on all external listening ports of the system, determine the second target process set that provides services to the outside world from the first target process set.
[0049] The vulnerability detection method provided in this application can detect vulnerabilities in target applications, which can be of various types, such as Java applications, Python applications, and C language applications. In this embodiment, a Java application will be used as an example for further explanation.
[0050] To perform security analysis on runtime Java applications, the running Java processes can be identified from all system processes. For ease of description, the running Java processes can be referred to as the first target processes, and the set of all first target processes is called the first target process set.
[0051] In this embodiment of the application, the Java process in the running state can be determined by means of query tools, query commands to find target fields, traversing running processes, etc.
[0052] Taking the query command to find the target field as an example, the first set of Java processes in the running state, i.e., the first target process set, can be determined based on the field information carried by the process command line.
[0053] In practice, an inspection program can be used to query all processes in the system; based on the field information carried by the process command line, the first target process set that is running can be selected from all processes.
[0054] Taking the development of inspection programs in Go language as an example, the github.com / shirou / gopsutil library can complete the query of system processes, network, and host information, including process-related programs, paths, network listening processes, programs, ports, etc.
[0055] Considering that target applications with exposed ports and in a running state have a higher probability of generating risks, in this embodiment of the application, after determining the first set of target processes in a running state, processes that provide services to the outside world can be further filtered from the first set of target processes. For ease of distinction, the target processes that provide services to the outside world from the first set of target processes can be referred to as second target processes. The set of all second target processes is referred to as the second target process set.
[0056] In practical applications, it is possible to obtain all external listening ports of the system and the processes corresponding to all external listening ports. Then, the processes corresponding to all external listening ports are matched with the first target processes in the first target process set to determine the second target process set that provides services externally.
[0057] Since each process has a unique process identifier (PID), process matching can be achieved by relying on process identifiers. In a specific implementation, all external listening ports of the system and the process identifiers corresponding to all external listening ports can be obtained; the first identifiers corresponding to each first target process in the first target process set can be obtained; all first identifiers are matched with the process identifiers corresponding to all external listening ports to determine the second target process set that provides services externally.
[0058] S102: parse the second target process set to determine the components to be investigated and their component information.
[0059] The component information may include the component name and its version.
[0060] Commonly used components can include xstream, log4j, fastjson, shiro, etc.
[0061] In this embodiment of the application, in order to extract component information that may have security vulnerabilities from the second target process set, the second target process set can be parsed to determine component information that matches the preset list from the second target process set.
[0062] There can be multiple preset lists, each containing key components for a specific target language. These key components can be those identified by industry analysis as having easily exploitable vulnerabilities, i.e., components frequently found to have security vulnerabilities.
[0063] The default list can be a security vulnerability list. This list records components that frequently have security vulnerabilities and their information. The components to be investigated can be those that frequently have security vulnerabilities.
[0064] In this embodiment, there are two ways to obtain component information: one is through file parsing, and the other is through instruction parsing. Component information can be obtained through either method.
[0065] In this embodiment, a combination of two methods can be used to determine component information to ensure its comprehensiveness and accuracy. Component name resolution rules can include file resolution methods and instruction resolution methods.
[0066] In a practical implementation, file parsing can be performed on each second target process in the second target process set, and the target component name and component version that match the security vulnerability list from the first parsing result can be stored. For a feasible implementation of file parsing, please refer to [link to relevant documentation]. Figure 2 The details of its introduction will not be repeated here.
[0067] The instructions of each second target process in the second target process set are parsed, and the target component names that match the security vulnerability list and the corresponding component versions are stored in the second parsing results. For a feasible implementation of instruction parsing, please refer to [link to relevant documentation]. Figure 3 The details of its introduction will not be repeated here.
[0068] S103: Conduct risk analysis based on the component information of the components to be investigated to identify the risky components.
[0069] Risk analysis of component information can be achieved by matching component information with vulnerability databases to identify component information that poses a risk.
[0070] In practical applications, the collected component names and version sequences can be compared with vulnerability databases such as NVD / CNVD to analyze whether there are any known risks.
[0071] For example, if the current version of component A is 1.1, and the vulnerability database records that version 1.1 of component A is risky, then there is a known risk. If the vulnerability database only records that version 1.1 of component A is risky, but the current system only uses version 1.3 of component A, then there is no known risk. If the current system uses both version 1.1 and version 1.3 of component A, then there is a known risk.
[0072] As can be seen from the above technical solution, considering that target applications with open ports and in operation have a higher probability of generating risks, a second set of target processes providing services can be determined from the first set of target processes based on all external listening ports of the system. The first set of target processes contains multiple running first target processes. To analyze whether the third-party components relied upon by the second target processes pose risks, the second set of target processes can be parsed to identify the components to be investigated and their component information; the components to be investigated can be components that frequently exhibit security vulnerabilities. After identifying the components to be investigated and their component information, further risk analysis can be performed on the component information to identify risky components. In this technical solution, by filtering target processes that are running and have open ports, target applications that can actually generate risks can be accurately located. By parsing the second set of target processes, component information that frequently exhibits security vulnerabilities can be extracted, and then risk analysis can be performed on the component information to more accurately determine the potential security risks of running target processes, thus achieving security risk detection for running target applications.
[0073] After conducting risk analysis based on the component information of the components to be investigated, and identifying the risky components, the second target process corresponding to the risky component can be marked as a risky process.
[0074] By marking potentially risky target processes as risky processes, the system can promptly detect risks associated with these processes, thereby effectively restricting the operations performed by the target processes and ensuring system security.
[0075] Figure 2 A flowchart of a method for parsing a file of a second target process provided in this application embodiment, the method comprising:
[0076] S201: Extract the deployment file from the second target process.
[0077] The second target process is any one of the second target processes included in the set of second target processes.
[0078] In practical applications, you can find the running program name, the application name and path, and thus determine the deployment file. Taking a Java process as an example, the deployment file can be a .jar file or a .war file.
[0079] S202: Decompress the deployment files to locate the metadata information directory.
[0080] The deployment file is a compressed file, so it can be decompressed to locate the metadata information directory (meta-info).
[0081] S203: Parse the configuration file in the metadata information directory to determine the target component name and component version.
[0082] In the actual implementation, the configuration file can be found in the meta-info directory. The configuration file can be a pom.xml file or a gradle file. The configuration file is parsed to obtain the component names and component versions that the second Java process (the second target process) depends on.
[0083] In this embodiment of the application, the component name corresponding to the target second Java process can be used as the target component name.
[0084] S204: If the target component name and component version match the security vulnerability list, record the target component name and component version.
[0085] The security vulnerability list can include common risk components.
[0086] If the target component name and version match the security vulnerability list, it indicates that the component corresponding to the target component name is at risk. In this case, the target component name and version can be recorded for further analysis.
[0087] In this embodiment, the deployment file is extracted based on the application name and path of the target process. By decompressing the deployment file to locate the metadata information directory, and parsing the configuration files in the metadata information directory, the component names and component versions that the target process depends on can be accurately obtained.
[0088] Figure 3 A flowchart of a method for parsing instructions of a second target process provided in this application embodiment, the method including:
[0089] S301: Traverse the set of second target processes and determine the corresponding execution instructions for each second target process.
[0090] S302: Parse the target execution instructions to determine the dependent library fields.
[0091] The target instruction to be executed is any one of the many instructions to be executed.
[0092] In practice, the execution instructions can be found in the second target process, and the dependency library fields in the instructions can be parsed.
[0093] Taking gopsutil as an example, the data is stored in the cmdline field, and -cp is the dependency library field.
[0094] S303: Determine whether the parameter following the dependency library field in the second target process contains a target component name that matches the security vulnerability list.
[0095] If the parameter following the dependency library field in the second target process contains a target component name that matches the security vulnerability list, it indicates that the component corresponding to the target component name is at risk, and S304 can be executed in this case.
[0096] S304: Extract the component version from the target execution instruction according to the regular expression extraction method, and record the target component name and component version.
[0097] Taking a Java process as an example, in the specific implementation, a regular expression like "-(\d+\.\d+\.\d+(?:[-.][\w]+)*)\.jar$" can be used to extract the component version and record the component name and component version.
[0098] The provided regular expression -(\d+\.\d+\.\d+(?:[-.][\w]+)*)\.jar$ can be used to accurately extract the version number.
[0099] In regular expressions, -(\d+\.\d+\.\d+: matches the core version number (at least three digits, such as 3.2.1, 2.10.5).
[0100] (?:[-.][\w]+)*: Matches optional extended versions (such as -beta1, -RELEASE, .patch2); (?:) indicates a non-capture group, which is not extracted separately.
[0101] `.jar$`: Matches the .jar at the end, ensuring it's a JAR file. The `$` symbol anchors the end of the string to prevent partial matching.
[0102] In this embodiment, by parsing the execution instructions corresponding to each second target process, the dependency library field can be determined. Matching the parameters after the dependency library field with the security vulnerability list allows for the precise identification of risky component names. Using regular expression extraction, the component version can be extracted from the target execution instructions, and the target component name and version are recorded, thus providing accurate component names and versions for subsequent security analysis.
[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0104] Figure 4 A schematic diagram of a vulnerability detection device provided in an embodiment of this application includes a determination unit 41, a parsing unit 42, and an analysis unit 43;
[0105] The determining unit 41 is used to determine a second target process set that provides services to the outside world from the first target process set based on all external listening ports of the system; wherein, the first target process set includes multiple first target processes that are in the running state;
[0106] The parsing unit 42 is used to parse the second target process set to determine the component to be investigated and its component information.
[0107] Analysis unit 43 is used to perform risk analysis based on the component information of the component to be investigated in order to identify the risky component.
[0108] In some embodiments, the parsing unit is used to parse the second target process set to determine component information that matches a preset list from the second target process set.
[0109] In some embodiments, the parsing unit includes a file parsing subunit and an instruction parsing subunit;
[0110] The file parsing subunit is used to parse the files of each second target process in the second target process set and store the target component name and component version that match the security vulnerability list in the first parsing result;
[0111] The instruction parsing subunit is used to parse instructions for each second target process in the second target process set and store the target component name that matches the security vulnerability list in the second parsing result and the component version corresponding to the target component name.
[0112] In some embodiments, the file parsing subunit is used to extract the deployment file from the second target process; wherein the second target process is any one of all second target processes included in the set of second target processes;
[0113] The deployment files are decompressed to locate the metadata information directory;
[0114] Parse the configuration files in the metadata information directory to determine the target component name and component version;
[0115] If the target component name and version match the security vulnerability list, record the target component name and version.
[0116] In some embodiments, the instruction parsing subunit is used to traverse the second target process set and determine the execution instructions corresponding to each second target process.
[0117] Parse the target execution instruction to determine the dependent library fields; where the target execution instruction is any one of all execution instructions.
[0118] Determine whether the parameter following the dependency library field in the second target process contains a target component name that matches the security vulnerability list;
[0119] If the parameter following the dependency library field in the second target process contains the name of a target component that matches the security vulnerability list, the component version is extracted from the target execution instruction using regular expression extraction, and the target component name and component version are recorded.
[0120] In some embodiments, the determining unit is configured to obtain all external listening ports of the system and the processes corresponding to all external listening ports; and match the processes corresponding to all external listening ports with each first target process in the first target process set to determine the second target process set that provides services to the outside world.
[0121] In some embodiments, a marking unit is also included;
[0122] The marking unit is used to mark the second target process corresponding to the risk component as a risk process.
[0123] As can be seen from the above technical solution, considering that target applications with open ports and in operation have a higher probability of generating risks, a second set of target processes providing services can be determined from the first set of target processes based on all external listening ports of the system. The first set of target processes contains multiple running first target processes. To analyze whether the third-party components relied upon by the second target processes pose risks, the second set of target processes can be parsed to identify the components to be investigated and their component information; the components to be investigated can be components that frequently exhibit security vulnerabilities. After identifying the components to be investigated and their component information, further risk analysis can be performed on the component information to identify risky components. In this technical solution, by filtering target processes that are running and have open ports, target applications that can actually generate risks can be accurately located. By parsing the second set of target processes, component information that frequently exhibits security vulnerabilities can be extracted, and then risk analysis can be performed on the component information to more accurately determine the potential security risks of running target processes, thus achieving security risk detection for running target applications.
[0124] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described vulnerability detection method embodiments.
[0125] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described vulnerability detection method embodiments when it is run.
[0126] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0127] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described vulnerability detection method embodiments.
[0128] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described vulnerability detection method embodiments.
[0129] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0130] The above provides a detailed description of a vulnerability detection method, apparatus, device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.
Claims
1. A vulnerability detection method, characterized in that, include: Based on all external listening ports of the system, a second target process set that provides services to the outside world is determined from the first target process set; wherein, the first target process set contains multiple first target processes that are in a running state; The second target process set is parsed to determine the component to be investigated and its component information; Risk analysis is performed based on the component information of the components to be investigated in order to identify the risky components.
2. The vulnerability detection method according to claim 1, characterized in that, The step of parsing the second target process set to determine the component to be investigated and its component information includes: The second target process set is parsed to determine the component information that matches the preset list from the second target process set.
3. The vulnerability detection method according to claim 2, characterized in that, The step of parsing the second target process set to determine component information matching the preset list from the second target process set includes: File parsing is performed on each second target process in the second target process set, and the target component name and component version that match the security vulnerability list in the first parsing result are stored; And / or, perform instruction parsing on each second target process in the second target process set, and store the target component name that matches the security vulnerability list in the second parsing result and the component version corresponding to the target component name.
4. The vulnerability detection method according to claim 3, characterized in that, The step of parsing files for each second target process in the second target process set and storing the target component name and component version that match the security vulnerability list in the first parsing result includes: The deployment file is extracted from the second target process; wherein, the second target process is any one of all the second target processes contained in the set of second target processes; The deployment file is decompressed to locate the metadata information directory; The configuration files in the metadata information directory are parsed to determine the target component name and component version; If the target component name and the component version match the security vulnerability list, the target component name and the component version are recorded.
5. The vulnerability detection method according to claim 3, characterized in that, The step of parsing instructions for each second target process in the second target process set and storing the target component name that matches the security vulnerability list and the component version corresponding to the target component name in the second parsing result includes: Traverse the second target process set to determine the execution instructions corresponding to each second target process; Parse the target execution instruction to determine the dependent library field; wherein, the target execution instruction is any one of all the execution instructions. Determine whether the parameter following the dependent library field in the second target process contains a target component name that matches the security vulnerability list; If the parameter following the dependency library field in the second target process contains a target component name that matches the security vulnerability list, the component version is extracted from the target execution instruction using regular expression extraction, and the target component name and component version are recorded.
6. The vulnerability detection method according to claim 1, characterized in that, The second target process set, which provides services externally, is determined from the first target process set based on all external listening ports of the system, including: Get all external listening ports of the system and the processes corresponding to all external listening ports; Match all processes corresponding to the external listening ports with each of the first target processes in the first target process set to determine the second target process set that provides services to the outside world.
7. The vulnerability detection method according to claim 1, characterized in that, After performing risk analysis based on the component information of the components to be investigated to identify the risky components, the process also includes: Mark the second target process corresponding to the risk component as a risk process.
8. A vulnerability detection device, characterized in that, It includes a determining unit, a parsing unit, and an analysis unit; The determining unit is used to determine a second target process set that provides services to the outside world from a first target process set based on all external listening ports of the system; wherein, the first target process set includes multiple first target processes that are in a running state; The parsing unit is used to parse the second target process set to determine the component to be investigated and the component information of the component to be investigated; The analysis unit is used to perform risk analysis based on the component information of the component to be investigated, so as to identify the risky component.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the vulnerability detection method as described in any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the vulnerability detection method as described in any one of claims 1 to 7.