Code security detection and version control method and system for distributed environment

Abstract

The application provides a code security detection and version control method and system for a distributed environment, relates to the technical field of software security, and comprises the following steps: receiving source code files submitted by distributed nodes, analyzing a syntax tree structure and extracting semantic features and control flow features, determining code call relations and data access modes, and establishing a cross-node code dependency graph; tracking call links and data flow directions on the dependency graph, calculating call frequencies, access permissions and data interaction intensities between nodes, and identifying security risk propagation paths; constructing a federated learning network to train a security risk identification submodel, generating a security level evaluation result through an encrypted gradient aggregation and a differential privacy protection mechanism; and performing double confirmation through hash verification of a proof of work layer and threshold verification of a voting consensus layer, and converting a version state based on a time sequence dependency chain constraint. The application can accurately identify security risks of distributed codes and realize safe and controllable management of versions.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software security, in particular to a code security detection and version control method and system for distributed environment. BACKGROUND

[0002] With the popularity of distributed development mode, code collaboration and version control have become an important part of software development. Traditional distributed version control mainly focuses on the management and tracking of code version, and maintains the consistency of code repository through code synchronization and merging between distributed nodes. In terms of code security, the existing technology mainly relies on static code scanning, dynamic testing and other means to detect security vulnerabilities of single code file or module, and uses access control, signature verification and other mechanisms to ensure the security of code submission and merging. However, with the expansion of code collaboration scale in distributed environment, the propagation path of code security risk is increasingly complex, and a more systematic code security detection and version control method is needed.

[0003] The existing technology mainly analyzes single code file in the code security detection method, which is difficult to effectively identify the security risk propagation caused by the calling relationship between codes in distributed nodes. At the same time, it lacks in-depth analysis of code semantic features and control flow features, and cannot accurately grasp the cross-node code dependency relationship. The version control mechanism is relatively simple, relying only on single signature or voting verification, which is insufficient in security protection in the attack scenario of malicious code injection. Each distributed node conducts security detection independently, and fails to fully utilize the collaborative effect among nodes to improve the detection accuracy. In addition, the version state management lacks strict time sequence constraints, making it difficult to ensure the consistency and traceability of the version evolution process.

[0004] In summary, a code security detection and version control method for distributed environment is needed, which can build a cross-node code dependency graph based on code semantic analysis and control flow analysis, accurately identify the security risk propagation path, integrate the security detection capabilities of distributed nodes using federated learning network, improve the detection accuracy on the premise of protecting node privacy, design double-layer control parameters to realize trusted verification of version submission, and constrain the ordered evolution of version state through time sequence dependency chain, and record the key data such as verification proof generated in the version control process in the distributed ledger to ensure the transparency and non-tamperability of version management, thereby improving the code security detection effect and version control reliability in distributed environment. SUMMARY

[0005] The embodiment of the present application provides a code security detection and version control method and system for distributed environment, which can solve the problems in the prior art.

[0006] The first aspect of the embodiment of the application provides a code security detection and version control method for a distributed environment, comprising:

[0007] receiving a source code file submitted by a distributed node, parsing a syntax tree structure of the source code file, and extracting semantic features and control flow features;

[0008] determining code call relationships and data access patterns based on the semantic features and the control flow features, and establishing a cross-node code dependency graph;

[0009] tracking call links and data flow directions on the code dependency graph, calculating call frequencies, access permissions and data interaction intensities between nodes, and identifying a security risk propagation path;

[0010] based on the security risk propagation path, constructing a communication topology structure between the distributed nodes to establish a federated learning network, training a security risk identification sub-model by each distributed node, integrating the model through an encrypted gradient aggregation and a differential privacy protection mechanism, and generating a security level evaluation result of the code;

[0011] setting double-layer control parameters according to the security level evaluation result, double- confirming the version through hash verification of a proof of work layer and threshold verification of a voting consensus layer, and constraining a version state conversion process based on a time sequence dependency chain;

[0012] based on the code submission request and the security level evaluation result, generating a version submission control instruction through double confirmation, and writing the time sequence dependency chain of the version state and the verification proof data into a distributed ledger.

[0013] In an optional embodiment, tracking call links and data flow directions on the code dependency graph, calculating call frequencies, access permissions and data interaction intensities between nodes, and identifying a security risk propagation path comprises:

[0014] traversing each node of the code dependency graph, extracting direct call relationships between nodes, and constructing a directed edge connection matrix according to a call direction, while recording access permission levels of the nodes in the directed edge connection matrix;

[0015] based on the directed edge connection matrix, traversing by using a heuristic search strategy guided by a search value, determining call links through dynamic priority sorting, and generating a weighted multi-layer call propagation tree;

[0016] detecting data transmission operations on each edge of the multi-layer call propagation tree, recording data flow directions, and counting data interaction times within a unit time to construct a data flow feature topology graph;

[0017] The call frequency weight in the multi-layer call propagation tree is normalized and combined with the data interaction times in the feature topology graph to obtain a security correlation coefficient between node pairs;

[0018] A risk level threshold is set according to the security correlation coefficient, and a call link between node pairs higher than the risk level threshold is identified as a security risk propagation path.

[0019] In an optional embodiment, based on the directed edge connection matrix, a heuristic search strategy guided by search generation value is used for traversal, the call link is determined through dynamic priority sorting, and a multi-layer call propagation tree with weights is generated, including:

[0020] Based on the directed edge connection matrix, a call frequency matrix is obtained by counting the historical call times between nodes, the call frequency matrix and the access permission level of the nodes are linearly weighted, and a call intensity table between nodes is generated;

[0021] According to the call intensity table between nodes, the search generation value of the path is set, the nodes are prioritized according to the search generation value, and a dynamically updated priority search queue is constructed;

[0022] The priority search queue is used as a traversal order guide, and the search space is expanded layer by layer from the starting node, the sum of the search generation values of the newly accessed nodes and the accessed paths is calculated, and the minimum search cost threshold is set, and the priority sequence of the nodes to be searched in the queue is dynamically updated;

[0023] The path search cost record table is maintained during the search process, and when the sum of the search generation values of the newly expanded paths is lower than the minimum search cost threshold, the backtracking operation is triggered, the upper layer node is returned to search other branches, and the call link set is output;

[0024] The call link set is reconstructed into a multi-layer call propagation tree in descending order of the sum of the search generation values, and the call frequency weight is marked on the edges of the multi-layer call propagation tree.

[0025] In an optional embodiment, based on the security risk propagation path, a communication topology structure between distributed nodes is constructed to establish a federated learning network, each distributed node trains a security risk identification sub-model, and the model is integrated through an encrypted gradient aggregation and a differential privacy protection mechanism to generate a security level evaluation result of the code, including:

[0026] Based on the security risk propagation path, a feature vector sequence is constructed, the feature vector sequence and the relationship between distributed nodes are mapped into a double-weighted adjacency matrix, and a communication topology structure diagram between distributed nodes is calculated according to the double-weighted adjacency matrix;

[0027] According to the communication topology diagram, the training load distribution of the distributed nodes is calculated, the training parameter set is configured in combination with the computing capacity of the distributed nodes, and a security risk identification sub-model of each distributed node is constructed;

[0028] The training gradient data of each distributed node is extracted, the training gradient data is reconstructed into a feature mapping matrix, and encryption processing is performed, and the training gradient data is transmitted to the center node to perform aggregation operation to obtain the global encrypted gradient;

[0029] The trust degree index of the distributed node is calculated according to the historical behavior, the Laplace noise parameter is determined, and the privacy protection gradient is obtained by performing differential privacy protection on the global encrypted gradient;

[0030] The privacy protection gradient is distributed to each distributed node, the model parameters are updated, and the optimized security risk identification model is obtained by iterative training, and the security level evaluation result is determined by inputting the code to be evaluated.

[0031] In an optional embodiment, extracting the training gradient data of each distributed node, reconstructing the training gradient data into a feature mapping matrix, and performing encryption processing to obtain the global encrypted gradient by transmitting the training gradient data to the center node to perform aggregation operation includes:

[0032] The training gradient data of each distributed node is extracted, and the gradient data is reconstructed into a feature mapping matrix according to the neural network hierarchical structure, and a polynomial encoding sequence is obtained by performing dimension reduction conversion on the feature mapping matrix;

