A blockchain ecological cross-project security patch detection and migration method and device

Abstract

This invention discloses a method and apparatus for cross-project security remediation detection and migration in the blockchain ecosystem, relating to the field of blockchain technology. The method includes: constructing a code submission knowledge graph with code submission as the central node and edge relationships such as submitted modified functions, submitted related topics, submitted related merge requests, submission belonging to a project, project reuse of a project, and merge request discussion topics; determining the editing action based on the syntax tree differences of the affected functions to which the code submission belongs, and determining the action code sequence by backfilling the original source code; outputting the remediation probability of a code submission belonging to a security remediation submission using the submission message and line-level differences, the code submission evidence subgraph of the code submission knowledge graph, and the action code sequence; and constructing cross-project migration rules and performing project migration detection when the remediation probability is greater than a probability threshold to determine the cross-project vulnerability status. Based on the above scheme, the identification and migration performance of cross-project security remediation in the blockchain ecosystem is improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a cross-project security repair, detection, and migration method and apparatus for the blockchain ecosystem. Background Technology

[0002] Blockchain systems are characterized by frequent cross-project reuse and often employ multiple programming languages. However, in open-source maintenance practices within the blockchain ecosystem, existing solutions typically end after identifying security fixes. The migration and execution of similar fixes in downstream projects relies on manual summarization, making timely fix propagation difficult. Furthermore, security fix identification often relies solely on commit descriptions, line-level differences, or simple combinations of both. This coarse-grained semantic representation of code changes fails to capture subtle fix logic. Additionally, some methods depend on constructing code attribute graphs and analyzers specific to a particular language, but these are difficult to migrate to a multi-language blockchain ecosystem and cannot effectively support cross-project fix propagation judgment. Therefore, there is an urgent need to improve the performance of cross-project security fix identification and migration. Summary of the Invention

[0003] This invention provides a method and apparatus for cross-project security remediation detection and migration in the blockchain ecosystem, which improves the identification and migration performance of cross-project security remediation in the blockchain ecosystem.

[0004] The first aspect of this invention provides a cross-project security remediation, detection, and migration method for the blockchain ecosystem, comprising:

[0005] With code submissions as the central node, and with the edge relationships of submitting modified functions, submitting related topics, submitting related merge requests, submitting items belonging to a project, projects reusing projects, and merge requests discussing topics, a code submission knowledge graph is constructed.

[0006] The editing action is determined based on the syntax tree differences of the affected function to which the code submission belongs, and the action code sequence of each editing action is determined by backfilling the original source code;

[0007] The code submission is analyzed by fusing the submission message and line-level differences associated with the code submission, the code submission evidence subgraph of the code submission knowledge graph, and the action code sequence input code detection model to output the probability that the code submission belongs to a security fix submission.

[0008] When the repair probability is greater than the probability threshold, cross-project migration rules are constructed based on the code commit and the code commit evidence subgraph.

[0009] The code submissions are subjected to project migration detection according to the cross-project migration rules to determine the cross-project vulnerability status.

[0010] Furthermore, the method of fusing and analyzing the commit message and line-level differences associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence input code detection model to output the probability that the code commit belongs to a security fix commit includes:

[0011] The commit message and line-level difference associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence are respectively processed by a cascaded SentenceTransformer model, a linear projection layer, a multi-layer Transformer encoder, and a Bi-LSTM network, and the corresponding outputs are commit message features, line-level difference features, evidence subgraph features, and action code features.

[0012] Based on the feature addition layer, the text feature branch is constructed by adding the submission message feature to the evidence subgraph feature;

[0013] The row-level difference features are added to the action code features according to the feature addition layer to form the code feature branch;

[0014] In the feature fusion layer, the text feature branches and the code feature branches are adaptively fused to determine the code submission representation;

[0015] A classification prediction network is used to output the probability that a code submission belongs to a security fix submission based on the code submission representation.

[0016] Furthermore, when the repair probability is greater than a probability threshold, constructing cross-project migration rules based on the code commit and the code commit evidence subgraph includes:

[0017] When the repair probability is greater than the probability threshold, the project reuse edge relationship of the code submission evidence subgraph is parsed to determine the applicable project scope.

[0018] Based on the submission modification function edge relationships of the code submission evidence subgraph, the function signature of the source repair function is determined;

[0019] The key code segments that were not modified in each of the source repair functions were used as context anchor points.

[0020] The vulnerability-critical variable data stream of the source fix function is determined based on the data stream submitted by the code.

[0021] Cross-project migration rules are constructed using the applicable project scope, the function signature of the source repair function, context anchor features, and vulnerability key variable data flow.

[0022] Furthermore, the step of performing project migration detection on the code submission according to the cross-project migration rules to determine the cross-project vulnerability status includes:

[0023] The target project set is determined by the applicable project scope;

[0024] For any target item in the target item set, the function signature of each source repair function and the context anchor features are used for search and matching to determine the successfully matched function to be verified.

