Dynamic component safety management method and system based on DevOps

Abstract

The invention discloses a DevOps-based dynamic component security management method and system, and belongs to the technical field of information security detection. Component information data and vulnerability information data are matched by using a matching engine, potential security vulnerabilities are identified, and the security vulnerabilities of the component information data and the vulnerability information data are matched; according to the severity of the vulnerability, the deployment environment of the project, the involved user data volume and the involved sensitive data volume, risk assessment is carried out on the security vulnerability, automatic rating and classification are carried out on risk levels, the priority of the security vulnerability and a corresponding repair strategy are confirmed, a risk report is generated, and the risk report is displayed or exported through a user interface. According to the dynamic component security management method and system based on DevOps disclosed by the invention, potential security vulnerabilities can be accurately identified, automatic risk rating is carried out, vulnerability repair priorities can be ranked according to project risk levels, and later project vulnerability management is facilitated.

Description

Technical Field

[0001] The present invention relates to the field of information security detection technology, and in particular to a DevOps-based dynamic component security management method and system. Background Art

[0002] In modern software development, componentization and modularization have become standard practices. Developers widely adopt third-party libraries, frameworks, and open source components to speed up development, reduce costs, and improve functionality. However, with the introduction of these external components, security risks also increase. Vulnerabilities in third-party components may become an entry point for attackers, compromising the security of the entire system.

[0003] Traditional security auditing methods mainly rely on manual review and regular scanning, which are usually time-consuming and labor-intensive, and cannot respond to emerging security threats in a timely manner. Especially in the DevOps environment that relies on continuous integration / continuous deployment (CI / CD), the software release cycle is significantly shortened, and traditional methods are difficult to meet the needs of rapid response. Therefore, enterprises urgently need an automated, real-time security auditing solution to ensure the security of software throughout the development life cycle. Summary of the invention

[0004] In order to overcome the defects of the prior art, the technical problem to be solved by the present invention is to propose a dynamic component security management method and system based on DevOps, which can accurately identify potential security vulnerabilities and perform automatic risk rating, help rank the priority of vulnerability repair according to the project risk level, facilitate the subsequent project vulnerability management, and automatically detect, analyze and manage the security of various components used in the project.

[0005] To achieve this object, the present invention adopts the following technical solutions:

[0006] The present invention provides a DevOps-based dynamic component security management method, the method comprising:

[0007] S1: Use external vulnerability data sources and manual collection methods of security personnel to obtain vulnerability information data, push the vulnerability information data to the server for storage, and establish a local vulnerability library;

[0008] S2: Use the build tools in the DevOps pipeline to obtain component information data used in the project, push the component information data to the server for storage, and establish a component library;

[0009] S3: Use the matching engine to match component information data in the component library with vulnerability information data in the local vulnerability library, configure the CI / CD pipeline, automatically trigger scanning and regular scanning, discover new vulnerability information data on the market, and identify potential security vulnerabilities;

[0010] S4: Conduct risk assessment on security vulnerabilities based on the severity of the vulnerabilities, the project deployment environment, the amount of user data involved, and the amount of sensitive data involved. Based on the assessment results, classify the risk level of security vulnerabilities, and confirm the priority of security vulnerabilities and corresponding repair strategies.

[0011] S5: Generate a risk report based on vulnerability information data, risk level, and repair strategy, and display or export the risk report through the system user interface.

[0012] The preferred technical solution of the present invention is to allow the specified vulnerability to be added to the whitelist to form whitelist vulnerability information data, and to establish a whitelist feature library based on the corresponding relationship between the component information data and the whitelist vulnerability information data;

[0013] Vulnerability information data in the whitelist feature library will no longer appear in the risk report;

[0014] Among them, the security threat level of the vulnerability, the repair cost, the business impact and the technical compatibility are used as the criteria for judging whether the vulnerability can be included in the whitelist feature library. If the security threat of the vulnerability is controllable, the repair cost is high, the business impact is low and the technical compatibility is good, the vulnerability can be included in the whitelist feature library; otherwise, the vulnerability cannot be included in the whitelist feature library.

[0015] The preferred technical solution of the present invention is to classify the risk level of security vulnerabilities based on the evaluation results, determine the priority of security vulnerabilities and corresponding repair strategies, including:

[0016] Based on the four risk assessment dimensions of vulnerability severity, project deployment environment, amount of user data involved, and amount of sensitive data involved, each dimension is integrated and then any one of the weighted addition algorithm, multiplication model algorithm, maximum value algorithm, fuzzy logic model algorithm, and machine learning model algorithm is used to obtain the risk assessment score of the security vulnerability, where each dimension refers to the four risk assessment dimensions, including the severity of the vulnerability, the project deployment environment, amount of user data involved, and amount of sensitive data involved;

[0017] The risk assessment scores are set into four risk levels from small to large, namely low risk level, medium risk level, high risk level and severe risk level;

[0018] The risks are ranked in ascending order according to low risk level, medium risk level, high risk level and severe risk level. The priority value increases with the ranking. The larger the priority value of the security vulnerability, the higher the priority of vulnerability repair.

[0019] The preferred technical solution of the present invention is to calculate the integral of each dimension based on the four risk assessment dimensions of the severity of the vulnerability, the deployment environment of the project, the amount of user data involved, and the amount of sensitive data involved, including:

[0020] Sort the severity of the vulnerabilities in ascending order from small to large and score them. The score increases as the ranking increases.

[0021] Sort the deployment environments of the projects in ascending order by intranet deployment, private network deployment, and public network deployment, and score them. The score increases as the ranking increases.

