Open source software code security and compliance control method

Abstract

The invention relates to the field of computer software, and discloses an open source software code security and compliance management and control method which comprises the following steps: acquiring security vulnerabilities, licenses, version information and dependency relationship data of an open source component, constructing a component-characteristic matrix based on the data and performing dimension reduction processing, predicting a security vulnerability risk and a compliance risk of the component; key components and potential vulnerability propagation paths are identified by constructing a dependency graph and calculating a Laplacian matrix in combination with eigenvalue analysis; and finally, generating a security vulnerability repair suggestion and a compliance review report, helping a development team to preferentially process high-risk problems, and ensuring that the project meets the requirements of related licenses. According to the method, the bug repairing process can be optimized, the safety and compliance of open source software are improved, and the maintainability of the system is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software, and particularly to a method for security and compliance control of open-source software code. Background Art

[0002] With the wide application of open-source software in modern software development, more and more enterprises and development teams choose to use open-source components to build and improve their systems. However, the use of open-source software also brings challenges in terms of security and compliance. Since open-source software is usually maintained and updated by multiple external developers, there is a great deal of uncertainty in its code quality, vulnerability repair progress, and license compliance issues.

[0003] Currently, the security management of open-source software often relies on manual review or simple static code analysis tools, lacking effective automated detection mechanisms. This traditional manual management method is not only inefficient but also prone to missing some potential security vulnerabilities. Even when using automated tools, existing tools mostly focus on single vulnerability scanning and ignore the complex dependency relationships between open-source components. This underestimates the spread and impact of vulnerabilities in an environment where multiple components are used in coordination. In addition, existing compliance checking tools can usually only identify some common license conflicts and cannot deeply analyze the compatibility of licenses between components and its impact on the entire project.

[0004] In addition, existing technologies have not effectively combined the security vulnerabilities, compliance issues, and dependency relationships of open-source components to conduct a comprehensive risk assessment. This single risk assessment method makes it difficult for development teams to identify which components are key nodes in the system or which vulnerability spreads will cause a wider impact throughout the system.

[0005] Therefore, there are multiple deficiencies in the existing technologies in terms of security and compliance control of open-source software code, and they cannot comprehensively and accurately evaluate and manage the risks of open-source components, thus affecting the overall security and compliance of the system. Summary of the Invention

[0006] Aiming at the deficiencies of the existing technology, the present invention provides a method for security and compliance control of open-source software code, which solves the problem of insufficient security and compliance control of open-source software in the existing technology.

[0007] To achieve the above objectives, the present invention is realized through the following technical solutions: A method for security and compliance control of open-source software code, including the following steps: Collect characteristic data of open-source software components, where the characteristic data at least includes security vulnerability information, license information, version information, and dependency relationship information; Construct a component-feature matrix based on the characteristic data, and use matrix factorization technology to reduce the dimension of the matrix and extract key characteristic data; Predict the security vulnerability risk and compliance risk of open-source components according to the result of dimension reduction processing; Construct a dependency graph among open-source components, where the components are nodes and the dependencies are edges; Calculate the Laplacian matrix based on the dependency graph, and identify key components and vulnerability propagation paths through eigenvalue analysis; generate security vulnerability repair suggestions and compliance review reports.

[0008] Preferably, the steps of collecting the characteristic data of open-source software components include: Obtain the security vulnerability information of each component, where the security vulnerability information includes vulnerability history records, vulnerability levels, and vulnerability repair status; Obtain the license information of each component, where the license information includes license types, license risk levels, and license compatibility data; Obtain the version information of each component, where the version information includes the current version, historical versions, and version update records; Obtain the dependency relationship data among components, where the data includes the dependencies of each component and the list of components being depended on.

[0009] Preferably, the steps of constructing a component-feature matrix based on the characteristic data include: Classify the security vulnerability information, license information, version information, and dependency relationship information of open-source software components by component, and assign corresponding characteristic tags to each component; Organize the characteristic data of all components into a matrix form, where the rows of the matrix represent different components, the columns represent each characteristic, and each matrix element represents the association degree between the component and the characteristic.

[0010] Preferably, the steps of using matrix factorization technology to reduce the dimension of the matrix and extract key characteristic data include: Perform matrix factorization on the component-feature matrix, and decompose it into several matrix factors using a dimension reduction algorithm; Select and retain the top k singular values and corresponding eigenvectors with the most information, and construct a low-dimensional representation matrix to ensure that the matrix after dimension reduction can accurately represent the key characteristics in the original matrix; Reconstruct the components using the low-dimensional matrix representation, evaluate the importance of each characteristic in the components, and determine the key characteristics affecting security and compliance.

[0011] Preferably, the steps of predicting the security vulnerability risk and compliance risk of open-source components according to the result of dimension reduction processing include: Based on the low-dimensional matrix after dimensionality reduction, calculate the eigenvectors of each component and perform similarity matching with the known security vulnerabilities or compliance issues of historical components; Perform a risk score on the components with high similarity, and predict the possible security vulnerabilities and compliance issues of the new components through a risk scoring model; Based on the prediction results, determine the risk level of each component and classify and label it as low risk, medium risk, or high risk.