[0033] The polynomial encoding sequence is segmented according to the data block size, and each data block is encrypted by using a homomorphic encryption key, and a digital signature is generated in combination with the identity characteristics of the distributed node, and the encrypted data block and the digital signature are combined to form a secure transmission package;

[0034] After receiving the secure transmission package, the validity of the digital signature is verified, the encrypted data block is extracted and a ciphertext mapping table is established, and the encrypted gradient of different distributed nodes is aligned to a unified ciphertext space according to the mapping relationship;

[0035] Weighted summation operation is performed in the unified ciphertext space, the aggregation weight is determined based on the node trust degree, and the global encrypted gradient is calculated.

[0036] In an optional embodiment, according to the security level evaluation result, the double-layer control parameters are set, the version is double-confirmed through the hash verification of the proof-of-work layer and the threshold verification of the voting consensus layer, and the version state conversion process is constrained based on the time sequence dependency chain includes:

[0037] According to the security level evaluation result, double-layer control parameters are generated, including the hash difficulty coefficient of the proof-of-work layer and the verification unit threshold of the voting consensus layer;

[0038] The hash difficulty coefficient is used to perform hash calculation on the version submission request at the proof-of-work layer to obtain a proof-of-work identifier, and the proof-of-work identifier is compared with a preset hash condition, and when the proof-of-work identifier satisfies the preset hash condition, a candidate version record is generated;

[0039] The candidate version record is sent to a voting consensus layer, a voting weight distribution table is generated based on historical voting records of the verification unit, multiple rounds of voting verification are performed and the verification unit threshold is dynamically updated, final voting consensus data is generated, a timestamp is added to the candidate version record, and a time sequence dependency chain is constructed;

[0040] Each link unit in the time sequence dependency chain is traversed, and it is verified whether the timestamp of each link unit satisfies the increasing relationship and the version state corresponding to the previous version identifier has been in the confirmed state, and when the verification is passed, the version state of the candidate version record is converted from the candidate state to the confirmed state, and stored in the version control database.

[0041] In an optional embodiment, the candidate version record is sent to the voting consensus layer, the voting weight distribution table is generated based on the historical voting records of the verification unit, the multiple rounds of voting verification are performed and the verification unit threshold is dynamically updated, the final voting consensus data is generated, the timestamp is added to the candidate version record, and the time sequence dependency chain is constructed, which comprises:

[0042] The historical voting records of each verification unit are extracted, the number of correct votes and the response time interval are calculated, the credit points of the verification unit are accumulated, the trust relationship network between the verification units is constructed according to the credit points, the voting weight distribution table is generated, and the initial verification unit threshold is determined;

[0043] According to the number of network connections of the verification unit and the voting weight distribution table, the voting groups are divided, the first round of voting results are counted according to the weight in the voting group, the voting data are combined according to the weight proportion of each group, the verification unit threshold is updated, and the preliminary consensus data is generated;

[0044] The cross-group verification is performed on the preliminary consensus data, the weighted deviation value is calculated in combination with the voting weight distribution table, the second voting confirmation is triggered when the weighted deviation value is less than the verification unit threshold, and the verification unit threshold is further updated according to the verification result of each group;

[0045] The second voting data and the preliminary consensus data are weighted calculated according to the voting weight distribution table, the calculation result is verified based on the verification unit threshold, and the final voting consensus data is output, and the timestamp is added to the candidate version record;

[0046] The time sequence dependency chain is constructed based on the final voting consensus data and the timestamp, and the version state conversion is completed.

[0047] In a second aspect of the embodiment of the application, a code security detection and version control system for a distributed environment is provided, comprising:

[0048] The first unit is configured to receive a source code file submitted by a distributed node, parse a syntax tree structure of the source code file, and extract semantic features and control flow features;

[0049] The second unit is configured to determine code call relationships and data access patterns based on the semantic features and the control flow features, and establish a code dependency graph across nodes;

[0050] The third unit is configured to track call links and data flow directions on the code dependency graph, calculate call frequencies, access permissions and data interaction intensities between nodes, and identify a security risk propagation path;

[0051] The fourth unit is configured to construct a communication topology structure between the distributed nodes based on the security risk propagation path, establish a federated learning network, train a security risk identification sub-model by each distributed node, integrate the model through an encrypted gradient aggregation and a differential privacy protection mechanism, and generate a security level evaluation result of the code;

[0052] The fifth unit is configured to set double-layer control parameters according to the security level evaluation result, perform double confirmation on the version through hash verification of a proof of work layer and threshold verification of a voting consensus layer, and constrain a version state conversion process based on a time sequence dependency chain.

[0053] The sixth unit is configured to generate a version submission control instruction through the double confirmation based on the code submission request and the security level evaluation result, and write the time sequence dependency chain of the version state and the verification proof data into a distributed ledger.

[0054] The third aspect of the embodiment of the present application provides an electronic device, comprising:

[0055] a processor;

[0056] a memory for storing processor-executable instructions;

[0057] The processor is configured to invoke the instructions stored in the memory to execute the method described above.

[0058] The fourth aspect of the embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon, wherein the computer program instructions are executed by a processor to implement the method described above.

[0059] In the embodiment of the present application, by parsing the syntax tree structure of the source code to extract semantic features and control flow features, a code dependency graph across nodes is established, which can comprehensively depict the calling relationship and data access mode of the code in a distributed environment, and by tracking the calling link and data flow on the dependency graph, the calling frequency, access permission and data interaction strength between nodes are accurately calculated, so as to accurately identify the propagation path of the security risk between the distributed nodes, and significantly improve the coverage and risk identification accuracy of the code security detection; based on the security risk propagation path, a federated learning network is constructed, each distributed node independently trains a security risk identification sub-model, and the encrypted gradient aggregation and differential privacy protection mechanism are used for model integration, which not only ensures the privacy security of the code data of each node, but also realizes the intelligent security evaluation ability of distributed collaboration, avoids the data leakage risk and single point failure problem in the traditional centralized detection method, and effectively improves the reliability and scalability of the security detection; a double-layer control parameter is set, a double confirmation mechanism of version is realized through the hash verification of the proof of work layer and the threshold verification of the voting consensus layer, the version state conversion process is constrained in combination with the time sequence dependency chain, and the verification proof data is written into the distributed ledger, thereby constructing a traceable and tamper-proof version control system, ensuring the security and consistency of the code version management, and solving the technical problems that the version control is vulnerable to attack and difficult to trace in the distributed environment. BRIEF DESCRIPTION OF DRAWINGS

[0060] Figure 1 A flowchart of a code security detection and version control method for a distributed environment according to an embodiment of the present application is shown in

[0061] Figure 2 A flowchart for generating a minimum cost propagation path tree is shown in DETAILED DESCRIPTION

[0062] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0063] The technical scheme of the present application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described in some embodiments.

[0064] Figure 1 A flowchart of a code security detection and version control method for a distributed environment according to an embodiment of the present application is shown in Figure 1 as shown, the method comprises:

[0065] receiving a source code file submitted by a distributed node, parsing a syntax tree structure of the source code file, and extracting semantic features and control flow features;

[0066] based on the semantic features and the control flow features, determining code call relationships and data access patterns, and establishing a code dependency graph across nodes;

[0067] tracking call links and data flow directions on the code dependency graph, calculating call frequencies, access permissions, and data interaction intensities between nodes, and identifying a security risk propagation path;

[0068] based on the security risk propagation path, constructing a communication topology structure between distributed nodes, establishing a federated learning network, training a security risk identification sub-model by each distributed node, integrating the model through an encrypted gradient aggregation and a differential privacy protection mechanism, and generating a security level evaluation result of the code;

[0069] setting double-layer control parameters according to the security level evaluation result, performing double confirmation on the version through hash verification of a proof of work layer and threshold verification of a voting consensus layer, and constraining a version state conversion process based on a time sequence dependency chain;

[0070] based on the code submission request and the security level evaluation result, generating a version submission control instruction through the double confirmation, and writing the time sequence dependency chain of the version state and the verification proof data into a distributed ledger.

[0071] In an optional implementation, tracking call links and data flow directions on the code dependency graph, calculating call frequencies, access permissions, and data interaction intensities between nodes, and identifying a security risk propagation path includes:

[0072] traversing each node of the code dependency graph, extracting direct call relationships between nodes, and constructing a directed edge connection matrix according to call directions, while recording access permission levels of the nodes in the directed edge connection matrix;