[0022] The amount of user data involved is sorted in ascending order and integrated, and the integration increases with the increase of the order;

[0023] The amount of sensitive data involved is sorted in ascending order and integrated. The integration increases with the increase of the order.

[0024] The larger the score, the higher the risk level of the security vulnerability and the greater the priority value of the security vulnerability;

[0025] Among them, the severity of the vulnerability is obtained through the repair status and historical verification results of the identified vulnerabilities stored in the history library, the deployment environment of the project is obtained through the project component information stored in the component library, and the amount of user data involved or the amount of sensitive data involved is obtained through the component information data stored in the component library or manually entered by security personnel.

[0026] The preferred technical solution of the present invention is that, in a weighted addition algorithm, a corresponding weight coefficient is set for each dimension according to the importance of each dimension, the integral of each dimension is multiplied by the corresponding weight coefficient to achieve weighting, and then the weighted integrals of each dimension are added to obtain a risk assessment score for the security vulnerability.

[0027] The preferred technical solution of the present invention is that, in the multiplication model algorithm, the integrals of each dimension are multiplied to obtain a risk assessment score of the security vulnerability.

[0028] The preferred technical solution of the present invention is that, in the maximum value algorithm, the integral value corresponding to the dimension with the highest integral value among all dimensions is taken as the risk assessment score of the security vulnerability.

[0029] The preferred technical solution of the present invention is that in the fuzzy logic model algorithm, the fuzzy logic model uses fuzzy set theory to generate a fuzzy risk assessment score as the risk assessment score of the security vulnerability according to the input integral values ​​of each dimension.

[0030] The preferred technical solution of the present invention is that a variety of notification methods can be used to timely feedback vulnerability alerts and vulnerability repair progress to the project team;

[0031] Notification methods include email, text message, and instant messaging tools.

[0032] The preferred technical solution of the present invention is to determine the programming language type of the component, select the matching engine corresponding to the programming language according to the component type of different programming languages, and associate the component information data in the component library corresponding to the project with the vulnerability information data in the local vulnerability library.

[0033] The present invention provides a system using a DevOps-based dynamic component security management method, comprising:

[0034] External vulnerability library, used to store external data sources and provide vulnerability information data;

[0035] The local vulnerability database is used to internally store vulnerability information data obtained synchronously from the external vulnerability database and vulnerability information data collected by the internal security personnel of the team;

[0036] Component library, used to internally store project component information data collected from the DevOps pipeline;

[0037] A matching engine, which is used to match component information data with vulnerability information data through algorithms to identify potential security vulnerabilities;

[0038] User interface, as the interface for users to interact with the system, is used to provide an entry point for users to operate and manage the system;

[0039] Report library, used to store and manage all generated risk reports, allowing users to view and export risk reports through the user interface;

[0040] A history library to track and record the repair status and historical verification results of each vulnerability;

[0041] Notification system, used to send vulnerability alerts and vulnerability remediation progress updates to project teams through various notification methods.

[0042] The beneficial effects of the present invention are:

[0043] First, the present invention accurately identifies potential security vulnerabilities by deeply analyzing various component versions used in the DevOps pipeline, and automatically generates a detailed risk report, while automatically verifying whether the vulnerability is fixed and archiving historical vulnerability information.

[0044] Second, the present invention can also perform automatic risk rating based on factors such as the severity of different vulnerabilities, the deployment environment of different projects (such as whether it is deployed on the public network, a private network or an intranet), the amount of user data involved, the amount of sensitive data involved, etc., thereby helping to rank the priority of vulnerability repair according to the project risk level, facilitating later project vulnerability management.

[0045] Third, by integrating security tools and vulnerability databases, it is possible to accurately identify potential security vulnerabilities, automatically assess project risk levels, and prioritize and fix these security vulnerabilities, and automatically detect, analyze, and manage the security of various components used in the project. Through continuous monitoring and real-time analysis, it can quickly identify and respond to emerging security threats, ensuring that a high level of security protection is maintained at every stage of the development process. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a schematic diagram of the overall process control of the DevOps-based dynamic component security management method provided in the specific implementation manner of the present invention.

[0047] Figure 2 It is a detailed process control diagram of the DevOps-based dynamic component security management method provided in the specific implementation mode of the present invention.

[0048] Figure 3 It is a schematic diagram of the module architecture of a system using a DevOps-based dynamic component security management method provided in a specific embodiment of the present invention.

[0049] In the figure:

[0050] 1. External vulnerability library; 2. Local vulnerability library; 3. Component library; 4. Matching engine; 5. User interface; 6. Report library; 7. History library; 8. Notification system. DETAILED DESCRIPTION

[0051] The technical solution of the present invention is further described below with reference to the accompanying drawings and through specific implementation methods.

[0052] Embodiment 1

[0053] like Figures 1 to 3 As shown, in order to accurately identify potential security vulnerabilities, realize automatic risk rating, facilitate the analysis, viewing and management of vulnerabilities, and automatically detect, analyze and manage the security of various components used in the project. Furthermore, a dynamic component security management method based on DevOps is provided in this embodiment, and the method includes:

[0054] S1: Use external vulnerability data sources and manual collection methods of security personnel to obtain vulnerability information data, push the vulnerability information data to the server for storage, and establish a local vulnerability library 2;

[0055] S2: Use the build tools in the DevOps pipeline to obtain component information data used in the project, push the component information data to the server for storage, and establish a component library 3;

[0056] S3: Use the matching engine 4 to match the component information data in the component library 3 with the vulnerability information data in the local vulnerability library 2, configure the CI / CD pipeline, automatically trigger scanning and periodic scanning, discover new vulnerability information data on the market, and identify potential security vulnerabilities;