[0012] Preferably, the steps of constructing a dependency graph between open-source components include: Obtain the direct dependency relationship data between open-source components, including the other components and their version information that each component depends on; According to the strength and hierarchy of the dependency relationships, construct a dependency graph between components, where nodes represent components and edges represent dependency relationships; for each component, calculate the depth and breadth of its dependencies to quantify its influence in the system; Assign weights to each dependency relationship to complete the construction of the dependency graph.

[0013] Preferably, the steps of calculating the Laplacian matrix based on the dependency graph include: According to the constructed dependency graph, calculate the degree of each component, that is, the number of other components directly connected to this component; Construct a degree matrix, where each diagonal element represents the degree of the corresponding component; Construct an adjacency matrix to represent the direct dependency relationships between components, and the elements in the matrix represent the dependency strength between two components; calculate the Laplacian matrix through the difference between the degree matrix and the adjacency matrix.

[0014] Preferably, the steps of identifying key components and vulnerability propagation paths through eigenvalue analysis include: Calculate the eigenvalues and corresponding eigenvectors of the Laplacian matrix, and the eigenvalues represent the strength of mutual dependencies between components; Determine the importance of each component in the dependency graph according to the magnitude of the components in the eigenvector; Identify potential vulnerability propagation paths according to the distribution of the eigenvectors. The paths corresponding to the nodes with larger components in the eigenvector are the key paths for vulnerability propagation.

[0015] Preferably, the steps of generating security vulnerability repair suggestions and compliance review reports include: Based on the security vulnerability risk assessment results of the components, generate repair suggestions for each component. The repair suggestions include the priority of vulnerability repair, repair methods, and required resources; Through compliance analysis, identify issues related to license compatibility, generate a compliance review report, which includes incompatible license types and their risk levels; For security vulnerabilities and compliance issues, generate a comprehensive report by combining repair suggestions and compliance reviews, listing all vulnerabilities that need to be repaired, related compliance issues, and their repair measures.

[0016] The present invention also provides an open-source software code security and compliance control system, including: A data collection module for obtaining security vulnerability, license, and dependency data of open-source components; A matrix processing module for constructing a component-feature matrix and performing dimensionality reduction processing; A dependency analysis module for constructing a component dependency graph and calculating the Laplacian matrix; A risk prediction module for predicting security vulnerabilities and compliance risks based on the dimensionality reduction matrix and eigenvalue analysis; A report generation module for outputting security repair suggestions and compliance review reports.

[0017] The present invention provides a method for controlling the security and compliance of open-source software code. It has the following beneficial effects: 1. Through comprehensive prediction and analysis of security vulnerabilities of open-source components, the present invention can timely identify potential security risks in the system. By constructing a component-feature matrix and performing dimensionality reduction processing, the system can efficiently extract key security feature data, helping developers prioritize the handling of high-risk vulnerabilities and significantly improving the security of open-source software.

[0018] 2. The present invention can automatically analyze the license compatibility of open-source components and identify potential compliance issues. Through the compliance review report, developers can timely discover and resolve license conflicts, ensure that the project complies with open-source license agreements and laws and regulations, and avoid legal risks caused by compliance issues.

[0019] 3. Through vulnerability repair suggestions based on risk levels, the present invention can provide clear repair priorities, repair methods, and required resources for the development team. In this way, developers can efficiently arrange repair tasks, prioritize high-risk issues, thereby optimizing the vulnerability repair process and improving repair efficiency.

[0020] 4. By constructing a dependency graph among open-source components and combining Laplacian matrix and eigenvalue analysis, the present invention can accurately identify key components and vulnerability propagation paths in the system. This in-depth dependency analysis helps developers better understand the interactions among components, thereby effectively preventing the spread of vulnerabilities in the system.

[0021] 5. By generating a comprehensive report, the present invention provides a systematic and operable repair and review plan for the development team. The report not only summarizes all security vulnerabilities and compliance issues, but also arranges repair tasks according to the priority and repair timeline, ensuring the orderly progress of the repair work and improving the maintainability and long-term stability of the system. Description of the Drawings

[0022] Figure 1 is a schematic flow chart of the method of the present invention; Figure 2 is a schematic structural diagram of the system of the present invention.

[0023] Among them, 10. Data acquisition module; 20. Matrix processing module; 30. Dependency analysis module; 40. Risk prediction module; 50. Report generation module. Detailed Embodiments

[0024] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0025] Please refer to the attached Figure 1 , the present invention provides a method for security and compliance control of open-source software code, which comprehensively monitors, evaluates and controls the security and compliance of open-source software components through intelligent technical means.

[0026] As Figure 1 shown, the method for security and compliance control of open-source software code may include the following steps: S1. Collect characteristic data of open-source software components; S2. Based on the characteristic data, construct a component-characteristic matrix, perform dimensionality reduction processing, and extract key characteristic data; S3. Predict the security vulnerability risk and compliance risk of open-source components according to the dimensionality reduction processing result; S4. Construct a dependency relationship graph between open-source components; S5. Calculate the Laplacian matrix based on the dependency relationship graph, and identify key components and vulnerability propagation paths through eigenvalue analysis; S6. Generate security vulnerability repair suggestions and compliance review reports.