[0073] based on the directed edge connection matrix, using a heuristic search strategy guided by search value to perform traversal, determining call links through dynamic priority sorting, and generating a weighted multi-layer call propagation tree;

[0074] detecting data transmission operations on each edge of the multi-layer call propagation tree, recording data flow directions, and counting data interaction times per unit time, and constructing a data flow feature topology graph;

[0075] jointly calculating the call frequency weights in the multi-layer call propagation tree and the data interaction times in the feature topology graph after normalization processing, to obtain a security correlation coefficient between node pairs;

[0076] A risk level threshold is set according to the security correlation coefficient, and a call link between a node pair higher than the risk level threshold is identified as a security risk propagation path.

[0077] In one specific embodiment, a full traversal is performed on the code dependency graph. Each program file is regarded as an independent node, and a direct call relationship between the nodes is extracted by a static analysis tool. For example, when a method of class A calls a method of class B, it is determined that there is a call relationship between node A and node B. According to the call direction, a directed edge connection matrix is constructed, which is a two-dimensional array. The value of a matrix element is 1, indicating that there is a call from the row index node to the column index node, and the value is 0, indicating that there is no call relationship. At the same time, the access permission level of each node is recorded in the matrix, such as public access (value 3), protected access (value 2), private access (value 1), and default access (value 0). This permission level record is helpful for subsequent security risk assessment. Taking a distributed application containing 5 code files as an example, a 5x5 directed edge connection matrix can be obtained through code scanning, in which node 1 calls nodes 2 and 3, node 2 calls node 4, node 3 calls node 5, and the corresponding matrix elements are marked as 1, and the access permission levels of these nodes are recorded as 3, 2, 2, 1, and 0, respectively.

[0078] Based on the constructed directed edge connection matrix, a heuristic search strategy using search cost value guidance is used for graph traversal. The heuristic search strategy uses an evaluation function to calculate the expected cost from the current node to the target node, and preferentially explores paths with lower cost. The search cost value is calculated by weighting three factors: call depth, permission level difference, and historical call frequency. The deeper the call depth, the higher the cost value; the greater the difference between the caller and the callee, the higher the cost value; the higher the historical call frequency, the lower the cost value. A dynamic priority queue is used to maintain the nodes to be accessed, and the node with the smallest cost value is taken out of the queue each time for expansion. This way can efficiently find important call links while avoiding the problem of search space explosion. For each discovered call link, a weighted multi-layer call propagation tree is constructed according to the call frequency. In the above example, if the call link from node 1 to node 4 (1→2→4) is called 200 times during monitoring, and the call link from node 1 to node 5 (1→3→5) is called 50 times, the weights of the two paths are set to 200 and 50, respectively.

[0079] After obtaining the multi-layer call propagation tree, each edge of the tree needs to be analyzed in depth to detect data transmission operations. This includes parameter passing, return value passing, shared memory access, and other data exchange methods. Through bytecode or intermediate code analysis, the data flow direction is identified, such as input parameters representing data flowing from the caller to the callee, and return values representing data flowing from the callee to the caller. At the same time, with the help of performance monitoring tools, the number of data interactions per unit time is counted. For example, within a one-hour monitoring window, if node 2 transmits data to node 4 320 times and node 4 returns data to node 2 280 times, this information is recorded. By integrating all the data flow information between nodes, a data flow feature topology graph is constructed, which not only contains the call relationship but also contains the data flow direction and interaction frequency information.

[0080] In order to comprehensively evaluate the security association degree between nodes, the call frequency weight in the multi-layer call propagation tree and the data interaction times in the feature topology graph are normalized and jointly calculated. The normalization process uses the max-min normalization method to map the call frequency weight and data interaction times to the range of 0 to 1. For any two node pairs, the security association coefficient is calculated by weighted average, where the call frequency weight normalization value accounts for 0.4 and the data interaction times normalization value accounts for 0.6. This weighting method reflects that the importance of data interaction in security risk is slightly higher than that of the call relationship itself. In the above example, the call frequency weight normalization value between node 2 and node 4 is 0.8, and the data interaction times normalization value is 0.9, so the security association coefficient is 0.4 x 0.8 + 0.6 x 0.9 = 0.86.

[0081] According to the calculated security association coefficient, the risk level threshold is set through cluster analysis. Generally, the security association coefficient is divided into high, medium, and low risk levels, and the corresponding thresholds are 0.8 and 0.5. Node pairs with a security association coefficient greater than or equal to 0.8 are identified as high risk, those between 0.5 and 0.8 are medium risk, and those less than 0.5 are low risk. The call links between node pairs above the risk level threshold (usually referring to high risk level) and data flow direction are identified as security risk propagation paths. These paths are highlighted in red in the visualization interface and trigger the security warning mechanism. For medium risk paths, they are identified in yellow and added to the list of key monitoring. In the version control process, for code files involved in high-risk paths, code review and security testing are required, and only after passing the review can they be submitted to the main branch.

[0082] In this embodiment, security risk propagation paths in a distributed environment can be effectively identified to prevent security vulnerabilities from spreading in the system.

[0083] In an alternative embodiment, based on the directed edge connection matrix, a heuristic search strategy guided by search generation value is used for traversal, the calling link is determined by dynamic priority ranking, and the generation of the weighted multi-layer calling propagation tree includes:

[0084] Based on the directed edge connection matrix, the calling frequency matrix is obtained by counting the historical calling times between nodes, the calling frequency matrix and the access permission level of the node are linearly weighted and operated to generate the calling intensity table between nodes;

[0085] According to the calling intensity table between nodes, the search generation value of the path is set, the nodes are prioritized according to the search generation value, and a dynamically updated priority search queue is constructed;

[0086] The priority search queue is used as a traversal order guide, and the search space is expanded layer by layer from the starting node, the sum of the search generation values of the newly accessed nodes and the accessed paths is calculated, and the minimum search cost threshold is set to dynamically update the priority sequence of the nodes to be searched in the queue;

[0087] In the search process, the path search cost record table is maintained, and when the sum of the search generation values of the newly expanded paths is lower than the minimum search cost threshold, the backtracking operation is triggered, the upper layer node is returned to search other branches, and the calling link set is output;

[0088] The calling link set is reconstructed into a multi-layer calling propagation tree in descending order of the sum of the search generation values, and the calling frequency weight is marked on the edge of the multi-layer calling propagation tree.

[0089] In a specific embodiment, in the process of implementing the code security detection and version control method for a distributed environment, the directed edge connection matrix is the basic representation form of the code dependency relationship, the directed edge connection matrix uses a two-dimensional array structure, and the row and column indexes correspond to the caller node and the callee node respectively. The matrix element value is 1 indicating that there is a calling relationship, and 0 indicating that there is no calling relationship. Through the deployment of the calling monitoring probe on each distributed node, the calling information during code running is continuously collected. The monitoring probe adds a counter before and after the method call based on the bytecode injection technology, and records the number of times and the timestamp of the call. These raw calling data are sent to the central data collector, and after data cleaning and aggregation processing, the historical calling time statistics result is formed. For a distributed application containing 100 core code files, about 50 million method call records can be collected in a week of monitoring period. After aggregation, a 100x100 calling frequency matrix is generated, and each element in the matrix represents the calling times of the row index node to the column index node. For example, a financial transaction processing module calls the risk assessment module 3240 times in a day, and the corresponding matrix element value is 3240.

[0090] The call frequency matrix provides a quantitative indicator of the strength of inter-code interaction, but does not take into account the security attributes of the nodes themselves. To this end, the call frequency is linearly weighted with the node access permission level to generate a more security-oriented inter-node call strength table. The node access permission level is divided into four levels: public access (value 3), protected access (value 2), private access (value 1), and default access (value 0). The higher the permission level, the greater the security risk. The call strength calculation adopts a weighted method, with the call frequency weight coefficient set to 0.7 and the permission level weight coefficient set to 0.3. For a node pair with a call frequency of 3240 times, a caller permission level of 3 (public access), and a callee permission level of 1 (private access), the call strength value is calculated as: 0.7 x (3240 / maximum call frequency) + 0.3 x (3 + 1) / 6 = 0.7 x 0.65 + 0.3 x 0.67 = 0.65. The call strength table is also a 100 x 100 matrix, with matrix element values ranging from 0 to 1. The larger the value, the tighter the call relationship and the higher the security risk.

