Dependence risk version automatic forbidding method, equipment and medium
By using md5 fingerprint to compare with the dependency risk version library during the project construction and operation stage, it automatically identifies and blocks high-risk risk components, and solves the security risks faced by the system due to dependence on high-risk components in the existing technology, and realizes system security guarantees.
Patent Information
- Application Number
- CN202411543078.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-12
- Publication Date
- 2025-02-25
AI Technical Summary
The prior art is difficult to effectively prevent the security risks faced by systems that rely on high-risk components during project construction and operation, especially when the three-party component vulnerabilities emerge in an endless stream.
By embedding component detection links in the project construction and project operation stages, using md5 fingerprint to compare with the dependency risk version library, it automatically identifies and blocks high-risk risk components to ensure system security.
It realizes automatic identification, intercepting and blocking of three-party dependent components with risk vulnerabilities during the project integration construction stage or when the system is started and run, and avoids the system from raising related high-risk risks in the production operation environment.
Smart Images
Figure CN119513874A_ABST
Abstract
Description
[0001] This application is a divisional application of the invention patent application with application number 202311173841.8, application date September 12, 2023, and invention name "Method, device and medium for automatically disabling risky versions" Technical Field
[0002] The embodiments of the present invention relate to the field of information security technology, and in particular to a method, device and medium for automatically disabling a risky version of a dependency. Background Art
[0003] In computer system development, the development, integration, deployment and operation of new projects are closely linked to the middleware released by third parties (open source organizations or commercial organizations), such as log4j, a common log output component, database middleware, and various tool middleware when the integrated system is running. These middlewares always leave some versions with high-risk attack vulnerabilities or major bugs in their own version iterations, such as the day0 vulnerability of log4j2 that can be attacked remotely. If the business system references these vulnerable components, it will face huge risks, and information data may be stolen and leaked at any time.
[0004] In the existing technology, most system development relies on the constraints of development specifications or manual code checks to avoid risky components. However, with the emergence of vulnerabilities in third-party components and the numerous versions of known vulnerable components, the above methods are difficult to ensure system security. Summary of the invention
[0005] The embodiments of the present application provide a method, device and medium for automatically disabling risky versions of dependencies, which automatically identify and block high-risk components during project construction and project operation to ensure system security.
[0006] In a first aspect, an embodiment of the present invention provides a method for automatically disabling a dependency risk version, comprising:
[0007] During the project building process, fingerprint analysis is performed on each dependent component of the project integration package, and the md5 (message-digest algorithm 5) fingerprint of each dependent component is used to compare the first appearance of the full name fingerprint with the dependent risk version library to detect whether each dependent component has a vulnerability risk; if any dependent component has a vulnerability risk, the dependent component is disabled and the project building is terminated, or replaced with a safe version to continue the project building; if all dependent components have no vulnerability risks, the project building continues;
[0008] After the project is built, in the project startup process, extract the dependent components of the new process for fingerprint analysis, and use the md5 fingerprint of each dependent component to compare with the dependent risk version library to detect whether each dependent component has vulnerability risks; if any dependent component has vulnerability risks, disable the dependent component and terminate the project, or replace it with a safe version to continue running;
[0009] The dependency risk version library includes: the names of multiple dependency components, risk version information, security version information, and md5 fingerprints of each version file; the md5 fingerprint of each dependency component is compared with the dependency risk version library to detect whether each dependency component has a vulnerability risk, including: for any dependency component, searching for a target dependency component with the same name in the dependency risk version library; if the following conditions exist, it is determined that any dependency component has a vulnerability risk: the version information of any dependency component matches the risk version information of the target dependency component; or the version information of any dependency component matches the security version information of the target dependency component, and the md5 fingerprint of any dependency component does not match the md5 fingerprint of the security version file of the target dependency component;
[0010] The construction method of the dependency risk version library includes: calling the *.tar.gz package or *.war package of all projects through an automated script; using the jar or tar command to output the file name in each project integration package, and identifying the name of the currently referenced dependency component according to the naming rule of the dependency component, and adding it to the library with a data structure of {component name, storage time, version number, storage reason, whether there is a vulnerability, vulnerability level, file md5 fingerprint} after successful identification. When the name of the currently applied dependency component is identified according to the naming rule, the file name is parsed one by one according to various forms of naming rules according to the set priority. When the parsing is successful according to any form of naming rule, it indicates that the file name is a dependency component name.
[0011] In a second aspect, an embodiment of the present invention provides an electronic device, including:
[0012] one or more processors;
[0013] a memory for storing one or more programs,
[0014] When the one or more programs are executed by the one or more processors, the one or more processors implement the above-mentioned method for automatically disabling the risk-dependent version.
[0015] In a third aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned method for automatically disabling risky versions of dependencies.
[0016] The embodiment of the present invention provides a method for automatically disabling a dependency risk version, which provides the latest comparison basis for component security through a dependency risk version library. In a specific project construction process, a security detection link for dependent components is added, and the md5 fingerprint of each component file is compared one by one with the components in the dependency risk version library to improve the accuracy of security detection; if there is a vulnerability risk, the continuous construction process is immediately stopped and the safe version is replaced to block the risk from spreading. For risk components that use deceptive means to bypass detection, the md5 fingerprint of the component file is extracted again through process monitoring in the project operation process, and a second comparison is performed with the components in the dependency risk version library; if there is a vulnerability risk, the continuous construction process is immediately stopped to block the risk from spreading. The above double scanning, double comparison, and double blocking are used to avoid omissions, so that during the project integration construction phase or when the system is started and operated, it is possible to automatically identify, intercept, and block third-party dependent components with risk vulnerabilities, thereby avoiding the system from generating related high-risk risks in the production operation environment. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0018] Figure 1 It is a flow chart of a method for automatically disabling a risky version of a dependency provided by an embodiment of the present invention;
[0019] Figure 2 It is a schematic diagram of embedding the module in a project building process of a Jenkins platform provided by an embodiment of the present invention;
[0020] Figure 3 is a flowchart of another method for automatically disabling a risky version provided by an embodiment of the present application;
[0021] Figure 4 It is a structural schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0022] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work belong to the scope of protection of the present invention.
[0023] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.
[0024] In the description of the present invention, it is also necessary to explain that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.
[0025] An embodiment of the present invention provides a method for automatically disabling risky versions of dependencies. In order to illustrate the method, the basic process of the project CICD (Continuous Integration / Continuous Deployment) is introduced first. CICD refers to the automatic implementation of code integration and deployment in the development process through a series of automated script executions to improve development efficiency. It mainly includes two-stage processes: project construction and project operation. Among them, the project construction process completes the integrated construction of the project by packaging and publishing project scripts and third-party components; the project startup process completes the deployment and startup of the project by decompressing and running the packaged files. For the same project, the two processes are carried out continuously, and the project startup process is automatically entered after the project construction process is completed.
[0026] To facilitate understanding, a specific implementation of CICD is given below: First, through automated integration platforms such as Jenkins or Maven, integrate and compile project scripts and third-party components into code that can run in the target environment. Then, package the code into a release compressed package and copy and distribute it to the deployment environment. The copying method is not limited to manual copying, but can also be downloaded automatically through the network or copy commands through the network; the deployment environment is the final operating environment of the system program, such as a server with a Linux operating system installed. Finally, decompress and start the business system process. After the business system process is successfully created, the system can provide corresponding business services to the outside world.
[0027] Based on the above process, Figure 1 The present invention provides a flowchart of a method for automatically disabling a risky version of a dependency. The method is applicable to the case where a third-party dependency component is introduced during the CICD process of a project. By embedding component detection links in the project construction and project startup stages, high-risk vulnerabilities introduced by the dependency component are avoided, and system security is fully guaranteed. The method is executed by an electronic device, such as Figure 1 As shown, the specific steps include:
[0028] S110. In the project building process, fingerprint analysis is performed on each dependent component of the project integration package, and the md5 fingerprint of each dependent component is compared with the dependent risk version library to detect whether each dependent component has a vulnerability risk.
[0029] The md5 fingerprint is also called the file fingerprint, which refers to the md5 information value of the file. In this embodiment, the md5 fingerprint is used as the unique identifier of the file, and each file corresponds to a unique md5 information value. The dependency risk version library is a pre-built dependency component information library, including the names, storage time, storage reason, version information and md5 fingerprints of the version files of multiple dependency components. Specifically, the version information includes the version name, version number, whether there is a vulnerability, the vulnerability level and whether it is disabled, etc. Among them, when the "Whether there is a vulnerability" field is "there is a vulnerability", the entire version information is called risk version information; when the "Whether there is a vulnerability" field is "there is no vulnerability", the entire version information is called safe version information.
[0030] This step uses the project integration package obtained in the project construction process as the data source of the entire method, adds a comparison link with the dependency risk version library in the project construction process, and implements component detection of dependent components through md5 fingerprints and pre-built dependency risk version libraries. In a specific implementation, the above process may include the following steps:
[0031] Step 1: Call the project building tool to automatically integrate and package the project scripts. Optionally, use the Jenkins platform to automatically integrate and package the project scripts to obtain a binary package that can be published to the running environment, such as a *.tar.gz package or a *.war package.
[0032] Step 2: Unzip the packaged file and calculate the md5 fingerprint of each file after decompression. Specifically, although automated integrated build and release platforms such as Jenkins have rich functional plug-ins, they cannot automatically identify file packages with risk vulnerabilities and block continuous build and release behaviors. After obtaining the project integration package, this embodiment does not continue the subsequent project construction operation, but decompresses the project integration package to obtain all the files in the file package, and calculates the md5 fingerprint of each file according to the file information, including the md5 fingerprint of each dependent component.
[0033] Step 3: For each dependent component of the project integration package, perform the following operations: for any dependent component, search for the target dependent component with the same name in the dependent risk version library; compare the version information and file fingerprint of any dependent component with that of the target dependent component to determine whether the current version of any dependent component has a vulnerability risk. Depending on the comparison results, the following situations may be included:
[0034] Case 1: The version information of any dependent component matches the risk version information of the target dependent component. In this case, it can be considered that any dependent component has a vulnerability risk based on the version information.
[0035] Case 2: The version information of any dependent component matches the security version information of the target dependent component, and the md5 fingerprint of any dependent component does not match the md5 fingerprint of the corresponding security version file. At this time, it can be determined that any dependent component has a vulnerability risk based on the md5 fingerprint. As mentioned above, the md5 fingerprint can identify the uniqueness of the file, and the version information and component name may be modified, but the md5 fingerprint cannot be modified. When the md5 fingerprint does not match, it not only indicates that the dependent component has a risk vulnerability, but also indicates that the name and / or version information of any dependent component and / or the target dependent component may be modified, thereby bypassing the comparison link of the version information library. At this time, it is possible to further detect whether the above information is accurate.
[0036] Case 3: The version information of any dependent component matches the security version information of the target dependent component, and the md5 fingerprint of any dependent component matches the md5 fingerprint of the corresponding security version file. At this time, through the double comparison of version information and md5 fingerprint, it can be determined that any dependent component is a security version.
[0037] Case 4: All cases except Case 1, Case 2, and Case 3. At this time, it is usually considered that any of the dependent components is a version that has not been recorded in the risky version library. In order to ensure the smooth progress of the project construction, the dependent component is also regarded as a safe version.
[0038] Furthermore, the dependency risk repository can be built in the following way:
[0039] Step 1: Parse the names of all dependent components in the current project and add them to the dependent risk version library. Optionally, call the project integration package of each current project; use the file parsing command to output the file name in each project integration package, and extract the dependent component name therein and automatically store it in the library. Exemplarily, call the *.tar.gz package or *.war package of all projects through an automated script; use the jar or tar command to output the file name in each project integration package, and identify the name of the dependent component currently being referenced according to the naming rules of the dependent component. After successful identification, add it to the library with a data structure of {component name, storage time, version number, storage reason, whether there is a vulnerability, vulnerability level, file md5 fingerprint}. More specifically, the naming rules of the dependent component can include multiple forms, such as a character form name sequence, a character + timestamp form name sequence, or a text form name sequence. When identifying the name of the dependent component currently being applied according to the naming rules, it is necessary to parse the file name one by one according to the set priority and various forms of naming rules. When the parsing is successful according to any form of naming rules, it indicates that the file name is a dependent component name.
[0040] Step 2: Crawling the names of the dependent components in the dependency risk version library at regular intervals, and crawling the security information of each dependent component from the external vulnerability information library to update the dependency risk version library. Exemplarily, the component name log4j is obtained from the dependency risk version library through a scheduled task, and the component name is used to go to an external vulnerability disclosure platform (such as the National Information Security Vulnerability Library and the nvd search engine, etc.), and the returned vulnerability description is crawled through a crawler to determine whether the current component has had a vulnerability and the hazard level (i.e., the vulnerability level). After confirming that log4j has had a vulnerability through a crawler, further confirm whether the version in the dependency risk version library is a repaired safe version. If it is not a repaired safe version, the disabled field is set to disabled, and a new allowed safe version data record is inserted at the same time.
[0041] S120. If any dependent component has a vulnerability risk, disable the dependent component and terminate the project building, or replace it with a safe version to continue the project building; if all dependent components have no vulnerability risk, continue the project building.
[0042] For the above cases 1 and 2, if it is determined that any of the dependent components has a risk vulnerability, the component will be disabled and the project build process will be interrupted. If there is a safe version of the component in the dependent risk version library, the dependent component can be replaced with a safe version and the subsequent process of the project build can be continued. If there is no replaceable safe version, the subsequent process of the project build will be terminated to prevent the security vulnerability from continuing to spread in CICD.
[0043] S130. After the project is built, in the project startup process, each dependent component of the newly created process is extracted for fingerprint analysis, and the md5 fingerprint of each dependent component is compared with the dependent risk version library to detect whether there are vulnerabilities in each dependent component.
[0044] After the project building process is completed, the project startup process will automatically be entered. There may be two situations at this time. One is that all dependent components in the project integration package are safe versions. The other is that there are security vulnerabilities in the dependent components in the project integration package, but through some deceptive means or forced addition, the component detection in the project building process is still bypassed and the project startup process is entered. In order to avoid the risk spread caused by the second situation, this embodiment performs a second component detection in the project startup process to make up for the omissions in the project building process.
[0045] In a specific implementation, first, a process monitoring program is used to scan the file handle of a newly created process to identify the files opened by the process, and dependent component files are extracted therefrom for fingerprint analysis. Exemplarily, the file handles of the processes in the running environment are scanned by an agent program in the running environment, such as by scanning the files opened by the process through lsof -p10624, and fingerprint analysis is performed on the dependent component files therein. Then, the md5 fingerprint of each dependent component is compared with the dependent risk version library to detect whether each dependent component has a vulnerability. The detection process is the same as that described in S120, and will not be repeated here.
[0046] S140. If any dependent component has a vulnerability risk, disable the dependent component and terminate the project operation, or replace it with a safe version to continue running.
[0047] Similarly, this step is similar to S120. If a dependent component in the process has a vulnerability risk, the process is stopped directly through the kill command, and a log report of the reason for the stop is given. It is worth mentioning that the dependent component with a vulnerability risk detected in this step successfully bypassed the component detection in the project build process. It may be that the normal build process was deliberately bypassed, or the vulnerable component was manually added to the project deployment package. At this time, the cause of the missed detection can be further traced to enhance the security precautions in the project CICD. For example, it is possible to further detect whether any of the dependent components and / or the target dependent component with the same name in the dependent risk version library has been modified based on the log report; and / or trace the reason for adding any of the dependent components to locate the reason for bypassing the detection.
[0048] In another specific embodiment, the operation of "using the md5 fingerprint of each dependent component to compare with the dependent risk version library to detect whether each dependent component has a vulnerability risk; if any dependent component has a vulnerability risk, disabling the dependent component and terminating the current process, or replacing it with a safe version to continue the current process" in the above method can also be encapsulated as a callable dependency risk component detection module and embedded in the project build process and project operation process. Figure 2 FIG. 1 is a schematic diagram of embedding the module in a project building process of a Jenkins platform provided by an embodiment of the present invention. Figure 2 As shown in the figure, when integrating and building the project pName, click the "Configure" button to configure the build process and embed the execution script of the risk component detection module in the project build process. After the configuration is completed, click "Build Now" and the project will automatically execute according to the configured steps. After obtaining the project integration package, the risk version will be automatically detected. Only after passing the detection will the subsequent steps of the project build be executed.
[0049] In addition, it should be noted that for multiple projects that are continuously built and deployed, the build process and startup process between different projects, as well as the update process of the dependent risk version library, can be carried out simultaneously or interspersed with each other, and there is no absolute order of precedence. Figure 3 This is a flowchart of another method for automatically disabling risky versions of dependencies provided by an embodiment of the present application, which embodies in another form the relationship between the simultaneous advancement and mutual interweaving of the project construction process, the project startup process, and the update of the risky version library. Through the above method, it is possible to ensure the continuous construction and deployment of multiple projects and the timely update of the risky version library.
[0050] This embodiment provides a method for automatically disabling a risky version of a dependency. The script scans the component version of the project in use, initializes the basic version data of the risky version library, and then periodically reads the component name in the version library, automatically crawls the relevant vulnerabilities and version information of the dependent component to update the data, and provides the latest comparison basis for component security. At the same time, a security detection link for dependent components is added to the specific project construction process, and the md5 fingerprint of each component file is extracted by scanning the project integration package, and compared with the components in the risky version library one by one to improve the accuracy of security detection; if there is a vulnerability risk, the continuous construction process is immediately blocked and a suitable version is recommended to block the risk spread. For risky components that use deceptive means to bypass detection, the md5 fingerprint of the component file is extracted again through the process monitoring in the project operation process, and a secondary comparison is performed with the components in the risky version library; if there is a vulnerability risk, the continuous construction process is immediately blocked to block the risk spread. Through the above double scanning, double comparison, and double blocking to avoid omissions, it is possible to automatically identify, intercept, and block third-party dependent components with risk vulnerabilities during the project integration construction phase or when the system is started and operated, so as to avoid the system from generating related high-risk risks in the production operation environment.
[0051] Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention is shown in FIG. Figure 4 As shown, the device includes a processor 50, a memory 51, an input device 52 and an output device 53; the number of processors 50 in the device can be one or more. Figure 4 A processor 50 is taken as an example; the processor 50, memory 51, input device 52 and output device 53 in the device can be connected by a bus or other means. Figure 4 The example of connecting through bus is taken in the following.
[0052] The memory 51 is a computer-readable storage medium that can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the method for automatically disabling risky versions in the embodiment of the present invention. The processor 50 executes various functional applications and data processing of the device by running the software programs, instructions and modules stored in the memory 51, that is, implementing the above-mentioned method for automatically disabling risky versions.
[0053] The memory 51 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the terminal, etc. In addition, the memory 51 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 51 may further include a memory remotely arranged relative to the processor 50, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0054] The input device 52 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the device. The output device 53 may include a display device such as a display screen.
[0055] An embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for automatically disabling a dependency risk version of any embodiment is implemented.
[0056] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, a device or a device or used in combination with it.
[0057] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.
[0058] The program code contained on the computer readable medium can be transmitted with any appropriate medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination of the above. The computer program code for performing the operation of the present invention can be written in one or more programming languages or their combinations, and the programming language includes object-oriented programming languages-such as Java, Smalltalk, C++, and also includes conventional procedural programming languages-such as "C" language or similar programming languages. The program code can be executed completely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on the remote computer, or completely on the remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, using an Internet service provider to connect through the Internet).
[0059] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present invention.
Claims
1. A method for automatically disabling a risky version, characterized in that: include: During the project building process, fingerprint analysis is performed on each dependent component of the project integration package, and the md5 fingerprint of each dependent component is compared with the dependent risk version library to detect whether each dependent component has vulnerability risks; if any dependent component has vulnerability risks, the dependent component is disabled and the project building is terminated, or replaced with a safe version to continue the project building; if all dependent components have no vulnerability risks, the project building continues; After the project is built, in the project startup process, extract the dependent components of the new process for fingerprint analysis, and use the md5 fingerprint of each dependent component to compare with the dependent risk version library to detect whether each dependent component has vulnerability risks; if any dependent component has vulnerability risks, disable the dependent component and terminate the project, or replace it with a safe version to continue running; The dependency risk version library includes: the names of multiple dependency components, risk version information, security version information, and md5 fingerprints of each version file; the md5 fingerprint of each dependency component is compared with the dependency risk version library to detect whether each dependency component has a vulnerability risk, including: for any dependency component, searching for a target dependency component with the same name in the dependency risk version library; if the following conditions exist, it is determined that any dependency component has a vulnerability risk: the version information of any dependency component matches the risk version information of the target dependency component; or the version information of any dependency component matches the security version information of the target dependency component, and the md5 fingerprint of any dependency component does not match the md5 fingerprint of the security version file of the target dependency component; The construction method of the dependency risk version library includes: calling the *.tar.gz package or *.war package of all projects through an automated script; using the jar or tar command to output the file name in each project integration package, and identifying the name of the currently referenced dependency component according to the naming rule of the dependency component, and adding it to the library with a data structure of {component name, storage time, version number, storage reason, whether there is a vulnerability, vulnerability level, file md5 fingerprint} after successful identification. When the name of the currently applied dependency component is identified according to the naming rule, the file name is parsed one by one according to various forms of naming rules according to the set priority. When the parsing is successful according to any form of naming rule, it indicates that the file name is a dependency component name.
2. The method according to claim 1, characterized in that The fingerprint analysis of each dependent component of the project integration package includes: Call the project building tool to automatically integrate and package the project scripts; Decompress the packaged file and calculate the md5 fingerprint of each decompressed file.
3. The method according to claim 1, characterized in that After comparing the md5 fingerprint of each dependent component with the dependent risk version library to detect whether each dependent component has a vulnerability risk, the following method is also included: If the version information of any dependent component matches the security version information of the target dependent component, and the md5 fingerprint of any dependent component does not match the md5 fingerprint of the security version file of the target dependent component, then detect whether the name and / or version information of any dependent component and / or target component is modified.
4. The method according to claim 1, characterized in that The construction method of the dependency risk version library also includes: The name of each dependent component in the dependency risk version library is captured regularly, and the security information of each dependent component is crawled from the external vulnerability information library and updated to the dependency risk version library.
5. The method according to claim 4, characterized in that Crawling the security information of each dependent component from the external vulnerability information repository and updating it to the dependent risk version repository, including: Use crawlers to obtain the returned vulnerability descriptions and determine whether the current dependent components have vulnerabilities and the vulnerability levels. After confirming through crawling that the current dependent component has had a vulnerability, further confirm whether the version in the dependent risk version library is a fixed safe version. If it is not a fixed safe version, the disabled field is set to disabled, and a new allowed safe version data record is inserted.
6. The method according to claim 1, characterized in that The step of extracting the dependent components of the newly created process for fingerprint analysis includes: Scan the file handles of the newly created process using a process monitoring program to identify the files opened by the process; Extract dependent component files from the identification results for fingerprint analysis.
7. The method according to claim 1, characterized in that After disabling the dependent component and terminating the project if any dependent component has a vulnerability risk, or replacing it with a safe version to continue running, it also includes: Detect whether any of the dependent components and / or the target dependent component with the same name in the dependent risk version library is modified; and / or Trace back the reason why any of the dependencies were added.
8. An electronic device, characterized in that: include: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method for automatically disabling risky versions of dependencies as described in any one of claims 1-7.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for automatically disabling a risky version of dependency as described in any one of claims 1 to 7 is implemented.