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

Abstract

The application provides a component security vulnerability processing method and device, equipment and a storage medium. It relates to the technical field of application security. The method comprises the following steps: based on a full amount warehouse of component risk knowledge, marking the known risk enterprise-level components existing in the enterprise, the version range of the enterprise-level components, and the related applications having a dependency relationship with the enterprise-level components in the pre-constructed component panoramic view, the component panoramic view recording all components in the enterprise and the applications having a dependency relationship with each component; determining the risk level of the enterprise-level components based on the use of the enterprise-level components in each related application; determining the risk processing strategy for the enterprise-level components based on the risk level; and processing the enterprise-level components published in the enterprise component warehouse based on the risk processing strategy. The method of the application solves the problem of poor rectification effect when rectifying the enterprise-level components having security vulnerabilities.

Description

TECHNICAL FIELD

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

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

[0003] In the prior art, social security organizations and institutions will periodically publish known problems in various open source components, and enterprises also have corresponding risk discovery mechanisms. By discovering social component security risks that are not publicly disclosed through the above mechanisms, the purpose of early defense and early rectification can be achieved.

[0004] However, the existing rectification method has poor actual final rectification effect because the number of enterprise components is usually large, and there may be mutual dependencies between various components. SUMMARY

[0005] The present application provides a component security vulnerability processing method, device, equipment and storage medium 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] constructing a component risk knowledge full warehouse;

[0008] Based on the component risk knowledge full warehouse, mark the known risk enterprise-level components existing in the enterprise, the version range of the enterprise-level components, and the related applications having a dependency relationship with the enterprise-level components in the pre-constructed component panoramic view, and record all components in the enterprise and applications having a dependency relationship with each component in the component panoramic view.

[0009] Based on the use of the enterprise-level components in each related application, determine the risk level of the enterprise-level components;

[0010] Based on the risk level, determine the risk processing strategy for the enterprise-level components;

[0011] Based on the risk processing strategy, processing the enterprise-level components published in the enterprise component warehouse.

[0012] In a possible design, the component risk knowledge full warehouse is constructed, comprising:

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

[0014] Form an industry component risk knowledge base based on component vulnerability risks published by industry-related fields;

[0015] Form an enterprise component risk knowledge base based on component vulnerability risks obtained by performing security checks on enterprise components, wherein the security checks include security risk scanning and / or security risk testing;

[0016] Integrate the public risk knowledge base, the industry component risk knowledge base, and the enterprise component risk knowledge base to obtain the component risk knowledge full warehouse.

[0017] In a possible design, based on the component risk knowledge full warehouse, the enterprise component with a known risk, the version range of the enterprise component, and the related application having a dependency relationship with the enterprise component are marked in a pre-constructed component panoramic view, including:

[0018] Based on the component risk knowledge full warehouse, the enterprise component with a known risk is determined in the component panoramic view;

[0019] Based on the component panoramic view, the version range of the enterprise component is obtained;

[0020] Based on the version range and the component and application dependency relationship view depicted in the component panoramic view, the application having a dependency relationship with each version of the enterprise component is marked as the related application.

[0021] In a possible design, the application having a dependency relationship with each version of the enterprise component is marked as the related application, including:

[0022] Based on the component and application dependency relationship view, the application having at least one of a direct dependency relationship, a transitive dependency relationship, and a full dependency relationship with each version of the enterprise component is obtained as the related application, the direct dependency relationship is a component dependency relationship defined in a definition description file of the enterprise component, the transitive dependency relationship is a dependency relationship defined in a definition description file of another component having a direct dependency relationship with the enterprise component, and the full dependency relationship is a union set of the direct dependency relationship and the transitive dependency relationship.

[0023] In a possible design, based on the risk level, a risk handling strategy for the enterprise component is determined, including:

[0024] Based on the risk level, at least one strategy is selected from a component version upgrade strategy, a component replacement strategy, a targeted immune component release strategy, and a code rectification strategy as the risk processing 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 processing strategy, the enterprise-level component is rectified to obtain a rectified component product;

[0027] The rectified component product is scanned by using at least one of a component scanning tool, a vulnerability scanning tool, and manual detection, to obtain a scanning result;

[0028] Based on a set component rule, the component product after scanning is verified to obtain a verification result, the component rule including at least one of a component version exclusion rule and an immune component dependency rule;

[0029] Based on the scanning result and / or the verification result, it is determined whether the enterprise-level component is rectified completely;

[0030] If the enterprise-level component is not rectified completely, the rectification of the enterprise-level component is continued.

[0031] In a possible design, the method further includes:

[0032] If the enterprise-level component is rectified completely, the rectified component product is used as a production product, and the production product is subjected to a security vulnerability scan;