[0091] The call strength table is directly used to calculate the search generation value of the path. The search generation value is inversely proportional to the call strength, i.e., the larger the call strength, the smaller the search generation value. The search generation value is calculated as: 1 minus the call strength value. The purpose of this design is to prioritize the exploration of high call strength paths, as these paths are more likely to be the main functional flow or the transmission path of security risks. According to the calculated search generation value, all adjacent nodes are prioritized and a dynamically updated priority search queue is constructed. This queue is implemented using a minimum heap data structure, with the top element always being the node with the smallest search generation value, ensuring that the search continues from the most prioritized node each time. The priority search queue initially contains only the starting node, and as the search process progresses, new nodes are constantly added and old nodes are removed.

[0092] The priority search queue is used as the traversal order guide, and the search space is expanded layer by layer from the specified starting node. Each time a node is taken out of the queue, the node is marked as visited, and all unvisited adjacent nodes are examined. For each adjacent node, the sum of the search cost values from the starting node to the node through the visited path is calculated. The sum of the search cost values here uses an accumulative calculation method. If the path from the starting node to the current node contains three edges, the corresponding search cost values are 0.2, 0.3, and 0.4, respectively, and the sum of the search cost values is 0.2+0.3+0.4=0.9. The algorithm sets a minimum search cost threshold, with a default value of 3.0. When the sum of the path search cost values exceeds this threshold, it is considered that the path has a low priority and is no longer searched in that direction. For adjacent nodes that do not exceed the threshold, they are added to the priority queue, and their positions in the queue are updated according to the newly calculated sum of the cost values. Experiments show that in a code library containing complex circular dependencies, setting a reasonable minimum search cost threshold can reduce the search space by about 65% while retaining more than 95% of the key call paths.

[0093] A path search cost record table is maintained during the search process, implemented in the form of a hash table, with the key being the node identifier and the value being the current minimum sum of search cost values to reach the node. Each time a node is accessed, it is checked whether the node exists in the record table. If it exists, the sum of the cost values of the new and old paths is compared. If the sum of the cost values of the new path is smaller, the record table is updated and the search continues. If the sum of the cost values of the old path is smaller, the new path is abandoned. When the sum of the search cost values of the newly expanded path is lower than the minimum search cost threshold but greater than the existing value in the record table, a backtracking operation is triggered, returning to the upper layer node to search other branches. The backtracking operation is implemented by maintaining a node access stack. Each time the stack is popped, the top node is marked as not fully visited, indicating that the node still has other branches to explore. When the priority queue is empty or all reachable nodes have been visited, the search ends and the call link set is output. In an application containing 100 core files, the typical output call link set size is about 300 to 500 different paths, covering all important functional processes and data exchange channels.

[0094] The call link set is restructured into a multi-layer call propagation tree in descending order of the sum of search generation values. The call propagation tree adopts a forest structure and contains multiple independent trees, and the root node of each tree is the starting node of the call link. Each edge of the tree represents a direct call relationship, and the direction of the edge points from the caller to the callee. The construction of the call propagation tree adopts an incremental manner and processes each call link in turn. For each link, starting from the root node, it is checked whether the corresponding path exists in the tree node by node, and for the part that does not exist, a new node and edge are created to extend it. The call frequency weight is marked on each edge of the multi-layer call propagation tree, and the weight value is directly obtained from the call frequency matrix. For example, the frequency of node A calling node B is 2000 times, and the weight 2000 is marked on the edge from A to B. The call propagation tree constructed in this way not only retains the code structure information, but also intuitively shows the call intensity distribution through the edge weight, providing an important basis for subsequent security risk assessment. The call propagation tree is displayed through a visualization tool, and security analysts can quickly identify high-frequency call paths and potential security risk propagation channels, and then implement targeted security measures and version control strategies.

[0095] As shown in Figure 2 , a minimum cost propagation path tree generation flowchart is shown.

[0096] In an optional implementation, based on the security risk propagation path, a communication topology structure between distributed nodes is constructed to establish a federated learning network, each distributed node trains a security risk identification sub-model, and the model is integrated through an encrypted gradient aggregation and a differential privacy protection mechanism to generate a security level evaluation result of the code, including:

[0097] Based on the security risk propagation path, a feature vector sequence is constructed, the feature vector sequence and the relationship between the distributed nodes are mapped into a double-weighted adjacency matrix, and a communication topology structure diagram between the distributed nodes is calculated according to the double-weighted adjacency matrix;

[0098] According to the communication topology structure diagram, the training load distribution of the distributed nodes is calculated, the training parameter set is configured in combination with the computing capacity of the distributed nodes, and a security risk identification sub-model of each distributed node is constructed;

[0099] The training gradient data of each distributed node is extracted, the training gradient data is restructured into a feature mapping matrix and is encrypted, and is transmitted to a center node to perform an aggregation operation to obtain a global encrypted gradient;

[0100] The trust degree index of the distributed node is calculated by using the historical behavior, the Laplace noise parameter is determined, and the privacy protection gradient is obtained by performing differential privacy protection on the global encrypted gradient;

[0101] The privacy-protected gradient is distributed to each distributed node to update the model parameters, and an optimized security risk identification model is obtained through iterative training, and the security level evaluation result of the code to be evaluated is determined.

[0102] In a specific embodiment, for the identified security risk propagation path, constructing a feature vector sequence is the basis for achieving accurate security risk identification. The feature vector is composed of multiple attributes, including path length, node access permission level, call frequency, data traffic size, code complexity, etc. Each dimension uses a normalized value of 0 to 1 to ensure that different feature dimensions are consistent. Taking an e-commerce application as an example, the risk propagation path from the payment module to the account module can extract the feature vector [0.8, 0.7, 0.9, 0.6, 0.5], each dimension represents the relative path length as 0.8 (close to the longest path), the average permission level as 0.7 (biased towards public access), the call frequency as 0.9 (very frequent), the data traffic as 0.6 (moderate), and the code complexity as 0.5 (moderate). These feature vectors are mapped to a double-weighted adjacency matrix with distributed nodes, and the matrix size is the square of the number of nodes, and each element contains two weight values: feature similarity weight and physical connection weight. The feature similarity weight is obtained by calculating the cosine similarity between the feature vectors, and the physical connection weight is determined based on the network delay, bandwidth and packet loss rate between nodes. In an environment containing 50 distributed nodes, the double-weighted adjacency matrix is of size 50x50, and the logical association strength and physical communication quality between nodes can be intuitively displayed through the matrix.

[0103] According to the double-weighted adjacency matrix, the communication topology structure diagram between the distributed nodes is calculated, and the communication topology structure diagram is represented by a directed graph, where the nodes represent distributed computing units and the edges represent communication links. The thickness of the edge represents the communication bandwidth, and the color depth represents the feature similarity. The communication topology structure diagram is subjected to community discovery through a spectral clustering algorithm, and closely related nodes are grouped to form multiple sub-network communities. In practical applications, 50 nodes can usually be clustered into 5 to 8 communities, and the communication between nodes in each community is frequent and the feature similarity is high. For example, nodes responsible for user authentication-related functions are clustered into the same community, including registration, login, permission verification, and other components. The communication topology structure diagram not only reflects the static network structure, but also records dynamic communication behavior, such as periodic synchronization, burst request response, and other patterns, providing a basis for subsequent training load allocation.

[0104] The training load distribution of the distributed nodes is calculated according to the communication topology diagram, and a node centrality and computing power weighted distribution method is adopted. The higher the node centrality, the closer the connection between the node and other nodes, and the greater the training load. Combined with the computing power of the distributed nodes, including the number of processor cores, memory capacity, storage speed and other hardware indicators, the training parameter set is configured. The training parameters include batch size, learning rate, iteration number, regularization coefficient, etc. High-performance nodes are configured with larger batch sizes (such as 256) and higher learning rates (such as 0.01), and low-performance nodes are configured with smaller batch sizes (such as 64) and lower learning rates (such as 0.005). Through adaptive adjustment of parameters, the training time of each node is basically consistent, avoiding training bottlenecks. Based on the configured training parameters, each distributed node constructs a security risk identification sub-model, which adopts a deep neural network structure, including a feature extraction layer, an attention mechanism layer and a classification layer. The model input is the syntax tree and call relationship graph of the code snippet, and the output is the security risk score and type identification.

