Component security vulnerability processing method and device, equipment and storage medium

Abstract

The invention provides a component security vulnerability processing method and device, equipment and a storage medium. Relates to the technical field of application security. The method comprises the following steps: marking enterprise-level components with known risks in an enterprise, a version range of the enterprise-level components and related applications having a dependency relationship with the enterprise-level components in a pre-constructed component panoramic view on the basis of a component risk knowledge full-amount warehouse, wherein the enterprise-level components, the version range of the enterprise-level components and the related applications have the dependency relationship with the enterprise-level components; all components in the enterprise and applications having dependency relationships with the components are recorded in the component panoramic view; determining the risk level of the enterprise-level component based on the use condition of the enterprise-level component in each related application; determining a risk processing strategy for the enterprise-level component based on the risk level; and processing the enterprise-level components published in the enterprise component warehouse based on the risk processing strategy. According to the method provided by the invention, the problem that the rectification effect is poor when enterprise-level components with security vulnerabilities are rectified is solved.

Description

Technical Field

[0001] The present application relates to the field of application security technology, and in particular to a component security vulnerability processing method, device, equipment and storage medium. Background Art

[0002] In actual applications, open source components have widespread technical vulnerabilities and risks of illegal intrusion, which not only threaten the security of the software, but may also have significant legal and financial impacts on the enterprise.

[0003] In the existing technology, social security organizations and institutions will publish known issues in various open source components from time to time, and enterprises also have corresponding risk discovery mechanisms. Through the above mechanism, undisclosed component security risks can be discovered, thereby achieving the purpose of early deployment and early rectification.

[0004] However, the existing rectification method has a poor final rectification effect because the number of enterprise components is usually large and the components may be interdependent. Summary of the invention

[0005] The present application provides a component security vulnerability processing method, device, equipment and storage medium, which are used to solve the problem of poor rectification effect of enterprise-level components with security vulnerabilities in the prior art.

[0006] In a first aspect, the present application provides a component security vulnerability processing method, comprising:

[0007] Build a comprehensive repository of component risk knowledge;

[0008] Based on the full component risk knowledge warehouse, the enterprise-level components with known risks within the enterprise, the version range of the enterprise-level components, and related applications with dependencies on the enterprise-level components are marked in the pre-built component panoramic view. The component panoramic view records all components within the enterprise and applications with dependencies on each component.

[0009] Determining a risk level of the enterprise-level component based on usage of the enterprise-level component in various related applications;

[0010] Based on the risk level, determining a risk treatment strategy for the enterprise-level component;

[0011] Based on the risk handling strategy, the enterprise-level components published in the enterprise component repository are processed.

[0012] In a possible design, the building component risk knowledge full warehouse includes:

[0013] Form a public risk knowledge base based on component vulnerability risks published by the public Internet and / or security organizations;

[0014] Based on the component vulnerability risks published in relevant industry fields, an industry component risk knowledge base is formed;

[0015] Based on the component vulnerability risks obtained by security screening of enterprise-level components, an enterprise-level component risk knowledge base is formed, wherein the security screening includes security risk scanning and / or security risk testing;

[0016] The public risk knowledge base, the industry component risk knowledge base and the enterprise-level component risk knowledge base are integrated to construct a complete warehouse of component risk knowledge.

[0017] In a possible design, based on the component risk knowledge full warehouse, the enterprise-level components with known risks existing within the enterprise, the version range of the enterprise-level components, and related applications having dependencies with the enterprise-level components are marked in a pre-built component panoramic view, including:

[0018] Based on the full warehouse of component risk knowledge, enterprise-level components with known risks are identified in the component panoramic view;

[0019] Based on the component panorama view, obtaining a version range of the enterprise-level component;

[0020] Based on the version range and the component-application dependency view depicted in the component panorama view, applications that have dependencies on enterprise-level components of each version are marked as the related applications.

[0021] In a possible design, the tagging of applications that have dependencies with various versions of enterprise-level components as the related applications includes:

[0022] Based on the dependency view of the component and the application, applications that have at least one of direct dependency, transitive dependency and full dependency with each version of the enterprise-level component are obtained as the related application, the direct dependency is the component dependency defined in the definition description file of the enterprise-level component, the transitive dependency is the dependency defined in the definition description file of other components that have direct dependencies on the enterprise-level component, and the full dependency is the union of the direct dependency and the transitive dependency.

[0023] In a possible design, determining a risk handling strategy for the enterprise-level component based on the risk level includes:

[0024] Based on the risk level, at least one strategy is selected from component version upgrade strategy, component replacement strategy, targeted immune component release strategy, and code rectification strategy as the risk handling strategy.

[0025] In a possible design, the processing of the enterprise-level component based on the risk processing strategy includes:

[0026] Based on the risk handling strategy, rectify the enterprise-level component to obtain a component product after rectification;

[0027] Scan the corrected component product using at least one of a component scanning tool, a vulnerability scanning tool, and manual detection to obtain a scanning result;

[0028] Based on the set component rules, verify the scanned component products to obtain a verification result, wherein the component rules include at least one of component version exclusion and immune component dependency rules;

[0029] Determining whether rectification of the enterprise-level component has been completed based on the scanning result and / or verification result;

[0030] If the rectification is not completed, continue to rectify the enterprise-level components.

[0031] In one possible design, it also includes:

[0032] If the enterprise-level component has been rectified, the component product after rectification is used as a production product, and a security vulnerability scan is performed on the production product;

[0033] Re-publishing the products that have passed the security vulnerability scan to the enterprise component warehouse;

[0034] Based on the re-released production products, the corresponding components and the dependency relationships of the components in the component panorama are updated.

[0035] In a second aspect, the present application provides a component security vulnerability processing device, comprising:

[0036] Warehouse construction module, used to build a full warehouse of component risk knowledge;

[0037] A component marking module is used to mark the enterprise-level components with known risks existing within the enterprise, the version range of the enterprise-level components, and related applications with dependencies on the enterprise-level components in a pre-built component panoramic view based on the full warehouse of component risk knowledge. The component panoramic view records all components within the enterprise and applications with dependencies on each component.

[0038] A level determination module, used to determine the risk level of the enterprise-level component based on the usage of the enterprise-level component in various related applications;

[0039] A policy determination module, configured to determine a risk handling policy for the enterprise-level component based on the risk level;

[0040] The component processing module is used to process the enterprise-level components published in the enterprise component warehouse based on the risk processing strategy.

[0041] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method described above.

[0042] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to implement the method described above when executed by a processor.

[0043] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0044] The component security vulnerability processing method, device, equipment and storage medium provided in this application can fully grasp the current version distribution from the dimensions of development, testing, release and operation by utilizing the component panoramic view to obtain the version range of the risk component and the related applications that have dependencies on the risk component, so as to make more effective corrective measures for the component. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0046] Figure 1 Schematic diagram of enterprise-level IT architecture infrastructure provided for embodiments of the present application;

[0047] Figure 2 A schematic diagram of a process for handling component security vulnerabilities provided in an embodiment of the present application;

[0048] Figure 3 A schematic diagram of a process for handling component security vulnerabilities provided in another embodiment of the present application;

[0049] Figure 4 A schematic diagram of marking enterprise-level components with known risks provided in an embodiment of the present application;

[0050] Figure 5 A schematic diagram of the structure of a component security vulnerability processing device provided in an embodiment of the present application;

[0051] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0052] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0053] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0054] In the technical solution of this application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data involved shall comply with the provisions of relevant laws and regulations and shall not violate public order and good morals.

[0055] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0056] In real life, open source components have a wide range of technical vulnerabilities and illegal intrusion risks. Social security organizations and institutions will publish known problems in various open source components from time to time. In addition, some large financial enterprises also have continuous information exchange mechanisms and internal risk discovery mechanisms with financial industry organizations, security institutions, and regulatory agencies. Through the above mechanisms, the internal security department will also discover the security risks of components that are not disclosed in the society, and then deploy defenses and make rectifications in advance. The rectification of components usually also involves version management and improvement, but in related technologies, the version management and improvement of components can only be notified in the form of written notifications, and it is difficult to accurately grasp the upgrade of enterprise-level components. On the other hand, the various project teams in the enterprise lack a comprehensive overall plan for the application of open source components or internal components. Most technical components such as Spring and Mybatis lack unified enterprise-level version management and upgrade methods. Public components released within the enterprise lack application-level monitoring. In the same period, different versions of a single component are also relied on in multiple applications. This will cause the potential risk of errors in the functions of some applications due to the cross-version function changes of internal components, resulting in poor results in the final rectification of component security vulnerabilities.

[0057] In response to the above problems, this application proposes the following technical ideas: based on a panoramic view of enterprise-level components, combined with the technical component management content in the IT architecture, an enterprise-level full-application component dependency management method is formed, which effectively utilizes the vulnerability scanning, virus scanning, global vulnerability release and other capabilities in the enterprise-level IT architecture, and provides direct guidance, supervision and review for the component version upgrades of each project team, thereby improving the effect of rectifying security vulnerabilities in components.

[0058] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0059] First, the enterprise-level IT architecture mentioned in this application is explained.

