Software development system management method and system based on big data processing

Abstract

The invention relates to the technical field of software technology and big data processing, and discloses a software development system management method and system based on big data processing. The method comprises the following steps: acquiring interaction data and version updating records of modules in a software system, and analyzing a dependency relationship among the modules to obtain an initial path set; according to the initial path set, state changes of the paths in different environments are compared to determine the risk variation degree, and the paths with high variation risks are clustered to obtain a high-risk path group; analyzing a hidden danger amplification possibility of the high-risk path group and determining a specific service influence range, and further positioning a core bottleneck point of a propagation path; and comparing the core bottleneck point with the version updating record, and determining a key path of vulnerability propagation. By establishing an analysis closed loop from dynamic risk identification to service influence evaluation, the problem of low vulnerability propagation path detection precision in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the fields of software technology and big data processing technology, and in particular to a software development system management method and system based on big data processing. Background Technology

[0002] In the current information age, the security management of software development systems is crucial for ensuring business stability and data security. As systems become increasingly larger and more complex, effectively identifying and curbing the spread of security vulnerabilities within these systems has become a major technical challenge that urgently needs to be addressed within the industry.

[0003] In existing technologies, security management methods often focus on immediate patching of vulnerabilities, neglecting the potential spread risks of vulnerabilities during system evolution and environment switching. When faced with complex system environments, these methods often struggle to comprehensively capture the dynamic changes of vulnerabilities across different modules and versions, resulting in a lack of forward-looking security strategies. A deeper technical challenge lies in the highly concealed and cross-domain nature of vulnerability propagation paths. Vulnerabilities may silently transfer with the interaction of system modules and exhibit different manifestations due to version updates or environmental changes. This makes it difficult to accurately pinpoint the key links in vulnerability propagation, even with big data processing techniques for log analysis. For example, during a system version update, a vulnerability in a data processing module might affect the payment function module through interface calls. However, due to a lack of comprehensive analysis of module interactions, the problem is only discovered after actual economic losses have occurred.

[0004] Therefore, existing technologies suffer from low accuracy in detecting vulnerability propagation paths. Summary of the Invention

[0005] This invention provides a software development system management method and system based on big data processing to solve the problem of low accuracy in detecting vulnerability propagation paths in existing technologies.

[0006] Firstly, in order to solve the above-mentioned technical problems, the present invention provides a software development system management method based on big data processing, comprising:

[0007] Obtain interaction data and version update records of all modules in the software system, analyze the dependencies between the modules, and obtain an initial path set;

[0008] Based on the initial set of paths, the state changes of each path under different environments are compared to determine the degree of path risk variation;

[0009] Based on the degree of variation in path risk, a filtering and aggregation operation is performed to obtain a high-risk path group;

[0010] Analyze the dependencies within the high-risk path group to determine if there is any potential for amplification, and obtain the results of the potential for amplification judgment;

[0011] If the result of the potential hazard amplification judgment is yes, then the business impact data at the end of the path is obtained, and the specific impact range is determined in combination with the interaction data;

[0012] Based on the specific scope of impact, the initial path set is filtered to determine the core bottlenecks of the propagation path;

[0013] Obtain the version update records related to the core bottleneck, compare the version update records with the core bottleneck, determine the critical path of vulnerability propagation, and generate vulnerability detection results.

[0014] Preferably, the step of acquiring interaction data and version update records of all modules in the software system, and analyzing the dependencies between the modules to obtain an initial path set includes:

[0015] The interaction data and version update records of each module in the software system are collected to obtain the initial interaction dataset;

[0016] Based on the initial interaction dataset, a graph traversal algorithm is used to parse the dependencies between the modules to obtain a preliminary dependency path graph.

[0017] Based on the preliminary dependency path graph, the interaction data of the modules corresponding to the version update are analyzed to obtain interaction performance indicators;

[0018] The interaction performance metrics are compared with a preset performance benchmark. If the comparison result is abnormal, the corresponding module is marked as a high-risk node, and the initial path set is determined based on the high-risk node.

[0019] Preferably, the step of determining the degree of path risk variation by comparing the state changes of each path under different environments based on the initial path set includes:

[0020] Extract the state of nodes within each path in the initial path set at different time points to obtain node change trajectory information;

[0021] Obtain the environmental parameters during the version update, and calculate the node's adaptability based on the node change trajectory information and the environmental parameters;

[0022] If the degree of adaptation is lower than the preset adaptation threshold, the node is determined to be a risk node, and the potential threat distribution range is obtained;

[0023] Based on the distribution range of the potential threats, the changes in the path are analyzed and the variation data of the risk nodes are extracted to determine the degree of variation of the path risk.

[0024] Preferably, the step of performing screening and aggregation operations based on the degree of variation in path risk to obtain a high-risk path group includes:

[0025] Obtain the connection relationship of each node in the initial path set. If the dependency between nodes is higher than the preset dependency threshold, then group the nodes into the same set to obtain the preliminary node grouping result.

[0026] Based on the preliminary node grouping results, the variation characteristics of each node under different environments are extracted. If the variation amplitude of the variation characteristics exceeds the preset variation amplitude threshold, a high-risk node subset is determined.

[0027] Based on the high-risk node subset, nodes with similar variation characteristics are grouped, and the paths containing nodes within the group divisions are identified as the high-risk path groups.

[0028] Preferably, the step of analyzing the dependencies within the high-risk path group to determine whether there is a potential risk amplification and obtaining a potential risk amplification judgment result includes:

[0029] Identify core interaction modules from the high-risk path groups, parse the path interaction logic within the groups, and obtain the association weights between modules and paths;

[0030] The node connection strength is determined based on the association weight. If the node connection strength is higher than the preset connection strength threshold, the dependency chain length and group cohesion are analyzed to determine the triggering conditions for potential risks.

[0031] The hazard triggering conditions are compared with the preset hazard amplification standards to obtain the hazard amplification judgment result.

[0032] Preferably, if the hazard amplification judgment result is yes, then the business impact data at the end of the path is obtained, and combined with the interaction data, the specific impact range is determined, including:

[0033] Based on the results of the hazard amplification judgment, paths with potential hazard amplification are selected from the high-risk path group;

[0034] From the path where the potential for amplification is identified, the end point of the path is determined, and the business scope and impact depth data of the end point of the path are obtained. Then, the correlation between the end points of the path is analyzed to obtain the preliminary impact duration.

[0035] Based on the preliminary impact duration and the interaction data, the interaction frequency and intensity are analyzed to determine the distribution characteristics of the potential hazard scale.

[0036] By combining the distribution characteristics of the potential hazard scale with the initial impact duration, a comprehensive analysis is conducted to determine the specific impact range.

[0037] Preferably, the step of filtering the initial path set and determining the core bottleneck points of the propagation path based on the specific scope of influence includes:

[0038] Based on the specific scope of impact, the distribution data of key nodes in the initial path set are analyzed to obtain preliminary bottleneck judgment results;

[0039] Based on the preliminary bottleneck assessment results, the correlation information between potential bottlenecks and propagation paths is analyzed to determine the specific location of the bottleneck point.

[0040] Analyze the interaction intensity at the specific location of the bottleneck point. If the interaction intensity is higher than a preset intensity threshold, then the specific location of the bottleneck point is determined as the core bottleneck point of the propagation path.

[0041] Preferably, the step of obtaining the version update records related to the core bottleneck, comparing the version update records with the core bottleneck, determining the critical path of vulnerability propagation, and generating vulnerability detection results includes:

[0042] Extract version difference data related to the core bottleneck from the version update records to obtain the version difference distribution;

[0043] Based on the version difference distribution, analyze the path data of the core bottleneck points to determine the key locations for vulnerability localization;

[0044] Based on the key locations of the vulnerability, the matching accuracy with the path data of the core bottleneck point is calculated. If the matching accuracy is higher than a preset matching threshold, the critical path of the vulnerability propagation is determined, and the vulnerability detection result is generated.

[0045] Secondly, this invention provides a software development system management system based on big data processing, comprising:

[0046] The initial path identification module is used to acquire the interaction data and version update records of all modules in the software system, and analyze the dependencies between the modules to obtain the initial path set;

[0047] The risk variation analysis module is used to compare the state changes of each path under different environments based on the initial path set to determine the degree of path risk variation.

[0048] The high-risk group segmentation module is used to perform filtering and aggregation operations based on the degree of variation of the path risk to obtain high-risk path groups;

[0049] The hidden danger amplification judgment module is used to analyze the dependency relationship within the high-risk path group, determine whether there is hidden danger amplification, and obtain the hidden danger amplification judgment result;

[0050] The impact range determination module is used to obtain the business impact data at the end of the path and determine the specific impact range in combination with the interaction data if the hazard amplification judgment result is yes.

[0051] The core bottleneck location module is used to filter the initial path set according to the specific impact range and determine the core bottleneck point of the propagation path.

[0052] The path confirmation and result generation module is used to obtain the version update records related to the core bottleneck, compare the version update records with the core bottleneck, determine the critical path for vulnerability propagation, and generate vulnerability detection results.

[0053] Thirdly, the present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the software development system management method based on big data processing described in any one of the above.

[0054] Fourthly, the present invention also provides a computer-readable storage medium comprising a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the software development system management method based on big data processing described above.

[0055] Compared with the prior art, the present invention has the following beneficial effects:

[0056] (1) This invention obtains the interaction data and version update records of all modules in the software system and determines the degree of path risk variation by combining the state changes under different environments, thus transforming static vulnerability analysis into dynamic propagation path tracing. This process solves the shortcomings of existing technologies that are difficult to fully capture the dynamic changes of vulnerabilities due to ignoring system evolution and environment switching, thereby accurately identifying hidden potential risks that change with the environment and improving the comprehensiveness and foresight of risk identification.

[0057] (2) This invention analyzes the potential for amplification of hidden dangers in high-risk paths and combines business impact data to reverse-filter the initial path set, thereby locating the core bottleneck. This global analysis method of "inferring the technical root cause from the business impact" solves the shortcomings of existing technologies that only focus on immediate repairs, lack an overall perspective, and are difficult to understand the root cause of problems. It ensures that the system can prioritize locating and handling the core risks that pose the greatest threat to the business, thereby improving the efficiency and accuracy of security management.

[0058] (3) This invention establishes a complete chain of evidence from specific version changes to technical bottlenecks and then to business impacts by comparing and verifying the accuracy of the identified core bottlenecks with the relevant version update records. This closed-loop verification process solves the problem that existing technologies lack a comprehensive understanding of the interaction relationships, resulting in vague vulnerability location and difficulty in tracing the source. It achieves accurate tracing of the vulnerability propagation path and provides a reliable basis for quickly repairing and preventing similar problems. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the software development system management method based on big data processing provided in the first embodiment of the present invention;

[0060] Figure 2 This is a schematic diagram of the management system structure of the software development system based on big data processing provided in the second embodiment of the present invention. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] Reference Figure 1 The first embodiment of the present invention provides a software development system management method based on big data processing, including the following steps:

[0063] S11, Obtain the interaction data and version update records of all modules in the software system, and analyze the dependencies between the modules to obtain the initial path set;

[0064] S12, Based on the initial set of paths, compare the state changes of each path under different environments to determine the degree of path risk variation;

[0065] S13, Based on the degree of variation of the path risk, perform screening and aggregation operations to obtain a high-risk path group;

[0066] S14, Analyze the dependencies within the high-risk path group to determine whether there is a potential risk amplification and obtain the potential risk amplification judgment result;

[0067] S15, if the result of the potential hazard amplification judgment is yes, then obtain the business impact data at the end of the path, and combine it with the interaction data to determine the specific impact range;

[0068] S16. Based on the specific scope of influence, filter the initial path set and determine the core bottleneck point of the propagation path;

[0069] S17, obtain the version update record related to the core bottleneck, compare the version update record with the core bottleneck, determine the critical path of vulnerability propagation, and generate vulnerability detection results.

[0070] In step S11, the interaction data and version update records of all modules in the software system are obtained, and the dependencies between the modules are analyzed to obtain an initial path set, including:

[0071] The interaction data and version update records of each module in the software system are collected to obtain the initial interaction dataset;

[0072] Based on the initial interaction dataset, a graph traversal algorithm is used to parse the dependencies between the modules to obtain a preliminary dependency path graph.

[0073] Based on the preliminary dependency path graph, the interaction data of the modules corresponding to the version update are analyzed to obtain interaction performance indicators;

[0074] The interaction performance metrics are compared with a preset performance benchmark. If the comparison result is abnormal, the corresponding module is marked as a high-risk node, and the initial path set is determined based on the high-risk node.

[0075] This embodiment utilizes the system logs built into the software development system to collect real-time interaction data and version update records from each module within the software system. The interaction data includes detailed information such as inter-module call instructions, execution result status, and response time; the version update records contain timestamps of each module's version updates. These two types of data together constitute the initial interaction dataset.

[0076] It should be noted that after obtaining the initial interaction dataset, this method employs a graph traversal algorithm (e.g., breadth-first search, BFS) to resolve the dependencies between modules. This resolution process begins with a pre-defined core module as the starting node and avoids infinite traversal caused by circular dependencies by maintaining a list of "visited nodes." Specifically, the algorithm places the starting node into a queue, then iteratively removes a module from the head of the queue, queries all its directly called downstream modules from the initial interaction dataset, adds any unvisited modules to the tail of the queue, and records these newly discovered dependencies. This process is repeated layer by layer until the queue is empty, thus constructing a preliminary dependency path graph. It should be noted that the determination of the core modules is based on the analysis of the system architecture design document, selecting the modules with the greatest impact on core business (such as the payment module and order processing module); or by preprocessing the initial interaction dataset and calculating the connectivity of each module. It should be noted that the connectivity refers to the degree centrality of a module in the dependency graph. The calculation method is as follows: for each module, traverse all interaction records involving that module in the initial interaction dataset, and count the total number of unique interaction objects as both callers and callees. This total number is the connectivity of the module. The module with the highest connectivity is selected as the starting node. In another implementation, to fully cover complex microservice architectures, this method can also configure multiple core modules as starting nodes for traversal and merge the results of each traversal to generate a more complete preliminary dependency path graph. By querying the call records in the initial interaction dataset, all other modules directly or indirectly called by that node and their call paths are discovered and recorded layer by layer. This exploration and recording process ultimately generates the preliminary dependency path graph that clearly shows the call chain between modules.