[0057] S4: Conduct risk assessment on security vulnerabilities based on the severity of the vulnerabilities, the project deployment environment, the amount of user data involved, and the amount of sensitive data involved. Based on the assessment results, classify the risk level of security vulnerabilities, and confirm the priority of security vulnerabilities and corresponding repair strategies.

[0058] S5: Generate a risk report based on the vulnerability information data, risk level and repair strategy, and display or export the risk report through the system user interface 5.

[0059] The local vulnerability database 2 (Vulnerability Database) is a database that centrally stores and manages known vulnerability information. The system directly synchronizes the trivy image repository to obtain the latest vulnerability information and stores it in the local vulnerability database 2. Among them, the main source of Trivy's vulnerability database is external vulnerability data sources, including National Vulnerability Database (NVD), Debian Security Bug Tracker, Open Source Vulnerability (OSV) Database, GitHub Security Advisories and other data sources. In addition to synchronizing the trivy image repository, this system can also directly synchronize external vulnerability data sources, the advantage is that it does not rely solely on the trivy image repository. At the same time, project security personnel can supplement the vulnerability information data (such as zero-day vulnerabilities, etc.) found by searching into the local vulnerability database 2. The component database 3 is a database that stores and manages various component information used in software projects. The system obtains the component version information used in the project by integrating the build tools in the DevOps pipeline (such as Jenkins, GitLab CI), and then stores the component information data in the system's component database 3. The component version is the component name plus the version number, for example: org.springframework:spring-beans5.2.8.RELEASE, github.com / gin-gonic / gin v1.7.4. When generating a risk report, the repair version number will be given. Through the above process, the collection and storage of vulnerability information data and component information data are realized.

[0060] The matching engine 4 is a system component used to match component information with vulnerability information. It uses an algorithm to compare the component information stored in the component library 3 with the vulnerability information in the local vulnerability library 2. The trigger points include CI / CD pipeline trigger scans and regular scans to promptly discover newly reported vulnerabilities on the market. Through the above process, the matching engine 4 can identify potential security vulnerabilities through the matching algorithm, identify whether the components used in the project have known security vulnerabilities, and record the matching results for subsequent processing.

[0061] Risk Assessment is a process of analyzing and classifying identified vulnerabilities. Risk assessment is performed on vulnerabilities based on factors such as the severity of the vulnerability, the deployment environment of the project (such as whether it is deployed on the public network, private network, or intranet), the amount of user data involved, and the amount of sensitive data involved (such as whether sensitive data is involved and its amount). By performing risk assessment on security vulnerabilities, multiple risk levels of varying degrees are obtained. Based on the degree of risk level, the priority of security vulnerabilities is determined so that corresponding repair strategies can be formulated.

[0062] Risk Report Generation is a process of generating a report containing detailed vulnerability information, risk level and remediation suggestions. Based on the results of the matching engine 4 and the analysis of the risk assessment, the system generates a comprehensive risk report, providing users with detailed vulnerability information and remediation suggestions so that they can take appropriate remediation measures.

[0063] The user interface 5 (UI) is the interface for users to interact with the system. Through a graphical interface, command line interface or other interactive methods, users can view and manage vulnerability information, risk reports, application and component information. The user interface 5 provides an entry for users to operate and manage the system. Users can view vulnerability reports, configure scanning parameters, set notifications, etc. through the user interface 5.

[0064] In summary, this solution adopts a hierarchical risk management approach. First, the application is risk-rated, and then a targeted repair strategy is formulated based on the risk level of the specific vulnerability, including the following steps:

[0065] 1. Application risk rating

[0066] First, conduct a comprehensive risk rating of the application based on factors such as the application's network environment, user data volume, and sensitive data volume. This rating logic includes:

[0067] Network environment: Evaluate whether the application is deployed on an intranet, private network, or public network.

[0068] Data importance: Applications are classified based on the amount of data processed and the sensitivity of the data. For example, applications involving a large amount of sensitive user data will have a higher risk level.

[0069] User object: Determine the importance of the application based on the user type (such as ToC, ToB, ToG) and user scale of the application.

[0070] This rating logic is able to accurately assess the inherent risk of each application and classify it into different risk levels, such as severe risk level, high risk level, medium risk level, and low risk level.

[0071] 2. Vulnerability risk level and repair strategy

[0072] After determining the risk rating of the application, and combining the specific risk level of the vulnerability (such as severe, high, medium, and low), formulate a corresponding repair strategy for each application:

[0073] High-risk vulnerabilities in high-risk applications: Fix immediately and apply the most stringent security measures.

[0074] Medium-risk vulnerabilities in medium-risk applications: Remediate as planned to ensure business continuity and security.

[0075] Low-risk vulnerabilities in low-risk applications: Repair can be delayed and conventional security measures can be used.

[0076] 3. Comprehensive repair strategy

[0077] This comprehensive assessment method can better allocate resources to ensure that the most critical systems and applications are protected first, while not neglecting the security of other parts. The repair strategy is not only based on the risk of the vulnerability itself, but also combines the importance of the application, making the overall security management more efficient and targeted.

[0078] 4. Dynamic adjustment and continuous optimization

[0079] Risk ratings and repair strategies are dynamic. As time goes by and new information emerges, the risk rating library and its corresponding repair strategies will be continuously updated and optimized to ensure that the system is always in the best security state.

[0080] Through the above process, by integrating security tools and vulnerability databases, potential security vulnerabilities can be accurately identified, project risk levels can be automatically assessed, and priority of these security vulnerabilities can be classified and repaired. It can automatically detect, analyze and manage the security of various components used in the project. Through continuous monitoring and real-time analysis, new security threats can be quickly identified and responded to, ensuring that a high level of security protection is maintained at every stage of the development process.