[0033] The production product after the security vulnerability scan is republished to the enterprise component warehouse;

[0034] Based on the republished production product, a corresponding component in the component panoramic view and a dependency relationship of the component are updated.

[0035] In a second aspect, the application provides a component security vulnerability processing apparatus, including:

[0036] A warehouse construction module is configured to construct a component risk knowledge full-amount warehouse.

[0037] A component marking module is configured to mark, based on the component risk knowledge full-amount warehouse, an enterprise-level component with a known risk, a version range of the enterprise-level component, and a related application having a dependency relationship with the enterprise-level component in a pre-constructed component panoramic view, the component panoramic view recording all components in an enterprise and applications having a dependency relationship with each component.

[0038] a level determination module configured to determine a risk level of the enterprise-level component based on usage of the enterprise-level component in each related application;

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

[0040] a component handling module configured to handle the enterprise-level component published in the enterprise component warehouse based on the risk handling policy.

[0041] In a third aspect, an electronic device is provided, including a processor and a memory connected with the processor in communication; the memory stores computer-executable instructions; and the processor executes the computer-executable instructions stored in the memory to implement the method described above.

[0042] In a fourth aspect, a computer-readable storage medium is provided, which stores computer-executable instructions; and the computer-executable instructions are executed by a processor to implement the method described above.

[0043] In a fifth aspect, a computer program product is provided, which includes a computer program; and the computer program is executed by a processor to implement the method described above.

[0044] The component security vulnerability handling method, device, and equipment provided by the present application and the storage medium can obtain the version range of the risk component and the related application having a dependency relationship with the risk component by using the component panoramic view, can comprehensively master the current version distribution from the development state, the test state, the release state, and the running state, and can make more effective rectification measures for the component. BRIEF DESCRIPTION OF DRAWINGS

[0045] The accompanying drawings, which are incorporated herein and constitute part of the 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 An enterprise-level IT architecture infrastructure diagram provided by an embodiment of the present application;

[0047] Figure 2 A flowchart of a component security vulnerability handling method provided by an embodiment of the present application;

[0048] Figure 3 A flowchart of a component security vulnerability handling method provided by another embodiment of the present application;

[0049] Figure 4 A marking diagram of a known risk enterprise-level component provided by an embodiment of the present application;

[0050] Figure 5 A structural schematic diagram of an assembly security vulnerability processing apparatus provided in an embodiment of the present application is shown in the following figure.

[0051] Figure 6 A structural schematic diagram of an electronic device provided in an embodiment of the present application is shown in the following figure.

[0052] The specific embodiments of the present application have been shown in the above figures, and will be described in more detail hereinafter. These figures and the written description are not intended to restrict the scope of the present application in any way, but to illustrate the present application by reference to specific embodiments. DETAILED DESCRIPTION

[0053] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The following description is made with reference to the accompanying drawings in which like reference numerals refer to like elements, unless otherwise indicated. The following exemplary embodiments described are not meant to limit the scope of the application to all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with aspects of the present application as set forth in the claims.

[0054] In the technical solutions of the present application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data comply with relevant laws and regulations and do not violate public order and good customs.

[0055] It should be noted that in the embodiments of the present application, some software, components, models and other existing solutions in the industry may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions 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, and social security organizations and institutions will release 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 agencies, and regulatory agencies. Through the above mechanisms, the in-house security department will also discover social component security risks that are not publicly disclosed, and then take precautions and make corrections in advance. The correction of the component usually involves version management and improvement, but in related technologies, the version management and improvement of the component can only be notified through a notice, and it is difficult to accurately grasp the upgrade situation of the enterprise-level component. On the other hand, each project team in the enterprise lacks a comprehensive overall plan for the application of open source components or internal components, and most technical components such as Spring and Mybatis lack enterprise-level unified version management and upgrade methods. Because of the lack of application-level monitoring, different versions of a single component may be relied on in multiple applications at the same time, which may cause potential risks of function errors in some applications due to cross-version function changes of internal components, thereby affecting the effectiveness of the final component security vulnerability correction.

[0057] To solve the above problems, the present application proposes the following technical concept: based on the enterprise-level component panoramic view, combined with the technical component management content in the IT architecture, an enterprise-level full-application component dependency management method is formed, and the capabilities of vulnerability scanning, virus scanning, and global vulnerability release in the enterprise-level IT architecture are effectively utilized to provide direct guidance, supervision, and audit for the component version upgrade of each project team, thereby improving the effectiveness of the security vulnerability correction of the component.

[0058] The technical solutions of the present application and how the technical solutions of the present application solve the above technical problems will be 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 described again in some embodiments. The embodiments of the present application will be described below with reference to the accompanying drawings.

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