[0077] To analyze whether performance anomalies occur after a version update event of a certain module, based on the preliminary dependency path graph, this method first filters all interaction data related to that module within a preset time window. It's worth noting that the size of the time window is determined based on the analysis of the software system's business cycle, balancing the completeness of data collection with the timeliness of anomaly response. For example, a 24-hour window can be selected to ensure coverage of a complete business cycle, including data from both peak and off-peak periods. Subsequently, these filtered interaction data are aggregated and statistically analyzed to calculate quantified interaction performance indicators. Specifically, the calculation includes: counting the number of records with a "failure" result in the interaction data and dividing it by the total number of records to obtain the call failure rate; and summing the response times of all records with a "success" result and dividing it by the total number of successful records to obtain the average response time.

[0078] It is worth noting that the calculated interaction performance metric is compared with a preset performance benchmark. This benchmark is determined through statistical analysis of a large amount of historical interaction data from normal operation. The determination process includes: collecting historical values ​​of a specific interaction performance metric (e.g., call failure rate) over several past normal operation cycles; calculating the mean (μ) and standard deviation (σ) of all these historical values; and setting the performance benchmark as μ + 3σ based on the statistical principle of 3-σ. If the currently calculated interaction performance metric exceeds this benchmark, the comparison result is considered abnormal.

[0079] If the comparison result is abnormal, the module that has undergone a version update is marked as a high-risk node in the preliminary dependency path graph. Finally, the preliminary dependency path graph is traversed, and all paths containing the high-risk nodes are extracted to form the initial path set.

[0080] For example, suppose an order processing module has a mean call failure rate of 1% and a standard deviation of 0.5% during its historical normal operation. Based on this, a performance baseline of 2.5% is calculated. After the module performs a version update, this method filters 1000 relevant interaction data within 24 hours of the update. Statistical analysis reveals that 50 of these records resulted in "failure." Based on this, its latest call failure rate is calculated to be 5%. Since 5% exceeds the 2.5% performance baseline, the comparison result is considered abnormal. Therefore, the order processing module is marked as a high-risk node, and all paths passing through this node are identified as members of the initial path set.

[0081] In step S12, based on the initial path set, the state changes of each path under different environments are compared to determine the degree of path risk variation, including:

[0082] Extract the state of nodes within each path in the initial path set at different time points to obtain node change trajectory information;

[0083] Obtain the environmental parameters during the version update, and calculate the node's adaptability based on the node change trajectory information and the environmental parameters;

[0084] If the degree of adaptation is lower than the preset adaptation threshold, the node is determined to be a risk node, and the potential threat distribution range is obtained;

[0085] Based on the distribution range of the potential threats, the changes in the path are analyzed and the variation data of the risk nodes are extracted to determine the degree of variation of the path risk.

[0086] In one implementation, to obtain the node change trajectory information, the present invention first traverses the initial path set obtained in S11 to identify all nodes contained in the path. It should be noted that the extraction process refers to using the identified nodes as indexes to query and retrieve the performance status of these nodes from the initial interaction dataset obtained in S11 at multiple different points in the past (e.g., daily). The performance status may specifically include the node's call frequency and response time. By orderly arranging the status retrieved from a node at multiple time points, a node change trajectory information reflecting its historical behavioral changes can be formed.

[0087] It should be noted that this method obtains environmental parameters related to version update events and calculates the node's adaptability based on the node's change trajectory information and the environmental parameters. The environmental parameters refer to the configuration and load information of the software system under different migration or operation scenarios, such as low-load or high-load environments. The calculation of the adaptability is specifically accomplished through a preset performance evaluation function. This function compares the node's interaction performance indicators under specific environmental parameters with a performance benchmark. It should be noted that the calculation method for the node's interaction performance indicators under specific environmental parameters is the same as that described in S11, i.e., it is obtained by aggregating and statistically analyzing the node's corresponding interaction data under those environmental parameters; the performance benchmark refers to the average interaction performance indicator value recorded by the node during its historical normal operation.

[0088] For example, the specific definition of the performance evaluation function depends on the nature of the interaction performance indicators, and can be divided into the following two cases: For indicators such as call failure rate and average response time, where lower values ​​indicate better performance, the function can be defined as dividing the performance benchmark value by the interaction performance indicator value of the node under specific environmental parameters to obtain a ratio; to avoid the denominator being zero, if the interaction performance indicator value of the node under specific environmental parameters is zero, then a very small positive number (ε) is used instead for calculation. For indicators such as success rate and throughput, where higher values ​​indicate better performance, the function can be defined as dividing the interaction performance indicator value of the node under specific environmental parameters by the performance benchmark value to obtain a ratio. For example, if a node's performance benchmark (call failure rate) is 1%, and the call failure rate rises to 2% under high load, then its adaptability is calculated as 1% / 2%=0.5; if a node's performance benchmark (success rate) is 99%, and the success rate drops to 90% under high load, then its adaptability is calculated as 90% / 99%≈0.91. In both cases, the calculated ratio represents the degree of adaptation of the node, and its value intuitively reflects the degradation of node performance under environmental changes.

[0089] It is worth noting that after obtaining the fitness level of the node, this method compares it with a preset fitness threshold. The determination of the fitness threshold is a process of optimizing the classification boundary based on historical data, and its specific steps are as follows:

[0090] Step 1: Collect the software system's operation logs and fault records from the past 6 months to construct a labeled historical node dataset. For each node sample in the dataset, if it does not trigger any fault alarms within a certain time window (e.g., within 24 hours after a version update), it is marked as "stable adaptation" (positive sample); if it triggers a fault that is confirmed as a performance problem through root cause analysis (e.g., a P1 or P2 level fault), it is marked as "poor adaptation" (negative sample).

[0091] Step 2: Calculate the fit score for each node sample in the dataset according to the performance evaluation function.

[0092] Step 3: Using all the fit scores calculated in Step 2 as candidate thresholds, iterate from high to low. For each candidate threshold, calculate its corresponding True Positive Rate (TPR, the proportion of correctly identifying "misfit") and False Positive Rate (FPR, the proportion of misclassifying "stable fit" as "misfit"). Plot an ROC curve in the TPR-FPR coordinate system and calculate Youden's J statistic (TPR-FPR) for each point. Select the point that maximizes the Youden's J statistic; the fit score corresponding to this point is determined as the optimal fit threshold. For example, after analysis, the Youden's J statistic reaches its maximum value when the fit is 0.75, so the fit threshold is set to 0.75. Below this threshold, it indicates that the node's fit performance is at a statistically low probability level. If the calculated current fit is lower than the fit threshold, the present invention determines the node as a risk node and summarizes all determined risk nodes to obtain the potential threat distribution range.

[0093] Finally, to determine the degree of variation in the path risk, this invention first extracts the variation data of the risk nodes based on the distribution range of the potential threats. It should be noted that the variation data specifically refers to a set of performance data pairs recorded for each risk node. These data pairs record the interaction performance index value used as a performance benchmark, and the value of the same interaction performance index under specific environmental parameters (e.g., the number of call timeouts). The degree of variation in the path risk is determined by quantifying the variation data. The quantification process is as follows: First, calculate the difference between the interaction performance index value of the risk node under specific environmental parameters and the interaction performance index value used as a performance benchmark; then, divide this difference by the interaction performance index value used as a performance benchmark to calculate a relative rate of change, which is the degree of variation in the path risk.

[0094] In step S13, based on the degree of variation in path risk, a filtering and aggregation operation is performed to obtain a high-risk path group, including:

[0095] Obtain the connection relationship of each node in the initial path set. If the dependency between nodes is higher than the preset dependency threshold, then group the nodes into the same set to obtain the preliminary node grouping result.