[0027] The following is a detailed description of each step in the method of the present invention, and a comprehensive elaboration is carried out on the specific implementation principles, technical details and processes of each step.

[0028] For step S1, in this embodiment, this step is the first step of the entire security and compliance control method, aiming to comprehensively collect multi-dimensional information such as the security, compliance, and dependencies of open-source software components, providing basic data support for subsequent analysis and processing. Specifically, the collected characteristic data mainly includes four categories: security vulnerability information, license information, version information, and dependency relationship data between components.

[0029] In this embodiment, when collecting the security vulnerability information of open-source software components, it is first necessary to obtain the vulnerability history record of each component. The vulnerability history record usually includes the known vulnerability ID, the time when the vulnerability was discovered, the severity of the vulnerability, and the description information of the vulnerability. This information can help developers quickly identify the potential risks of components and ensure the security of open-source software.

[0030] In addition, the vulnerability information should also include the assessment of the vulnerability level. The vulnerability level is usually scored according to standards such as CVSS (Common Vulnerability Scoring System). For example, a vulnerability may be marked as "low risk", "medium risk", or "high risk", which can help developers quickly judge the severity of the vulnerability and prioritize the repair of high-risk vulnerabilities.

[0031] The vulnerability repair status is also an important part of the security vulnerability information. The repair status of each vulnerability can include statuses such as "not repaired", "repairing", or "repaired", so that the system can have a clear understanding of the security status of each component. This data helps to track and manage the security vulnerabilities in the system and ensure that all known vulnerabilities are repaired in a timely manner.

[0032] The license information collection in this embodiment mainly involves evaluating the license type, license risk level, and license compatibility of open-source components. First, collect the license type of each open-source component, such as MIT, GPL, Apache, etc. Each license type has different usage restrictions and conditions. By understanding the license type of each component, the system can discover potential license conflict problems in advance, thus avoiding problems during compliance checks.

[0033] Secondly, the system needs to evaluate the risk level of the license. The license risk level is usually divided according to the terms of the license, the scope of application, and the impact on enterprise use. For example, some open-source licenses may require the source code to be open-sourced, or require that the code using this component must be compatible with the original license. These terms may have an impact on the compliance of the project.

[0034] The collection of license compatibility data is also an important part of this step. License compatibility data is used to evaluate whether the licenses of the components used in the current project can work together, especially in the case where multiple open-source components are used in the project. If there are conflicts in the licenses of multiple components, it may lead to project compliance issues and affect the use or release of the project. Therefore, collecting this data is crucial for preventing compliance risks.

[0035] In this embodiment, the collection of version information aims to ensure the tracking of different versions of open-source components. The content of version information collection includes the current version, historical versions, and version update records of each open-source component. The current version information can help the system identify the version in use and perform real-time security vulnerability repairs and update checks.

[0036] The collection of historical versions helps to trace the evolution process of components, which is particularly important when evaluating whether there are known vulnerabilities in historical versions. By collecting historical version information, the system can analyze the vulnerability repair history of components, determine whether the new version has addressed the vulnerabilities in the old version, and avoid using old versions with known vulnerabilities.

[0037] The version update records contain the update history of each open-source component. The system can understand the evolution process of components through these records, determine which functions or features have changed in the updates, whether new security vulnerabilities have been introduced, or whether the license terms have changed. This information can provide a basis for subsequent risk prediction and repair suggestions.

[0038] In this embodiment, collecting the dependency relationship data between open-source components is a very important step. Open-source software usually consists of multiple components, and there are complex dependency relationships between these components. Collecting the dependencies of each component and the list of components that depend on this component can provide basic data for subsequent vulnerability propagation path analysis and the construction of dependency graphs.

[0039] The dependencies of a component refer to the situation where a component depends on other components, which is usually identified and collected through package management tools (such as npm, pip, Maven, etc.). The list of components that are depended on indicates which other components depend on the current component. By collecting dependency relationships, the system can identify components with high dependency levels, which may play a key role in the system, and the spread of their security vulnerabilities may affect a large number of other components.

[0040] For example, if a core component has a vulnerability and multiple other components depend on it, then the vulnerability may quickly spread throughout the system, resulting in a wide range of security risks. Therefore, understanding and collecting the dependency relationship data between components is crucial for formulating effective repair plans and prevention strategies.

[0041] For step S2, in this embodiment, this step includes two parts. First, a component-feature matrix is constructed based on the collected feature data, and then matrix factorization technology is used to reduce the dimension of this matrix to extract key feature data. The core of this step is to construct a matrix and perform dimension reduction to help the system effectively extract the most critical features affecting security and compliance, providing basic data for subsequent risk assessment and prediction.

[0042] In this embodiment, first, various feature data of the collected open-source software components need to be classified and sorted. Specifically, the feature data includes security vulnerability information, license information, version information, and dependency relationship information. For each open-source software component, its corresponding feature data is classified, and a corresponding feature label is assigned to each component.