[0105] During the training process, each distributed node uses local data for forward and backward propagation calculations to extract training gradient data. Training gradient data is the first derivative of model parameters with respect to the loss function, which records the parameter update direction and amplitude. To ensure data privacy, the training gradient data is reconstructed into a feature mapping matrix, and the singular value decomposition technique is used for dimensionality reduction to retain main feature information while reducing communication overhead. The feature mapping matrix is processed by homomorphic encryption, using a Paillier encryption algorithm with a key length of 2048 bits to ensure that addition and scalar multiplication operations can be performed in an encrypted state. The size of the encrypted gradient data is usually 1.5 to 2 times that of the original gradient, and is serialized in JSON format and transmitted to the center node. The center node receives the encrypted gradients of all distributed nodes and performs weighted average aggregation operations to obtain the global encrypted gradient. The weight coefficients are determined according to the data volume and data quality of each node, and nodes with larger data volume and higher quality have higher weights.

[0106] Not all distributed nodes are fully trusted, and there may be malicious nodes submitting incorrect gradients to affect model training. Therefore, the trust degree of the distributed nodes is calculated based on historical behavior. Historical behavior indicators include gradient stability, prediction accuracy change, communication reliability, etc. The trust degree indicator is updated using the exponential moving average method, with a new behavior weight of 0.3 and a historical cumulative weight of 0.7. The trust degree indicator ranges from 0 to 1, with an initial value of 0.8. When the gradient of a certain node deviates from the global average gradient by more than 3 times the standard deviation, its trust degree indicator will decrease by 0.1. The trust degree indicator is used to determine the Laplace noise parameter. The lower the trust degree, the larger the noise parameter, providing stronger privacy protection. Differential privacy protection is performed on the global encrypted gradient, adding random noise following the Laplace distribution. The typical value of the noise parameter is between 0.01 and 0.1, which can provide ε = 1 to 5 differential privacy guarantee, where the smaller the ε, the higher the privacy protection level.

[0107] The privacy-protected gradient is decrypted and distributed to each distributed node, which uses the received gradient to update the local model parameters. The update uses the momentum gradient descent method with a momentum factor of 0.9. The learning rate is dynamically adjusted during training, with an initial value of 0.01 and a decay of 0.9 times the original value every 10 rounds. The optimized security risk identification model is obtained through iterative training, which usually requires 50 to 100 iterations to reach convergence. The final model has a security risk identification accuracy of 92% on the test set, a recall rate of 88%, and an F1 score of 90%. After the model is deployed, when inputting the code to be evaluated, the static features and dynamic behavior features of the code are first extracted, and the security risk score is calculated through model inference. The security level is divided into four levels according to the score range: high risk (score > 0.8), medium risk (0.5 < score ≤ 0.8), low risk (0.2 < score ≤ 0.5), and safe (score ≤ 0.2). The evaluation results are integrated with the version control system, and high-risk code must be reviewed by at least two experts before being merged into the main branch, medium-risk code must be added with unit tests to cover risk points, low-risk code must be added with annotations to explain potential problems, and safe code can be directly submitted.

[0108] In an alternative embodiment, the training gradient data of each distributed node is extracted, the training gradient data is reconstructed into a feature mapping matrix, and the feature mapping matrix is encrypted and transmitted to the center node for aggregation operation to obtain the global encrypted gradient.

[0109] The training gradient data of each distributed node is extracted, and the gradient data is reconstructed into a feature mapping matrix according to the neural network hierarchical structure. The feature mapping matrix is subjected to dimensionality reduction conversion to obtain a polynomial encoding sequence.

[0110] The polynomial encoding sequence is segmented according to the data block size, a homomorphic encryption key is used to perform an encryption operation on each data block, a digital signature is generated in combination with the identity characteristics of the distributed nodes, and the encrypted data block and the digital signature are combined to form a secure transmission package;

[0111] After receiving the secure transmission package, the validity of the digital signature is verified, the encrypted data block is extracted and a ciphertext mapping table is established, and the encrypted gradients of different distributed nodes are aligned to a unified ciphertext space according to the mapping relationship;

[0112] In the unified ciphertext space, a weighted summation operation is performed, the aggregation weight is determined based on the node credibility, and the global encrypted gradient is calculated.

[0113] In one specific embodiment, after the distributed nodes are trained, the gradient data generated during the training process needs to be extracted from each node. For a deep learning model, the gradient data of each node is usually in the form of a multi-dimensional tensor. Taking a neural network containing three convolutional layers and two fully connected layers as an example, its gradient data is four-dimensional convolutional layer gradient and two-dimensional fully connected layer gradient. The extracted gradient data is organized according to the network level structure, for example, the convolutional layer gradient can be represented as [64, 32, 3, 3] form, representing 64 output channels, 32 input channels, and 3x3 convolution kernel size; the fully connected layer gradient can be represented as [512, 128] form, representing 512 output features and 128 input features. These multi-dimensional gradient data are flattened in turn and spliced by level to obtain a feature mapping matrix.

[0114] For the constructed feature mapping matrix, a dimension reduction conversion technique is used to compress the high-dimensional gradient data into a polynomial encoding sequence. Through a random projection method, a randomly generated projection matrix is used to map the original high-dimensional gradient data to a low-dimensional space. For example, for a gradient vector with a dimension of one million, it can be reduced to a few thousand dimensions through random projection. The main structural information of the gradient data is preserved during dimension reduction, while the complexity of subsequent encryption calculations is reduced. The reduced data is further converted into a coefficient sequence through polynomial encoding, i.e., the gradient values are mapped to the coefficients of the polynomial. For example, the original gradient values are [0.231, -0.189, 0.567], and after conversion, the polynomial coefficient sequence [0.231, -0.189, 0.567, 0] is obtained.

[0115] After the polynomial encoding sequence is generated, the sequence is segmented according to a preset data block size. The selection of the data block size needs to balance the encryption efficiency and communication overhead, and a block size of 2KB to 4KB is usually selected. Assuming that the data block size is selected to be 2048 elements, the polynomial encoding sequence with a length of 10240 will be divided into 5 data blocks. For each data block, homomorphic encryption technology is used for encryption processing to ensure the security of the data in the transmission and aggregation process. Specifically, a partial homomorphic encryption scheme is used, which supports addition operations in the ciphertext space. The encryption process needs to generate an encryption key pair in advance, including a public key and a private key. The public key is used to encrypt the data, and the private key is reserved for the final decryption operation. For the data block [0.231, -0.189, 0.567, 0], the encrypted data block in the form of ciphertext is obtained, represented as a set of large integers.

[0116] To ensure the verifiability of data transmission, a digital signature is generated in combination with the identity characteristics of the distributed nodes. The identity characteristics include node identifiers, network addresses, security certificates, and other information. A hash algorithm is used to calculate the digest of the encrypted data block, and then the digest is signed using the node private key. For example, the SHA-256 hash value of the encrypted data block is calculated to obtain a 32-byte digest, and then an elliptic curve digital signature algorithm is used to generate 64-byte signature data. The encrypted data block and the digital signature are combined, and necessary metadata such as timestamps, sequence numbers, etc. are added to form a complete secure transmission package.

[0117] After receiving the secure transmission package from each distributed node, the central server verifies the validity of the digital signature. The verification process uses the public key of the node to decrypt the signature, calculates the hash value of the received encrypted data block, and compares the decrypted signature with the calculated hash value to determine whether they are consistent. If they are consistent, the verification is passed; otherwise, it is determined that the transmission package may be tampered with or the source is untrustworthy, and it is discarded. The encrypted data block is extracted from the verified transmission package, and a mapping relationship between the node identifier and the encrypted data block is established, i.e. a ciphertext mapping table. The structure of the ciphertext mapping table can be represented as a set of key-value pairs, with the key being the node identifier and the value being the encrypted data block set of the corresponding node.

[0118] Since different nodes may use different encryption keys, it is necessary to align the encrypted gradients of different nodes to a unified ciphertext space. The alignment process uses the characteristics of homomorphic encryption to achieve conversion between different ciphertext spaces through key conversion technology. For example, node A uses key KA to encrypt to get ciphertext CA, and node B uses key KB to encrypt to get ciphertext CB. Through a key conversion function, CA is converted to an equivalent ciphertext CA' encrypted using KB, so that CA' and CB are in the same ciphertext space. In actual implementation, proxy re-encryption technology is used to generate a conversion key from key KA to KB, and then the conversion key is used to process CA to obtain CA'.