[0060] This solution provides an IT component and dependency management method and tool based on an enterprise-level IT management platform and enterprise-level IT architecture infrastructure. Figure 1 The schematic diagram of the enterprise-level IT architecture infrastructure provided by the embodiment of the present application is as follows: Figure 1 As shown in Figure 1, in the enterprise-level IT architecture and system, there are the following infrastructures: ① Enterprise-level IT management platform, which is used for online and structured management of enterprise-level R&D processes and assets. ② Enterprise-level dependency warehouse (reference Figure 1③ Document system, used to implement the release and notification of enterprise-level specifications and standards. ④ Artifact building and release process and pipeline, used to implement the construction, release and verification of enterprise-level application products. ⑤ Artifact scanning and verification tools, used to parse artifacts and perform specific verification operations, such as security vulnerability scanning, virus scanning, etc.

[0061] It should be noted that the architecture governance of enterprise-level applications has always been a relatively advanced and complex topic in the IT field. Because architecture itself is a high-level abstraction, organizations of different sizes and different analytical perspectives have different views. For example, from the perspective of most application developers or small enterprises, technical components or component frameworks such as Spring Cloud, Dubbo, and Spring Framework are enterprise-level architectures. Distributed service strategies, full-link monitoring and other technologies are usually the responsibilities of architects. However, in some large financial enterprises, based on the industry-leading architectural perspective and concepts, financial enterprises will scientifically divide the enterprise-level architecture in an orderly manner based on the strategic goals of the enterprise. For example, a large bank has made the following definition of enterprise-level architecture: Enterprise-level architecture is a description of the enterprise business operation and IT support framework, including business architecture and IT architecture. Among them, IT architecture includes application architecture, data architecture, technical architecture and security architecture. The above description scientifically and completely describes the scope and hierarchical division of enterprise-level architecture, and can effectively guide business and IT teams to transform enterprise strategic goals and enterprise business knowledge into enterprise IT capabilities and business operation capabilities, and to integrate business operations and IT systems. In traditional large banks, since their main business is banking, the personnel roles of the enterprise have a good understanding of banking business and clear governance ideas. Therefore, they often have good division capabilities and management ideas in the management and control of business architecture and application architecture in IT architecture. However, in other areas of IT architecture (such as technical architecture), due to professional reasons, there is no clear hierarchical division and effective governance structure. In practice, although the enterprise has divided the architecture level and governance areas, there is no effective management and control method and tool implementation.

[0062] This application provides a method for managing technical component dependencies based on the current status of enterprise-level IT architecture. This method combines the actual situation of enterprise-level R&D processes and infrastructure to conduct multi-dimensional analysis and management of the technical component dependencies of the Java application system, providing a new idea, direction and management method for the management of technical components in enterprise-level IT architecture. This application is based on the technical component management process and method of product scanning and IT architecture management platform, and ultimately realizes a comprehensive management method from the technical component dimension of enterprise-level IT architecture, and provides corresponding management tools.

[0063] Figure 2 This is a flow chart of a component security vulnerability processing method provided in an embodiment of the present application. The method can be applied to electronic devices such as computers. Taking the electronic device as the execution subject as an example, Figure 2 As shown, the method specifically comprises the following steps:

[0064] Step S210: Build a full component risk knowledge warehouse.

[0065] In this embodiment, the component risk knowledge full warehouse identifies which components have risks. The component risk knowledge full warehouse may be composed of multiple knowledge bases.

[0066] Step S220: Based on the full component risk knowledge warehouse, the enterprise-level components with known risks within the enterprise, the version range of the enterprise-level components, and related applications that have dependencies on the enterprise-level components are marked in the pre-built component panoramic view.

[0067] The component panorama view records all components within the enterprise and applications that have dependencies on each component.

[0068] In this embodiment, the risky components have been marked in the component risk knowledge warehouse. As mentioned above, a component panoramic view can be constructed within the enterprise. In this way, the components with risks marked in the component risk knowledge warehouse can be used to identify which components within the enterprise are currently at risk.

[0069] The component panoramic view needs to be constructed by obtaining the dependency relationship of the component. Specifically, when an enterprise-level component is released, the developer submits a definition description file, which may include the version information (such as the version number) of the enterprise-level component and the version numbers of other components that have a dependency relationship with the enterprise-level component.

[0070] Dependencies are divided into direct dependencies, transitive dependencies, and full dependencies. Direct dependencies are component dependencies defined in the component definition description file. Transitive dependencies are dependencies defined in the component definition description file that the component directly depends on and the resulting multi-level transitive dependencies. Full dependencies are the union of direct dependencies and transitive dependencies.

[0071] In this embodiment, the enterprise-level IT platform should use the above-mentioned component dependencies to establish a panoramic view of enterprise-level application dependencies based on component dimensions, so as to achieve global management and risk analysis of enterprise-level component dependencies, and issue rectification instructions and guidance suggestions for specific applications when specific component vulnerability risks occur.

[0072] Step S230: Determine the risk level of the enterprise-level component based on the usage of the enterprise-level component in various related applications.

[0073] In this embodiment, multiple risk levels may be divided, such as high risk, medium risk, and low risk, and then the corresponding risk level may be determined for the enterprise-level component with known risks.

[0074] Exemplarily, applications can be divided into multiple different categories such as core applications and non-core applications. If the enterprise-level component is associated with one or more core applications, then the enterprise-level component is determined to be high risk. If the enterprise-level component is associated with all non-core applications, then the enterprise-level component is determined to be low risk.

[0075] For another example, the number of related applications of the enterprise-level component may also be obtained. The greater the number of related applications, the higher the risk level of the enterprise-level component.

[0076] Step S240: Based on the risk level, determine a risk handling strategy for the enterprise-level component.

[0077] Step S250: Based on the risk processing strategy, the enterprise-level components published in the enterprise component warehouse are processed.

[0078] In this embodiment, different risk levels may correspond to different risk handling strategies. For example, when the enterprise-level component is high risk, the corresponding risk handling strategy may be: component replacement strategy, that is, using a new component to replace the enterprise-level component with known risks. For another example, when the enterprise-level component is low risk, the corresponding risk handling strategy may be: component version upgrade strategy, that is, upgrading the enterprise-level component to eliminate the known risks it has.

[0079] The embodiment of the present application uses a component panoramic view, combined with enterprise-level IT architecture, component and application management processes and system reality, to design a complete enterprise-level component security vulnerability management method and process. This achieves global visibility of component security vulnerabilities and full process control. At the same time, based on the above-mentioned enterprise-level component panoramic view, it is possible to fully grasp the current version distribution from the dimensions of development, testing, release and operation, so as to effectively manage the components.

[0080] Figure 3 A flowchart of a security vulnerability processing method provided by another embodiment of the present application is as follows: Figure 3 As shown in the figure, when building a full warehouse of component risk knowledge, it can be achieved through the following steps:

[0081] Step S310: forming a public risk knowledge base based on component vulnerability risks published by the public Internet and / or security organizations;

[0082] Step S320: forming an industry component risk knowledge base based on component vulnerability risks published in industry-related fields;

[0083] Step S330: forming an enterprise-level component risk knowledge base based on component vulnerability risks obtained by performing security checks on enterprise-level components, wherein the security checks include security risk scanning and / or security risk testing;

[0084] Step S340: Integrate the public risk knowledge base, the industry component risk knowledge base, and the enterprise-level component risk knowledge base to construct a full component risk knowledge warehouse;

[0085] Step S220: Based on the full component risk knowledge warehouse, mark the enterprise-level components with known risks existing within the enterprise, the version range of the enterprise-level components, and related applications that have dependencies with the enterprise-level components in the pre-built component panoramic view;

[0086] Step S230: determining the risk level of the enterprise-level component based on the usage of the enterprise-level component in various related applications;

[0087] Step S240: Determine a risk handling strategy for the enterprise-level component based on the risk level;

[0088] Step S250: Based on the risk processing strategy, the enterprise-level components published in the enterprise component warehouse are processed.

[0089] In this embodiment, the component risk knowledge full warehouse is composed of multiple knowledge bases, including a public risk knowledge base, an industry component risk knowledge base, and an enterprise-level component risk knowledge base. Different types of risk components can be identified in different knowledge bases.

[0090] Among them, component vulnerability risks published by the public Internet and / or security organizations can be obtained to form a public risk knowledge base; in addition, component vulnerability risks published by industry-related fields can also be obtained to form an industry component risk knowledge base; at the same time, enterprise-level components can also be security checked, and based on the component vulnerability risks obtained from the security check, an enterprise-level component risk knowledge base is formed, wherein the security check includes security risk scanning and / or security risk testing.

[0091] Among them, components can be divided into open source components, public components within the enterprise, and private components. Open source components are components provided by certain organizations for public use by various enterprises. The assets of open source components come from open source asset repositories, such as a globally used Maven central repository, or an enterprise-level open source component repository released by various open source components. Public components within the enterprise are global common components developed by a responsible unit or project team within the enterprise for use by all projects and applications within the enterprise, or domain business components widely used in a certain business field. Private components refer to components used by a system or project team within the enterprise in a single application or multiple applications within the enterprise. They are components released for sharing by a single project or application based on the project-level or application-level layered architecture principles. Such components are usually published in a specific organization's private repository in the enterprise's public repository for independent use by project teams or applications.

[0092] Among them, open source components with risks can be recorded through the public risk knowledge base, while public and private components within the enterprise with risks can be recorded through the enterprise-level component risk knowledge base.

[0093] Figure 4 A schematic diagram of marking enterprise-level components with known risks provided in an embodiment of the present application, such as Figure 4 As shown, the above step S220 can be specifically implemented by the following steps:

[0094] (1) Based on the full component risk knowledge warehouse, enterprise-level components with known risks are identified in the component panorama view;

[0095] (2) Obtain the version range of enterprise-level components in the component panorama view;

[0096] (3) Based on the component and application dependency view depicted in the version range and component panorama view, mark the applications that have dependencies on the enterprise-level components of each version as related applications.

[0097] In this embodiment, the component panoramic view includes all component information used by the enterprise, such as open source components used within the enterprise, public components and private components within the enterprise, etc. It can also include a definition description file of the component, which contains a direct dependency description of the component, component coordinates (unique identifier), a summary value of a specific version of the component calculated based on one or more summary algorithms (the summary value is used for comparison and matching, and the component can be matched and queried through the summary value), component name, etc.

[0098] In this embodiment, there may be multiple versions of a component. For example, different versions of a single component may be relied upon in multiple applications during the same period. This may lead to the potential risk of errors in the functions of some applications due to cross-version functional changes of internal components. Therefore, when rectifying the components, it is also necessary to promote the normalization of internal component dependency versions through the component panoramic view as much as possible.

[0099] In this embodiment, the dependency view ( Figure 4 The connection lines in the figure represent the dependency relationship) to describe the dependency relationship between these components. For example, Figure 4 As shown, the applications that have direct dependencies on component 1 include application 1, application 2, and component 2. In addition, the dependency relationship can also include transitive dependencies and full dependencies, for example Figure 4 Application 3 can be considered to have a transitive dependency on component 1.

[0100] Among them, suppose that component 1 has two versions, the first version has a dependency relationship with application 1, and the second version has a dependency relationship with application 2. At this time, in order to avoid the potential risk of errors in the functions of some subsequent applications, if component 1 has known risks, then when rectifying the component, it is necessary to promote the normalization of internal component dependency versions as much as possible.

[0101] As mentioned above, dependencies include direct dependencies, transitive dependencies, and full dependencies. Therefore, when checking for applications that have dependencies on enterprise-level components with known risks, it is necessary to check for all applications that have dependencies on the enterprise-level components based on the dependency view of components and applications. Figure 4 , there is a transitive dependency between application 3 and component 1, which will also be regarded as a related application of the enterprise-level component.

[0102] Among them, it is also mentioned above that the component information in the component panoramic view may include a definition description file, which may contain direct dependencies, and the transitive dependencies are the dependency relationships defined in the definition description files of other components that have direct dependencies on the enterprise-level components. The full dependency is the union of the direct dependency and the transitive dependency.

[0103] The embodiment of the present application utilizes the component and application dependency view to mark all enterprise-level component-related applications, which can further clarify the usage of the risky enterprise-level components in applications, thereby further determining the risk level of the enterprise-level components and the severity of their impact on the entire enterprise, providing a strong basis for subsequent rectification and improving the management and control of internal enterprise components.

[0104] After determining the risk level of the enterprise-level component, the next step is to perform maintenance and rectification on the enterprise-level component, which will be described in detail below through some embodiments.

[0105] Exemplarily, in some embodiments, a variety of risk management strategies can be configured, such as component version upgrade strategy, component replacement strategy, targeted immune component release strategy, and code rectification strategy. After the risk level of the enterprise-level component is determined, one or more strategies can be selected to rectify the enterprise-level component.

[0106] Among them, the applicable scenario of component version upgrade can be: when security vulnerabilities or defects are found in the component, if the upstream developer has released a new version to fix these problems, it is recommended to upgrade the version. The applicable scenario of component replacement can be: if a component is no longer supported, or its security issues cannot be resolved by upgrading, you may need to consider using a replacement component with similar functions but safer and more stable. The applicable scenario of targeted immune component release strategy or code rectification strategy can be: when a quick patch or change can solve the security vulnerability of the component and there is no need to wait for a full version update, this measure can be taken.

[0107] Each strategy has its own unique application scenario and operation process, and the most appropriate response strategy needs to be selected based on the actual security vulnerability situation and business needs. In addition, no matter which solution is adopted, the security, systematic and continuous operation should be guaranteed to maintain the security and stability of the entire system. For example, after determining the component risk handling strategy, the internal security department and component management department of the enterprise will send the solution to the management department of the component-related application, and the specific application management department will make rectifications based on the solution and its own situation.

[0108] Furthermore, after the enterprise-level components are rectified based on the risk management strategy to obtain the rectified component products, the rectified component products can be scanned using at least one of a component scanning tool, a vulnerability scanning tool, and manual detection to obtain the scanning results; at the same time, based on the set component rules, the component products that have passed the scan are verified to obtain the verification results, wherein the component rules include at least one of component version exclusion and immune component dependency rules; finally, based on the scanning results and / or verification results, it is determined whether the enterprise-level components have been rectified; if the rectification has not been completed, the enterprise-level components continue to be rectified.

[0109] In this embodiment, after the application management department completes the rectification, it shall report the rectification completion status on the component management platform and report the rectified application products. The security department and the component management department use tools such as component scanning and vulnerability scanning, manual confirmation, etc. to complete the scanning of the rectified products, and verify the rectification through specific component rules, such as component version exclusion and immune component dependency rules.

[0110] In this embodiment, it is crucial to ensure the security and compatibility of components during component development and maintenance. The security department and component management department usually use a series of tools and methods to verify the effectiveness of the rectification products. For example, automated scanning tools are used to conduct in-depth analysis of the rectified components. These tools can identify potential security issues in the code. In addition, vulnerability scanning tools can be used to detect and report security vulnerabilities that may exist in components. These tools usually have updated vulnerability databases and can detect the latest known vulnerabilities.

[0111] In addition to using tools, security experts can also manually confirm the scan results. This can include analyzing complex or novel attack vectors and evaluating the accuracy and relevance of scan results. Experienced developers or security experts can also audit the code line by line to find security issues that may be missed by automated tools.

[0112] In this embodiment, component version exclusion requires the formulation of a clear strategy to exclude the use of component versions with known risks, which involves monitoring component version updates and security announcements to ensure that the component versions used are authenticated and safe. Immune component dependency rules can ensure that dependencies between components do not cause new security issues. For example, if a component needs to be replaced due to security issues, all other components that depend on it also need to be updated or replaced accordingly to prevent potential vulnerability exploits.

[0113] Furthermore, after the rectification of the enterprise-level component with known risks is completed, the rectified component product can be used as a production product, and the production product can be scanned for security vulnerabilities; the production product that has passed the security vulnerability scan can then be re-published to the enterprise component warehouse; finally, based on the re-published production product, the corresponding components and component dependencies in the component panoramic view are updated.

[0114] In this embodiment, the security vulnerability scan can be divided into automatic scanning by an automated scanning tool and manual review and evaluation of the scan results. Among them, the automated scanning tool can efficiently identify security vulnerabilities in the code, while the manual review and evaluation is used to manually review the scan results to confirm which vulnerabilities are real and valid and which may be false positives. According to the severity and scope of the vulnerability, a corresponding repair plan is formulated and resources are allocated for repair work.

[0115] In this embodiment, the update of components and dependencies in the component panoramic view mainly includes: updating the dependency view of components and applications through tools or manually, specifically including timely removal of version components that are no longer used or have been abandoned, and replacing version components with known security issues.

[0116] In this embodiment, during the re-release process of the product, strict production release processes and rules can be formulated to ensure that only products that have been fully tested and safety verified can be released to the production environment, including version control, rollback mechanism, and establishment of emergency response measures. In addition, continuous monitoring is implemented during the release process to ensure that the product is deployed as expected and any anomalies can be discovered and handled in a timely manner. At the same time, detailed logs of all release activities are recorded for post-audit and problem tracking.

[0117] In this embodiment, the enterprise component warehouse can specifically include an open source asset warehouse, an internal shared resource library of the enterprise, and a private warehouse of a specific organization. Different types of components need to be published to corresponding warehouses. For example, if the component is an open source component, it needs to be published in the open source asset warehouse; if the component is a public component within the enterprise, it needs to be published in the internal shared resource library of the enterprise; if the component is a private component, it needs to be published in the private warehouse of a specific organization, which is convenient for subsequent management and maintenance.

[0118] The above-mentioned embodiments process enterprise-level components based on risk handling strategies, which can improve system security, enhance operational efficiency, enhance compliance and traceability, ensure enterprise system security and compliance, and avoid major losses to enterprises due to security vulnerabilities.

[0119] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0120] Figure 5 A schematic diagram of the structure of a component security vulnerability processing device provided in an embodiment of the present application is shown in FIG. Figure 5 As shown, the component security vulnerability processing device 500 includes: a warehouse construction module 510, a component marking module 520, a level determination module 530, a policy determination module 540, and a component processing module 550.