[0043] For example, the security vulnerability information may include vulnerability ID, vulnerability level, vulnerability description, and vulnerability repair status, etc.; the license information includes license type, risk level, and compatibility situation; the version information includes the current version, historical versions, and version update records; the dependency relationship information includes the dependencies of this component and the list of components it depends on. For each component, these feature information need to be regarded as different dimensions.

[0044] When converting these data into matrix form, the rows of the matrix represent different open-source components, and the columns represent various features. Each element in the matrix represents the degree of association between the component and the feature. For example, a certain element in the matrix can indicate whether a certain component has a certain security vulnerability, or whether this component meets the requirements of a certain license. The construction process of this matrix is based on the collected feature data, and various feature information is uniformly represented through a standardization method, enabling data between different components and features to be processed within a unified framework.

[0045] After constructing the component-feature matrix, this embodiment further uses matrix factorization technology to reduce the dimension of the matrix. The purpose of matrix factorization is to transform the original high-dimensional matrix into several low-dimensional matrix factors, which can extract the main information in the original matrix and remove redundant information. This process is completed by using dimension reduction algorithms such as Singular Value Decomposition (SVD).

[0046] Specifically, the Singular Value Decomposition algorithm decomposes matrix A into the product of three matrices, expressed as: A = U∑V T where U and V respectively represent the feature matrices of components and features, ∑ is a diagonal matrix containing the singular values of matrix A. By selecting and retaining the first k most informative singular values and their corresponding eigenvectors, a low-dimensional matrix can be extracted. That is: The "singular values" in this step reflect the importance of each feature to the component features, while the "eigenvectors" provide the deep structure of the relationships between components. Through dimensionality reduction, we can retain the most critical feature data, ensure that the matrix after dimensionality reduction can accurately represent the key features in the original matrix, and remove the redundant and unimportant features for analysis.

[0047] The low-dimensional matrix after dimensionality reduction can be further used for the reconstruction of components, thereby evaluating the importance of each feature in the components. For example, certain features may have a higher weight in security vulnerability prediction, while certain features may have a greater impact on compliance issues. Through this method, the system can identify which features are the key features determining whether an open-source component is secure and compliant.

[0048] In the low-dimensional matrix after dimensionality reduction, the feature vectors of each component represent the security and compliance characteristics of the component. These feature vectors can help us evaluate various features of the component, and then determine which features have the greatest impact on the security and compliance of the component.

[0049] For example, if the feature component related to "license compliance" in the feature vector of a certain component is relatively large, it can be determined that the importance of this component in terms of compliance is relatively high. In this way, the system can identify the most important features in different dimensions, further optimizing the accuracy of security vulnerability and compliance risk prediction.

[0050] The reconstruction process of the low-dimensional matrix further verifies the effectiveness of the dimensionality reduction result. By mapping the low-dimensional matrix back to the original matrix space, the system can reconstruct the security and compliance characteristics of the components and analyze potential risks. If a certain feature is not retained in the low-dimensional representation, it indicates that this feature has less impact on security and compliance and can be ignored in subsequent risk assessments.

[0051] For step S3, in this embodiment, this step mainly involves using the low-dimensional matrix after the aforementioned dimensionality reduction to predict the security vulnerability risk and compliance risk of open-source components. The core of this step is to evaluate the potential risks of new components by performing similarity matching on the feature vectors of each component in the low-dimensional matrix with the known risk data of historical components.

[0052] First, based on the low-dimensional matrix after dimensionality reduction, each open-source component can be represented by a feature vector. These feature vectors contain data on the security, compliance, and other key features of the components. Each dimension in the feature vector corresponds to the importance of the component in a specific feature. For example, one dimension may represent the vulnerability risk of the component, and another dimension may reflect the license compliance situation of the component.

[0053] By vectorizing each component of the low-dimensional matrix, we can transform each component into a low-dimensional vector and then perform matching based on the similarity between the vectors. Exemplarily, similarity matching can be calculated through algorithms such as cosine similarity. The formula for cosine similarity is as follows: where A and B represent the feature vectors of two components respectively, A·B is the inner product of the vectors, and ∥A∥ and ∥B∥ are the norms of vectors A and B respectively. By calculating the similarity between two vectors, we can judge the similarity degree of the new component and the historical component in terms of security vulnerabilities and compliance.

[0054] When the similarity between the new component and the historical component is relatively high, the system can infer that the new component may face security vulnerabilities or compliance issues similar to those of the historical component. Therefore, through similarity matching, the system can predict the possible risk types for the new component based on historical data.

[0055] After completing the similarity matching, the next step is to perform risk scoring on the components with relatively high similarity. This process is achieved through a risk scoring model. The risk scoring model is usually based on machine learning algorithms and may be trained using algorithms such as regression analysis, support vector machine (SVM), or other classification algorithms to evaluate the risk of components according to their feature vectors.