[0025] Identify the deleted and added code blocks in the code commit;

[0026] If the semantic similarity between the function to be verified and the newly added code block is greater than the semantic threshold, then it is determined that the vulnerability to which the source repair function belongs in the target project is in a repaired state.

[0027] If the semantic similarity between the function to be verified and the deleted code block is greater than the semantic threshold and the semantic similarity between the newly added code block is less than or equal to the semantic threshold, then it is determined that the vulnerability to the source repair function in the target project is in a vulnerability residual state.

[0028] If the semantic similarity between the function to be verified and the newly added code block and the deleted code block is less than or equal to the semantic threshold, or if the data flow matching degree between the function to be verified and the data flow of the vulnerability key variable is less than or equal to the data flow threshold, then it is determined that the vulnerability to which the source repair function belongs in the target project is in a vulnerability-irrelevant or vulnerability-reconstructed state.

[0029] Further, the step of determining the editing action based on the syntax tree differences of the affected function to which the code submission belongs, and determining the action code sequence of each editing action by backfilling the original source code, includes:

[0030] Extract the affected functions from the code submission;

[0031] An abstract syntax tree is constructed for each of the source code snapshots of the affected functions before and after the changes, and the editing actions are output through the tree difference tool;

[0032] For each of the aforementioned editing actions, the original source code is backfilled to generate a corresponding action code sequence, which includes an insertion action code sequence, an update action code sequence, a deletion action code sequence, and a move action code sequence.

[0033] Furthermore, the training loss function of the code detection model includes class-weighted cross-entropy loss and contrastive loss, wherein the class weight of the security repair submission training sample is greater than the class weight of the ordinary submission training sample in the class-weighted cross-entropy loss.

[0034] The second aspect of this invention provides a cross-project security remediation, detection, and migration device for the blockchain ecosystem, comprising:

[0035] The graph construction module is used to build a code submission knowledge graph with code submission as the central node and edge relationships such as submitting modified functions, submitting related topics, submitting related merge requests, submitting belonging to the project, the project reusing the project, and the merge request discussion topics.

[0036] The action editing module is used to determine the editing action based on the syntax tree differences of the affected function to which the code submission belongs, and to determine the action code sequence of each editing action by backfilling the original source code;

[0037] The repair detection module is used to perform fusion analysis using the commit message and line-level differences associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence input code detection model, and output the repair probability that the code commit belongs to a security repair commit;

[0038] The rule building module is used to build cross-project migration rules based on the code submission and the code submission evidence subgraph when the repair probability is greater than the probability threshold.

[0039] The migration detection module is used to perform project migration detection on the code submission according to the cross-project migration rules and determine the cross-project vulnerability status.

[0040] A computer device provided in a third aspect of the present invention includes a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the cross-project security repair, detection and migration method for the blockchain ecosystem as described in any of the preceding claims.

[0041] The fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed, it implements the cross-project security repair, detection and migration method for the blockchain ecosystem as described in any of the preceding claims.

[0042] The fifth aspect of this invention provides a computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the cross-project security repair, detection, and migration method for the blockchain ecosystem as described in any of the preceding claims.

[0043] As can be seen from the above technical solutions, the present invention has the following advantages:

[0044] The above-described solution of the present invention provides a cross-project security remediation detection and migration method for the blockchain ecosystem, comprising: constructing a code submission knowledge graph with code submission as the central node and edge relationships such as submitted modified functions, submitted related topics, submitted related merge requests, submitted belonging to a project, projects reusing projects, and merge request discussion topics; determining the editing action based on the syntax tree differences of the affected functions to which the code submission belongs, and determining the action code sequence of each editing action by backfilling the original source code; performing fusion analysis using the submission messages and line-level differences associated with the code submission, the code submission evidence subgraph of the code submission knowledge graph, and the action code sequence as input to the code detection model, and outputting the remediation probability that the code submission belongs to a security remediation submission; when the remediation probability is greater than the probability threshold, constructing cross-project migration rules based on the code submission and the code submission evidence subgraph; and performing project migration detection on the code submission according to the cross-project migration rules to determine the cross-project vulnerability status. Based on the above scheme, starting with code submission, a code submission knowledge graph that provides external information and a function-level syntax tree are introduced to finely characterize the repair semantics of the code sequence of editing actions. A multimodal fusion representation analysis is performed through a code detection model to determine whether the code submission has the significance of vulnerability repair. Then, cross-project migration rules are generated in a structured manner and applied to downstream project detection. This realizes an automated closed loop of upstream security repair discovery, repair semantic extraction and downstream project migration detection, and improves the identification and migration performance of cross-project security repair in the blockchain ecosystem. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 The flowchart illustrates the steps of a cross-project security remediation, detection, and migration method for the blockchain ecosystem, as provided in Embodiment 1 of the present invention.

[0047] Figure 2 This is a schematic diagram of a cross-project security remediation, detection, and migration framework for the blockchain ecosystem provided in Embodiment 1 of the present invention.