[0121] Among them, the warehouse construction module 510 is used to build a full warehouse of component risk knowledge. The component marking module 520 is used to mark the enterprise-level components with known risks, the version range of enterprise-level components, and related applications with dependencies on enterprise-level components in the pre-built component panoramic view based on the full warehouse of component risk knowledge. The component panoramic view records all components within the enterprise and applications with dependencies on each component. The level determination module 530 is used to determine the risk level of enterprise-level components based on the usage of enterprise-level components in various related applications. The policy determination module 540 is used to determine the risk handling strategy for enterprise-level components based on the risk level. The component processing module 550 is used to process enterprise-level components published in the enterprise component warehouse based on the risk handling strategy.

[0122] Optionally, the warehouse construction module can be specifically used to: obtain component vulnerability risks published by the public Internet and / or security organizations to form a public risk knowledge base; obtain component vulnerability risks published in industry-related fields to form an industry component risk knowledge base; perform security checks on enterprise-level components, and form an enterprise-level component risk knowledge base based on the component vulnerability risks obtained from the security checks, and the security checks include security risk scanning and / or security risk testing; integrate the public risk knowledge base, the industry component risk knowledge base, and the enterprise-level component risk knowledge base to construct a full warehouse of component risk knowledge.

[0123] Optionally, the component marking module can be specifically used to: identify enterprise-level components with known risks in the component panoramic view based on the full repository of component risk knowledge; obtain the version range of enterprise-level components in the component panoramic view; and mark applications that have dependencies on enterprise-level components of various versions as related applications based on the version range and the component and application dependency view depicted in the component panoramic view.