[0096] Based on the preliminary node grouping results, the variation characteristics of each node under different environments are extracted. If the variation amplitude of the variation characteristics exceeds the preset variation amplitude threshold, a high-risk node subset is determined.

[0097] Based on the high-risk node subset, nodes with similar variation characteristics are grouped, and the paths containing nodes within the group divisions are identified as the high-risk path groups.

[0098] In one implementation, the present invention first obtains the connection relationships of each node from the initial path set. It should be noted that the connection relationship refers to the call and called relationship defined between nodes in the preliminary dependency path graph. This method calculates the dependency degree between nodes by analyzing the call logs in the initial interaction dataset. For example, the dependency degree can be quantified as the total number of bidirectional calls between two modules per unit time. If the calculated dependency degree between nodes is higher than a preset dependency threshold, the present invention groups these nodes into the same temporary set, thereby obtaining the preliminary node grouping result. It is worth noting that the determination of the dependency threshold is based on statistical analysis of the dependency degree data between all nodes under historical normal operating conditions. The specific steps are as follows: collect the interaction logs between all modules during the past three months of stable system operation (without major failures); calculate the total number of bidirectional calls between any two directly interacting modules on an hourly basis, forming a dataset containing a large number of dependency degree values; statistically analyze all values ​​in this dataset and calculate its cumulative distribution function. Select the 90th percentile value at the high end of the distribution as the dependency threshold. For example, if statistics show that 90% of the modules in the dataset have fewer than 150 calls per hour, then the dependency threshold is set to 150 calls per hour. A threshold higher than this indicates that the coupling between nodes is statistically significantly higher than the average.

[0099] It should be noted that, based on the preliminary node grouping results, this invention extracts the variation characteristics of each node under different environments. These variation characteristics are the path risk variation levels calculated for each node in S12. This method compares the change magnitude of the variation characteristics of each node with a preset change magnitude threshold. The determination process of the change magnitude threshold is similar to the method for determining the dependency threshold; that is, by statistically analyzing the change magnitude of the variation characteristics of historical normal nodes, the 95th percentile of its distribution is selected as the threshold. If the change magnitude of the variation characteristics of a node exceeds this threshold, the node is identified and classified into the high-risk node subset.

[0100] Finally, based on the high-risk node subset, the present invention groups nodes with similar mutation characteristics. In one implementation, the grouping is achieved using the K-means clustering algorithm, and its specific application process is as follows:

[0101] Step 1: For each node in the high-risk node subset, construct a multi-dimensional digital feature vector. This vector consists of one or more variation features of the node. For example, the feature vector of a node can be represented as [the degree of variation of call failure rate, the degree of variation of average response time].

[0102] Step two: Use the elbow method to determine the optimal number of clusters K. Set the range of K values ​​(e.g., from 2 to 10), run the full K-means algorithm for each K value, and calculate its within-cluster sum of squares (WCSS). Plot the WCSS as a function of K values, and select the K value corresponding to the "elbow" point where the slope of the curve changes most significantly as the optimal number of clusters. For example, K=3 can be set.

[0103] Step 3: Using the optimal number of clusters K determined in Step 2 as a parameter, perform clustering on the feature vectors of all nodes. This process is iterated until convergence: randomly select K nodes as the initial cluster centers (centroids); calculate the distance (e.g., Euclidean distance) from each node vector to the K centroids and assign it to the cluster containing the nearest centroid (assignment step); recalculate the centroid of each cluster, i.e., take the average of all node vectors in the cluster as the new centroid (update step); repeat the assignment and update steps until the cluster assignment no longer changes or the preset maximum number of iterations is reached.

[0104] Step four: After the algorithm converges, each cluster represents a group of nodes with similar mutation characteristics. Subsequently, this invention traverses the initial path set, extracting all paths containing nodes from any group, which together constitute the final high-risk path group.

[0105] For example, assuming that in an inventory management system, the "Order Generation" module and the "Inventory Query" module have an average daily bidirectional call count of 200 times, exceeding the dependency threshold of 150 times calculated based on historical data, they are grouped into the same initial node group. Subsequently, analysis revealed that the risk variability of the "Order Generation" module reached 250%, exceeding the 200% variability threshold, thus identifying it as a high-risk node. Finally, the clustering algorithm grouped the "Order Generation" module and another module, "Logistics Tracking," which also exhibited high-risk variability, into the same group. This invention then filters out all paths in the initial path set that pass through both modules, forming the high-risk path group.

[0106] In step S14, the dependencies within the high-risk path group are analyzed to determine whether there is a potential risk amplification, and the potential risk amplification judgment result is obtained, including:

[0107] Identify core interaction modules from the high-risk path groups, parse the path interaction logic within the groups, and obtain the association weights between modules and paths;

[0108] The node connection strength is determined based on the association weight. If the node connection strength is higher than the preset connection strength threshold, the dependency chain length and group cohesion are analyzed to determine the triggering conditions for potential risks.

[0109] The hazard triggering conditions are compared with the preset hazard amplification standards to obtain the hazard amplification judgment result.

[0110] In one implementation, the present invention first identifies core interaction modules from the high-risk path group obtained in S13. It should be noted that the identification of the core interaction modules is based on their connectivity or business criticality within the group. For example, this method can analyze the initial interaction dataset and identify the module with the highest total number of calls and calls within the group, or the module marked as a business process hub according to the system architecture document, as the core interaction module. Subsequently, the present invention calculates the association weight between the module and the path within the group. The calculation process of the association weight includes: extracting two raw indicators, call frequency and data transmission volume, from the initial interaction dataset; performing Min-Max Normalization on these two raw indicators to map them to a unified interval of [0,1] to eliminate the influence of dimensions; and calculating using a preset weighted summation method, which involves multiplying the normalized call frequency by a first weight coefficient, multiplying the normalized data transmission volume by a second weight coefficient, and then adding the two products together, the sum of which is the final association weight.

[0111] The first and second weighting coefficients are preset weighting coefficients, and their sum is 1. It is worth noting that the weighting coefficients are determined by constructing and solving a multiple linear regression model, the specific steps of which are as follows:

[0112] The first step is to construct a historical dataset. This invention first extracts and constructs a dataset for model analysis from historical system operation logs. Each data sample in this dataset contains three fields: normalized call frequency (as the first independent variable), normalized data transmission volume (as the second independent variable), and a historical major fault label (as the dependent variable, where "major fault occurred" is marked as 1, and "no major fault occurred" is marked as 0). It should be noted that the historical major fault label is determined by parsing historical event work orders or fault review reports and applying a preset quantitative rule. It should be noted that this rule is preset based on statistical analysis of the interruption duration data of all historical fault events, calculating the probability distribution of all historical fault interruption durations, and selecting, for example, the duration corresponding to the 90th percentile as the major event duration threshold. It should be noted that selecting the 90th percentile as the threshold defines it as an extremely long-lasting event that ranks in the top 10% of statistical durations. Specifically, this rule can be defined as follows: if the service interruption duration recorded in a historical event exceeds the threshold for the duration of a major event, then the logistic regression model for that event will be fitted to the historical dataset. Specifically, the maximum likelihood estimation method can be used to find a set of regression coefficients ( and ),in The intercept term represents the baseline prediction when all independent variables are zero. and These are the regression coefficients of their respective variables. The probability of a failure occurring can be calculated using the following formula. :

[0113]

[0114] in, This represents the probability of a failure occurring; the regression coefficients of the normalized data transmission volume are solved using the maximum likelihood estimation method. and These coefficients reflect the degree to which each independent variable influences the logarithmic probability of the failure occurrence.