[0048] Figure 3 This is an example of a syntax tree editing action for code changes provided in Embodiment 1 of the present invention;

[0049] Figure 4 This is an example of a changed fragment in a code commit provided in Embodiment 1 of the present invention;

[0050] Figure 5This is a structural block diagram of a cross-project security repair, detection, and migration device for the blockchain ecosystem, provided in Embodiment 2 of the present invention. Detailed Implementation

[0051] This invention provides a method and apparatus for cross-project security remediation detection and migration in the blockchain ecosystem, which improves the identification and migration performance of cross-project security remediation in the blockchain ecosystem.

[0052] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0053] Please see Figure 1 and Figure 2 Embodiment 1 of this invention provides a cross-project security remediation, detection, and migration method for the blockchain ecosystem. The blockchain ecosystem (blockchain system) can be understood as a cross-chain collaborative ecosystem comprised of core clients implemented in multiple programming languages, forked projects derived through code reuse, and themselves, and includes:

[0054] Step 101: Using code submissions as the central node and with edge relationships such as submitting modified functions, submitting related topics, submitting related merge requests, submitting belonging to a project, projects reusing projects, and merge request discussion topics, construct a code submission knowledge graph.

[0055] It should be noted that code commit refers to the operation of persistently recording a set of code changes and their metadata in a version control system. For any code commit, this embodiment places it in the structured context of a knowledge graph, which is a knowledge representation method that organizes data in a graph structure.

[0056] Specifically, based on information such as code repository commit records, file-level and line-level differences, issue records, merge request discussions, function source code snapshots, and forking or reuse relationships between projects, this code commit is used as the central node. Through graph edge relationships, it connects the project to which it belongs, the modified function, the issue that triggered the commit, and the merge request (PR) containing the commit. This code commit-centric graph construction method, by introducing discussion information from issues and PRs to complete the context of the fix motivation, and by introducing projects and functions to reveal code reuse relationships, aims to improve the problem of coarse-grained semantic representation of code changes and lack of context. The nodes of the constructed code commit knowledge graph include:

[0057] 1) Commit nodes, whose node attributes include, but are not limited to, commit hash, repository identifier, commit time, commit message, set of changed files, and row-level difference summary;

[0058] 2) Issue nodes, whose node attributes include, but are not limited to, issue number, title, body text, comment time, and discussion keywords;

[0059] 3) Merge request nodes, whose node attributes include, but are not limited to, request number, title, review comments, merge time, and associated submission set;

[0060] 4) Function nodes, whose node attributes include, but are not limited to, function name, file path, language type, function source code before the change, function source code after the change, and normalized function signature;

[0061] 5) Project nodes, whose node attributes include, but are not limited to, project name, upstream source, fork identifier, and chain or protocol identifier;

[0062] Based on the nodes mentioned above, the edge relationships constructed in the graph include: submitting a modified function, submitting an associated issue, submitting an associated merge request, submitting to a project, a project reusing a project, and a merge request discussing an issue. "Submitting a modified function" connects a submit node and a function node, indicating that the code submission modified a function (e.g., adding or deleting). "Submitting an associated issue" connects a submit node and an issue node, indicating that the code submission is related to an issue. "Submitting an associated merge request" connects a submit node and a merge request node, indicating that the code submission belongs to a merge request. "Submitting to a project" connects a submit node and a project node, indicating that the code submission was generated in a specific project's code repository. "A project reusing a project" connects two project nodes, indicating that one project reuses code from another project (e.g., forking, copying). "A merge request discussing an issue" connects a merge request node and an issue node, indicating that an issue was referenced in the discussion of the merge request.

[0063] Step 102: Determine the editing action based on the syntax tree differences of the affected function to which the code submission belongs, and determine the action code sequence of each editing action by backfilling the original source code.

[0064] In one specific embodiment of this example, step 102 includes the following sub-steps:

[0065] S1021. Extract the affected functions from code commits;

[0066] S1022. Construct abstract syntax trees for the source code snapshots of the affected functions before and after the changes, and output the editing actions through the tree difference tool;

[0067] S1023. Generate the corresponding action code sequence by backfilling the original source code for each editing action.

[0068] Affected functions refer to functions whose source code has changed during code submissions.

[0069] Editing actions refer to the types of modifications made to the source code.

[0070] Action code sequence refers to a sequence of code that uses source code to represent the semantics of editing actions.

[0071] A function source code snapshot refers to the complete source code of a function at a certain point in time; function source code snapshots before and after a change include the function source code snapshot before the change and the function source code snapshot after the change, which refer to the complete source code of the affected function before the modification and the complete source code after the modification.

[0072] Abstract syntax tree (AST) refers to the tree-structured syntactic representation of code.

[0073] Tree difference tools are tools used to compare the differences between two tree structures.