[0060] The present application provides an IT component and dependency control method and tool relying on an enterprise-level IT management platform and enterprise-level IT architecture infrastructure. For example, Figure 1 The enterprise-level IT architecture infrastructure schematic diagram provided for the embodiments of the present application is shown in Figure 1 As shown in the figure, in the enterprise-level IT architecture and system, the following infrastructure exists: ① Enterprise-level IT management platform, used for enterprise-level research and development process and asset online structured control. ② Enterprise-level dependency warehouse (refer to Figure 1The third is a component warehouse in the enterprise, which is used to provide consistent open source and enterprise public dependency component release management and control to each R&D department. The fourth is a document system, which is used to implement the release and notification of enterprise-level specifications and standards. The fifth is a product construction and release process and pipeline, which is used to implement the construction, release and review operations of enterprise-level application products. The sixth is a product scanning and review tool, which is used to analyze products and perform specific review operations such as security vulnerability scanning and virus scanning.

[0061] It should be noted that the architecture governance of enterprise-level applications has always been a relatively deep and complex issue in the IT field. Because architecture is a high-level abstraction, based on different sizes of organizations and different analysis perspectives, different people have different opinions. For example, in the perspective of most application developers or small enterprises, technology 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 within the scope of responsibility of architects. However, in some large financial enterprises, based on industry-leading architecture perspectives and concepts, financial enterprises will scientifically and orderly divide enterprise-level architecture based on enterprise strategic goals. For example, a large bank internally defines enterprise-level architecture as follows: Enterprise-level architecture is a description of enterprise business operation and IT support framework, including business architecture and IT architecture. The IT architecture includes application architecture, data architecture, technology architecture, and security architecture. The above description scientifically and completely describes the scope and level division of enterprise-level architecture, and can effectively guide the business and IT teams to transform enterprise strategic goals and enterprise business knowledge into enterprise IT capabilities and business operation capabilities, and integrate business operation and IT systems consistently. In traditional large banks, because their main business is bank business, the personnel roles of the enterprise have a good understanding and clear governance ideas for bank business, so in the management of business architecture and application architecture in IT architecture, they often have good division capabilities and management ideas. However, in other fields of IT architecture (such as technology architecture), due to professional reasons, there is no clear level division and effective governance structure. In practice, although the enterprise internally divides the architecture level and governance field, there is no effective management method and tool to implement it.

[0062] The present application provides a technical component dependency governance method in combination with the current status of enterprise-level IT architecture. The method analyzes and governs the technical component dependency relationship of the Java application system in multiple dimensions in combination with the actual situation of enterprise-level research and development processes and infrastructure, and provides a new train of thought, direction and governance method for the governance of technical components in enterprise-level IT architecture. The present application is based on the technical component management process and method of the product scanning and IT architecture management platform, and ultimately realizes a comprehensive governance method from the technical component dimension of enterprise-level IT architecture, and provides corresponding management tools.

[0063] Figure 2 A flowchart of a component security vulnerability processing method provided by an embodiment of the present application. The method can be applied to electronic devices such as computers, and the electronic device is taken as an example of an execution subject, as shown in Figure 2 The method specifically includes the following steps:

[0064] Step S210: Construct a component risk knowledge full-amount warehouse.

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

[0066] Step S220: Based on the component risk knowledge full-amount warehouse, mark out the enterprise-level components with known risks, the version range of the enterprise-level components, and the related applications with dependency relationships with the enterprise-level components in the pre-constructed component panoramic view.

[0067] The component panoramic view records all components in the enterprise and the applications with dependency relationships with each component.

[0068] In this embodiment, the component risk knowledge full-amount warehouse has marked out which components have risks. As mentioned above, the enterprise can construct a component panoramic view. Therefore, through the component risk knowledge full-amount warehouse, the components with risks in the enterprise can be found out in the component panoramic view. For example

[0069] The component panoramic view needs to be constructed by obtaining the dependency relationship of the component. Specifically, the enterprise-level component is submitted by the developer when it is released. The definition description file can contain the version information (such as version number) of the enterprise-level component, and can also contain the version number of other components with dependency relationships with the enterprise-level component.

[0070] The dependency relationship is divided into direct dependency, transitive dependency and full dependency. The direct dependency is the dependency relationship of the component defined in the definition description file of the component. The transitive dependency is the dependency relationship defined in the definition description file of the component directly dependent on the component and the multi-level transitive dependency relationship generated thereby. The full dependency is the union of the direct dependency and the transitive dependency.

[0071] In the embodiment, the enterprise-level IT platform should use the component dependency relationship to establish an enterprise-level application dependency panoramic view based on the component dimension, so as to realize global control and risk analysis of the enterprise-level component dependency, and issue rectification instructions and guidance suggestions for specific applications when a specific component vulnerability risk occurs.

[0072] Step S230: determining the risk level of the enterprise-level component based on the use of the enterprise-level component in each related application.

[0073] In the embodiment, a plurality of risk levels can be divided, such as high risk, medium risk and low risk, and then the corresponding risk level of the known risk enterprise-level component is determined.

[0074] For example, the application can be divided into core applications, non-core applications and the like. If the enterprise-level component is associated with one or more core applications, the enterprise-level component is determined to be high risk. If the enterprise-level component is associated with non-core applications, the enterprise-level component is determined to be low risk.

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

[0076] Step S240: determining the risk processing strategy for the enterprise-level component based on the risk level.

[0077] Step S250: processing the enterprise-level component published in the enterprise component warehouse based on the risk processing strategy.

[0078] In the embodiment, different risk levels can correspond to different risk processing strategies. For example, when the enterprise-level component is high risk, the corresponding risk processing strategy can be a component replacement strategy, that is, using a new component to replace the known risk enterprise-level component. For another example, when the enterprise-level component is low risk, the corresponding risk processing strategy can be a component version upgrade strategy, that is, performing version upgrade on the enterprise-level component to eliminate the known risk thereof.

[0079] The embodiment of the application designs a perfect enterprise-level component security vulnerability management method and process by combining the component panoramic view, enterprise-level IT architecture, component and application management process and system practice. Thus, the global visibility of component security vulnerability and the controllability of the whole process are realized. Meanwhile, based on the above enterprise-level component panoramic view, the current version distribution can be comprehensively mastered from the development state, test state, release state and running state, so that the component can be effectively managed.

[0080] Figure 3 The flowchart of the security vulnerability processing method provided by another embodiment of the application is shown in Figure 2. Figure 3 As shown in Figure 2, when the component risk knowledge full-quantity warehouse is constructed, the following steps can be implemented:

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

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

[0083] Step S330: Forming an enterprise-level component risk knowledge base based on the component vulnerability risks obtained by the security inspection of the enterprise-level components, and the security inspection includes security risk scanning and / or security risk testing;

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

[0085] Step S220: Based on the component risk knowledge full-quantity warehouse, marking the known risk enterprise-level components, the version range of the enterprise-level components and the related applications having the dependency relationship with the enterprise-level components in the pre-constructed component panoramic view;

[0086] Step S230: Determining the risk level of the enterprise-level components based on the use of the enterprise-level components in the related applications;

[0087] Step S240: Determining the risk processing strategy for the enterprise-level components based on the risk level;

[0088] Step S250: Processing the enterprise-level components published in the enterprise component warehouse based on the risk processing strategy.

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

[0090] Wherein, the component vulnerability risks published by public Internet and / or security organizations can be acquired to form a public risk knowledge base; in addition, the component vulnerability risks published by industry-related fields can be acquired to form an industry component risk knowledge base; and the enterprise-level components can be subjected to security investigation, and based on the component vulnerability risks obtained by the security investigation, an enterprise-level component risk knowledge base is formed, wherein the security investigation includes security risk scanning and / or security risk testing.

[0091] Wherein, the components can be divided into open source components, enterprise internal public components and private components. The open source components are components provided by some organizations for public use by various enterprises. The assets of the open source components come from an open source asset warehouse, such as a global maven central warehouse or an enterprise-level open source component warehouse published by each open source component. The enterprise internal public components are global general components developed by a responsible unit or a project team in an enterprise for use by all projects and applications in the enterprise, or domain business components widely used in a certain business field. The private components are components used by a certain system or project team in a single application or multiple applications in an enterprise, which are published for sharing by a single project or application based on the project-level or application-level hierarchical architecture principle. Such components are usually published in a specific organization private warehouse of an enterprise public warehouse for independent use by a project team or an application.

[0092] Wherein, the open source components with risks can be recorded by the public risk knowledge base, and the enterprise internal public components and private components with risks can be recorded by the enterprise-level component risk knowledge base.

[0093] Figure 4 A marking diagram of the enterprise-level components with known risks provided by the embodiments of the present application is shown in FIG. 2, as shown in FIG. 2, the above step S220 can be realized by the following steps: Figure 4

[0094] (1) Based on the component risk knowledge full-amount warehouse, the enterprise-level components with known risks are determined in the component panoramic view.

[0095] (2) The version range of the enterprise-level components is acquired in the component panoramic view.

[0096] (3) Based on the version range and the component and application dependency relationship view depicted in the component panoramic view, the applications having dependency relationship with each version of the enterprise-level components are marked as related applications.

[0097] ​In the embodiment, the component panoramic view contains all component information used by the enterprise, for example, including open source components used in the enterprise, public components and private components in the enterprise, and can also include the definition description file of the component, which contains the direct dependency description of the component, the component coordinates (unique identifier), the digest value of the specific version of the component calculated based on one or more digest algorithms (the digest value is used for comparison and matching, and the component can be matched by the digest value), the component name, etc.

[0098] In the embodiment, there can be multiple versions of a component, for example, different versions of a single component in the same period are also dependent in multiple applications, which can cause potential risks of function errors of some applications due to cross-version function changes of internal components. Therefore, when the component is rectified, the internal component dependency version normalization also needs to be promoted as much as possible through the component panoramic view.

[0099] In the embodiment, the dependency relationship between the components can be described by the connection line in the application dependency relationship view. Figure 4 For example, as shown in Figure 4 , the applications that have direct dependency with the component 1 include the application 1, the application 2 and the component 2. In addition, the dependency relationship can also include transitive dependency and full dependency, for example, Figure 4 , the application 3 can be regarded as having transitive dependency with the component 1.

[0100] Among them, it is assumed that the component 1 has two versions, the first version has a dependency relationship with the application 1, and the second version has a dependency relationship with the application 2. At this time, in order to avoid potential risks of function errors of some applications in the future, if the component 1 has known risks, when the component is rectified, the internal component dependency version normalization needs to be promoted as much as possible.

[0101] Among them, it is assumed that the component 1 has two versions, the first version has a dependency relationship with the application 1, and the second version has a dependency relationship with the application 2. At this time, in order to avoid potential risks of function errors of some applications in the future, if the component 1 has known risks, when the component is rectified, the internal component dependency version normalization needs to be promoted as much as possible. Figure 4 For example, referring to the above , the application 3 has transitive dependency with the component 1, which is also regarded as a related application of the enterprise-level component.

[0102] Among them, it is mentioned above that the component information in the component panoramic view can include the definition description file, which can contain the direct dependency, the transitive dependency is the dependency relationship defined in the definition description file of the other component that has direct dependency with the enterprise-level component, and the full dependency is the union of the direct dependency and the transitive dependency.

[0103] The embodiment of the present application labels the full enterprise-level component related application by using the component and application dependency relationship view, so that the use of the enterprise-level component at risk in the application can be further clarified, thereby further determining the risk level of the enterprise-level component and the severity of the impact on the entire enterprise, providing a strong basis for subsequent rectification and improving the management and control effect of the enterprise-level components.

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

[0105] For example, in some embodiments, a plurality of risk handling strategies can be configured, such as component version upgrade strategy, component replacement strategy, targeted immune component release strategy, and code rectification strategy. After determining the risk level of the enterprise-level component, 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 a security vulnerability or defect is found in a component, if the upstream developer has released a new version that fixes these problems, version upgrade is recommended. The applicable scenario of the component replacement strategy can be: if a component is no longer supported or its security problems cannot be solved by upgrading, it may be necessary to consider using a similar but safer and more stable alternative component. The applicable scenario of the targeted immune component release strategy or the 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 the complete version update, this measure can be taken.

[0107] Among them, each strategy has its unique application scenario and operation process, and the most suitable response strategy needs to be selected according to the actual security vulnerability situation and business needs. In addition, regardless of which solution is adopted, the safety, systematicness and continuity of the operation should be ensured to maintain the safety and stability of the entire system. For example, after determining the component risk handling strategy, the security department and component management department of the enterprise will issue the solution to the management department of the component related application, and the specific application management department will rectify it according to the solution and its own situation.

[0108] Further, after the enterprise-level component is rectified to obtain a rectified component product based on the risk-based treatment strategy, at least one of a component scanning tool, a vulnerability scanning tool, and manual detection can be used to scan the rectified component product to obtain a scanning result; meanwhile, based on a set component rule, the rectified component product after scanning is verified to obtain a verification result, wherein the component rule includes at least one of a component version exclusion and an immune component dependency rule, and finally, based on the scanning result and / or the verification result, it is determined whether the enterprise-level component is rectified; if not, the enterprise-level component is continuously rectified.

[0109] In this embodiment, after the application management department completes the rectification, it should report the rectification completion on the component management platform and report the application product after rectification. The security department and the component management department use component scanning, vulnerability scanning tools, manual confirmation and other methods to complete the scanning of the rectified product, and implement the verification work of rectification through specific component rules such as component version exclusion and immune component dependency rule.

[0110] In this embodiment, in the component development and maintenance, it is crucial to ensure the security and compatibility of the component, and the security department and the component management department usually use a series of tools and methods to verify the effectiveness of the rectified product. For example, using automated scanning tools to deeply analyze the rectified component, these tools can identify potential security problems in the code. In addition, vulnerability scanning tools can be used to detect and report possible security vulnerabilities in the component, and these tools usually have an updated vulnerability database, which can detect the latest known vulnerabilities.

[0111] In addition, in addition to using tools, manual confirmation of the scanning result by security experts can also be used. Specifically, it can include analyzing complex or novel attack vectors, and evaluating the accuracy and relevance of the scanning result. At the same time, experienced developers or security experts can also conduct line-by-line audits of the code to find security problems that may be missed by automated tools.

[0112] In this embodiment, component version exclusion requires 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 used component version is certified and secure. The immune component dependency rule can ensure that the dependency relationship between components does not cause new security problems. For example, if a component needs to be replaced due to security problems, all other components that depend on this component also need to be updated or replaced accordingly to prevent potential vulnerability exploitation.

[0113] Further, after the known-risk enterprise-level component completes rectification, the rectified component product can be taken as a production product, and the production product is subjected to a security vulnerability scan; then the production product after passing the security vulnerability scan is republished to the enterprise component warehouse; and finally, based on the republished production product, the corresponding component and the dependency relationship of the component in the component panoramic view are updated.

[0114] In this embodiment, the security vulnerability scan can be divided into automatic scanning by an automatic scanning tool and manual review and assessment of the scanning results. The automatic scanning tool can efficiently identify security vulnerabilities in the code, and the manual review and assessment is used to manually review the scanning results to confirm which vulnerabilities are real and effective and which may be false positives. According to the severity and impact range of the vulnerabilities, a corresponding repair scheme is formulated, and resources are allocated for repair work.

[0115] In this embodiment, the update of the components and dependency relationships in the component panoramic view mainly includes updating the dependency relationship view of the components and the application by a tool or manually, specifically including timely removing no longer used or abandoned version components, and replacing version components with known security problems.

[0116] In this embodiment, during the republishing of the production product, a strict production publishing process and rules can be formulated to ensure that only products that have been completely tested and security verified can be published to the production environment, specifically including version control, rollback mechanism, and establishment of emergency response measures. In addition, continuous monitoring is implemented during the publishing process to ensure that the products are deployed as expected, and any abnormalities can be discovered and handled in a timely manner. At the same time, detailed logs of all publishing activities are recorded for subsequent auditing and problem tracking.

[0117] In this embodiment, the enterprise component warehouse can specifically include an open source asset warehouse, an enterprise internal shared resource library, and a specific organization private warehouse. Different types of components need to be published to the corresponding warehouse. 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 an enterprise internal public component, it needs to be published in the enterprise internal shared resource library; and if the component is a private component, it needs to be published in the specific organization private warehouse, which facilitates subsequent management and maintenance.

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

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

[0120] Figure 5 A structural schematic diagram of the component security vulnerability processing apparatus provided by the embodiment of the present application is shown in FIG. 5. As shown in FIG. 5, the component security vulnerability processing apparatus 500 comprises a warehouse construction module 510, a component marking module 520, a level determination module 530, a strategy determination module 540, and a component processing module 550. Figure 5

[0121] The warehouse construction module 510 is configured to construct a component risk knowledge full-amount warehouse. The component marking module 520 is configured to mark, based on the component risk knowledge full-amount warehouse, the known-risk enterprise-level components, the version ranges of the enterprise-level components, and the related applications having a dependency relationship with the enterprise-level components in a pre-constructed component panoramic view, wherein the component panoramic view records all the components in the enterprise and the applications having a dependency relationship with each component. The level determination module 530 is configured to determine the risk level of the enterprise-level components based on the use of the enterprise-level components in each related application. The strategy determination module 540 is configured to determine the risk processing strategy for the enterprise-level components based on the risk level. The component processing module 550 is configured to process the enterprise-level components published in the enterprise component warehouse based on the risk processing strategy.

[0122] Optionally, the warehouse construction module can be specifically configured to: acquire the component vulnerability risks published by the public Internet and / or security organizations to form a public risk knowledge base; acquire the component vulnerability risks published by the industry-related fields to form an industry component risk knowledge base; perform a security investigation on the enterprise-level components, and form an enterprise-level component risk knowledge base based on the component vulnerability risks obtained by the security investigation, wherein the security investigation comprises a security risk scanning and / or a security risk testing; and integrate the public risk knowledge base, the industry component risk knowledge base, and the enterprise-level component risk knowledge base to construct the component risk knowledge full-amount warehouse.

[0123] Optionally, the component marking module can be specifically configured to: determine the known-risk enterprise-level components in the component panoramic view based on the component risk knowledge full-amount warehouse; acquire the version ranges of the enterprise-level components in the component panoramic view; and mark the applications having a dependency relationship with each version of the enterprise-level components as the related applications based on the version ranges and the component and application dependency relationship view depicted in the component panoramic view.

[0124] ​Optionally, the component marking module can be specifically configured to: based on the dependency view of the components and the application, obtain the application having at least one of a direct dependency, a transitive dependency and a full dependency with each version of the enterprise component as the related application, the direct dependency being a component dependency defined in a definition description file of the enterprise component, the transitive dependency being a dependency defined in a definition description file of another component having a direct dependency with the enterprise component, and the full dependency being a union of the direct dependency and the transitive dependency.

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

[0126] Optionally, the component processing module can be specifically configured to: based on the risk handling strategy, rectify the enterprise component to obtain a rectified component product; scan the rectified component product by using at least one of a component scanning tool, a vulnerability scanning tool and manual detection to obtain a scanning result; based on a set component rule, verify the component product after scanning to obtain a verification result, the component rule including at least one of a component version exclusion and an immune component dependency rule; based on the scanning result and / or the verification result, determine whether the enterprise component is rectified; if not, continue to rectify the enterprise component.

[0127] Optionally, the application further includes an updating module configured to: if the enterprise component is rectified, take the rectified component product as a production product, and perform a security vulnerability scan on the production product; release the production product after the security vulnerability scan to the enterprise component warehouse; and based on the released production product, update the corresponding component and the dependency of the component in the component panoramic view.

[0128] The apparatus provided by the embodiments of the application can be used to execute the method in the above embodiments, and has similar implementation principles and technical effects, which will not be repeated here.

[0129] It should be noted that the division of the various modules of the above apparatus is only a logical functional division, and all or part of them can be integrated into a physical entity, or physically separated. These modules can all be implemented in the form of software invoked by a processing element; all in the form of hardware; or some modules are implemented in the form of software invoked by a processing element, and some modules are implemented in the form of hardware. For example, the warehouse construction module can be a separately set processing element, or can be integrated in a chip of the above apparatus, in addition, it can also be stored in the form of program code in the memory of the above apparatus, and the function of the above warehouse construction module is invoked and executed by a processing element of the above apparatus. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together, or can be independently implemented. The processing element here can be an integrated circuit with signal processing capability. In the implementation process, each step of the above method or each module can be completed by the integrated logic circuit of hardware or the instruction of software in the processing element.

[0130] Figure 6 The structure schematic diagram of the electronic device provided by the embodiment of the present application is shown in the figure. Figure 6 As shown in the figure, 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 complete the communication among each other through the bus. The communication interface is used for communication 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, etc.

[0131] The processor is used to execute the computer execution instructions stored in the memory, and can execute the related steps in the method described in the above embodiments.

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

[0133] The embodiment also provides a computer readable storage medium, and the computer readable storage medium stores computer instructions. When at least one processor of the electronic device executes the computer instructions, the electronic device executes the method provided by the various embodiments described above.

[0134] The embodiment further provides a computer program product, which comprises computer instructions stored in a readable storage medium. At least one processor of an electronic device can read the computer instructions from the readable storage medium, and the at least one processor executes the computer instructions to enable the electronic device to implement the method provided in the various embodiments.

[0135] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other manners. For example, the embodiments of the device described above are merely schematic; for example, the division of the modules is merely a logical function division; an actual implementation can be another division manner, for example, multiple modules or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or modules, and can be electrical, mechanical or in other forms.

[0136] The modules illustrated as separated components can or can not be physically separated, and the components illustrated as modules can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to implement the embodiments of the present application.

[0137] In addition, each functional module in each embodiment of the present application can be integrated in one processing unit, or each module can be physically present separately, or two or more modules can be integrated in one unit. The unit formed by the above modules can be realized in the form of hardware, or in the form of hardware plus software function unit.

[0138] The integrated module realized in the form of software function module can be stored in a computer readable storage medium. The software function module stored in the storage medium includes a plurality of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute some steps of the method of each embodiment of the present application.

[0139] It should be appreciated that the above processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in combination with the application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor.

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

[0141] The bus can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, the bus in the drawings of the present application does not limit to only one bus or one type of bus.

[0142] The above storage medium can be realized by any type of volatile or non-volatile storage device or their combination, 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 storage, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0143] An exemplary storage medium is coupled to the processor, so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be an integral part 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 host device.