[0081] Preferably, it is allowed to add the specified vulnerability to the whitelist to form whitelist vulnerability information data, and a whitelist feature library is established based on the correspondence between the component information data and the whitelist vulnerability information data;

[0082] Vulnerability information data in the whitelist feature library will no longer appear in the risk report;

[0083] Among them, the security threat level of the vulnerability, the repair cost, the business impact and the technical compatibility are used as the criteria for judging whether the vulnerability can be included in the whitelist feature library. If the security threat of the vulnerability is controllable, the repair cost is high, the business impact is low and the technical compatibility is good, the vulnerability can be included in the whitelist feature library; otherwise, the vulnerability cannot be included in the whitelist feature library.

[0084] In a specific embodiment, users can add specific vulnerabilities to the whitelist feature library so that they no longer appear in the vulnerability risk report. When performing scanning inspections, skipping detection of security vulnerabilities in the whitelist feature library can reduce the workload of vulnerability verification, which is especially useful for vulnerabilities that do not pose a threat in the current project and have a high cost to repair. Users can flexibly manage and adjust the whitelist feature library according to actual conditions to better meet enterprise needs.

[0085] To add a vulnerability to the whitelist, strict criteria must be met, including:

[0086] 1. Security threats are controllable: The existence of the vulnerability will not pose a significant threat to the overall security of the system, and there are sufficient protection measures to ensure that the vulnerability will not be maliciously exploited. For example, the vulnerability will only be triggered in certain circumstances, and these circumstances have been strictly controlled.

[0087] 2. High repair cost: The time, manpower or resource cost required to repair the vulnerability is too high, and after comprehensively considering the risks and costs, it is decided not to repair the vulnerability for the time being, or to repair it in the next major update.

[0088] 3. Low business impact: This vulnerability will not have a significant impact on the core business of the system or application, and even if it is exploited, it will not lead to serious consequences.

[0089] 4. Good technical compatibility: Fixing this vulnerability may cause functional failure or incompatibility of existing systems or applications. After evaluation, it was decided to maintain the current status to ensure that the vulnerability is compatible with existing systems or applications to avoid larger problems.

[0090] By setting the above evaluation criteria, it is ensured that a vulnerability will be included in the whitelist only when it is completely controllable, so as to prevent the arbitrary relaxation of vulnerability handling standards from causing system security risks.

[0091] Once the vulnerability is evaluated and added to the whitelist, the system will build a whitelist signature library based on the data relationship between component information and vulnerability information. This whitelist signature library contains all verified and risk-controlled vulnerability information for future automated scanning and vulnerability management.

[0092] Furthermore, the system of this solution also sets up a gray list and a black list, including:

[0093] 1. Greylist: It is used to record those vulnerabilities that are high risk but cannot be fixed or should not be fixed for the time being. Unlike the whitelist, the vulnerabilities in the greylist need to be continuously monitored, and they may be transferred to the whitelist or blacklist in the future according to the change of risk. The greylist usually also includes a mechanism for regular review to assess the risk changes of these vulnerabilities.

[0094] 2. Blacklist: Contains high-risk vulnerabilities that are considered intolerable and must be fixed or isolated immediately. These vulnerabilities are identified as serious threats to the system, and the system is usually not allowed to continue running or going online until these vulnerabilities are fixed or the system is reinforced.

[0095] Gray lists and black lists are commonly used supplementary mechanisms in risk management, and can form a more comprehensive vulnerability management strategy together with white lists. When matching information, the matching engine 4 not only matches the component library 3 with the vulnerability library, but also combines the black, white and gray lists for matching.

[0096] Preferably, the risk level of security vulnerabilities is classified based on the assessment results, and the priority of security vulnerabilities and corresponding repair strategies are determined, including:

[0097] Based on the four risk assessment dimensions of vulnerability severity, project deployment environment, amount of user data involved, and amount of sensitive data involved, each dimension is integrated and calculated, and then any one of the weighted addition algorithm, multiplication model algorithm, maximum value algorithm, fuzzy logic model algorithm, and machine learning model algorithm is used to obtain the risk assessment score of the security vulnerability, where each dimension refers to the four risk assessment dimensions, including the severity of the vulnerability, the project deployment environment, amount of user data involved, and amount of sensitive data involved;

[0098] The risk assessment scores are set into four risk levels from small to large, namely low risk level, medium risk level, high risk level and severe risk level;

[0099] The risks are ranked in ascending order according to low risk level, medium risk level, high risk level and severe risk level. The priority value increases with the ranking. The larger the priority value of the security vulnerability, the higher the priority of vulnerability repair.

[0100] Furthermore, based on the four risk assessment dimensions of vulnerability severity, project deployment environment, amount of user data involved, and amount of sensitive data involved, points are calculated for each dimension, including:

[0101] Sort the severity of the vulnerabilities in ascending order from small to large and score them. The score increases as the ranking increases.

[0102] Sort the deployment environments of the projects in ascending order by intranet deployment, private network deployment, and public network deployment, and score them. The score increases as the ranking increases.

[0103] The amount of user data involved is sorted in ascending order and integrated, and the integration increases with the increase of the order;

[0104] The amount of sensitive data involved is sorted in ascending order and integrated. The integration increases with the increase of the order.

[0105] The larger the score, the higher the risk level of the security vulnerability and the greater the priority value of the security vulnerability;