[0074] It should be noted that this embodiment first uses a syntax parsing tool to extract the affected functions in the code submission, then constructs abstract syntax trees for the functions before and after the change, and uses a tree difference tool to output a set of editing actions, such as... Figure 3 As shown, editing actions include insertion, update, deletion, and move actions. The editing actions output by the tree diff tool only contain abstract descriptions. Based on this, the abstract editing actions are converted into code sequences carrying specific semantics by backfilling the original source code. The action code sequences include insertion action code sequences, update action code sequences, deletion action code sequences, and move action code sequences; specifically:

[0075] 1) For insertion actions, this type of action is used to express repair behaviors such as adding new validation, adding new exception handling, and adding new state synchronization; by extracting the content of the inserted node from the source code of the modified function, and recording its target parent node and insertion position index, it is serialized into an insertion action code sequence of "action = insertion, node content = inserted code fragment, target context = parent node code, position = index value";

[0076] 2) For update actions, this type of action is used to express behaviors such as parameter replacement, operator replacement, constant replacement, and identifier replacement; by extracting the original node type and original node text from the function source code before the change, and then recording the new label value after the change, it is serialized into an update action code sequence of "action = update, source node = original code fragment, target node = new code fragment";

[0077] 3) For deletion actions, this type of action is used to express behaviors such as deleting dangerous paths, deleting unsafe calls, and deleting redundant state modifications; by extracting the content of the deleted node from the source code of the function before the change, it is serialized into a deletion action code sequence of "action = deletion, node content = deleted code fragment";

[0078] 4) For move actions, this type of action is used to express behaviors such as sensitive call order adjustment, state update forward or backward; by extracting the content of the moved node from the source code of the function before the change, and then recording the target parent node and the target position index, it is serialized into a move action code sequence of "action = move, node content = moved code fragment, target context = parent node code, position = index value";

[0079] For example, the abstract description of "insert a node of type Y at position X" can be transformed into the concrete semantics of "insert the code snippet if(x<0) return; at position X". This approach avoids losing the concrete repair semantics by only retaining the abstract operation type and node type. In this embodiment, the above editing action is standardized into a modelable action code sequence for subsequent embedding. Unlike row-level addition and deletion information, the action code sequence explicitly retains the action type, source node, target node, and target position, making it more suitable for repair pattern extraction in cross-project migration scenarios.

[0080] Step 103: Perform a fusion analysis using the commit message and line-level differences associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence input code detection model to output the probability that the code commit belongs to the security fix commit.

[0081] A code inspection model is a model used to detect whether a code commit is a security fix.

[0082] A security fix commit refers to a code commit that fixes a known or potential security vulnerability. The corresponding code commit can be called a regular commit, which refers to code commits not aimed at fixing security vulnerabilities, such as feature updates, refactoring, and fixing business logic errors.

[0083] The probability of a fix refers to the confidence level that the current code commit belongs to a "safe fix commit".

[0084] In one specific embodiment of this example, step 103 includes the following sub-steps:

[0085] S1031. The commit messages and line-level differences associated with code commits, the code commit evidence subgraphs of the code commit knowledge graph, and the action code sequences are respectively processed by a cascaded SentenceTransformer model, a linear projection layer, a multi-layer Transformer encoder, and a Bi-LSTM network, and the corresponding outputs are commit message features, line-level difference features, evidence subgraph features, and action code features.

[0086] S1032. Based on the feature addition layer, the submission message features and evidence subgraph features are added to construct a text feature branch;

[0087] S1033. Based on the feature addition layer, the row-level difference features and action code features are added together to form the code feature branch;

[0088] S1034. Adaptively fuse text feature branches and code feature branches in the feature fusion layer to determine the code submission representation;

[0089] S1035. A classification prediction network is used to output the repair probability that a code submission belongs to a security repair submission based on the code submission representation.

[0090] It should be noted that the code detection model in this embodiment includes a SentenceTransformer model, a linear projection layer, a multi-layer Transformer encoder, a Bi-LSTM network, a feature addition layer, a feature fusion layer, and a classification prediction network. Specifically:

[0091] The model input includes the commit message and line-level difference (Diff) associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence; where 1) the commit message refers to the natural language description of the code commit (explaining the intent of the change); 2) the code commit evidence subgraph refers to the serialized result of the evidence subgraph retrieved from the code commit knowledge graph. This means that by retrieving information from the graph structure, the originally scattered summaries of related issues, merge request review comments, descriptions of affected functions, and project reuse information are aggregated into structured contextual text. This process enables the representation vector used for code commit classification and detection to include the remediation intent behind the code change (such as vulnerability discussions) and cross-project impact (such as component reuse relationships), aiming to improve the insufficient semantic representation capabilities that can easily result from relying solely on code and commit messages; 3) line-level differences refer to the line-by-line additions, deletions, and modifications of the code commit at the file level, for example, such as... Figure 4 The code snippet shows a line-level change, where lines 4-5 represent deletion and lines 6-7 represent addition.