[0144] Those skilled in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction related hardware. The foregoing program can be stored in a computer readable storage medium. The program executes to perform the steps of the above-mentioned method embodiments; and the foregoing storage medium includes various storage media that can store program codes, such as ROM, RAM, magnetic disk or optical disk.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. An assembly security vulnerability handling method, characterized by, The method comprises the following steps: constructing a component risk knowledge full-amount warehouse; the component risk knowledge full-amount warehouse comprises a public risk knowledge base, an industry component risk knowledge base and an enterprise-level component risk knowledge base; based on the component risk knowledge full-amount warehouse, marking out the enterprise-level components with known risks existing in the enterprise, the version range of the enterprise-level components and the related applications having a dependency relationship with the enterprise-level components in a pre-constructed component panoramic view, wherein all components in the enterprise and the applications having a dependency relationship with each component are recorded in the component panoramic view; the dependency relationship comprises direct dependency, transitive dependency and full-amount dependency; determining the risk level of the enterprise-level components based on the use of the enterprise-level components in the related applications; determining the risk treatment strategy for the enterprise-level components based on the risk level; treating the enterprise-level components published in the enterprise component warehouse based on the risk treatment strategy.

2. The method of claim 1, wherein, The method of constructing the component risk knowledge full-amount warehouse comprises the following steps: forming the public risk knowledge base based on the component vulnerability risks published by the public Internet and / or security organizations; forming the industry component risk knowledge base based on the component vulnerability risks published by the industry-related fields; forming the enterprise-level component risk knowledge base based on the component vulnerability risks obtained by the security check of the enterprise-level components, wherein the security check comprises security risk scanning and / or security risk testing; integrating the public risk knowledge base, the industry component risk knowledge base and the enterprise-level component risk knowledge base to construct the component risk knowledge full-amount warehouse.