[0124] Optionally, the component marking module can be specifically used to: based on the dependency view of components and applications, obtain applications that have at least one of direct dependency, transitive dependency and full dependency with each version of enterprise-level components, as related applications, direct dependency is the component dependency defined in the definition description file of the enterprise-level component, transitive dependency is the dependency defined in the definition description file of other components that have direct dependencies on the enterprise-level component, and full dependency is the union of direct dependency and transitive dependency.

[0125] Optionally, the policy determination module can be specifically used to: based on the risk level, select at least one policy from component version upgrade policy, component replacement policy, targeted immune component release policy, and code rectification policy as a risk management strategy.

[0126] Optionally, the component processing module can be specifically used to: rectify enterprise-level components based on risk management strategies to obtain rectified component products; scan the rectified component products using at least one of component scanning tools, vulnerability scanning tools, and manual detection to obtain scanning results; verify the component products that pass the scan based on set component rules to obtain verification results, and the component rules include at least one of component version exclusion and immune component dependency rules; determine whether the enterprise-level components have been rectified based on the scanning results and / or verification results; if the rectification is not completed, continue to rectify the enterprise-level components.

[0127] Optionally, it also includes an update module, which is used to use the rectified component products as production products and scan the production products for security vulnerabilities if the enterprise-level components have been rectified; re-publish the production products that have passed the security vulnerability scan to the enterprise component warehouse; and update the corresponding components and component dependencies in the component panoramic view based on the re-published production products.