[0115] The third step is to determine the weights based on the regression coefficients. After the model fitting is complete, the regression coefficients are obtained. and The absolute values ​​of these two coefficients objectively reflect their relative importance in triggering historical failures. This invention determines the final weighting coefficients by normalizing the absolute values ​​of these two coefficients. The calculation process is as follows: calculate the regression coefficients separately. and Find the absolute value of the two values ​​and calculate their sum; Dividing the absolute value of the first weighting coefficient by the sum of the absolute values ​​yields the first weighting coefficient; similarly, the first weighting coefficient is obtained by dividing the absolute value of the first weighting coefficient by the sum of the absolute values ​​of the second weighting coefficient. The absolute value of the weight is divided by the sum of the absolute values ​​to obtain the second weighting coefficient.

[0116] It should be noted that this method determines the node connection strength based on the association weights and compares them with a preset connection strength threshold. The connection strength threshold is determined by statistically analyzing the association weights between a large number of historically stable system modules and selecting the 95th percentile of its distribution as the threshold. A connection exceeding this threshold indicates a statistically high-strength connection. If the node connection strength is higher than this threshold, this method initiates the process of determining potential vulnerability trigger conditions. This process first calculates the dependency chain length and group cohesion of the connection. Specifically, the dependency chain length is determined by traversing the initial dependency path graph and calculating the minimum number of call hops between two modules; the group cohesion is quantified by querying the initial interaction dataset and calculating the average daily interaction frequency between modules within the group.

[0117] Subsequently, this method compares the calculated dependency chain length with a preset length threshold and the group cohesion with a preset cohesion threshold. It should be noted that the determination of the length threshold and cohesion threshold is a process of optimizing the classification boundary based on historical data. The specific steps are as follows: Prepare a labeled historical fault dataset, where each record contains the dependency chain length, group cohesion, and a classification label based on the fault's impact range (e.g., "chain reaction fault" or "local fault"). For the dependency chain length indicator, by iterating through all values ​​in the dataset, testing every possible value as a candidate threshold, and calculating the True Positive Rate and False Positive Rate to distinguish between "chain reaction faults" and "local faults," a Receiver Operating Characteristic (ROC) curve is generated. This invention selects the critical point closest to the upper left corner (i.e., point (0,1)) on this curve, and determines the dependency chain length value corresponding to this point as the final length threshold. The determination process for the cohesion threshold is the same. The threshold obtained in this way can accurately distinguish system states with high diffusion risk to the greatest extent. If the calculated dependency chain length exceeds its threshold and the group cohesion exceeds its threshold, then the present invention determines that the hazard triggering condition is met. The hazard triggering condition is a set of logical conditions that are satisfied, such as (connection strength > threshold AND dependency chain length > 3 AND group interaction frequency > 200 times / day).

[0118] Finally, the present invention compares the aforementioned hazard triggering conditions with a preset hazard amplification standard to obtain the final hazard amplification judgment result. It should be noted that the hazard amplification standard is a set of performance degradation thresholds, determined based on well-known standards of User Experience (UX). Specifically, for front-end or interface modules that directly interact with the user, the performance thresholds are determined based on well-known conclusions in human factors engineering regarding user-perceived latency. For example, "response time delay exceeding 2 seconds" or "call failure rate increasing by more than 5%" can be set as specific thresholds in the standard to ensure that the system response remains within an acceptable range of smoothness for the user. The comparison process determines whether the hazard triggering conditions will cause any performance indicator to exceed the hazard amplification standard. If it is determined that it will exceed the standard, the hazard amplification judgment result is "yes"; otherwise, it is "no".

[0119] In step S15, if the hazard amplification judgment result is yes, then the business impact data at the end of the path is obtained, and combined with the interaction data, the specific impact range is determined, including:

[0120] Based on the results of the hazard amplification judgment, paths with potential hazard amplification are selected from the high-risk path group;

[0121] From the path where the potential for amplification is identified, the end point of the path is determined, and the business scope and impact depth data of the end point of the path are obtained. Then, the correlation between the end points of the path is analyzed to obtain the preliminary impact duration.

[0122] Based on the preliminary impact duration and the interaction data, the interaction frequency and intensity are analyzed to determine the distribution characteristics of the potential hazard scale.

[0123] By combining the distribution characteristics of the potential hazard scale with the initial impact duration, a comprehensive analysis is conducted to determine the specific impact range.

[0124] In one implementation, the present invention first selects all paths that are determined to have potential for potential amplification from the high-risk path group based on the "yes" result of the potential amplification judgment obtained in S14.

[0125] It should be noted that this method determines the path endpoints from the paths identified in the previous step that have the potential for amplification. The path endpoints are determined by analyzing the preliminary dependency path graph, identifying modules in the path that have no subsequent call relationships and serve as the endpoints of the call chain as path endpoints. Subsequently, this invention obtains the business scope and impact depth data of the path endpoints, and then analyzes the relationships between the path endpoints to obtain the preliminary impact duration. The business scope and impact depth data are obtained by querying a pre-established business architecture knowledge base.

[0126] It is worth noting that the business architecture knowledge base establishes a mapping relationship between each module in the software system and one or more specific business processes it supports (such as "user payment" and "inventory update") by parsing system architecture documents and business process specifications; and calculates a quantitative criticality level for each business process. This calculation is accomplished by extracting historical operational data related to each business process (such as average daily transaction volume, average revenue per transaction, and amount of fines for compliance failures), normalizing this data, and then performing a weighted summation. It should be noted that the weight coefficients of the weighted summation are objectively determined using Principal Component Analysis (PCA) based on the variance contribution rate of each operational data indicator to the total historical business loss; indicators with higher contribution rates are assigned higher weights. The mapping relationship between the module and the business process it supports constitutes the "business scope" data; the criticality level calculated for the business process constitutes the "depth of influence" data. By structurally storing these mapping relationships and level data, the business architecture knowledge base is constructed. The analysis process involves associating the module at the end of the path with the historical fault database, finding the mean time to recovery (MTTR) when similar modules fail, and using this time as the initial impact duration.

[0127] It should be noted that the specific content of the business architecture knowledge base and the risk amplification standard can be initialized and continuously optimized according to the characteristics of the target software system and industry best practices. In the absence of complete historical data, industry benchmark reports or expert experience values ​​can be used for initialization, and the system can be dynamically adjusted and updated through machine learning or feedback mechanisms during operation to ensure its adaptability and accuracy.

[0128] Next, based on the preliminary impact duration and the interaction data, this invention analyzes the interaction frequency and intensity to determine the distribution characteristics of the hazard scale. The analysis process includes: extracting interaction data related to the path from the initial interaction dataset within the time window covered by the preliminary impact duration; calculating the interaction frequency (number of calls per unit time) and interaction intensity (average data transmission volume per unit time) of these records. The distribution characteristics of the hazard scale are obtained by classifying the calculation results using a pre-trained decision tree classification model. It should be noted that the model's construction and training process includes:

[0129] A historical dataset of potential incidents is obtained, where each sample includes interaction frequency and interaction intensity as input features, and a distribution feature label (e.g., "localized concentrated outbreak" or "persistent impact") derived from historical log analysis as output. It should be noted that the distribution feature label is obtained by annotating historical fault data. The annotation process is as follows: First, the total duration of the fault is divided into multiple equal-length time intervals. The number of intervals is determined based on the principle of ensuring sufficient data points for stable statistics within each interval; for example, the total duration can be divided into 10 intervals. Then, the number of error logs occurring in each time interval is counted. Finally, the proportion of error logs in the top 20% of time intervals is calculated relative to the total number of error logs. If this proportion exceeds a preset concentration threshold, the fault event is labeled "localized concentrated outbreak"; otherwise, it is labeled "persistent impact." It is worth noting that the determination of the concentration threshold (e.g., 60%) is a process of optimizing the classification boundary based on historical data. The specific steps are as follows: Prepare a historical case dataset that has been manually classified ("outbreak" or "continuation"), and calculate the proportion value of each case in the dataset; use each calculated proportion value as a candidate threshold, iterate through all possible threshold points, and calculate the true positive rate (TPR) and false positive rate (FPR) corresponding to each threshold point to generate a receiver operating characteristic (ROC) curve; select the point on the curve that maximizes the Youden index (Youden's J statistic = TPR - FPR), and determine the proportion value corresponding to that point as the final concentration threshold.

[0130] The standard CART (Classification and Regression Tree) algorithm is used, with Gini impurity as the splitting criterion for model training. To prevent overfitting and improve the model's generalization ability, a grid search combined with k-fold cross-validation is employed. Within a predefined hyperparameter space (e.g., the maximum tree depth range is [5,20], and the minimum number of leaf node samples range is [10,50]), the optimal hyperparameter combination is determined by achieving the highest F1 score on the validation set.

[0131] After determining the optimal hyperparameter combination, the final model is constructed using the entire training dataset. This construction process is the standard decision tree generation process. The algorithm starts from the root node and recursively partitions the data and generates child nodes according to the principle of minimizing Gini impurity. The training process is completed and the final model is output when any of the following preset stopping conditions are met: the tree growth depth has reached the optimal maximum depth determined in the hyperparameter optimization stage; the number of samples in the current node is less than the minimum number of samples required for the next partition; all data samples in the current node belong to the same distribution feature label, that is, the node has reached purity.

[0132] It is worth noting that this invention combines the distribution characteristics of the potential hazard scale with the initial impact duration for comprehensive processing to determine the final specific impact range. In one implementation, this comprehensive processing is accomplished by querying a pre-set risk matrix. The construction process of the risk matrix includes: defining two dimensions of the matrix; one dimension is the distribution characteristics of the potential hazard scale (e.g., discrete categories such as "localized concentrated outbreak" and "continuous impact"), and the other dimension is the quantitative classification of the initial impact duration (e.g., "less than 1 hour", "1-4 hours", "more than 4 hours"). The value of each cell in the matrix (i.e., the percentage of business impact) is determined by querying a historical fault database, filtering out all historical events that meet the characteristics corresponding to that cell (e.g., the characteristic is "localized concentrated outbreak" and the duration is between "1-4 hours"), and calculating the statistical average of the actual business losses caused by these events. This model uses the distribution characteristics of the potential hazard scale and the initial impact duration as input, searches for the corresponding cell in the risk matrix, and outputs a quantitative percentage of business impact, which is the specific impact range.

[0133] In step S16, based on the specific scope of influence, the initial path set is filtered to determine the core bottleneck points of the propagation path, including:

[0134] Based on the specific scope of impact, the distribution data of key nodes in the initial path set are analyzed to obtain preliminary bottleneck judgment results;

[0135] Based on the preliminary bottleneck assessment results, the correlation information between potential bottlenecks and propagation paths is analyzed to determine the specific location of the bottleneck point.

[0136] Analyze the interaction intensity at the specific location of the bottleneck point. If the interaction intensity is higher than a preset intensity threshold, then the specific location of the bottleneck point is determined as the core bottleneck point of the propagation path.

[0137] In one implementation, the present invention first analyzes the initial path set based on the specific influence range obtained in S15 to obtain a preliminary bottleneck judgment result.

[0138] It should be noted that the parsing process includes: extracting key nodes on all paths related to the specific scope of influence in the initial path set; and querying the historical operational data of these key nodes from the initial interaction dataset, such as the average response time and processing volume per unit time of the nodes.

[0139] It should be noted that this invention determines the preliminary bottleneck judgment result by performing statistical outlier detection on the performance data of these nodes. Specifically, the detection process includes: calculating the average (μ) and standard deviation (σ) of a certain performance index (e.g., response time) for the associated nodes; comparing the performance index value of each node with a statistical upper limit (μ+3σ) set according to the "3-sigma principle"; if the performance index value of a node exceeds the upper limit, then the node is determined as the preliminary bottleneck judgment result.

[0140] In one implementation, the present invention analyzes the correlation information between potential bottlenecks and propagation paths based on the preliminary bottleneck judgment results to determine the specific location of the bottleneck point. The analysis process includes: for nodes initially judged as bottlenecks, further extracting detailed interaction data between the node and its upstream and downstream nodes from the initial interaction dataset, particularly call frequency and data consistency records. It should be noted that the analysis is implemented through a time series correlation analysis. The specific process is as follows: extracting the time-varying sequence of the bottleneck node's performance indicators (e.g., response time); extracting the time-varying sequence of the corresponding indicators (e.g., call frequency) of each interface or service interacting with it; to ensure the consistency of the time base, using linear interpolation, resampling the time-varying sequences of the bottleneck node's performance indicators and the time-varying sequences of the corresponding indicators of each interface or service interacting with it onto a uniform, regular time interval (e.g., one data point per minute); and using the standard Pearson correlation coefficient algorithm to calculate the correlation coefficient between the bottleneck node's performance sequence and the sequence of indicators for each interaction interface. The interaction interface or service with the highest absolute value of the correlation coefficient is the specific location identified as the bottleneck.

[0141] It is worth noting that this invention analyzes the interaction intensity at the specific location of the bottleneck point and compares it with a preset intensity threshold to ultimately determine the core bottleneck point of the propagation path. The interaction intensity is a comprehensive quantitative indicator, calculated by normalizing and weighting multiple raw indicators such as call frequency, data transmission volume, and data consistency deviation rate. It should be noted that the data consistency deviation rate refers to the proportion of inconsistent records among all compared records, calculated through periodic data reconciliation tasks comparing two data stores located in different modules that should be synchronized. It should also be noted that the weight coefficients of the weighted summation are objectively determined through multiple linear regression analysis of historical data, a process similar to that used in S14 to determine the correlation weight coefficients. This process uses each raw indicator as an independent variable and whether it has caused a core bottleneck event (yes = 1, no = 0) as the dependent variable. The regression coefficients obtained through the model and after normalization are the weight coefficients of each indicator. It should be noted that the core bottleneck event label is determined by parsing historical Root Cause Analysis (RCA) reports. An RCA report is a standardized document generated in the Information Technology Service Management (ITSM) process for major failure events, systematically tracing the root technical cause from the failure phenomenon using an industry-known standardized failure analysis process (such as the "5 Whys" method), and archived in an internal knowledge base or event management system. If a historical RCA report clearly identifies the interaction or its associated interface as the root cause of the failure, the corresponding historical data sample is labeled as 1; otherwise, it is 0. For example, after analysis, the weights can be set as follows: call frequency weight 0.5, data transmission volume weight 0.2, and data consistency deviation rate weight 0.3. The intensity threshold is determined based on statistical analysis of the interaction intensity data of historically normally functioning interaction interfaces, selecting the 95th percentile of its distribution as the threshold. If the calculated real-time interaction intensity is higher than this threshold, the present invention ultimately determines the specific location of the bottleneck point as the core bottleneck point of the propagation path.

[0142] In step S17, the version update records related to the core bottleneck are obtained, and the version update records are compared with the core bottleneck to determine the critical path of vulnerability propagation and generate vulnerability detection results, including:

[0143] Extract version difference data related to the core bottleneck from the version update records to obtain the version difference distribution;

[0144] Based on the version difference distribution, analyze the path data of the core bottleneck points to determine the key locations for vulnerability localization;

[0145] Based on the key locations of the vulnerability, the matching accuracy with the path data of the core bottleneck point is calculated. If the matching accuracy is higher than a preset matching threshold, the critical path of the vulnerability propagation is determined, and the vulnerability detection result is generated.

[0146] In one implementation, the present invention first extracts version difference data related to the core bottleneck point determined in S16 from the version update records obtained in S11, thereby obtaining a version difference distribution. It should be noted that the extraction process refers to: querying all historical version iteration records of the module to which the core bottleneck point belongs; and calculating the core performance indicators (e.g., average response time) of the module in each historical version using the initial interaction dataset, thereby obtaining a set of version difference data that reflects performance changes with version; this set of data is the version difference distribution.

[0147] Next, based on the version difference distribution, this invention analyzes the path data of the core bottleneck to determine the key locations for vulnerability localization. In one implementation, the analysis process is achieved by comparing the interaction between the core bottleneck and its upstream and downstream nodes under different versions. This invention first filters out module versions with performance indicators worse than the previous version from the version difference distribution; it then focuses on analyzing newly introduced features, modified configuration parameters, or refactored code logic in these versions where performance degradation has been confirmed, and determines the change points most relevant to the performance degradation by calculating a correlation score.

[0148] The calculation of the correlation score can comprehensively consider two dimensions: temporal proximity and logical correlation. Temporal proximity refers to the reciprocal of the time difference between the commit time of the version change and the time when performance first degrades. Logical correlation is quantified and assigned according to the following rules. It should be noted that the assignment ratio of this rule is based on the backtracking analysis of historical failure root causes and is set proportionally according to different correlation types and the conditional probability of actually causing failures: if the change directly modifies the code file or configuration item where the core bottleneck point is located, the logical correlation score is assigned 1.0; if the change modifies the module that directly calls or depends on the core bottleneck point, the score is assigned 0.5; otherwise, the score is assigned 0.1. In a better implementation, the logical correlation score can be calculated by code change impact analysis tools (such as program call graph analysis) to calculate the code dependency strength between the change set and the core bottleneck point, thereby obtaining a continuous quantified correlation score.

[0149] Before performing the weighted summation, the calculated scores for the two dimensions of temporal proximity and logical relevance are first subjected to min-max normalization to eliminate the influence of dimensions. The comprehensive relevance score is obtained by weighted summation of these two normalized dimensions. The weight coefficients are determined through grid search optimization on a labeled historical verification set. The grid search range can be set to iterate one weight from 0.1 to 0.9 in steps of 0.1, while the other weight is set to 1 minus the current weight value, finding the optimal weight combination that ranks the known root cause change point highest. This invention identifies the change point with the highest comprehensive relevance score as the key location for vulnerability localization.

[0150] It is worth noting that this invention calculates the matching accuracy between the key points of the vulnerability location and the path data of the core bottleneck point, and compares it with a preset matching threshold. The calculation of the matching accuracy is achieved through a quantitative comparison function. For example, for indicators such as cache hit rate, where a higher value indicates better performance, the function can be defined as: dividing the actual performance value recorded in the log data by the expected performance target value in the version change log to obtain a ratio, which is the matching accuracy. The determination of the matching threshold is based on the backtracking analysis of historical known vulnerability cases, and is achieved by finding the optimal confidence level through ROC curve analysis. This process aims to find a threshold point that can optimally balance correctly identifying real vulnerabilities (true positive rate) and misjudging occasional performance fluctuations as vulnerabilities (false positive rate), and the confidence level corresponding to this point is the matching threshold. Specifically, this invention selects the point on the ROC curve that maximizes Youden's J statistic, and the confidence level corresponding to this point (e.g., 80%) is determined as the matching threshold. If the calculated matching accuracy is higher than the threshold, the present invention will finally determine the critical path of the vulnerability propagation and generate the final vulnerability detection result, which includes details of the path, key locations, version information, and business impact scope.

[0151] For example, targeting the core bottleneck of the "database query interface," this invention extracted the version update records of its module and found that its average response time deteriorated from 4 seconds to 5 seconds in version 3.0, forming a version difference distribution. Analysis revealed that a caching mechanism was added in version 3.0, and this change was initially identified as a key point for vulnerability localization. Subsequently, this invention extracted the runtime logs of this caching mechanism and calculated that its actual hit rate during peak business periods was only 30%, far lower than the 60% expected in the version design document. Its matching accuracy was calculated to be 30% / 60% = 0.5 (or 50%), which was determined to be below the 90% matching threshold. Therefore, this invention ultimately determined that "the low hit rate due to improper caching configuration in version 3.0" was the critical path for vulnerability propagation and generated a vulnerability detection result report containing this conclusion.

[0152] It is worth noting that specific parameters involved in this invention (such as the value of ε and the assignment ratio of logical correlation) can be optimized through sensitivity analysis or cross-validation based on historical data. For example, ε can be a number much smaller than the normal performance index value, such as 1E-5; the assignment ratio can be determined by performing a grid search within a certain range (such as [0.1, 1.0]) with the goal of achieving the best classification effect on the validation set. Those skilled in the art can adjust these parameters according to the actual situation.

[0153] In summary, this invention discloses a software development system management method based on big data processing, comprising: acquiring interaction data and version update records of all modules in the software system, and analyzing the dependencies between the modules to obtain an initial path set; comparing the state changes of each path under different environments based on the initial path set to determine the degree of path risk variation; performing filtering and aggregation operations based on the degree of path risk variation to obtain a high-risk path group; analyzing the dependencies within the high-risk path group to determine whether there is vulnerability amplification and obtaining a vulnerability amplification judgment result; if the vulnerability amplification judgment result is yes, acquiring business impact data at the end of the path and combining it with the interaction data to determine the specific impact range; filtering the initial path set based on the specific impact range to determine the core bottleneck point of the propagation path; acquiring the version update records related to the core bottleneck point and comparing the version update records with the core bottleneck point to determine the critical path of vulnerability propagation and generate vulnerability detection results. This invention establishes a complete analytical closed loop from dynamic risk identification and business impact assessment to technical bottleneck location and version root cause tracing, achieving accurate detection of hidden and dynamically changing vulnerability propagation paths in software systems and solving the problem of low detection accuracy in existing technologies.

[0154] Reference Figure 2The second embodiment of the present invention provides a software development system management system based on big data processing, comprising:

[0155] The initial path identification module is used to acquire the interaction data and version update records of all modules in the software system, and analyze the dependencies between the modules to obtain the initial path set;

[0156] The risk variation analysis module is used to compare the state changes of each path under different environments based on the initial path set to determine the degree of path risk variation.

[0157] The high-risk group segmentation module is used to perform filtering and aggregation operations based on the degree of variation of the path risk to obtain high-risk path groups;

[0158] The hidden danger amplification judgment module is used to analyze the dependency relationship within the high-risk path group, determine whether there is hidden danger amplification, and obtain the hidden danger amplification judgment result;

[0159] The impact range determination module is used to obtain the business impact data at the end of the path and determine the specific impact range in combination with the interaction data if the hazard amplification judgment result is yes.

[0160] The core bottleneck location module is used to filter the initial path set according to the specific impact range and determine the core bottleneck point of the propagation path.

[0161] The path confirmation and result generation module is used to obtain the version update records related to the core bottleneck, compare the version update records with the core bottleneck, determine the critical path for vulnerability propagation, and generate vulnerability detection results.

[0162] It should be noted that the software development system management system based on big data processing provided in this embodiment of the invention is used to execute all the process steps of the software development system management method based on big data processing in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0163] This invention also provides an electronic device. The electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, such as a software development system management program based on big data processing. When the processor executes the computer program, it implements the steps in the various embodiments of the software development system management method based on big data processing described above, for example... Figure 1 The step S11 shown. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in the above system embodiments, such as the initial path identification module.