3. The method of claim 1, wherein, The method of marking out the enterprise-level components with known risks existing in the enterprise, the version range of the enterprise-level components and the related applications having a dependency relationship with the enterprise-level components in the pre-constructed component panoramic view based on the component risk knowledge full-amount warehouse comprises the following steps: determining the enterprise-level components with known risks in the component panoramic view based on the component risk knowledge full-amount warehouse; obtaining the version range of the enterprise-level components based on the component panoramic view; marking the applications having a dependency relationship with each version of the enterprise-level components as the related applications based on the version range and the component and application dependency relationship view depicted in the component panoramic view.

4. The method of claim 3, wherein, The method of marking the applications having a dependency relationship with each version of the enterprise-level components as the related applications comprises the following steps: obtaining the applications having at least one of the direct dependency, the transitive dependency and the full-amount dependency with each version of the enterprise-level components as the related applications based on the component and application dependency relationship view, wherein the direct dependency is the component dependency relationship defined in the definition description file of the enterprise-level components, the transitive dependency is the dependency relationship defined in the definition description file of other components having a direct dependency with the enterprise-level components, and the full-amount dependency is the union of the direct dependency and the transitive dependency.

5. The method of claim 1, wherein, The method of determining the risk treatment strategy for the enterprise-level components based on the risk level comprises the following steps: Based on the risk level, at least one strategy is selected from a component version upgrade strategy, a component replacement strategy, a targeted immune component release strategy, and a code rectification strategy as the risk processing strategy.