[0106] Among them, the severity of the vulnerability is obtained through the repair status and historical verification results of the identified vulnerability stored in the historical record library 7, the deployment environment of the project is obtained through the project component information stored in the component library 3, and the amount of user data involved or the amount of sensitive data involved is obtained through the component information data stored in the component library 3 or manually entered by security personnel.

[0107] Among them, corresponding points are set for the four risk assessment dimensions: severity of the vulnerability, project deployment environment, amount of user data involved, and amount of sensitive data involved, which are S1, S2, S3, and S4 respectively.

[0108] Corresponding weights are set for the four risk assessment dimensions of the severity of the vulnerability, the project deployment environment, the amount of user data involved, and the amount of sensitive data involved, which are a, b, c, and d, respectively, and a+b+c+d=100%.

[0109] The risk assessment score of the security vulnerability is set to T, then T = a×S1+b×S2+c×S3+d×S4. The risk assessment score T is compared with the set score range, and the risk level of the security vulnerability is divided into low risk level, medium risk level, high risk level and severe risk level.

[0110] For a specific embodiment, in the weighted addition algorithm, a corresponding weight coefficient is set for each dimension according to the importance of each dimension, and the integral of each dimension is multiplied by the corresponding weight coefficient to achieve weighting, and then the weighted integrals of each dimension are added to obtain the risk assessment score of the security vulnerability. In the current scheme, the calculation method of integral and weighted addition is a relatively intuitive and easy-to-understand method. It scores each risk assessment dimension (such as the severity of the vulnerability, the deployment environment of the project, the amount of user data, and the amount of sensitive data), and then weights them according to the importance of each dimension, and finally adds these weighted scores to obtain the overall risk assessment score of the vulnerability. The advantages of this algorithm are: 1. Flexibility: The weights of each dimension can be adjusted according to business needs to reflect the actual situation of different projects. 2. Transparency: The scores and weights of each risk dimension can be clearly displayed for easy review and interpretation.

[0111] Preferably, the score calculation is performed based on the risk assessment dimension of the severity of the vulnerability, including:

[0112] The severity of the vulnerabilities is sorted in ascending order from small to large and the points are accumulated. The points increase with the increase of the ranking. The greater the severity of the vulnerability, the greater the points, which means the higher the risk level of the security vulnerability.

[0113] The severity of the vulnerability is obtained through the repair status and historical verification results of the identified vulnerability stored in the history library 7.

[0114] In a specific embodiment, the severity of security vulnerabilities is divided into four levels from small to large, namely low, medium, high, and extremely high, and the points of each level can be set to 1, 2, 3, and 4 points. Among them, the low level, which represents the least severe security vulnerability, has the lowest score and the lowest risk level; and the extremely high level, which represents the most severe security vulnerability, has the highest score and the highest risk level.

[0115] Preferably, the points are calculated based on the risk assessment dimension of the project deployment environment, including:

[0116] Sort the deployment environment of the project by intranet deployment, private network deployment, and public network deployment in ascending order and score them. The score increases with the ranking. The larger the score, the higher the risk level of the security vulnerability.

[0117] The deployment environment of the project is obtained through the project component information stored in the component library 3.

[0118] In a specific embodiment, according to the different deployment environments of the projects, they are divided into intranet deployment, private network deployment and public network deployment, and the points of each can be set to 1 point, 2 points and 3 points respectively. Among them, the project using intranet deployment has the lowest points and the lowest risk level; while the project using public network deployment has the highest points and the highest risk level.

[0119] Preferably, the points are calculated based on the risk assessment dimension of the amount of user data involved, including:

[0120] The amount of user data involved is sorted in ascending order and integrated. The integration increases with the order. The larger the amount of user data involved, the larger the integration, which means the higher the risk level of the security vulnerability.

[0121] The amount of user data involved is obtained through component information data stored in the component library 3 or manually entered by security personnel.

[0122] In a specific embodiment, the amount of user data involved is divided into three types of data amounts from small to large, namely small amount, medium amount, and large amount, and the points of each can be set to 1 point, 2 points, and 3 points respectively. Among them, the small amount, which represents the smallest amount of user data involved, has the lowest points and the lowest risk level; while the large amount, which represents the largest amount of user data involved, has the highest points and the highest risk level.

[0123] Preferably, the integral calculation is performed based on the risk assessment dimension of the amount of sensitive data involved, including:

[0124] The amount of sensitive data involved is sorted in ascending order and integrated. The integration increases with the increase of the order. The larger the amount of sensitive data involved, the larger the integration, which means the higher the risk level of the security vulnerability.

[0125] The amount of sensitive data involved is obtained through component information data stored in the component library 3 or manually entered by security personnel.

[0126] In a specific embodiment, the amount of sensitive data involved is divided into four types of data amounts from small to large, namely zero (indicating no sensitive data involved), small amount, medium amount, and large amount, and the points of each can be set to 0, 1, 2, and 3 points. Among them, zero, which represents the smallest amount of sensitive data involved, has the lowest score and the lowest risk level; while large amount, which represents the largest amount of sensitive data involved, has the highest score and the highest risk level.

[0127] In summary, in a specific embodiment, corresponding weights are set for the four risk assessment dimensions of vulnerability severity, project deployment environment, amount of user data involved, and amount of sensitive data involved, which are a=25%, b=15%, c=25%, and d=35%, respectively. Based on the collected information data, it is concluded that:

[0128] Security vulnerability V1 is: the severity of the vulnerability is low, the project deployment environment is intranet deployment, the amount of user data involved is small, and the amount of sensitive data involved is zero;

[0129] Security vulnerability V2 is: the severity of the vulnerability is extremely high, the project is deployed in the public network, the amount of user data involved is large, and the amount of sensitive data involved is large;