[0164] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0165] The electronic device may be a desktop computer, laptop, handheld computer, or smart tablet, etc. The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above components are merely examples of electronic devices and do not constitute a limitation on the electronic device. It may include more or fewer components than described above, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0166] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the electronic device, connecting all parts of the electronic device via various interfaces and lines.

[0167] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0168] Wherein, if the modules / units integrated in the electronic device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0169] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0170] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A software development system management method based on big data processing, characterized by, The method comprises the following steps: acquiring interaction data and version update records of all modules in a software system, and analyzing the dependency relationship between the modules to obtain an initial path set; comparing the state changes of each path under different environments according to the initial path set to determine the path risk variation degree; performing screening and aggregation operations according to the path risk variation degree to obtain a high-risk path group; analyzing the dependency relationship in the high-risk path group to determine whether there is hidden danger amplification, and obtaining a hidden danger amplification judgment result; if the hidden danger amplification judgment result is yes, acquiring business impact data at the end of the path, and combining the interaction data to determine the specific impact range; screening the initial path set according to the specific impact range to determine the core bottleneck point of the propagation path; acquiring the version update records related to the core bottleneck point, and comparing the version update records with the core bottleneck point to determine the vulnerability propagation key path, and generating a vulnerability detection result.

2. The big data processing based software development system management method of claim 1, wherein, The method comprises the following steps: collecting the interaction data and version update records of each module in the software system to obtain an initial interaction data set; using a graph traversal algorithm to analyze the dependency relationship between the modules according to the initial interaction data set to obtain a preliminary dependency path atlas; analyzing the interaction data of the modules corresponding to the version update according to the preliminary dependency path atlas to obtain an interaction performance index; comparing the interaction performance index with a preset performance benchmark, if the comparison result is abnormal, marking the corresponding module as a high-risk node, and determining the initial path set according to the high-risk node. 3.The big data processing based software development system management method of claim 1, wherein, The method comprises the following steps: extracting the state of each node in the initial path set at different time points to obtain node change trajectory information; acquiring environmental parameters at the time of version update, and calculating the adaptation degree of the node according to the node change trajectory information and the environmental parameters; if the adaptation degree is lower than a preset adaptation threshold, determining the node as a risk node, and obtaining a potential threat distribution range; analyzing the change of the path and extracting the variation data of the risk node according to the potential threat distribution range to determine the path risk variation degree.