[0119] After the ciphertext alignment is completed, a weighted sum operation is performed in the unified ciphertext space. The aggregation weight is determined based on the node credibility. Nodes with high credibility are assigned higher weights, and nodes with low credibility are assigned lower weights. The node credibility is evaluated comprehensively according to historical interaction records, response time, data quality, and other factors. For example, the credibility scores of five nodes are [0.95, 0.88, 0.76, 0.92, 0.85], and the normalized weights are [0.22, 0.20, 0.17, 0.21, 0.20]. Using the ciphertext addition and scalar multiplication features supported by homomorphic encryption, the weighted sum of the encrypted gradients of each node is calculated, and the result is the global encrypted gradient, which maintains the encrypted state to ensure data security.

[0120] In the embodiment, the secure and efficient aggregation of gradient data in a distributed environment is achieved, and the contradiction between data privacy protection and collaborative learning is solved, providing a reliable security mechanism for distributed machine learning.

[0121] In an optional implementation, double-layer control parameters are set according to the security level evaluation results, and the version is double-confirmed through hash verification of the proof-of-work layer and threshold verification of the voting consensus layer, and the version state conversion process is constrained based on the time sequence dependency chain, including:

[0122] The double-layer control parameters are generated according to the security level evaluation results, including the hash difficulty coefficient of the proof-of-work layer and the verification unit threshold of the voting consensus layer;

[0123] Based on the hash difficulty coefficient, hash calculation is performed on the version submission request in the proof-of-work layer to obtain a proof-of-work identifier, and the proof-of-work identifier is compared with a preset hash condition. When the proof-of-work identifier meets the preset hash condition, a candidate version record is generated;

[0124] The candidate version record is sent to the voting consensus layer, a voting weight distribution table is generated based on the historical voting records of the verification unit, multiple rounds of voting verification are performed and the verification unit threshold is dynamically updated, and final voting consensus data is generated. A timestamp is added to the candidate version record and a time sequence dependency chain is constructed;

[0125] Each link unit in the time sequence dependency chain is traversed, and it is verified whether the timestamp of each link unit satisfies the increasing relationship and the version state corresponding to the previous version identifier is in the confirmed state. When the verification is passed, the version state of the candidate version record is converted from the candidate state to the confirmed state, and stored in the version control database.

[0126] In a specific embodiment, the code security detection and version control method for distributed environment needs to generate appropriate control parameters according to the code security level evaluation results in practical application. The security level evaluation is based on multiple indicators such as code complexity, impact range, and function importance, and the security risk coefficient is calculated through a preset evaluation model. For example, for an enterprise-level distributed application, its core payment module may be evaluated as security level 5 (the highest level), and the log recording module may be evaluated as security level 2. After the security level evaluation is completed, double-layer control parameters are generated, including the hash difficulty coefficient of the proof-of-work layer and the verification unit threshold of the voting consensus layer. The hash difficulty coefficient is positively correlated with the security level, and the higher the security level, the greater the difficulty coefficient. In specific implementation, security level 1 corresponds to difficulty coefficient 0.05, security level 2 corresponds to 0.1, security level 3 corresponds to 0.2, security level 4 corresponds to 0.35, and security level 5 corresponds to 0.5. The verification unit threshold is also determined based on the security level, which represents the minimum number of verification units required to reach consensus in the voting consensus layer. Security level 1 corresponds to threshold 0.6, security level 2 corresponds to 0.65, security level 3 corresponds to 0.7, security level 4 corresponds to 0.8, and security level 5 corresponds to 0.9.

[0127] When the developer submits the code version, the proof-of-work layer performs hash calculation according to the hash difficulty coefficient generated as described above. The submission request contains code version content, version number, developer identity information, and other metadata. The system combines these information with a random number (nonce value) to calculate the proof-of-work identifier through hash algorithms such as SHA-256. The preset hash condition is represented as the target hash value must be less than a certain threshold, which is determined by the hash difficulty coefficient. Exemplarily, if the hash difficulty coefficient is 0.2, the preset hash condition can be that the leading zero bits of the hash result are at least 4 bits. To find the proof-of-work identifier that meets the condition, the system needs to continuously adjust the nonce value and recalculate the hash until the result that meets the condition is obtained. For example, for a payment module code submission with security level 3, the system may need to try thousands of times of hash calculation to find the nonce value that meets the condition. When the proof-of-work identifier that meets the condition is found, the system combines the version submission request with the proof-of-work identifier to generate a candidate version record. The candidate version record contains code content, version number, submission time, developer information, proof-of-work identifier, and other information.

[0128] After the candidate version record is generated, it is sent to the voting consensus layer for further verification. The voting consensus layer is composed of multiple verification units, which are usually highly trusted nodes in the distributed network. Based on the historical voting records of the verification units, a voting weight distribution table is generated, which determines the weight of each verification unit in the voting process. Historical voting records include correct voting rate, response time, online rate, etc. For example, verification unit A has 98 correct votes out of 100 in the past, with an average response time of 200 milliseconds and an online rate of 99.5%; verification unit B has 85 correct votes out of 100 in the past, with an average response time of 350 milliseconds and an online rate of 95.8%. According to these indicators, the weights of verification units A and B are calculated as 0.12 and 0.08, respectively. After receiving the candidate version record, the verification unit performs code quality inspection, security vulnerability scanning, version consistency verification, and other tests, and casts a vote of approval or opposition based on the test results. The voting process uses a multi-round mechanism, and the verification unit threshold is dynamically updated after each round. The initial threshold is determined by the security level, and the threshold of subsequent rounds is adjusted according to the voting results of the previous round. For example, if the proportion of approval votes in the first round of voting is close to but does not reach the threshold, the threshold of the second round may be slightly reduced; if the proportion of approval votes is much lower than the threshold, the threshold may be increased. Through multiple rounds of voting, the final voting consensus data is formed, containing the voting results of each verification unit, weighted statistical results, final decision, etc. If the final voting result reaches the verification unit threshold, a timestamp is added to the candidate version record and a time sequence dependency chain is constructed.

[0129] The time sequence dependency chain is a data structure designed based on the idea of blockchain, used to ensure the non-tamperability and time sequence consistency of version records. Each link unit in the time sequence dependency chain contains the hash value of the current version record, the identification of the previous version, the timestamp, etc. When constructing the time sequence dependency chain, the system traverses the existing link units, finds the previous version of the current candidate version record, associates the current version record with the previous version, and forms a new link unit. The timestamp of the new link unit must be greater than that of the previous version, ensuring the strict incremental nature of the time sequence. For example, the timestamp of version 1.0 is "2025-11-20 10:15:30", and the timestamp of version 1.1 must be later than this time.

[0130] After the construction of the time sequence dependency chain, the system traverses each link unit in the chain to perform final verification. The verification process checks whether the time stamp of each link unit satisfies the incremental relationship and whether the pre-version identifier corresponds to a confirmed version state. The time stamp incremental verification ensures the correct timing logic of version updates and prevents abnormal situations such as time backtracking. The pre-version state verification ensures that version updates are based on confirmed stable versions, avoiding the branching problem caused by development based on unconfirmed versions. When all verifications pass, the system converts the version state of the candidate version record from the candidate state to the confirmed state. The confirmed version record is stored in the version control database for access and use by the development team. In addition to storing version records, the version control database also maintains dependency relationships between versions, change history, access permissions, and other information, providing complete version management services for code development. Through this series of strict verification and control mechanisms, the safety, consistency, and traceability of code versions in a distributed environment are ensured, effectively preventing malicious code injection and version tampering risks.

[0131] In an optional implementation, the candidate version record is sent to the voting consensus layer, a voting weight distribution table is generated based on the historical voting records of the verification units, multiple rounds of voting verification are performed and the verification unit threshold is dynamically updated, the final voting consensus data is generated, a time stamp is added to the candidate version record, and a time sequence dependency chain is constructed, which includes:

[0132] The historical voting records of each verification unit are extracted, the number of correct votes and the response time interval are calculated, the reputation points of the verification units are accumulated, the trust relationship network between the verification units is constructed based on the reputation points, the voting weight distribution table is generated, and the initial verification unit threshold is determined;