[0092] In the code detection model's processing: First, submission messages, line-level differences, code submission evidence subgraphs, and action code sequences are fed into the SentenceTransformer model as independent inputs. A pre-trained language model is invoked to vectorize these four inputs. The corresponding high-dimensional embedding vectors are then normalized using the L2 norm to ensure that the features of each modality are distributed in the same vector space, thus determining the corresponding length-aligned embeddings. Next, a linear projection layer maps each length-aligned embedding to a unified input space, obtaining the corresponding dimension-aligned embeddings. Subsequently, for any dimension-aligned embedding... The process involves several steps. First, a multi-layer Transformer encoder captures global dependencies within the sequence. Then, a Bidirectional Long Short-Term Memory (Bi-LSTM) network extracts temporal features of the sequence, resulting in submission message features, line-level difference features, evidence subgraph features, and action code features. To avoid dimensionality expansion and noise accumulation caused by simple concatenation, a feature addition layer first adds features pairwise according to the text flow and code flow, generating text feature branches and code feature branches respectively. Then, a trainable fusion coefficient is used to adaptively fuse the text feature branches and code feature branches to obtain the code submission representation. This process can be represented as follows: , Indicates code commit signature, Represents the fusion coefficient. Indicates row-level differences. Indicates action code characteristics, Indicates the characteristics of the submitted message. The evidence subgraph features are represented; the code submission representation is used to determine whether the source submission belongs to the security fix submission; finally, the probability value of it belonging to the security fix submission is output by the classification prediction network. In one feasible way, the classification prediction network adopts a multilayer perceptron with batch normalization and dropout to improve the generalization ability.

[0093] In one specific implementation of this embodiment, the training loss function of the code detection model includes class-weighted cross-entropy loss and contrastive loss, wherein the class weight of the security repair submission training sample in the class-weighted cross-entropy loss is greater than the class weight of the ordinary submission training sample.

[0094] It should be noted that during the training of the code detection model, the dataset includes a training set, a test set, and a validation set, including security fix submission training samples and regular submission training samples. For example, the test set can account for 20% and the validation set for 10%. The training set is used to train the code detection model, and in this embodiment, class-weighted cross-entropy loss is employed. Compared with loss The training loss function ( The model parameters are jointly optimized using a contrastive loss (representing the weights of the contrastive loss). Class-weighted cross-entropy is used to handle the imbalanced situation where security repair samples are relatively scarce. Preferably, the class weights of security repair submissions are greater than those of ordinary submissions, for example, the weights are set to 1.0 for ordinary submissions and 3.0 for security repairs. The contrastive loss is used to bring similar repair patterns closer together and separate dissimilar patterns. The weight can be set to 0.6. For details on the loss function, please refer to existing technologies. The optimizer can use adaptive moment estimation, the learning rate is scheduled using cosine annealing, a random deactivation rate of 0.2 is set in the network, and the gradient norm is pruned to a threshold of 1.0. Thus, the model is trained, validated, and tested using training, testing, and validation sets to determine an applicable code detection model.

[0095] Step 104: When the probability of repair is greater than the probability threshold, construct cross-project migration rules based on code commits and code commit evidence subgraphs.

[0096] In one specific embodiment of this example, step 104 includes the following sub-steps:

[0097] S1041. When the probability of repair is greater than the probability threshold, analyze the project reuse edge relationship of the code submission evidence subgraph to determine the applicable project scope.

[0098] S1042. Determine the function signature of the source repair function based on the edge relationship of the commit modification function in the code commit evidence subgraph;

[0099] S1043. Use the key code segments that have not been modified in each source repair function as context anchor features;

[0100] S1044. Determine the vulnerability key variable data stream of the source repair function based on the data stream submitted by the code;

[0101] S1045. Construct cross-project migration rules by using the applicable project scope and the function signature, context anchor characteristics, and vulnerability key variable data flow of the source repair function.

[0102] Cross-project migration rules refer to the rules for detecting the status of vulnerabilities of the same origin when migrating reusable projects associated with security remediation submissions.

[0103] A source fix function refers to a function that is modified through a security fix in the upstream source project. The source fix function can be locked by the function node associated with the edge relationship of "modified function" in the code submission knowledge graph.

[0104] It should be noted that when the probability of a fix exceeds a certain threshold, the code commit is determined to be a security fix commit. The process then proceeds to build a cross-project migration rule that can be invoked by the program. The fields of the cross-project migration rule may include, but are not limited to, rule number, applicable project scope, objective function location characteristics, verification method, vulnerability key variable data flow, vulnerability fix semantics, migration priority, and result explanation summary. Specifically:

[0105] 1) Rule number refers to the identifier of the rule;

[0106] 2) Scope of application refers to the target projects to be tested, which can be determined by the edge relationships of projects that reuse projects in the code submission evidence subgraph;