[0130] The risk assessment score of security vulnerability V1 is set to T1, then T1 = 25% × 1 + 15% × 1 + 25% × 1 + 35% × 0 = 0.65;

[0131] The risk assessment score of security vulnerability V2 is set to T2, then T2 = 25% × 4 + 15% × 3 + 25% × 3 + 35% × 3 = 3.25;

[0132] When the score range X1 of T is set to 0.65-1, the risk level is low risk level; when the score range X2 of T is set to 1-1.65, the risk level is medium risk level; when the score range X3 of T is set to 1.65-2.65, the risk level is high risk level; when the score range X4 of T is set to 2.65-3.25, the risk level is severe risk level.

[0133] It can be seen that if T1 is within the score interval X1, the risk level of security vulnerability V1 is low risk level; if T2 is within the score interval X4, the risk level of security vulnerability V2 is severe risk level. Therefore, the priority value of security vulnerability V2 is greater than the priority value of security vulnerability V1, and security vulnerability V2 is repaired first. Furthermore, since the risk level of security vulnerability V1 is low risk level, the security vulnerability V1 does not pose a threat in the current project, and it can be added to the whitelist feature library, which can reduce the workload of vulnerability verification and improve system operation efficiency.

[0134] In addition to using the weighted addition algorithm, you can also use any of the multiplication model algorithms, maximum value algorithms, fuzzy logic model algorithms, and machine learning model algorithms to obtain a risk assessment score for security vulnerabilities.

[0135] Preferably, in the multiplication model algorithm, the integrals of each dimension are multiplied to obtain the risk assessment score of the security vulnerability. In the multiplication model, the scores of each risk dimension are multiplied instead of added. This method can amplify the impact of extreme values ​​of a certain dimension on the final risk score. For example, if the severity of a vulnerability is very high, its final risk assessment score will still be very high even if the scores of other dimensions are low. The main advantages of the multiplication model are: 1. Emphasis on a single high-risk factor: It can ensure that the extremely high risk of a certain dimension (such as extremely high severity) will not be ignored due to low scores in other dimensions. 2. Applicable to high-risk sensitive environments: Applicable to systems or projects where high-risk factors must be strictly controlled.

[0136] Preferably, in the maximum value algorithm, the integral value corresponding to the dimension with the highest integral value in each dimension is taken as the risk assessment score of the security vulnerability. In the maximum value method, the final risk score is directly taken from the highest one among all dimensions. For example, if a vulnerability scores particularly high in a certain dimension (such as severity), then its final risk assessment score will take this highest value. This method is suitable for use in situations where certain risk dimensions are particularly important. The advantages of this algorithm are: 1. Highlighting a single important dimension: ensuring that vulnerabilities with high scores in a key risk dimension are given priority. 2. Simple and direct: The calculation method is simple, easy to understand and implement.

[0137] Preferably, in the fuzzy logic model algorithm, the fuzzy logic model uses fuzzy set theory to generate a fuzzy risk assessment score as the risk assessment score of the security vulnerability according to the input integral values ​​of each dimension. The fuzzy logic model uses fuzzy set theory to generate a fuzzy risk assessment score according to the input scores of each dimension. Fuzzy logic can better handle uncertainty, especially when the weights of each dimension are difficult to determine. The advantages of the fuzzy logic model include: 1. Handling uncertainty: It can handle scenarios with information uncertainty or ambiguity, which is more flexible. 2. Multi-dimensional fusion: Better integration of multi-dimensional risk information, suitable for complex risk assessment scenarios.

[0138] Preferably, in the machine learning model algorithm, a machine learning model (such as regression analysis, decision tree, random forest, etc.) is used for risk assessment. This method requires a large amount of historical data for training to predict the risk score of future vulnerabilities. The advantages of machine learning models include: 1. Strong predictive ability: It can predict future risks based on historical data and adapt to the changing environment. 2. High degree of automation: It can automatically learn and adjust, reducing human intervention.

[0139] Preferably, multiple notification methods can be used to promptly feedback vulnerability alerts and vulnerability repair progress to the project team; notification methods include email, SMS, and instant messaging tools. Support multiple notification methods (such as email, SMS, and instant messaging tools) to ensure that the project team can get updates on vulnerability alerts and repair progress in a timely manner.

[0140] Preferably, the programming language type of the component is determined, and according to the component type of different programming languages, the matching engine 4 corresponding to the programming language is selected to associate the component information data in the component library 3 corresponding to the project with the vulnerability information data in the local vulnerability library 2. The system manages and views the components of different programming languages ​​(such as Java components, Go components) and the project information associated with the components, and selects the matching engine 4 corresponding to the programming language, thereby analyzing its local vulnerability library 2 and component library 3 to generate a risk report.

[0141] In a specific embodiment, the DevOps pipeline initiates a request, parses the request information: project and component information, and then stores the project and component information in the component library 3. At the same time, it regularly inspects data from an external vulnerability data source (which can be set to execute every Sunday morning), pulls all project information, and processes batch data classification. Based on the above steps, compare whether the data exists in the whitelist feature library. If it is in the whitelist feature library, skip the verification test, otherwise execute the next step: judge the programming language type of its component. For Java components and Go components, first judge the programming language type of the component. If it is Java language, perform a Java vulnerability language scan, match the bboltDB vulnerability library (bboltDB vulnerability library can collect data from the public network) with the mysql Java custom information library, identify whether the Java components used in the project have known security vulnerabilities, and record the matching results for subsequent vulnerability risk analysis and processing, and finally generate a risk report. If the language is Go, a Go vulnerability language scan is performed, and the bboltDB vulnerability library (the bboltDB vulnerability library can collect data from the public network) is matched with the mysql Go custom information library to identify whether the Go components used in the project have known security vulnerabilities, and the matching results are recorded for subsequent vulnerability risk analysis and processing, and finally a risk report is generated.