[0133] According to the number of network connections of the verification units and the voting weight distribution table, the voting groups are divided, the first round of voting results is counted according to the weights in the voting groups, the voting data is combined according to the weight proportion of each group, the verification unit threshold is updated, and the preliminary consensus data is generated;

[0134] The cross-group verification is performed on the preliminary consensus data, the weighted deviation value is calculated based on the voting weight distribution table, the second voting confirmation is triggered when the weighted deviation value is less than the verification unit threshold, and the verification unit threshold is updated according to the verification results of each group;

[0135] The second voting data and the preliminary consensus data are weighted calculated according to the voting weight distribution table, the calculation result is verified based on the verification unit threshold, and the final voting consensus data is output, and a time stamp is added to the candidate version record;

[0136] The time sequence dependency chain is constructed based on the final voting consensus data and the time stamp, and the version state conversion is completed.

[0137] In one specific implementation, the verification unit historical voting record extraction process is completed by querying historical data stored in the distributed database. For each verification unit, all voting events in which it participated are counted, the consistency of the voting results with the actual final results is recorded, and the number of correct votes is calculated. At the same time, the response time of each vote, i.e., the time interval from receiving the voting request to submitting the voting result, is measured. The reputation score of the verification unit is obtained by weighted calculation of the number of correct votes and the response time. For example, a certain verification unit has 85 correct results in the past 100 votes, and the average response time is 200 milliseconds, so its basic reputation score is 85 x (1000 ÷ 200) = 425 points.

[0138] The trust relationship network is constructed based on the historical collaboration between verification units. When two verification units have consistent results in multiple votes and are both proven correct, the trust between them increases. The trust degree calculation takes into account the number of common correct votes, the reputation score of each, and the length of historical collaboration. The trust relationship is represented by a directed edge, and the weight of the edge is the trust degree. For example, the trust degree of verification unit A to verification unit B is 0.75, indicating that A highly recognizes the verification ability of B. In this way, a complete trust relationship network map is formed.

[0139] The voting weight distribution table is generated based on the reputation score and the trust relationship network. The basic weight of each verification unit is proportional to its reputation score, and then adjusted according to the in-degree and weight in the network. For example, if the reputation score of verification unit C is 350 and the total weight of the network in-degree is 1.2, then its final voting weight may be 350 x 1.2 = 420. The initial verification unit threshold is set to the median of all verification unit weights multiplied by 0.75, serving as a benchmark for judging the validity of consensus. In the example data, if the median weight is 380, then the initial threshold is 285.

[0140] The voting groups are divided according to the network connection characteristics and weight distribution of the verification units. Verification units that are densely connected and highly trusted with each other are grouped together. The number of verification units in each group is controlled between 15% and 30% of the total, ensuring that the grouping has a reasonable size while maintaining diversity. For example, 100 verification units can be divided into 5 groups, each with 20 units. The first round of voting is conducted independently within each group, and each verification unit votes on the candidate version according to the weight voting table. The voting results within the group are calculated by accumulating the weights, such as the first group voting "accept", and the cumulative weight reaches 85% of the total weight of the group. The voting results of each group are combined according to the weight proportion between groups to generate preliminary consensus data. If four out of the five groups vote "accept" and the total weight proportion is 78%, which exceeds the preset threshold of 65%, then the preliminary consensus is "accept".

[0141] The cross-packet verification is achieved by comparing the voting results of each packet with the preliminary consensus. The weighted deviation value between the voting results of each packet and the preliminary consensus is calculated. The deviation value calculation considers the packet weight, internal consistency and the degree of difference with other packets. If the weighted deviation value of a certain packet is 0.23, which is less than the current verification unit threshold 0.35, the secondary voting confirmation of the packet is triggered. In the secondary voting, the verification unit obtains the preliminary results of other packets as a reference, but makes an independent judgment. The verification results of each packet are used to dynamically adjust the verification unit threshold, and the adaptability of the system is improved.

[0142] In the final consensus data generation process, the secondary voting data and the preliminary consensus data are weighted calculated according to the voting weight distribution table. When calculating, the weight proportion of the preliminary consensus is considered to be 65%, and the weight proportion of the secondary voting is considered to be 35%. For example, the preliminary consensus is "accept", the weight integral is 780, the secondary voting weight is 420, and the final weighted calculation result is 780*65%+420*35%=654.3, which is much higher than the adjusted verification unit threshold 300, so the final consensus is determined to be "accept". For the code version confirmed by voting, a timestamp accurate to milliseconds is added to ensure the accuracy of version tracing.

[0143] The time sequence dependent chain is constructed based on the final voting consensus data and the timestamp. Each verified code version is a node on the chain, and the nodes are connected through the timestamp and the content hash value to establish the front and rear dependent relationship. The version state conversion follows the preset rules, such as the flow path of "to be audited→verified→published". The state conversion events are also recorded on the time sequence dependent chain to form a complete version change history. For example, a certain code version is marked as "verified" state at the timestamp "2025-06-15T08:24:35.721Z", and then changes to "published" state at "2025-06-15T10:15:22.489Z". These conversion records ensure the transparency and traceability of version control.

[0144] Through the above technical implementation, the code security detection and version control in the distributed environment can effectively resist the interference of malicious nodes, improve the consensus efficiency, and ensure the safety and reliability of the code version management. This method is especially suitable for the collaborative development of open source projects and the distributed code management in enterprises, and significantly reduces the security risks caused by verification errors.

[0145] The code security detection and version control system in the distributed environment according to the embodiment of the application comprises:

[0146] The first unit is used for receiving the source code file submitted by the distributed node, parsing the syntax tree structure of the source code file, and extracting the semantic features and control flow features;

[0147] The second unit is configured to determine code call relationship and data access mode based on semantic features and control flow features, and establish a code dependency graph across nodes.

[0148] The third unit is configured to track call links and data flow directions on the code dependency graph, calculate call frequency, access permission and data interaction strength between nodes, and identify a security risk propagation path.

[0149] The fourth unit is configured to construct a communication topology structure between distributed nodes based on the security risk propagation path, establish a federated learning network, train a security risk identification sub-model by each distributed node, integrate the model through an encrypted gradient aggregation and a differential privacy protection mechanism, and generate a security level evaluation result of the code.

[0150] The fifth unit is configured to set double-layer control parameters according to the security level evaluation result, perform double confirmation on the version through hash verification of the proof of work layer and threshold verification of the voting consensus layer, and constrain the conversion process of the version state based on a time sequence dependency chain.

[0151] The sixth unit is configured to generate a version submission control instruction through the double confirmation based on the code submission request and the security level evaluation result, and write the time sequence dependency chain of the version state and the verification proof data into a distributed ledger.

[0152] The third aspect of the embodiment of the application provides an electronic device, comprising:

[0153] a processor;

[0154] a memory for storing processor-executable instructions;

[0155] The processor is configured to call the instructions stored in the memory to execute the method described above.

[0156] The fourth aspect of the embodiment of the application provides a computer-readable storage medium having computer program instructions stored thereon, and the computer program instructions are executed by a processor to implement the method described above.

[0157] The application can be a method, device, system and / or computer program product. The computer program product can include a computer readable storage medium having computer readable program instructions loaded thereon for executing various aspects of the application.