6. The method of claim 1, wherein, The enterprise-level component is processed based on the risk processing strategy, including: The enterprise-level component is rectified based on the risk processing strategy to obtain a rectified component product; The rectified component product is scanned using at least one of a component scanning tool, a vulnerability scanning tool, and manual detection to obtain a scanning result; Based on the scanning result and / or the verification result, it is determined whether the enterprise-level component is rectified. If the enterprise-level component is rectified, the rectified component product is used as a production product, and the production product is subjected to a security vulnerability scan. The production product subjected to the security vulnerability scan is republished to the enterprise component warehouse.

7. The method of claim 6, wherein, Based on the republished production product, the corresponding component in the component panoramic view and the dependency relationship of the component are updated. The warehouse construction module is configured to construct a component risk knowledge full-quantity warehouse. The component risk knowledge full-quantity warehouse includes a public risk knowledge base, an industry component risk knowledge base, and an enterprise-level component risk knowledge base. The component marking module is configured to mark, based on the component risk knowledge full-quantity warehouse, in a pre-constructed component panoramic view, an enterprise-level component with a known risk existing in an enterprise, a version range of the enterprise-level component, and related applications having a dependency relationship with each version of the enterprise-level component.

8. An assembly security vulnerability handling apparatus, characterized by, The level determination module is configured to determine a risk level of the enterprise-level component based on a use condition of the enterprise-level component in each related application. The strategy determination module is configured to determine a risk processing strategy for the enterprise-level component based on the risk level. The component processing module is configured to process the enterprise-level component released in the enterprise component warehouse based on the risk processing strategy. The processor and the memory in communication with the processor are included. The memory stores computer execution instructions. The processor executes the computer execution instructions stored in the memory to implement the method of any one of claims 1-7. The computer-readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1-7.

9. An electronic device, comprising: The computer program is executed by the processor to implement the method of any one of claims 1-7. ​ ​ ​ 10. A computer-readable storage medium, characterized in that, ​ 11. A computer program product, characterised in that, ​

Images