[0142] Embodiment 2

[0143] like Figure 3 As shown, in order to enable the system to automatically assess the risk of project security vulnerabilities, classify and repair the priorities of these vulnerabilities, and monitor and respond to security threats in real time to ensure the security of the software throughout the development cycle, further, a system using a dynamic component security management method based on DevOps is provided in this embodiment, including:

[0144] External vulnerability library 1, used to store external data sources and provide vulnerability information data;

[0145] Local vulnerability library 2 is used to internally store vulnerability information data synchronously obtained from the external vulnerability library 1 and vulnerability information data collected by internal security personnel of the team;

[0146] Component library 3, used to internally store project component information data collected from the DevOps pipeline;

[0147] A matching engine 4, used to match component information data with vulnerability information data through an algorithm to identify potential security vulnerabilities;

[0148] User interface 5, as an interface for users to interact with the system, used to provide an entry for users to operate and manage the system;

[0149] A report library 6, used to store and manage all generated risk reports, so that users can view and export risk reports through the user interface 5;

[0150] History repository 7, used to track and record the repair status and historical verification results of each vulnerability;

[0151] The notification system 8 is used to send vulnerability alerts and vulnerability repair progress updates to the project team through various notification methods.

[0152] The vulnerability database is Vulnerability Database. External vulnerability database 1 is used to store external data sources and provide vulnerability information data. External data sources include NVD, Debian Security Bug Tracker, OSV Database, GitHubSecurityAdvisories, etc. Local vulnerability database 2 is a database that centrally stores and manages known vulnerability information. It contains detailed information on various known vulnerabilities, including vulnerability descriptions, impact ranges, vulnerability exploitation methods, repair suggestions, etc. It is used to store vulnerability information obtained from external vulnerability database 1 (such as NVD, Debian Security Bug Tracker, OSV Database, GitHubSecurityAdvisories, etc.) for reference by the system when performing vulnerability identification and risk assessment.

[0153] Component Database 3 is a database that stores and manages various component information used in software projects. It records the version information and dependencies of all third-party libraries, plug-ins, modules and other components used in the project. It is used to store project component information collected from DevOps pipelines (such as Jenkins, GitLab CI, etc.) for the system to use when matching vulnerabilities.

[0154] The matching engine 4 is a system component used to match component information with vulnerability information. It compares the component information stored in the component library 3 with the vulnerability information in the local vulnerability library 2 through an algorithm to identify potential security vulnerabilities. It identifies whether the components used in the project have known security vulnerabilities and records the matching results for subsequent processing.

[0155] The User Interface 5 (UI) is the interface for users to interact with the system. Through a graphical interface, command line interface, or other interactive methods, users can view and manage vulnerability information, risk reports, application and component information. It is used to provide an entry point for users to operate and manage the system. Users can view vulnerability reports, configure scanning parameters, set notifications, etc. through the interface.

[0156] The Report Database 6 is a database for storing risk reports generated by the system. It records all generated reports and their related information for users to view and manage, and stores and manages all generated risk reports for users to view and export through the user interface.

[0157] The History Database 7 is a database that stores the history of vulnerability repair verification. It records the repair status and verification results of all identified vulnerabilities, tracks and records the repair status and historical verification results of each vulnerability, and ensures the continuity and traceability of vulnerability repair.

[0158] The Notification System 8 is a system component that sends vulnerability alerts and repair progress updates to the project team through various means (such as email, SMS, and instant messaging tools), ensuring that the project team can receive timely notifications about vulnerabilities and repair progress, helping them to quickly respond to and handle security issues.

[0159] Through the above-mentioned unit modules, the system can automatically assess the risks of project security vulnerabilities, classify and repair these vulnerabilities according to their priorities, and monitor and respond to security threats in real time to ensure the security of the software throughout the entire development cycle.

[0160] The present invention is described by preferred embodiments, and those skilled in the art will appreciate that various changes or equivalent substitutions may be made to these features and embodiments without departing from the spirit and scope of the present invention. The present invention is not limited to the specific embodiments disclosed herein, and other embodiments falling within the claims of this application are within the scope of protection of the present invention.

[0161] It should be noted that in the claims, any reference signs placed between brackets shall not be construed as limiting the claims. The word "comprising" does not exclude the presence of technical features or steps not listed in the claims. The word "a" or "an" preceding a technical feature does not exclude the presence of a plurality of such technical features. The present invention may be implemented by means of hardware comprising several different technical features and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names.

[0162] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0163] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0164] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0165] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0166] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0167] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

[0168] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms should not be understood as necessarily referring to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, unless they are contradictory.

[0169] The above description is only a preferred embodiment of the present invention. All equivalent changes and modifications made according to the scope of the patent application of the present invention should fall within the scope of the present invention.

Claims

1. A dynamic component security management method based on DevOps, characterized in that: The method comprises: Utilize external vulnerability data sources and manual collection methods of security personnel to obtain vulnerability information data, push the vulnerability information data to the server for storage, and establish a local vulnerability database (2); Using the build tools in the DevOps pipeline, obtain the component information data used in the project, push the component information data to the server for storage, and establish a component library (3); Using a matching engine (4), the component information data in the component library (3) is matched with the vulnerability information data in the local vulnerability library (2), and a CI / CD pipeline is configured to automatically trigger scanning and periodic scanning to discover new vulnerability information data on the market and identify potential security vulnerabilities; Conduct risk assessment on security vulnerabilities based on the severity of the vulnerability, the project deployment environment, the amount of user data involved, and the amount of sensitive data involved. Classify the risk level of security vulnerabilities based on the assessment results, and confirm the priority of security vulnerabilities and corresponding repair strategies; Based on the vulnerability information data, risk level and repair strategy, a risk report is generated, and the risk report is displayed or exported through the system user interface (5).