[0158] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions recorded in the above embodiments can be modified, or some or all of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for code security detection and version control in a distributed environment, characterized by, Comprise: Receiving source code files submitted by distributed nodes, parsing the syntax tree structure of the source code files, extracting semantic features and control flow features; Based on semantic features and control flow features, determine the code call relationship and data access mode, and establish the code dependency relationship graph across nodes; On the code dependency relationship graph, track the call link and data flow direction, calculate the call frequency, access permission and data interaction strength between nodes, and identify the security risk propagation path, including: Traverse each node of the code dependency relationship graph, extract the direct call relationship between nodes, and construct a directed edge connection matrix according to the call direction, while recording the access permission level of the node in the directed edge connection matrix; Based on the directed edge connection matrix, use the heuristic search strategy guided by search value to traverse, determine the call link through dynamic priority sorting, and generate a weighted multi-layer call propagation tree; On each edge of the multi-layer call propagation tree, detect the data transmission operation, record the data flow direction, and count the data interaction times per unit time to construct a data flow feature topology graph; After normalization processing of the call frequency weight in the multi-layer call propagation tree and the data interaction times in the feature topology graph, joint calculation is performed to obtain the security correlation coefficient between node pairs; According to the security correlation coefficient, set the risk level threshold, and identify the call link and data flow direction between node pairs higher than the risk level threshold as the security risk propagation path; Based on the security risk propagation path, construct the communication topology structure between distributed nodes to establish a federated learning network, each distributed node trains a security risk identification sub-model, integrates the model through encrypted gradient aggregation and differential privacy protection mechanism, and generates the security level evaluation result of the code, including: Based on the security risk propagation path, construct a feature vector sequence, map the feature vector sequence and the relationship between distributed nodes to a double-weighted adjacency matrix, and calculate the communication topology structure diagram between distributed nodes according to the double-weighted adjacency matrix; According to the communication topology structure diagram, calculate the training load distribution of the distributed nodes, combine the computing capacity of the distributed nodes to configure the training parameter set, and construct the security risk identification sub-model of each distributed node; Extract the training gradient data of each distributed node, reconstruct the training gradient data into a feature mapping matrix, and perform encryption processing, and transmit it to the center node to perform aggregation operation to obtain the global encrypted gradient; Use the historical behavior to calculate the trust degree index of the distributed nodes, determine the Laplace noise parameter, and perform differential privacy protection on the global encrypted gradient to obtain the privacy protection gradient; Distribute the privacy protection gradient to each distributed node to update the model parameters, and obtain the optimized security risk identification model through iterative training, and input the code to be evaluated to determine the security level evaluation result; According to the security level evaluation result, set the double-layer control parameters, perform double confirmation on the version through the hash verification of the proof of work layer and the threshold verification of the voting consensus layer, and constrain the version state conversion process based on the time sequence dependence chain; Based on the code submission request and the security level evaluation result, a version submission control instruction is generated through double confirmation, and a time sequence dependent chain of version state and verification proof data are written into a distributed ledger.

2. The method of claim 1, wherein, Based on the directed edge connection matrix, a heuristic search strategy guided by search generation value is used for traversal, a calling link is determined through dynamic priority sorting, and a weighted multi-layer calling propagation tree is generated including: Based on the directed edge connection matrix, the calling frequency matrix is obtained by counting the historical calling times between nodes, the calling frequency matrix and the access permission level of the node are linearly weighted to generate a calling intensity table between nodes; According to the calling intensity table between nodes, the search generation value of the path is set, the nodes are prioritized according to the search generation value, and a dynamically updated priority search queue is constructed; The priority search queue is used as the traversal order guide, and the search space is expanded layer by layer from the starting node, the sum of the search generation values of the newly accessed nodes and the accessed paths is calculated, and the minimum search cost threshold is set to dynamically update the priority sequence of the nodes to be searched in the queue; In the search process, a path search cost record table is maintained, and when the sum of the search generation values of the newly expanded paths is lower than the minimum search cost threshold, a backtracking operation is triggered, the upper layer node is returned to search other branches, and a calling link set is output; The calling link set is reconstructed into a multi-layer calling propagation tree in descending order of the sum of the search generation values, and the calling frequency weight is marked on the edge of the multi-layer calling propagation tree.

3. The method of claim 1, wherein, Extract the training gradient data of each distributed node, reconstruct the training gradient data into a feature mapping matrix, and perform encryption processing, and transmit it to the center node to perform aggregation operation to obtain the global encrypted gradient including: Extract the training gradient data of each distributed node, and reconstruct the gradient data into a feature mapping matrix according to the neural network hierarchical structure, and perform dimension reduction conversion to obtain a polynomial encoding sequence; The polynomial encoding sequence is segmented according to the data block size, and each data block is encrypted using a homomorphic encryption key, and a digital signature is generated based on the identity characteristics of the distributed node, and the encrypted data block and the digital signature are combined to form a secure transmission package; After receiving the secure transmission package, the validity of the digital signature is verified, the encrypted data block is extracted and a ciphertext mapping table is established, and the encrypted gradients of different distributed nodes are aligned to a unified ciphertext space according to the mapping relationship; Perform weighted summation operation in the unified ciphertext space, determine the aggregation weight based on the node credibility, and calculate the global encrypted gradient.

4. The method of claim 1, wherein, According to the security level evaluation result, set double-layer control parameters, perform double confirmation on the version through the hash verification of the proof of work layer and the threshold verification of the voting consensus layer, and constrain the conversion process of the version state based on the time sequence dependent chain including: According to the security level evaluation result, generate double-layer control parameters, including the hash difficulty coefficient of the proof of work layer and the verification unit threshold of the voting consensus layer; Based on the hash difficulty coefficient, perform hash calculation on the version submission request in the proof of work layer to obtain a proof of work identifier, and compare the proof of work identifier with the preset hash condition, and when the proof of work identifier meets the preset hash condition, generate a candidate version record; The candidate version record is sent to the voting consensus layer. A voting weight distribution table is generated based on the historical voting record of the verification unit. Multiple rounds of voting verification are performed and the verification unit threshold is dynamically updated to generate the final voting consensus data. A timestamp is added to the candidate version record and a time-series dependency chain is built. Traverse each link unit in the time-series dependency chain, check whether the timestamp of each link unit satisfies the increasing relationship and whether the version status corresponding to the previous version identifier is in the confirmed state. When the check passes, change the version status of the candidate version record from the candidate state to the confirmed state and store it in the version control database.

5. The method of claim 4, wherein, Candidate version records are sent to the voting consensus layer. A voting weight distribution table is generated based on the historical voting records of the verification units. Multiple rounds of voting verification are performed, and the verification unit thresholds are dynamically updated. Final voting consensus data is generated, and timestamps are appended to the candidate version records, and a time-series dependency chain is constructed, including: Extract historical voting records for each verification unit, calculate the number of correct votes and response time intervals, accumulate the reputation scores of the verification units, construct a trust relationship network between verification units based on the reputation scores, generate a voting weight distribution table, and determine the initial verification unit threshold. Based on the network connection number and voting weight distribution table of the verification unit, voting groups are divided. Within each voting group, the first round of voting results are statistically calculated according to the weight. Voting data is merged according to the weight ratio of each group, the verification unit threshold is updated, and preliminary consensus data is generated. Cross-group verification is performed on the preliminary consensus data. The weighted deviation value is calculated in combination with the voting weight distribution table. When the weighted deviation value is less than the verification unit threshold, a second voting confirmation is triggered, and the verification unit threshold is adjusted according to the verification results of each group. The secondary voting data and the preliminary consensus data are weighted according to the voting weight distribution table. The calculation results are verified based on the verification unit threshold, and the final voting consensus data is output. A timestamp is added to the candidate version record. A time-series dependency chain is built based on the final voting consensus data and timestamps to complete the version state transition.

6. A code security detection and versioning system for a distributed environment for implementing the method of any of the preceding claims 1-5, characterized in that, include: The first unit is used to receive source code files submitted by distributed nodes, parse the syntax tree structure of the source code files, and extract semantic features and control flow features. The second unit is used to determine code call relationships and data access patterns based on semantic features and control flow features, and to establish a cross-node code dependency graph. The third unit is used to trace the call chain and data flow on the code dependency graph, calculate the call frequency, access permissions and data interaction strength between nodes, and identify the propagation path of security risks. The fourth unit is used to build a federated learning network by constructing a communication topology between distributed nodes based on the security risk propagation path. Each distributed node trains a security risk identification sub-model, and the models are integrated through encrypted gradient aggregation and differential privacy protection mechanisms to generate a security level assessment result for the code. The fifth unit is used to set two-layer control parameters based on the security level assessment results, and to double-confirm the version through hash verification of the proof-of-work layer and threshold verification of the voting consensus layer, and to constrain the version state transition process based on the time-series dependency chain. The sixth unit is configured to generate a version submission control instruction through double confirmation based on the code submission request and the security level evaluation result, and write a time sequence dependency chain of a version state and verification proof data into a distributed ledger.

7. An electronic device, comprising: Comprise: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to perform the method of any one of claims 1 to 5.

8. A computer-readable storage medium having stored thereon computer program instructions, wherein, The computer program instructions, when executed by the processor, implement the method of any one of claims 1 to 5.

Images