[0128] The device provided in the embodiment of the present application can be used to execute the method in the above embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0129] It should be noted that it should be understood that the division of the various modules of the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software called by processing elements; they can also be all implemented in the form of hardware; some modules can also be implemented in the form of software called by processing elements, and some modules can be implemented in the form of hardware. For example, the warehouse construction module can be a separately established processing element, or it can be integrated in a chip of the above device. In addition, it can also be stored in the memory of the above device in the form of program code, and called and executed by a processing element of the above device. The function of the above warehouse construction module. The implementation of other modules is similar. In addition, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor element or instructions in the form of software.

[0130] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 6 As shown, the electronic device 600 includes: at least one processor 601, a memory 602, a bus 603 and a communication interface 604. Among them: the processor, the communication interface and the memory communicate with each other through the bus. The communication interface is used to communicate with other devices. The communication interface includes a communication interface for data transmission and a display interface or an operation interface for human-computer interaction.

[0131] The processor is used to execute the computer-executable instructions stored in the memory, and specifically can execute the relevant steps in the method described in the above embodiment.

[0132] The processor may be a central processing unit, or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement an embodiment of the present invention. The one or more processors included in the review device may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The memory is used to store computer execution instructions. The memory may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk memory.

[0133] This embodiment also provides a computer-readable storage medium, in which computer instructions are stored. When at least one processor of an electronic device executes the computer instructions, the electronic device executes the methods provided in the above-mentioned various implementation modes.