[0056] For example, the model can evaluate the security vulnerability risk and compliance risk of components based on features such as vulnerability levels, license conflict situations, and update situations of historical versions in historical data. By learning the existing data, the model can identify which features played important roles in past vulnerability occurrences and which features have strong correlations with compliance issues. After training, the model can predict the risk level of the new component according to its feature vector.

[0057] The risk score output by the risk scoring model represents the risk level that the new component may face. By calculating the risk scores of each component, the system can classify the components into three categories: low risk, medium risk, or high risk.

[0058] Finally, based on the calculated risk scores, the system will classify each component into a risk level. Generally, risk scores can be divided into three levels according to a set threshold: low risk, medium risk, and high risk. Specifically, when the risk score is below a certain set threshold, the component is marked as low risk; when the risk score is between two thresholds, it is marked as medium risk; if the risk score is higher than the threshold, it is marked as high risk.

[0059] For example, if the risk score of a component is 0.8 and this score exceeds the high-risk threshold of 0.7, then the component is marked as high risk, indicating that it may have relatively serious security vulnerabilities or compliance issues. On the contrary, if the risk score is 0.2, which is lower than the low-risk threshold of 0.3, then the component is marked as low risk, indicating that it has relatively few security and compliance issues.

[0060] In actual operation, this classification of risk levels provides a clear order of priority for developers and security teams. For high-risk components, the system will recommend taking immediate repair measures, while low-risk components can have their repair times arranged flexibly according to the needs of the project.

[0061] For step S4, in this embodiment, constructing a dependency graph is to comprehensively understand the interdependencies between open-source components and further provide support for the analysis of vulnerability propagation paths and risk assessment. This step mainly includes obtaining dependency relationship data, constructing a dependency graph, calculating the dependency levels and breadths of components, and assigning weights to the dependency relationships, etc.

[0062] In the first step of constructing a dependency graph, it is necessary to obtain the direct dependency relationship data of each open-source component. This data usually includes the other components that each component depends on and the corresponding version information. The dependency relationships can be obtained through the package management tools of open-source components (such as Maven, npm, pip, etc.).

[0063] For example, assume that component C1 depends on component C2 and component C3, and the version of component C2 is The version of component C3 is Then the dependency relationship data will clearly record the relationships between component C1 and components C2 and C3, as well as their version correspondence. In this way, the dependency situation of each component in the project can be clearly understood. The direct dependency relationships not only include library dependencies between components but may also include aspects such as version control and API dependencies.

[0064] After obtaining the dependency data, the next step is to construct a dependency graph among open-source components based on this data. The construction of the dependency graph can be achieved through a graph model in graph theory, where each component serves as a node in the graph, and the dependencies between components serve as the edges. The direction of the edge usually indicates the direction of the dependency, that is, it indicates that one component depends on another component.

[0065] Specifically, the nodes in the dependency graph represent the respective open-source components, and the edges represent the dependencies between components. For example, if component C1 depends on component C2, then there will be a directed edge from node C1 to node C2. This graph structure can intuitively reflect the dependency structure among the components in the open-source software system, providing a visual basis for subsequent risk analysis.

[0066] The construction of the dependency graph is not just simply connecting nodes. It also needs to consider the strength and level of the dependencies. The connection strength between nodes can be measured by factors such as the dependency frequency and importance between components, while the level indicates the depth of a component's dependency or its position in the system. Different dependencies may affect the vulnerability propagation path and compliance risk of components, so the construction of this graph is particularly important.

[0067] Based on the construction of the dependency graph, in this embodiment, the dependency level depth and dependency breadth of each component are further calculated. These two parameters help to quantify the influence of a component in the system.

[0068] The dependency level depth refers to the number of intermediate nodes passed through from a certain component to reach the farthest component. The level depth reflects the depth of a component's dependency in the entire system. For example, component C1 depends on component C2, and component C2 depends on component C3, then the dependency depth of component C1 is 2.

[0069] The dependency breadth refers to the number of other components that a component directly depends on, or the number of components that depend on this component. The dependency breadth can reflect the influence scope of a component in the entire system. For example, if component C1 is depended on by multiple components, then the dependency breadth of component C1 is larger, which means that component C1 has a more extensive influence on the entire system. The dependency breadth can be expressed by the following formula: where, is an indicator function, indicating whether component C1 is depended on by component C i and n is the total number of dependency relationships. Components with a larger breadth usually have a greater influence in the system.

[0070] To further improve the dependency graph, in this embodiment, weights are assigned to each dependency relationship in the graph. These weights are used to quantify the strength of the dependency relationship and can help us better understand the importance of dependencies between components.

[0071] The method of assigning weights to dependency relationships can be based on multiple factors, such as the strength, frequency, core nature of components, usage of components, etc. Specifically, if a component is a core component in the system and another component depends on it, the weight of this dependency relationship should be higher. Conversely, if the dependency relationship between components is relatively indirect and the dependency frequency is low, a lower weight can be assigned.

[0072] Suppose each dependency relationship E ij represents that component C i depends on component C j , then its weight w ij can be expressed as: w ij = f(frequency, importance, core nature) where f is a function that calculates the weight based on factors such as the frequency of the dependency relationship, the core nature and importance of components. The larger the weight, the greater the impact of this dependency relationship on the system, and the higher the potential risk may be.