4. The big data processing based software development system management method of claim 1, wherein, The method comprises the following steps: acquiring the connection relationship of each node in the initial path set, if the dependency degree between nodes is higher than a preset dependency threshold, the nodes are grouped into the same set to obtain a preliminary node grouping result; extracting the variation characteristics of each node under different environments according to the preliminary node grouping result, if the variation amplitude of the variation characteristics exceeds a preset variation amplitude threshold, a high-risk node subset is determined; grouping the nodes with similar variation characteristics according to the high-risk node subset, and determining the paths containing the nodes in the group division as the high-risk path group. 5.The big data processing based software development system management method according to claim 1, wherein, The analysis of the dependency relationship in the high-risk path group determines whether there is hidden danger amplification, and obtains a hidden danger amplification judgment result, including: Identifying a core interaction module from the high-risk path group and analyzing the path interaction logic in the group to obtain the association weight of the module and the path; According to the association weight, determine the node connection strength, if the node connection strength is higher than the preset connection strength threshold, analyze the length of the dependency chain and the cohesion degree in the group to determine the hidden danger trigger condition; Compare the hidden danger trigger condition with the preset hidden danger amplification standard to obtain the hidden danger amplification judgment result.

6. The big data processing based software development system management method of claim 1, wherein, If the hidden danger amplification judgment result is yes, obtain the business impact data of the path end, and combine the interaction data to determine the specific impact range, including: According to the hidden danger amplification judgment result, filter out the path with hidden danger amplification from the high-risk path group; Determine the path end from the path with hidden danger amplification, and obtain the business range and impact depth data of the path end, and then analyze the association relationship of the path end to obtain the preliminary impact duration; According to the preliminary impact duration and the interaction data, analyze the interaction frequency and interaction strength to determine the distribution characteristics of the hidden danger scale; Combine the distribution characteristics of the hidden danger scale and the preliminary impact duration for comprehensive processing to determine the specific impact range. 7.The big data processing based software development system management method of claim 1, wherein, According to the specific impact range, filter the initial path set to determine the core bottleneck point of the propagation path, including: According to the specific impact range, analyze the distribution data of the key nodes in the initial path set to obtain a preliminary bottleneck judgment result; According to the preliminary bottleneck judgment result, analyze the association information of the potential bottleneck and the propagation path to determine the specific location of the bottleneck point; Analyze the interaction strength at the specific location of the bottleneck point, if the interaction strength is higher than the preset strength threshold, the specific location of the bottleneck point is determined as the core bottleneck point of the propagation path. 8.The big data processing based software development system management method of claim 1, wherein, Obtain the version update record related to the core bottleneck point, and compare the version update record with the core bottleneck point to determine the vulnerability propagation key path and generate the vulnerability detection result, including: From the version update record, extract the version difference data related to the core bottleneck point to obtain the version difference distribution; According to the version difference distribution, analyze the path data of the core bottleneck point to determine the key point of vulnerability positioning; According to the key point of vulnerability positioning, and calculate the matching accuracy of the core bottleneck point path data, if the matching accuracy is higher than the preset matching threshold, the vulnerability propagation key path is determined, and the vulnerability detection result is generated. 9.A software development system management system based on big data processing, characterized by, Including: An initial path identification module for obtaining interaction data and version update records of all modules in a software system, and analyzing the dependency relationship between the modules to obtain an initial path set; A risk variation analysis module for comparing the state changes of each path under different environments according to the initial path set to determine the path risk variation degree; A high-risk group division module is configured to perform screening and aggregation operations according to the path risk variation degree, to obtain a high-risk path group; A hidden danger amplification judgment module is configured to analyze the dependency relationship in the high-risk path group, to judge whether there is hidden danger amplification, and to obtain a hidden danger amplification judgment result; An influence range determination module is configured to, if the hidden danger amplification judgment result is yes, acquire business influence data of a path end, and determine a specific influence range in combination with the interaction data; A core bottleneck positioning module is configured to screen the initial path set according to the specific influence range, to determine a core bottleneck point of a propagation path; A path confirmation and result generation module is configured to acquire the version update record related to the core bottleneck point, and to compare the version update record and the core bottleneck point, to determine a vulnerability propagation key path, and to generate a vulnerability detection result.

Images