[0134] This embodiment also provides a computer program product, which includes computer instructions stored in a readable storage medium. At least one processor of the electronic device can read the computer instructions from the readable storage medium, and at least one processor executes the computer instructions so that the electronic device implements the methods provided in the above various embodiments.

[0135] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules is only a logical function division, and there may be other division methods in actual implementation, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, which can be electrical, mechanical or other forms.

[0136] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to implement the solution of this embodiment.

[0137] In addition, each functional module in each embodiment of the present application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The above-mentioned module-composed unit can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0138] The above-mentioned integrated module implemented in the form of a software function module can be stored in a computer-readable storage medium. The above-mentioned software function module is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the methods of various embodiments of the present application.

[0139] It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor.

[0140] The memory may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk memory, and may also be a USB flash drive, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc.

[0141] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0142] The above storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general or special purpose computer.

[0143] An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the storage medium can also exist as discrete components in an electronic control unit or a main control device.

[0144] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application 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 with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A component security vulnerability processing method, characterized in that: include: Build a comprehensive repository of component risk knowledge; Based on the full component risk knowledge warehouse, the enterprise-level components with known risks within the enterprise, the version range of the enterprise-level components, and related applications with dependencies on the enterprise-level components are marked in the pre-built component panoramic view. The component panoramic view records all components within the enterprise and applications with dependencies on each component. Determining a risk level of the enterprise-level component based on usage of the enterprise-level component in various related applications; Based on the risk level, determining a risk treatment strategy for the enterprise-level component; Based on the risk handling strategy, the enterprise-level components published in the enterprise component repository are processed.