[0073] The formula for weight assignment can adopt the weighted graph algorithm. According to the strength and frequency of the dependency relationship, a weight value is assigned to each edge. The larger the weight, the greater the impact of this component on the system. When there are security risks or compliance issues, this dependency relationship is given priority for handling.

[0074] For step S5, in this embodiment, step S5 covers two parts. First, the Laplacian matrix is calculated based on the dependency graph, and second, the key components and vulnerability propagation paths in the system are identified through eigenvalue analysis of the Laplacian matrix. The core of this step lies in quantifying the dependency relationship between components through the Laplacian matrix and eigenvalue analysis in graph theory, and further identifying potential risk points in the system.

[0075] First, the degree of each component in the dependency graph needs to be calculated. The degree of a component represents the number of other components directly connected to this component. The degree reflects the connection strength of a component in the dependency graph, that is, the influence of this component. Suppose each component in the dependency graph is represented as a node, and the dependency relationship between components is represented as an edge. The calculation method of the degree is: where d i represents the degree of node C i , A ij is the element at the (i, j) position in the adjacency matrix. If component Ci is dependent on C j then A ij = 1, otherwise 0. By calculating the degrees of all nodes, we can obtain the degrees of each component, providing a basis for subsequent matrix calculations.

[0076] Next, construct the degree matrix D. The degree matrix is a diagonal matrix, where each diagonal element D ii represents the degree of component C i . The structure of the degree matrix is as follows: In addition, an adjacency matrix A also needs to be constructed, which represents the direct dependencies between components. The element A ij in the matrix represents whether component C i depends on component C j . The adjacency matrix can clearly reflect the dependency structure between components.

[0077] Once the degree matrix and the adjacency matrix are calculated, the Laplacian matrix L can be calculated through their difference. The calculation formula for the Laplacian matrix L is: L = D - A where D is the degree matrix and A is the adjacency matrix. The Laplacian matrix is an important matrix in graph theory for representing the relationships between nodes, and its element L ij represents the relationship strength between nodes C i and C j . Specifically, each element of the Laplacian matrix provides information about the interaction between components, reflecting the degree of mutual dependence of components in the system.

[0078] After calculating the Laplacian matrix, the next step is to identify critical components and vulnerability propagation paths through eigenvalue analysis. Eigenvalue analysis is an important tool in graph theory for analyzing graph structures, which can help identify important nodes and potential vulnerability propagation paths in the system.

[0079] Eigenvalues and eigenvectors are important components of the Laplacian matrix. The eigenvalue λ and the eigenvector v satisfy the following equation: Lv = λv where L is the Laplacian matrix, v is the eigenvector, and λ is the corresponding eigenvalue. The eigenvalue λ represents the strength of the mutual dependence between nodes, and the eigenvector v represents the relative importance position of the nodes in the graph.

[0080] By calculating the eigenvalues and eigenvectors of the Laplacian matrix, the influence of each component in the system can be obtained. In the dependency graph, components with larger eigenvalues are usually key components in the system. They have stronger dependencies with other components and pose a greater risk of vulnerability propagation. These key components are crucial for the security and stability of the system. If one of the key components fails, it may cause problems in the entire system.

[0081] Exemplarily, eigenvalue analysis can help us identify that certain components may be "risk propagation sources" because they have strong dependencies with multiple other components. These components usually need to be repaired for security and compliance review first.

[0082] By analyzing the magnitudes of the components of the eigenvector, the vulnerability propagation paths can be further identified. The paths corresponding to the nodes with larger components in the eigenvector are usually considered key paths for vulnerability propagation. These paths connect multiple important components and are the main channels for vulnerabilities to spread from one component to another.

[0083] The larger components in the eigenvector indicate the importance of the nodes in the dependency graph. These nodes are usually high-risk components. By tracking these nodes, potential vulnerability propagation paths can be identified. For example, if a component has a large component in the eigenvector and has direct dependencies with multiple other components, it may be a key node for vulnerability propagation, and its problems may affect multiple other components.

[0084] For step S6, in this embodiment, the goal of this step is to provide specific repair suggestions based on the security vulnerabilities and compliance risks evaluated in the previous steps, and generate a detailed report to help developers and security teams repair the vulnerabilities in the system in a timely manner and ensure project compliance.

[0085] In this embodiment, based on the results of the component-based security vulnerability risk assessment, the system will first generate repair suggestions for each component. The content of the repair suggestions includes the following aspects: Priority of vulnerability repair: According to the risk level of the vulnerability, the repair suggestions will clearly indicate the repair priority of each vulnerability. Usually, vulnerabilities with higher risk levels should be repaired first. For example, if the vulnerability risk is evaluated as "high" and the repair priority is "urgent", it means that it needs to be repaired as soon as possible; if the vulnerability risk is low, the repair priority can be appropriately reduced. The specific priority assignment can be adjusted according to the actual needs of the system.