[0107] 3) The target function location features include the function signature and context anchor features of the source repair function. The function signature includes the function name, parameter type list and return value type. The context anchor features refer to the key code segments that have not been modified in the function body (such as specific log strings, unique API call sequences or complex control flow structures). This type of code can be used to characterize the core logic of the function.

[0108] 4) Vulnerability critical variable data flow refers to the path characteristics of the data flow of critical variables involved in the vulnerability (such as user input parameters) to the source fix function where it is used or verified;

[0109] 5) Verification method refers to the specific technology used to determine the state of the target function (fixed, vulnerability residual, irrelevant, or refactored), which is equivalent to the rule execution method of cross-project migration rules; for example, it may include syntax tree structure comparison, line-level difference template matching, or calling external test cases to trigger, etc.

[0110] 6) Vulnerability remediation semantics refers to the abstract remediation semantics mapped by the action code sequence of the source project through the retrieval of the matching vulnerability type description and remediation pattern knowledge. For example, the remediation semantics is similar to the form of "adding a non-null constraint before the variable is used" or "adding a boundary constraint check". This helps the agent or tester to understand the security remediation submission.

[0111] 7) Migration priority is strongly correlated with the severity of the vulnerability (such as CVSS score). Priority labels can be generated by using vulnerability type descriptions obtained from the model and certain prior knowledge, which helps to quantify the execution order of migrations.

[0112] 8) Results Explanation Summary: This summarizes the field content involved in the cross-project migration rule in natural language, providing a degree of interpretability.

[0113] It is understandable that the above migration rule generation process can be implemented using an agent-driven approach, with the help of scheduling tools such as graph retrieval tools, vulnerability knowledge query tools, and migration rule generation tools to output rule results.

[0114] Step 105: Perform project migration checks on code submissions according to cross-project migration rules to determine the cross-project vulnerability status.

[0115] In one specific embodiment of this example, step 105 includes the following sub-steps:

[0116] S1051. Determine the target project set by the applicable project scope;

[0117] S1052. For any target project in the target project set, the function signature of each source repair function and the context anchor features are used for search and matching to determine the successfully matched function to be verified.

[0118] S1053. Identify deleted and added code blocks in the code commit;

[0119] S1054. If the semantic similarity between the function to be verified and the newly added code block is greater than the semantic threshold, then it is determined that the vulnerability to which the source repair function belongs in the target project is in a repaired state.

[0120] S1055. If the semantic similarity between the function to be verified and the deleted code block is greater than the semantic threshold and the semantic similarity between the newly added code block is less than or equal to the semantic threshold, then it is determined that the vulnerability to the source repair function in the target project is in a vulnerability residual state.

[0121] S1056. If the semantic similarity between the function to be verified and the newly added code block and the deleted code block is less than or equal to the semantic threshold, or if the data flow matching degree between the function to be verified and the data flow of the vulnerability's key variable is less than or equal to the data flow threshold, then it is determined that the vulnerability to which the source repair function belongs in the target project is in a vulnerability-irrelevant or vulnerability-reconstructed state.

[0122] It should be noted that when executing cross-project migration rules:

[0123] First, the applicable project scope in the rules is analyzed. Based on the "project reuse project" edge relationship in the code submission knowledge graph, all downstream project nodes that have a fork, code reference or logical reuse relationship with the source project are automatically retrieved to construct the target project set to be detected.

[0124] Then, for each target project, the target function location features in the rules are read, and the function signature and context anchor features of the source repair function are used to perform fuzzy search and structure matching in the target project. If there are related functions that satisfy the same conditions in the target project, they are marked as "functions to be verified".

[0125] Finally, for the identified functions to be verified, their semantic similarity with the "deleted code blocks" and "added code blocks" in the upstream security remediation submissions is calculated. Combined with the vulnerability's key variable data stream, a cross-project vulnerability status migration determination is performed. It can be understood that multiple consecutive deleted lines are reorganized into "deleted code blocks" representing the pre-vulnerability state, while multiple consecutive added lines constitute "added code blocks" representing the remediation logic. Deletion and addition are considered because any code modification can be decomposed at the underlying logic level into the removal of old logic and the introduction of new logic. These two constitute a complete chain of evidence for determining the vulnerability status. The implementation of semantic similarity can refer to existing semantic distance measurement algorithms; this embodiment does not impose any limitations on this. The specific determination logic includes:

[0126] 1) If the function to be verified highly matches the "new code block", it is determined to be fixed, because the "new code block" usually contains critical security checks or correct logic, and its existence proves that the fix has been performed;

[0127] 2) Determined as a residual vulnerability: If the function to be verified highly matches "deleted code block" but does not match "added code block", this is a typical unpatched vulnerability state, that is, the wrong logic is retained and the correct logic has not been introduced;

[0128] 3) Determined to be irrelevant or refactored: If the function to be verified does not match either "new code block" or "deleted code block", or, since the data flow characteristics are the deep semantic conditions for the vulnerability trigger, if it is found that the data flow direction or call path of the key variables in the function to be verified does not match the data flow of the vulnerability's key variables, this indicates that although the function signatures are similar, the internal implementation logic is significantly different from the source project, or the target code has been refactored, and therefore the specific vulnerability logic does not exist. It can be classified as irrelevant or refactored.