2. The method according to claim 1, characterized in that The component risk knowledge full warehouse described above includes: Form a public risk knowledge base based on component vulnerability risks published by the public Internet and / or security organizations; Based on the component vulnerability risks published in relevant industry fields, an industry component risk knowledge base is formed; Based on the component vulnerability risks obtained by security screening of enterprise-level components, an enterprise-level component risk knowledge base is formed, wherein the security screening includes security risk scanning and / or security risk testing; The public risk knowledge base, the industry component risk knowledge base and the enterprise-level component risk knowledge base are integrated to construct a complete warehouse of component risk knowledge.

3. The method according to claim 1, characterized in that Based on the full component risk knowledge warehouse, the enterprise-level components with known risks existing within the enterprise, the version range of the enterprise-level components, and related applications that have dependencies with the enterprise-level components are marked in the pre-built component panoramic view, including: Based on the full warehouse of component risk knowledge, enterprise-level components with known risks are identified in the component panoramic view; Based on the component panorama view, obtaining a version range of the enterprise-level component; Based on the version range and the component-application dependency view depicted in the component panorama view, applications that have dependencies on enterprise-level components of each version are marked as the related applications.

4. The method according to claim 3, characterized in that: The applications that are marked as having dependencies with the enterprise-level components of various versions, as the related applications, include: Based on the dependency view of the component and the application, applications that have at least one of direct dependency, transitive dependency and full dependency with each version of the enterprise-level component are obtained as the related application, the direct dependency is the component dependency defined in the definition description file of the enterprise-level component, the transitive dependency is the dependency defined in the definition description file of other components that have direct dependencies on the enterprise-level component, and the full dependency is the union of the direct dependency and the transitive dependency.

5. The method according to claim 1, characterized in that The step of determining a risk handling strategy for the enterprise-level component based on the risk level includes: Based on the risk level, at least one strategy is selected from component version upgrade strategy, component replacement strategy, targeted immune component release strategy, and code rectification strategy as the risk handling strategy.

6. The method according to claim 1, characterized in that The processing of the enterprise-level component based on the risk processing strategy includes: Based on the risk handling strategy, rectify the enterprise-level component to obtain a component product after rectification; Scan the corrected component product using at least one of a component scanning tool, a vulnerability scanning tool, and manual detection to obtain a scanning result; Based on the set component rules, verify the scanned component products to obtain a verification result, wherein the component rules include at least one of component version exclusion and immune component dependency rules; Based on the scanning result and / or verification result, determining whether the enterprise-level component has completed rectification; If the rectification is not completed, continue to rectify the enterprise-level components.

7. The method according to claim 6, characterized in that Also includes: If the enterprise-level component has been rectified, the component product after rectification is used as a production product, and a security vulnerability scan is performed on the production product; Re-publishing the products that have passed the security vulnerability scan to the enterprise component warehouse; Based on the re-released production products, the corresponding components and the dependency relationships of the components in the component panorama are updated.

8. A component security vulnerability processing device, characterized in that: include: Warehouse construction module, used to build a full warehouse of component risk knowledge; A component marking module is used to mark the enterprise-level components with known risks existing within the enterprise, the version range of the enterprise-level components, and related applications with dependencies on the enterprise-level components in a pre-built component panoramic view based on the full warehouse of component risk knowledge. The component panoramic view records all components within the enterprise and applications with dependencies on each component. A level determination module, used to determine the risk level of the enterprise-level component based on the usage of the enterprise-level component in various related applications; A policy determination module, configured to determine a risk handling policy for the enterprise-level component based on the risk level; The component processing module is used to process the enterprise-level components published in the enterprise component warehouse based on the risk processing strategy.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

11. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 7 when being executed by a processor.

Images