2. The DevOps-based dynamic component security management method according to claim 1, characterized in that: Allows specified vulnerabilities to be added to the whitelist to form whitelist vulnerability information data, and establishes a whitelist feature library based on the correspondence between component information data and whitelist vulnerability information data; Vulnerability information data in the whitelist feature library will no longer appear in the risk report; Among them, the security threat level of the vulnerability, the repair cost, the business impact and the technical compatibility are used as the criteria for judging whether the vulnerability can be included in the whitelist feature library. If the security threat of the vulnerability is controllable, the repair cost is high, the business impact is low and the technical compatibility is good, the vulnerability can be included in the whitelist feature library; otherwise, the vulnerability cannot be included in the whitelist feature library.

3. The DevOps-based dynamic component security management method according to claim 1, characterized in that: The risk level of security vulnerabilities is classified based on the assessment results, and the priority of security vulnerabilities and corresponding repair strategies are determined, including: Based on the four risk assessment dimensions of vulnerability severity, project deployment environment, amount of user data involved, and amount of sensitive data involved, each dimension is integrated and then any one of the weighted addition algorithm, multiplication model algorithm, maximum value algorithm, fuzzy logic model algorithm, and machine learning model algorithm is used to obtain the risk assessment score of the security vulnerability, where each dimension refers to the four risk assessment dimensions, including the severity of the vulnerability, the project deployment environment, amount of user data involved, and amount of sensitive data involved; The risk assessment scores are set into four risk levels from small to large, namely low risk level, medium risk level, high risk level and severe risk level; The risks are ranked in ascending order according to low risk level, medium risk level, high risk level and severe risk level. The priority value increases with the ranking. The larger the priority value of the security vulnerability, the higher the priority of vulnerability repair.

4. The DevOps-based dynamic component security management method according to claim 3 is characterized in that: The four risk assessment dimensions, namely, the severity of the vulnerability, the deployment environment of the project, the amount of user data involved, and the amount of sensitive data involved, are used to calculate the points for each dimension, including: Sort the severity of the vulnerabilities in ascending order from small to large and score them. The score increases as the ranking increases. Sort the deployment environments of the projects in ascending order by intranet deployment, private network deployment, and public network deployment, and score them. The score increases as the ranking increases. The amount of user data involved is sorted in ascending order and integrated, and the integration increases with the increase of the order; The amount of sensitive data involved is sorted in ascending order and integrated. The integration increases with the increase of the order. The larger the score, the higher the risk level of the security vulnerability and the greater the priority value of the security vulnerability; The severity of the vulnerability is obtained through the repair status and historical verification results of the identified vulnerability stored in the history library (7), the deployment environment of the project is obtained through the project component information stored in the component library (3), and the amount of user data involved or the amount of sensitive data involved is obtained through the component information data stored in the component library (3) or manually entered by security personnel.

5. The DevOps-based dynamic component security management method according to claim 3 or 4, characterized in that: In the weighted addition algorithm, a corresponding weight coefficient is set for each dimension according to its importance, and the integral of each dimension is multiplied by the corresponding weight coefficient to achieve weighting. The weighted integrals of each dimension are then added together to obtain a risk assessment score for the security vulnerability.

6. The DevOps-based dynamic component security management method according to claim 3 or 4, characterized in that: In the multiplication model algorithm, the integrals of each dimension are multiplied to obtain a risk assessment score for the security vulnerability.

7. The DevOps-based dynamic component security management method according to claim 3 or 4, characterized in that: In the maximum value algorithm, the integral value corresponding to the dimension with the highest integral value among all dimensions is taken as the risk assessment score of the security vulnerability.

8. The DevOps-based dynamic component security management method according to claim 3 or 4, characterized in that: In the fuzzy logic model algorithm, the fuzzy logic model uses fuzzy set theory to generate a fuzzy risk assessment score as a risk assessment score of a security vulnerability according to the input integral values ​​of each dimension.

9. The DevOps-based dynamic component security management method according to claim 1, characterized in that: Determine the programming language type of the component, select the matching engine (4) corresponding to the programming language according to the component type of the different programming languages, and associate the component information data in the component library (3) corresponding to the project with the vulnerability information data in the local vulnerability library (2).

10. A system using the DevOps-based dynamic component security management method according to any one of claims 1 to 9, characterized in that: include: External vulnerability library (1), used to store external data sources and provide vulnerability information data; A local vulnerability library (2) is used to internally store vulnerability information data synchronously obtained from the external vulnerability library (1) and vulnerability information data collected by security personnel within the team; Component library (3), used to internally store project component information data collected from the DevOps pipeline; A matching engine (4), used to match component information data with vulnerability information data through an algorithm to identify potential security vulnerabilities; User interface (5), which is used as an interface for users to interact with the system and is used to provide an entry point for users to operate and manage the system; A report library (6), used for storing and managing all generated risk reports, so that users can view and export risk reports through the user interface (5); A history repository (7), used to track and record the repair status and historical verification results of each vulnerability; A notification system (8) is used to send vulnerability alerts and vulnerability remediation progress updates to the project team through various notification methods.

Images