[0086] Remediation Method: The remediation method includes detailed technical solutions to help developers understand how to eliminate vulnerabilities. For example, if the vulnerability is due to the use of an outdated library version, it can be fixed by upgrading to a more secure version; if the vulnerability is related to improper configuration or missing security policies, specific configuration suggestions can be provided. The description of the remediation method needs to be concise, specific, and take into account the implementation capabilities of the development team.

[0087] Required Resources: Each remediation suggestion will also include the resources required to fix the vulnerability. The types of resources can include developer time, test equipment, external tools or libraries, etc. This section helps to evaluate the workload and cost required for remediation and assists the project manager in resource allocation.

[0088] Specifically, the system will generate detailed remediation steps and priority rankings for each vulnerability based on the type, severity, and impact scope of the vulnerability, so that the development team can fix the vulnerabilities according to this priority.

[0089] In this embodiment, the compliance review report helps the development team identify compliance issues related to licenses by analyzing the license compatibility of open-source components. When generating the compliance review report, the system will perform the following tasks: Identify incompatible license types: Based on the license types of open-source components, the system will check whether there are license conflicts in the open-source components used in the project. For example, some open-source licenses require the disclosure of source code, while other licenses require the modified code to maintain the same license. If the licenses between components are incompatible, it may violate legal regulations and lead to compliance issues. The report will list all components with license compatibility issues and clearly indicate the conflicting license types.

[0090] Risk Level: For each license conflict issue, the system will evaluate its compliance risk level. The compliance risk level is usually divided into "low risk", "medium risk", and "high risk". For example, if the license requirements of a certain component conflict with the project's usage policy and cannot be resolved, that component will be marked as a "high risk" issue, indicating that it needs to be processed immediately. The system will generate a detailed risk level description based on the severity of each issue.

[0091] The compliance review report will list in detail all license issues that need to be reviewed and their corresponding risk levels, and provide suggestions for handling these issues to ensure that the project complies with laws and regulations.

[0092] Based on the remediation suggestions and the compliance review report, this embodiment further generates a comprehensive report. The comprehensive report combines the security vulnerability remediation suggestions and the results of the compliance review, summarizing all the vulnerabilities that need to be fixed, the related compliance issues, and their remediation measures. The generation process of the comprehensive report includes the following key points: Summarize security vulnerabilities: The system summarizes all components evaluated as having vulnerabilities and lists the repair suggestions for each component. Each repair suggestion will include the priority of the vulnerability repair, the repair method, and the required resources, providing developers with a complete repair path.

[0093] Handling compliance issues: The report will list all license compatibility issues that need to be addressed and provide handling suggestions for each issue. For example, if there is a conflict in the license of a certain component, the report will suggest whether it is necessary to replace the component or modify the license to be consistent with the usage requirements of the project.

[0094] Repair measures and timeline: The comprehensive report will also provide a repair timeline for each vulnerability and compliance issue, clearly indicating when the repair should be completed. The report can generate a repair plan based on the repair priority to help the development team reasonably arrange the repair work.

[0095] Assignment of responsible persons: To ensure the smooth progress of the repair work, the report can also assign the responsible persons for each vulnerability and compliance issue. In this way, developers or the security team can, according to their own workloads, assign and handle vulnerabilities according to the priority.

[0096] The goal of the comprehensive report is to provide the project team with a comprehensive and actionable repair and compliance review plan to help the team handle potential security vulnerabilities and compliance issues on time and according to priority.

[0097] Generally speaking, the present invention collects and analyzes the security vulnerabilities, licenses, version information of open-source software components and the dependency relationship data between components, constructs a component-feature matrix and performs dimensionality reduction processing, and predicts the security vulnerability risks and compliance risks of components. Based on the construction of the dependency graph and the analysis of the Laplacian matrix, the system can identify key components and potential vulnerability propagation paths, and generate detailed repair suggestions and compliance review reports according to the risk assessment. Finally, the comprehensive report provides the development team with a systematic repair plan to ensure the security and compliance of open-source software.

[0098] The open-source software code security and compliance control system described below can be correspondingly referred to the open-source software code security and compliance control method described above.

[0099] Please refer to the appendix Figure 2 , the present invention also provides an open-source software code security and compliance control system, including: A data collection module 10 for obtaining the security vulnerabilities, licenses, and dependency relationship data of open-source components; A matrix processing module 20 for constructing a component-feature matrix and performing dimensionality reduction processing; A dependency analysis module 30 for constructing a component dependency graph and calculating the Laplacian matrix; A risk prediction module 40, configured to predict security vulnerabilities and compliance risks based on dimensionality reduction matrices and eigenvalue analysis; A report generation module 50, configured to output security repair suggestions and compliance review reports.

[0100] The system of this embodiment can be used to execute the above method embodiment, and its principle and technical effects are similar, which will not be elaborated here.