[0129] It is understood that the aforementioned "high match" or "mismatch" can be determined by comparing the corresponding threshold values. Different thresholds can be set adaptively, and this embodiment does not impose any restrictions on this.

[0130] In one specific implementation of this embodiment, the timestamp of the fix submission for the target project whose cross-project vulnerability status is determined to be fixed is retrieved, and the difference between the timestamp of the code submission and the timestamp of the fix is ​​calculated to determine the propagation lag time.

[0131] It should be noted that the fix commit timestamp refers to the time when the target project submitted the security fix commit, while the fix timestamp refers to the commit time of the code commit (security fix commit) in the source project. The propagation lag time is calculated as follows:

[0132] 1) Quantitative risk window: The time difference between the release of upstream vulnerability patch and the actual completion of the patch migration in the downstream project was evaluated. This period is the window period during which the downstream project is exposed to the risk of attacks from known vulnerabilities.

[0133] 2) Construct a response efficiency profile: Based on lag time data, profile the maintenance activity of different downstream projects or branches, which helps to screen forks or projects with slow maintenance and high risk.

[0134] 3) Verify the necessity of automated migration: By confirming the inefficiency of manual migration, the necessity of the automated migration recognition technology proposed in this embodiment is verified.

[0135] In this embodiment of the invention, the aim is to construct a cross-project vulnerability migration identification scheme for a multi-project blockchain ecosystem. Starting with code submission, it introduces a code submission knowledge graph that provides external information and a function-level syntax tree to finely characterize the repair semantics of the code sequence of editing actions. Through a code detection model, it performs multimodal fusion representation analysis to determine whether the code submission has vulnerability repair significance. Then, it structurally generates cross-project migration rules and applies them to downstream project detection, realizing an automated closed loop of upstream security repair discovery, repair semantic extraction, and downstream project migration detection. This is more friendly to blockchain ecosystem application scenarios with multi-language clients and multi-project reuse environments.

[0136] Please see Figure 5 Embodiment 2 of the present invention provides a cross-project security remediation, detection, and migration device for the blockchain ecosystem, comprising:

[0137] The graph construction module 501 is used to construct a code submission knowledge graph with code submission as the central node and edge relationships such as submitting modified functions, submitting related topics, submitting related merge requests, submitting belonging to the project, the project reusing the project, and the merge request discussion topics.

[0138] The action editing module 502 is used to determine the editing action based on the syntax tree differences of the affected function to which the code submission belongs, and to determine the action code sequence of each editing action by backfilling the original source code;

[0139] The repair detection module 503 is used to perform fusion analysis using the commit message and line-level differences associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence input code detection model, and outputs the repair probability that the code commit belongs to the security repair commit;

[0140] Rule building module 504 is used to build cross-project migration rules based on code commits and code commit evidence subgraphs when the probability of fixing is greater than the probability threshold.

[0141] The migration detection module 505 is used to perform project migration detection on code submissions according to cross-project migration rules and determine the status of cross-project vulnerabilities.

[0142] Embodiment 3 of the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program; when the computer program is executed by the processor, the processor performs the steps of the cross-project security repair, detection and migration method for the blockchain ecosystem as described in Embodiment 1 of the present invention.

[0143] Embodiment 4 of the present invention also provides a computer-readable storage medium storing a computer program / instruction thereon, which, when executed by a processor, implements the steps of the cross-project security repair, detection and migration method for the blockchain ecosystem as described in Embodiment 1 of the present invention.

[0144] Embodiment 5 of the present invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the cross-project security repair, detection and migration method for the blockchain ecosystem as described in Embodiment 1 of the present invention.

[0145] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0146] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0147] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0148] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0149] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0150] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-project security remediation, detection, and migration method for the blockchain ecosystem, characterized in that, include: With code submissions as the central node, and with the edge relationships of submitting modified functions, submitting related topics, submitting related merge requests, submitting items belonging to a project, projects reusing projects, and merge requests discussing topics, a code submission knowledge graph is constructed. The editing action is determined based on the syntax tree differences of the affected function to which the code submission belongs, and the action code sequence of each editing action is determined by backfilling the original source code; The code submission is analyzed by fusing the submission message and line-level differences associated with the code submission, the code submission evidence subgraph of the code submission knowledge graph, and the action code sequence input code detection model to output the probability that the code submission belongs to a security fix submission. When the repair probability is greater than the probability threshold, cross-project migration rules are constructed based on the code commit and the code commit evidence subgraph. The code submissions are subjected to project migration detection according to the cross-project migration rules to determine the cross-project vulnerability status.

2. The cross-project security remediation, detection, and migration method for the blockchain ecosystem according to claim 1, characterized in that, The method involves fusing and analyzing the commit message and line-level differences associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence input code detection model to output the probability that the code commit belongs to a security fix commit, including: The commit message and line-level difference associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence are respectively processed by a cascaded SentenceTransformer model, a linear projection layer, a multi-layer Transformer encoder, and a Bi-LSTM network, and the corresponding outputs are commit message features, line-level difference features, evidence subgraph features, and action code features. Based on the feature addition layer, the text feature branch is constructed by adding the submission message feature to the evidence subgraph feature; The row-level difference features are added to the action code features according to the feature addition layer to form the code feature branch; In the feature fusion layer, the text feature branches and the code feature branches are adaptively fused to determine the code submission representation; A classification prediction network is used to output the probability that a code submission belongs to a security fix submission based on the code submission representation.

3. The cross-project security remediation, detection, and migration method for the blockchain ecosystem according to claim 1, characterized in that, When the probability of repair is greater than a probability threshold, cross-project migration rules are constructed based on the code commit and the code commit evidence subgraph, including: When the repair probability is greater than the probability threshold, the project reuse edge relationship of the code submission evidence subgraph is parsed to determine the applicable project scope. Based on the submission modification function edge relationships of the code submission evidence subgraph, the function signature of the source repair function is determined; The key code segments that were not modified in each of the source repair functions were used as context anchor points. The vulnerability-critical variable data stream of the source fix function is determined based on the data stream submitted by the code. Cross-project migration rules are constructed using the applicable project scope, the function signature of the source repair function, context anchor features, and vulnerability key variable data flow.

4. The cross-project security remediation, detection, and migration method for the blockchain ecosystem according to claim 3, characterized in that, The step of performing project migration detection on the code submission according to the cross-project migration rules to determine the cross-project vulnerability status includes: The target project set is determined by the applicable project scope; For any target item in the target item set, the function signature of each source repair function and the context anchor features are used for search and matching to determine the successfully matched function to be verified. Identify the deleted and added code blocks in the code commit; If the semantic similarity between the function to be verified and the newly added code block is greater than the semantic threshold, then it is determined that the vulnerability to which the source repair function belongs in the target project is in a repaired state. If the semantic similarity between the function to be verified and the deleted code block is greater than the semantic threshold and the semantic similarity between the newly added code block is less than or equal to the semantic threshold, then it is determined that the vulnerability to the source repair function in the target project is in a vulnerability residual state. If the semantic similarity between the function to be verified and the newly added code block and the deleted code block is less than or equal to the semantic threshold, or if the data flow matching degree between the function to be verified and the data flow of the vulnerability key variable is less than or equal to the data flow threshold, then it is determined that the vulnerability to which the source repair function belongs in the target project is in a vulnerability-irrelevant or vulnerability-reconstructed state.

5. The cross-project security remediation, detection, and migration method for the blockchain ecosystem according to claim 1, characterized in that, The step of determining the editing action based on the syntax tree differences of the affected function to which the code submission belongs, and determining the action code sequence of each editing action by backfilling the original source code, includes: Extract the affected functions from the code submission; An abstract syntax tree is constructed for each of the source code snapshots of the affected functions before and after the changes, and the editing actions are output through the tree difference tool; For each of the aforementioned editing actions, the original source code is backfilled to generate a corresponding action code sequence, which includes an insertion action code sequence, an update action code sequence, a deletion action code sequence, and a move action code sequence.

6. The cross-project security remediation, detection, and migration method for the blockchain ecosystem according to claim 1, characterized in that, The training loss function of the code detection model includes class-weighted cross-entropy loss and contrastive loss, wherein the class weight of the security repair submission training sample is greater than the class weight of the ordinary submission training sample in the class-weighted cross-entropy loss.

7. A cross-project security remediation, detection, and migration device for the blockchain ecosystem, characterized in that, include: The graph construction module is used to build a code submission knowledge graph with code submission as the central node and edge relationships such as submitting modified functions, submitting related topics, submitting related merge requests, submitting belonging to the project, the project reusing the project, and the merge request discussion topics. The action editing module is used to determine the editing action based on the syntax tree differences of the affected function to which the code submission belongs, and to determine the action code sequence of each editing action by backfilling the original source code; The repair detection module is used to perform fusion analysis using the commit message and line-level differences associated with the code commit, the code commit evidence subgraph of the code commit knowledge graph, and the action code sequence input code detection model, and output the repair probability that the code commit belongs to a security repair commit; The rule building module is used to build cross-project migration rules based on the code submission and the code submission evidence subgraph when the repair probability is greater than the probability threshold. The migration detection module is used to perform project migration detection on the code submission according to the cross-project migration rules and determine the cross-project vulnerability status.

8. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the cross-project security remediation, detection and migration method for the blockchain ecosystem as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the cross-project security repair, detection, and migration method for the blockchain ecosystem as described in any one of claims 1-6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the cross-project security repair, detection, and migration method for the blockchain ecosystem as described in any one of claims 1-6.

Images