[0101] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principle and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for the security and compliance control of open source software code, characterized in that: The following steps are involved: Collecting characteristic data of open source software components, the characteristic data including at least security vulnerability information, license information, version information, and dependency information; Building a component-characteristic matrix based on the characteristic data, and performing dimension reduction processing on the matrix using matrix decomposition technology to extract key characteristic data; Predict the security vulnerability risk and compliance risk of open source components based on the dimensionality reduction processing results; Construct a dependency graph between open source components, wherein the dependency graph has components as nodes and dependencies as edges; Calculate the Laplacian matrix based on the dependency graph, and identify key components and vulnerability propagation paths through eigenvalue analysis; Generate security vulnerability remediation recommendations and compliance review reports.

2. The open source software code security and compliance management method according to claim 1, characterized in that: The step of collecting characteristic data of open source software components includes: Obtain security vulnerability information of each component, the security vulnerability information including vulnerability history, vulnerability level and vulnerability repair status; Obtaining license information of each component, wherein the license information includes license type, license risk level, and license compatibility data; Obtaining version information of each component, including the current version, historical versions, and version update records; Dependency data between components is obtained, wherein the data includes dependencies of each component and a list of dependent components.

3. The open source software code security and compliance management method according to claim 1, characterized in that: The step of constructing a component-characteristic matrix based on the characteristic data comprises: Classify the security vulnerability information, license information, version information, and dependency information of open source software components by component, and assign corresponding feature labels to each component; The characteristic data of all components are organized into a matrix form, where the rows of the matrix represent different components, the columns represent the various characteristics, and each matrix element represents the correlation between the component and the characteristic.

4. The open source software code security and compliance management method according to claim 3, characterized in that: The step of reducing the dimension of the matrix by using matrix decomposition technology to extract key characteristic data includes: Perform matrix decomposition on the component-feature matrix and use a dimensionality reduction algorithm to decompose it into several matrix factors; Select the top k most informative singular values ​​and corresponding eigenvectors to construct a low-dimensional representation matrix, ensuring that the reduced-dimensional matrix can accurately represent the key features of the original matrix; Reconstruct components using low-dimensional matrix representations, assess the importance of individual features in a component, and identify key features that impact safety and compliance.

5. The open source software code security and compliance management method according to claim 1, characterized in that: The step of predicting the security vulnerability risk and compliance risk of the open source component according to the dimensionality reduction processing result includes: Based on the reduced low-dimensional matrix, the feature vector of each component is calculated and similarity matching is performed with known security vulnerabilities or compliance issues of historical components; Assign risk scores to components with high similarity, and use the risk scoring model to predict possible security vulnerabilities and compliance issues of new components; Based on the prediction results, the risk level of each component is determined and classified as low risk, medium risk or high risk.

6. The open source software code security and compliance management method according to claim 1, characterized in that: The step of constructing a dependency graph between open source components includes: Obtain direct dependency data between open source components, including other components that each component depends on and their version information; Based on the strength and level of dependencies, a dependency graph is constructed between components, where nodes represent components and edges represent dependencies. For each component, calculate the hierarchical depth and breadth of its dependencies to quantify its influence in the system; Assign a weight to each dependency and complete the construction of the dependency graph.

7. The open source software code security and compliance management method according to claim 1, characterized in that: The step of calculating the Laplacian matrix based on the dependency graph comprises: Based on the constructed dependency graph, calculate the degree of each component, that is, the number of other components directly connected to it; Construct a degree matrix where each diagonal element represents the degree of the corresponding component; Construct an adjacency matrix to represent the direct dependency between components. The elements in the matrix represent the dependency strength between two components. The Laplacian matrix is ​​calculated by taking the difference between the degree matrix and the adjacency matrix.

8. The open source software code security and compliance management method according to claim 7, characterized in that: The step of identifying key components and vulnerability propagation paths through feature value analysis includes: Calculate the eigenvalues ​​and corresponding eigenvectors of the Laplacian matrix. The eigenvalues ​​represent the strength of the interdependence between components. Determine the importance of each component in the dependency graph based on the size of the components in the feature vector; According to the distribution of feature vectors, potential vulnerability propagation paths are identified, and the paths corresponding to the nodes with larger components in the feature vectors are the key paths for vulnerability propagation.

9. The open source software code security and compliance management method according to claim 1, characterized in that: The steps of generating security vulnerability remediation suggestions and compliance review reports include: Generate repair suggestions for each component based on the component security vulnerability risk assessment results. The repair suggestions include the priority of vulnerability repair, repair method, and required resources. Through compliance analysis, issues related to license compatibility are identified and a compliance review report is generated, which includes incompatible license types and their risk levels. For security vulnerabilities and compliance issues, a comprehensive report is generated by combining repair suggestions and compliance reviews. The report lists all vulnerabilities that need to be repaired, related compliance issues and their repair measures.

10. An open source software code security and compliance management system, used to execute the open source software code security and compliance management method according to any one of claims 1 to 9, characterized in that: include: Data collection module, used to obtain security vulnerabilities, licenses, and dependency data of open source components; Matrix processing module, used to construct component-feature matrix and perform dimensionality reduction; Dependency analysis module, used to build component dependency graphs and calculate Laplacian matrices; Risk prediction module, used to predict security vulnerabilities and compliance risks based on dimensionality reduction matrix and eigenvalue analysis; The report generation module is used to output security repair suggestions and compliance review reports.

Images