Blockchain-based code audit system

Abstract

The application relates to the technical field of blockchain code auditing, and discloses a code auditing system based on a blockchain. The system comprises three modules, namely, an auditing feature extraction module, a vulnerability feature disambiguation module and a risk path analysis module. When the storage capacity of a target code repository reaches a preset threshold, the auditing feature extraction module calls a blockchain node to obtain a version snapshot, and extracts a code structure and a security attribute feature set; the vulnerability feature disambiguation module separates a to-be-verified vulnerability feature sequence from the code structure feature set, searches a candidate item set according to a vulnerability knowledge base, inputs a multi-level semantic decoupling model to generate a disambiguation vulnerability feature set; and the risk path analysis module constructs an auditing risk vector according to the security attribute and the disambiguation vulnerability feature set, and labels conflict and consistent path feature partition tags. The system guarantees data reliability by means of a blockchain, optimizes an auditing process by means of multi-module cooperation, and provides strong support for software system security auditing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain code auditing, in particular to a code auditing system based on blockchain. BACKGROUND

[0002] Under the background of rapid development of current software development and information technology, code security auditing has become an important link to ensure the stable operation of software systems. With the continuous expansion of software project scale, the amount of code stored in the code repository continues to grow, and the traditional code auditing method gradually exposes many problems. In the traditional auditing process, the acquisition of code repository versions depends on centralized servers, and once the server fails or the data is tampered with, it will directly affect the accuracy and integrity of the auditing data, resulting in the loss of reference value of the auditing results.

[0003] In the code feature extraction link, the traditional method often has difficulty in accurately capturing the key features of code structure and security attributes, especially when the code repository storage reaches a certain scale, the extraction efficiency is greatly reduced, and it is difficult to provide effective data support for auditing work in a timely manner. At the same time, in the vulnerability feature identification process, due to the lack of support of a perfect vulnerability knowledge base, and the existing technology cannot effectively process complex vulnerability feature sequences, the vulnerability feature confusion often occurs, making it difficult for auditors to accurately judge the vulnerability type and risk level.

[0004] In the risk path analysis stage, the traditional auditing system cannot construct a comprehensive auditing risk vector, nor can it clearly mark the conflict path features and consistent path features in the risk vector, making it difficult for auditors to quickly locate high-risk paths and increasing the difficulty and time cost of vulnerability elimination. The existence of these problems not only reduces the efficiency and accuracy of code auditing, but also cannot provide reliable protection for the security of software systems, and it is difficult to meet the high-standard needs of current software development for code security auditing. SUMMARY

[0005] The purpose of the present application is to provide a code auditing system based on blockchain to solve the problems raised in the background.

[0006] To achieve the above purpose, the present application provides a code auditing system based on blockchain, which comprises:

[0007] An auditing feature extraction module is used to call a blockchain node to obtain a version snapshot of a target code repository when the storage amount of the target code repository reaches a preset storage threshold, and extract a code structure feature set and a security attribute feature set of the version snapshot;

[0008] a vulnerability feature disambiguation module configured to separate a sequence of to-be-verified vulnerability features from the set of code structure features, retrieve a set of candidate vulnerability entries of the sequence of to-be-verified vulnerability features based on a vulnerability knowledge base, and input a multi-level semantic decoupling model to generate a disambiguated set of vulnerability features;

[0009] a risk path analysis module configured to construct an audit risk vector based on the set of security attribute features and the disambiguated set of vulnerability features, and mark a partition label of conflicting path features and consistent path features in the audit risk vector.

[0010] Preferably, the audit feature extraction module comprises:

[0011] a snapshot generation unit configured to monitor a storage increment of the target code repository, and trigger a distributed node to generate a blockchain transaction hash of the version snapshot when the storage increment reaches a preset storage threshold;

[0012] a structure analysis unit configured to analyze a syntax tree structure of the version snapshot, and extract a function call depth, a number of external dependencies, and a permission declaration type in the set of code structure features;

[0013] an attribute mapping unit configured to traverse a security policy node of the syntax tree structure, and map the set of security attribute features to a permission verification strength value, a data flow encryption identifier, and an external interface exposure level.

[0014] Preferably, the vulnerability feature disambiguation module comprises:

[0015] a feature separation unit configured to filter an unverified external dependency call feature from the set of code structure features, and generate the sequence of to-be-verified vulnerability features;

[0016] a knowledge base query unit configured to match the set of candidate vulnerability entries in the vulnerability knowledge base by taking the sequence of to-be-verified vulnerability features as an index key, wherein the set of candidate vulnerability entries comprises a vulnerability type code, a risk level score, and a repair mode identifier;

[0017] a semantic decoupling unit configured to input the sequence of to-be-verified vulnerability features and the set of candidate vulnerability entries into the multi-level semantic decoupling model, and output the disambiguated set of vulnerability features through vulnerability context semantic aggregation and feature decoupling verification.

[0018] Preferably, the semantic decoupling unit comprises:

[0019] a context encoding subunit configured to encode call context information of the sequence of to-be-verified vulnerability features into a vulnerability context semantic vector;

[0020] An item matching subunit is configured to calculate semantic similarity between the vulnerability context semantic vector and the candidate vulnerability item set, and filter candidate vulnerability items with similarity lower than a similarity threshold;

[0021] A conflict decoupling subunit is configured to perform feature dimension conflict detection on the remaining candidate vulnerability items, and output a conflict-free vulnerability type code and a risk level score as the disambiguated vulnerability feature set.

[0022] Preferably, the risk path analysis module comprises:

[0023] A vector construction unit is configured to associate and combine the permission check strength values of the security attribute feature set and the risk level scores of the disambiguated vulnerability feature set to generate a risk weight distribution of the audit risk vector;

[0024] A path marking unit is configured to identify feature paths in the audit risk vector with permission check strength values lower than a security baseline and risk level scores higher than a risk threshold, and mark them as conflict path features, and mark the rest as consistent path features.

[0025] Preferably, the system further comprises:

[0026] An audit chain generation module is configured to write the audit risk vector, the conflict path feature label, and the consistent path feature label into a new block to generate an audit event chain;

[0027] A verification node scheduling module is configured to schedule a blockchain verification node to perform consensus verification on the audit event chain according to the distribution density of the conflict path feature label.

[0028] Preferably, the audit chain generation module comprises:

[0029] An on-chain storage unit is configured to merge the hash digest of the code structure feature set and the audit risk vector into an on-chain audit data block;

[0030] An event anchoring unit is configured to anchor the code line number corresponding to the conflict path feature label to the timestamp sequence of the on-chain audit data block.

[0031] Preferably, the verification node scheduling module comprises:

[0032] A density calculation unit is configured to calculate the spatial distribution density of the conflict path feature label in the audit event chain;

[0033] A node allocation unit is configured to allocate an additional verification node to the new block when the spatial distribution density exceeds a dynamic allocation threshold.

[0034] The verification execution unit is configured to cross-verify the permission verification strength value of the on-chain audit data block by the additional verification node.

[0035] Preferably, the system further comprises:

[0036] The repair strategy binding module is configured to extract a repair mode identifier of the disambiguated vulnerability feature set from the vulnerability knowledge base, and generate a repair strategy instruction set.

[0037] The strategy execution module is configured to locate a target code segment according to the conflict path feature label of the risk path analysis module, and inject the repair strategy instruction set into the target code segment.

[0038] Preferably, the repair strategy binding module comprises:

[0039] The strategy matching unit is configured to retrieve a repair rule template library of the vulnerability knowledge base according to a vulnerability type code of the disambiguated vulnerability feature set.

[0040] The instruction compiling unit is configured to compile a security patch code in the repair rule template library into a blockchain smart contract instruction, and generate the repair strategy instruction set.

[0041] Compared with the prior art, the present application has the following beneficial effects:

[0042] The version snapshot of the target code repository is obtained by means of the blockchain node, and the decentralized nature of the blockchain can effectively avoid the faults or data tampering problems that may occur when the data is stored by the traditional centralized server, ensuring the accuracy and integrity of the version snapshot data, making the code features extracted based on the snapshot more credible, and laying a reliable data foundation for the entire audit process.

[0043] The audit feature extraction module starts the feature extraction work only when the storage amount of the target code repository reaches a preset threshold, which can avoid unnecessary extraction operations when the code amount is small, reduce system resource consumption, and focus on feature extraction of large-scale code repositories, so that the code structure feature set and the security attribute feature set can be more comprehensively captured, and rich and key feature data can be provided for subsequent vulnerability identification and risk analysis.

[0044] After the vulnerability feature disambiguation module separates the to-be-verified vulnerability feature sequence from the code structure feature set, the candidate vulnerability item set is retrieved based on the vulnerability knowledge base, and the disambiguated vulnerability feature set is generated by the multi-level semantic decoupling model. The introduction of the vulnerability knowledge base provides rich reference for vulnerability feature identification, and the multi-level semantic decoupling model can deeply process the complex to-be-verified vulnerability feature sequence, effectively solve the problem of vulnerability feature confusion in the traditional technology, and make the disambiguated vulnerability feature set clearer and more accurate, so as to facilitate the auditors to quickly identify the vulnerability type.

[0045] The risk path analysis module constructs an audit risk vector according to the security attribute feature set and the disambiguated vulnerability feature set, and marks the conflict path features and the consistent path feature partition tags in the audit risk vector, so that the auditor can intuitively understand the distribution of the audit risk, quickly locate the high-risk path with conflicts, reduce the blindness in the vulnerability elimination process, improve the efficiency of vulnerability elimination, help the auditor to more targetedly formulate a security protection strategy, and better guarantee the safe operation of the software system, and meet the diversified needs of code security audit in the current software development process. BRIEF DESCRIPTION OF DRAWINGS

[0046] Figure 1 a timing diagram of the code audit system based on the blockchain;

[0047] Figure 2 a flowchart of the working process of the audit feature extraction module;

[0048] Figure 3 a flowchart of the working process of the vulnerability feature disambiguation module;

[0049] Figure 4 a flowchart of the working process of the risk path analysis module;

[0050] Figure 5 a flowchart of the working process of the verification node scheduling module. DETAILED DESCRIPTION

[0051] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than 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.

[0052] Please refer to Figure 1 The present application provides a code audit system based on a blockchain, which comprises an audit feature extraction module, a vulnerability feature disambiguation module and a risk path analysis module.

[0053] The audit feature extraction module is configured to call a blockchain node to obtain a version snapshot of the target code repository when the storage amount of the target code repository reaches a preset storage threshold, and extract a code structure feature set and a security attribute feature set of the version snapshot. The vulnerability feature disambiguation module is configured to separate a to-be-verified vulnerability feature sequence from the code structure feature set, retrieve a candidate vulnerability item set based on a vulnerability knowledge base, and generate a disambiguated vulnerability feature set through a multi-level semantic decoupling model. The risk path analysis module is configured to construct an audit risk vector according to the security attribute feature set and the disambiguated vulnerability feature set, and mark a partition label of a conflict path feature and a consistent path feature in the audit risk vector.

[0054] Embodiment 1: see Figure 2 In the implementation process of the code audit system based on the blockchain, the function of the audit feature extraction module is realized through the cooperation of its three internal core units. The following takes a Python code repository named "ProjectAlpha" as an example to explain the specific operation mode of this module. The repository is hosted in a distributed version control system and connected to a blockchain network, and its preset storage threshold is set to 50 MB. The snapshot generation unit continuously monitors the storage increment of the ProjectAlpha repository. The unit is integrated with the version control system through a hook program. Every time new code is committed or merged, the total volume change of the repository is calculated. The monitoring period is set to every 5 minutes, and the metadata of the repository is scanned, including the size of code files, dependent libraries and binary resources. When the cumulative increment reaches the 50 MB threshold, for example, a large third-party library is introduced or a large number of resource files are added, the unit immediately triggers the distributed nodes in the blockchain network. The triggering mechanism is realized by calling a pre-deployed smart contract, which contains the logic of generating a version snapshot. After receiving the trigger signal, the distributed nodes take a snapshot of the current repository state, generating a data packet containing a timestamp, a commit hash and a file tree structure. The data packet is then encapsulated into a blockchain transaction, signed by the node and broadcast to the network. After the transaction is preliminarily consensus, a unique transaction hash value is generated, for example, "0x8a3b...f2c1", which is stored on the chain as a unique identifier of the snapshot and returned to the snapshot generation unit. This process ensures the non-tamperability of the snapshot. Any subsequent modification of the repository history will cause the hash value to be mismatched.

[0055] The structural analysis unit receives the version snapshot containing transaction hashes and initiates the syntax tree parsing process. This unit integrates static code analysis tools (e.g., an abstract syntax tree-based parser) to first extract all source code files from the snapshot. Taking a core module in ProjectAlpha, "core_service.py", as an example, the parser analyzes its code structure line by line. The calculation of function call depth is achieved by recursively traversing the function call chain: for example, function A calls function B, and function B calls function C, then the call depth is 3. This unit records the depth value of each function and takes the maximum depth as the feature value. The statistics of external dependencies are completed by identifying the import statements in the code: for example, statements such as "import os", "from cryptography.fernet import Fernet" in the file header are parsed as external dependencies, and their number is summed up. The extraction of permission declaration types involves scanning the security-related annotations or configurations in the code: for example, the decorator "@permission_required('admin')" is identified as a permission declaration, and the type is classified as "execution permission"; similarly, the configuration item "READ_ONLY=True" is classified as "read permission". All extracted features are aggregated into a structured code structure feature set, containing numerical and categorical data.

[0056] The attribute mapping unit then traverses the security policy nodes in the syntax tree and maps security attributes to quantitative indicators. In the syntax tree of ProjectAlpha, security policy nodes include permission check functions, data encryption calls, and API exposure declarations. The mapping of permission verification strength values is based on the complexity of the verification logic: for example, a permission check code containing multiple conditional judgments (such as user role, IP address, and session token verification) is assigned a high strength value of 0.9; while a code containing only a simple Boolean check is assigned a low strength value of 0.3. The determination of data flow encryption identification is achieved by detecting encryption function calls in data transmission or storage processes: for example, a code segment that uses "Fernet.encrypt()" to encrypt data is marked as "encrypted"; plaintext transmission without any encryption method is marked as "unencrypted". The assessment of external interface exposure level is achieved by analyzing API endpoint definitions: for example, HTTP interfaces decorated with "@public_api" are classified as "high exposure"; gRPC calls between internal services are classified as "low exposure". The mapping results are integrated into a security attribute feature set, including permission verification strength values (continuous numerical values), data flow encryption identification (binary labels), and external interface exposure levels (discrete levels).

[0057] Example 2: see Figure 3In the implementation of the blockchain-based code audit system, the function of the vulnerability feature disambiguation module is realized through the coordination of its three core units. The following example, which is based on the ProjectAlpha code repository, describes the specific operation of this module. The module receives the set of code structure features from the audit feature extraction module and outputs a set of disambiguated vulnerability features.

[0058] The feature separation unit first processes the set of code structure features and filters out the unverified external dependency call features. This unit scans all external dependencies recorded in the feature set and checks for each dependency whether there is a verification mechanism in its call context. Take the "fastjson" library introduced in ProjectAlpha as an example. The call of this library occurs in the data parsing link. The feature separation unit analyzes the call code segment and finds that it directly uses the JSON.parse(rawString) method to process the raw string of user input without configuring a security mode or performing type whitelist verification. Such a call is identified as "unverified", and its related features include: dependency name ("fastjson"), version number ("1.2.62"), call location ("DataProcessor.java: line 87"), call method ("parse"), and parameter type ("raw string"). These features are serialized into a structured sequence of unverified vulnerability features, with each entry containing the above fields. For cases where there are multiple unverified dependencies, the unit will generate a sequence containing multiple entries and sort them by call location.

[0059] The knowledge base query unit receives the vulnerability feature sequence to be verified, and performs matching retrieval in the vulnerability knowledge base by taking it as an index key. The vulnerability knowledge base is constructed on a distributed storage system, and includes entries of multiple vulnerability databases including CVE and NVD. The query unit first preprocesses the feature sequence and extracts key index information. For the "fastjson" entry, the unit extracts its name and version number to combine into the primary key "fastjson:1.2.62", and at the same time takes the calling method "parse" as an auxiliary key. Using these key values, the unit performs multi-level query in the knowledge base: first, accurately match the name and version, and then filter the entries related to the calling method in the known vulnerabilities under this version. The query may return multiple candidate vulnerability entries, such as "deserialization vulnerability (CVE-2022-25845)" and "type confusion vulnerability (CVE-2021-27568)" for the version fastjson. Each candidate vulnerability entry contains standardized fields: vulnerability type code (such as "CWE-502: deserialization"), risk level score (such as CVSS score 8.6), repair mode identification (such as "suggest upgrading to 1.2.83 and enabling SafeMode"), and affected version range. All these related entries are aggregated into a candidate vulnerability entry set.

[0060] The semantic decoupling unit receives the vulnerability feature sequence to be verified and the candidate vulnerability entry set, and processes them through a multi-level semantic decoupling model. The unit first encodes the calling context information into a semantic vector through a context encoding subunit. For the "fastjson.parse" call, the context information includes: the function name in which the call is located ("processUserData"), the parameter source ("from HTTP request body"), the return value processing method ("directly converted into a business object"), etc. These text information is converted into a high-dimensional vector representation through a pre-trained word embedding model, and then aggregated into a single vulnerability context semantic vector through an attention mechanism, capturing the semantic environment and potential risk features of the call.

[0061] The entry matching subunit calculates the semantic similarity between the semantic vector and the description vector of each candidate vulnerability entry. Each candidate entry has a detailed text description in the knowledge base, such as "attackers can execute arbitrary code by constructing malicious JSON strings". These descriptions are also encoded into vector representations. The similarity calculation uses the cosine similarity algorithm, and sets the threshold to 0.7. Suppose the similarity of the "deserialization vulnerability" entry is 0.85, and the similarity of the "type confusion vulnerability" entry is 0.65, the latter is filtered out because it is below the threshold. The remaining entries enter the conflict decoupling stage.

[0062] The conflict decoupling sub-unit performs feature dimension conflict detection on the remaining candidate entries. In some cases, multiple candidate entries can have conflicts in certain feature dimensions, such as inconsistent risk scores or contradictory repair suggestions. This sub-unit applies rule-based conflict resolution strategies by analyzing the feature dimensions of the entries. For example, if two entries have high similarity but different repair suggestions, the entry with a higher CVSS score is prioritized, or the entry from a more authoritative data source is selected. Ultimately, the output is a set of disambiguated vulnerability features without conflicts, including vulnerability type encoding and risk level score. For the Project Alpha example, the output may determine the vulnerability type encoding as "CWE-502", the risk level score as 8.6, and the corresponding repair pattern identification. This set provides clean and consistent vulnerability feature data for subsequent risk analysis.

[0063] Embodiment 3: Refer to Figure 4 In the implementation of the blockchain-based code audit system, the function of the risk path analysis module is realized through the vector construction unit and the path marking unit. This module receives the security attribute feature set and the disambiguated vulnerability feature set from the previous modules and outputs the marked audit risk vector. The following example of the Project Alpha code repository illustrates the specific operation of this module.

[0064] The vector construction unit first processes the input feature set. This unit combines the permission check strength value in the security attribute feature set with the risk level score in the disambiguated vulnerability feature set. The permission check strength value is a normalized value ranging from [0, 1], representing the completeness of the permission check mechanism in the code. The risk level score comes from the disambiguated vulnerability features and uses the CVSS score standard, ranging from [0, 10]. To effectively associate, the unit first normalizes the risk level score to the [0, 1] interval by dividing by the maximum possible value 10. The association and combination process uses a weighted aggregation method to generate the risk weight distribution of the audit risk vector. This distribution is calculated by the following formula:

[0065] W i =α·P i +β·(1-R i )

[0066] Where: W i represents the risk weight value of the i-th feature path, P i represents the permission check strength value of the path, and R i represents the normalized risk level score. Coefficients α and β are configurable weight parameters, satisfying α + β = 1, with default values set to 0.6 and 0.4, respectively. These parameters can be adjusted according to project characteristics, such as increasing the β weight for systems with extremely high security requirements. The weight value Wi The higher, the greater the risk, and its distribution reflects the risk status of different paths in the system.

[0067] The path marking unit classifies the feature paths based on the calculated risk weight distribution. This unit sets two key thresholds: a safety baseline and a risk threshold. The safety baseline is set to 0.5, representing the minimum acceptable level of permission verification strength; the risk threshold is set to 0.7, representing the critical value of risk level. The unit iterates through each dimension of the audit risk vector, identifying feature paths that meet the following conditions: the permission verification strength value is lower than the safety baseline (P i <0.5) and the risk level score is higher than the risk threshold (R i >0.7). These paths are marked as conflict path features, indicating high-risk and poorly protected code regions. The remaining paths are marked as consistent path features, indicating risk-controlled or properly protected code regions. During the marking process, the unit records the specific location information of each path, including file path, line number range, and related code snippets.

[0068] The audit chain generation module writes the analysis results to the blockchain. This module receives the complete audit risk vector, conflict path feature labels, and consistent path feature labels, and encapsulates them as a new block. The writing process calls the on-chain storage function of the smart contract, serializes the data and adds it to the distributed ledger. The new block contains a timestamp, version hash, and audit result summary, forming an immutable audit event chain.

[0069] The verification node scheduling module dynamically adjusts the verification resources based on the distribution of conflict path feature labels. This module calculates the spatial distribution density of conflict path features in the audit event chain by counting the number of conflict labels within a unit block length. When the density value exceeds the preset dynamic allocation threshold (such as 30 conflict labels per block), the module automatically schedules additional verification nodes to participate in the consensus process. These additional nodes cross-verify the permission verification strength values in the audit data blocks on the chain, ensuring data accuracy and consistency through multi-node independent calculation and result comparison. The verification results are updated to the audit event chain after consensus is reached, completing the closed-loop management of the entire audit cycle.

[0070] The entire implementation process is achieved through an automated process, from risk analysis to blockchain storage and verification scheduling, forming a complete audit closed loop. The system objectively identifies the risk distribution in the code repository through quantitative indicators and threshold judgments, providing a data basis for subsequent repair decisions. All operations are recorded on the blockchain, ensuring the transparency and traceability of the audit process.

[0071] Example 4: See Figure 5, the functions of the audit chain generation module and the verification node scheduling module are realized through the on-chain storage unit, the event anchoring unit, the density calculation unit, the node allocation unit, and the verification execution unit. The following is an audit result from the ProjectAlpha code repository, which describes the specific operation mode of the module. The on-chain storage unit of the audit chain generation module first processes the output data from the risk path analysis module. This unit receives the hash digest of the feature set and the audit risk vector, where the hash digest is a fixed-length string calculated by the SHA-256 algorithm on the feature set to ensure data integrity. The audit risk vector contains multiple dimensions of risk weight values, each corresponding to a risk assessment result of a feature path. The unit combines these data into a structured on-chain audit data block, which is organized in JSON format and contains header information and main content. The header information records the basic metadata of the blockchain transaction, including the version number, timestamp, and previous block hash. The main content contains specific audit data, where the hash digest is stored as a separate field, and the audit risk vector is serialized as an array structure, with each array element containing a path identifier and the corresponding risk weight value. After the data block is constructed, it is written into a new block by calling the storage method of the smart contract, and the corresponding transaction receipt and block height information are generated.

[0072] The event anchoring unit is responsible for associating the code location information of the conflict path feature labels with the blockchain timestamp. This unit reads the conflict path feature label data, which contains specific code line number information, such as lines 87 to 92 in the DataProcessor.java file. The unit creates independent anchoring records for each conflict path, which contain file path, start line number, end line number, and risk type description. These records are bound to the timestamp sequence of the on-chain audit data block through the creation of a mapping relationship. The timestamp sequence comes from the consistent timestamp generated by the blockchain network, with each timestamp corresponding to a block generation time. The anchoring process uses a Merkle tree structure to organize the code location information as leaf nodes and the timestamp as root nodes, generating corresponding hash proofs. Finally, all anchoring information is written into the metadata section of the on-chain audit data block, forming an unalterable association record.

[0073] The density calculation unit of the verification node scheduling module performs statistical analysis on the distribution of conflict paths in the audit event chain. This unit scans the newly generated audit event chain and extracts the spatial location information of all conflict path feature labels. During the statistical process, the unit divides the audit event chain by block and calculates the number of conflict paths contained in each block unit. Through the sliding window algorithm, the unit calculates the distribution density value of conflict paths in the chain, which is expressed as the average number of conflict paths per unit length of the chain. The density calculation result is recorded as time series data for subsequent node scheduling decisions.

[0074] The node allocation unit dynamically adjusts the allocation strategy of verification nodes based on the density calculation results. The unit sets a dynamic allocation threshold of 30 conflict paths per block. When the density value exceeds this threshold, an additional verification node allocation mechanism is triggered. The allocation process is implemented by calling the node management smart contract. The contract selects appropriate additional verification nodes from the available node pool based on the current network status and node reputation score. Selection criteria include historical performance, computing resource availability, and network latency indicators. The selected additional verification nodes are assigned to the verification task of the new block, and their node identifiers and allocation times are recorded in the block header.

[0075] The verification execution unit coordinates the cross-verification of on-chain audit data blocks by additional verification nodes. The unit sends verification tasks to each additional verification node, which includes the permission check strength value data to be verified and related context information. The verification nodes independently perform verification calculations by reproducing the audit process to verify the accuracy of the permission check strength value. The nodes return the signed verification results, which are collected and compared for consistency by the verification execution unit. When more than two-thirds of the nodes agree, the verification result is confirmed as valid, otherwise a re-verification process is triggered. Refer to Table 1 for the distribution of conflict path characteristics in the audit event chain.

[0076] Table 1: Audit Event Chain Conflict Path Space Distribution Statistics Table.

[0077] Block height Timestamp sequence Number of conflict paths Density interval Number of validating nodes 152789 2023-08-05T08:12:23Z 28 0.45 5 152790 2023-08-05T08:17:45Z 35 0.56 8 152791 2023-08-05T08:23:12Z 42 0.67 10 152792 2023-08-05T08:29:37Z 31 0.49 6 152793 2023-08-05T08:35:59Z 39 0.62 9

[0078] The entire implementation process is completed through an automated process, with each link from data storage to node scheduling following predefined rules and thresholds. The system dynamically adjusts the allocation of verification resources by monitoring the distribution density of conflict paths in real time, ensuring the reliability and consistency of audit results. All operations are recorded on the blockchain, forming a complete audit trail and providing a data foundation for subsequent audit tracing.

[0079] Example 5: The repair strategy binding module and the strategy execution module work together to complete the complete process from vulnerability identification to repair implementation. The following takes the audit results of the ProjectAlpha code repository to explain the specific operation of this module. The module receives the disambiguated vulnerability feature set from the vulnerability feature disambiguation module and the conflict path feature label from the risk path analysis module, and outputs the actual code repair operations.

[0080] The policy matching unit of the repair strategy binding module first processes the disambiguation vulnerability feature set. The unit reads the vulnerability type code field, such as the anti-serialization vulnerability detected in Project Alpha, which is coded as CWE-502. The unit uses this code as an index key to query the vulnerability knowledge base deployed in the distributed storage system. The repair rule template library in the knowledge base is stored by vulnerability type, and each template contains detailed repair guidance. The query process uses a multi-level retrieval mechanism, first matching the vulnerability type code, and then filtering applicable repair templates under the corresponding category. For CWE-502 type vulnerabilities, multiple related templates may be retrieved, including dependency library upgrades, security configuration adjustments, code refactoring, and other different repair schemes. The unit selects the most suitable repair template based on the specific context of the vulnerability. Factors considered in the selection process include the severity of the vulnerability, the scope of the affected code, system environment compatibility, and the like. The final repair template contains specific repair instruction descriptions, applicable code pattern examples, and expected repair effect descriptions.

[0081] The instruction compilation unit converts the selected repair template into an executable repair strategy instruction set. The unit parses the security patch code in the repair template, which is usually presented in the form of pseudocode or a specific domain language. The compilation process first performs syntax analysis and semantic checking to ensure the integrity and correctness of the repair instructions. Subsequently, the unit converts the repair instructions into blockchain smart contract instructions, encoded in Solidity language or on-chain script language. The conversion process maintains the equivalence of the repair logic while adapting to the requirements of the blockchain execution environment. For the fastjson anti-serialization vulnerability in Project Alpha, the repair instructions may include: upgrading the dependency library version to 1.2.83, adding a security mode configuration before parsing calls, and adding input validation logic. These instructions are organized into an ordered instruction sequence to form a complete repair strategy instruction set. The instruction set contains detailed operation descriptions such as execution steps, parameter configurations, and exception handling, ensuring the repeatability and reliability of the repair process.

[0082] The policy execution module receives the repair strategy instruction set and the conflict path feature label, and implements specific code repair operations. The module first parses the conflict path feature label to locate the target code segment that needs to be repaired. The label contains detailed code location information such as file path, line number range, and function identifier. The module accesses the target code repository through the version control system and reads the source code content at the specified location. According to the guidance of the repair strategy instruction set, the module performs modification operations on the target code segment. The modification may involve multiple aspects: updating the version declaration in the dependency configuration file, modifying the API call method in the code, inserting new security verification logic, or adjusting the existing business processing flow. Each modification operation follows the detailed instructions in the instruction set to ensure the accuracy and consistency of the modification.

[0083] After the modification is completed, the module submits the change to the version control system, generating a new code version. The detailed description of the repair is recorded in the submission information, including the type of vulnerability repaired, the repair strategy adopted, the list of modified files, etc. At the same time, the module records the repair operation through the blockchain smart contract, writing the relevant information of the repair event into the distributed ledger. The recorded content includes the repair time, the execution node, the modified code hash value, the version of the repair strategy instruction set, etc. These records form an unalterable repair history, providing a traceable basis for subsequent auditing and verification.

[0084] The entire implementation process is completed through an automated process, with close links from vulnerability matching to repair execution. The system guides the repair operation through a structured repair strategy instruction set, ensuring the consistency and reliability of the repair scheme. All repair operations are recorded on the blockchain, forming a complete repair track and providing complete data support for code quality management and security auditing. The repaired code version enters a new audit cycle, and the system continues to monitor its security status, forming a continuous improvement closed-loop management mechanism.

[0085] It should be noted that, in this text, relational terms such as first and second are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device.

[0086] Although embodiments of the present application have been shown and described, it will be understood by those of ordinary skill in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the present application, and the scope of the present application is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based code auditing system, characterized in that, The method comprises the following steps: An audit feature extraction module is used to call a blockchain node to obtain a version snapshot of a target code repository when the storage amount of the target code repository reaches a preset storage threshold, and to extract a code structure feature set and a security attribute feature set of the version snapshot; A vulnerability feature disambiguation module is used to separate a to-be-verified vulnerability feature sequence from the code structure feature set, retrieve a candidate vulnerability item set of the to-be-verified vulnerability feature sequence based on a vulnerability knowledge base, and input a multi-level semantic decoupling model to generate a disambiguated vulnerability feature set; A risk path analysis module is used to construct an audit risk vector according to the security attribute feature set and the disambiguated vulnerability feature set, and mark a partition label of a conflict path feature and a consistent path feature in the audit risk vector; The vulnerability feature disambiguation module comprises: A feature separation unit is used to filter unverified external dependency call features from the code structure feature set to generate the to-be-verified vulnerability feature sequence; A knowledge base query unit is used to match the candidate vulnerability item set in the vulnerability knowledge base by taking the to-be-verified vulnerability feature sequence as an index key, wherein the candidate vulnerability item set comprises a vulnerability type code, a risk level score, and a repair mode identifier; A semantic decoupling unit is used to input the to-be-verified vulnerability feature sequence and the candidate vulnerability item set into the multi-level semantic decoupling model, and output the disambiguated vulnerability feature set through vulnerability context semantic aggregation and feature decoupling verification; The risk path analysis module comprises: A vector construction unit is used to associate and combine a permission check strength value of the security attribute feature set and a risk level score of the disambiguated vulnerability feature set to generate a risk weight distribution of the audit risk vector; A path marking unit is used to identify a feature path in the audit risk vector whose permission check strength value is lower than a security baseline and whose risk level score is higher than a risk threshold, and mark it as the conflict path feature, and mark the rest as the consistent path feature.

2. The blockchain-based code audit system of claim 1, wherein, The audit feature extraction module comprises: A snapshot generation unit is used to monitor a storage increment of the target code repository, and trigger a distributed node to generate a blockchain transaction hash of the version snapshot when the storage increment reaches the preset storage threshold; A structure analysis unit is used to analyze a syntax tree structure of the version snapshot, and extract a function call depth, a number of external dependencies, and a permission declaration type in the code structure feature set; An attribute mapping unit is used to traverse a security policy node of the syntax tree structure, and map the security attribute feature set into a permission check strength value, a data flow encryption identifier, and an external interface exposure level.

3. The blockchain-based code audit system of claim 1, wherein, The semantic decoupling unit comprises: A context coding subunit is used to encode call context information of the to-be-verified vulnerability feature sequence into a vulnerability context semantic vector; An item matching subunit is used to calculate a semantic similarity of the vulnerability context semantic vector and the candidate vulnerability item set, and filter candidate vulnerability items below a similarity threshold; The conflict decoupling subunit is configured to perform feature dimension conflict detection on the remaining candidate vulnerability entries, and output a non-conflict vulnerability type code and a risk level score as the disambiguated vulnerability feature set.

4. The blockchain-based code audit system of claim 1, wherein, The system further comprises: An audit chain generation module configured to write the audit risk vector, the conflict path feature label, and the consistent path feature label into a new block to generate an audit event chain; A verification node scheduling module configured to schedule a blockchain verification node to perform consensus verification on the audit event chain according to a distribution density of the conflict path feature label.

5. The blockchain-based code audit system of claim 4, wherein, The audit chain generation module comprises: An on-chain storage unit configured to combine a hash digest of the code structure feature set and the audit risk vector into an on-chain audit data block; An event anchoring unit configured to anchor a code line number corresponding to the conflict path feature label to a timestamp sequence of the on-chain audit data block.

6. The blockchain-based code audit system of claim 5, wherein, The verification node scheduling module comprises: A density calculation unit configured to calculate a spatial distribution density of the conflict path feature label in the audit event chain; A node allocation unit configured to allocate an additional verification node to the new block when the spatial distribution density exceeds a dynamic allocation threshold; A verification execution unit configured to perform cross-verification on a permission check strength value of the on-chain audit data block by the additional verification node.

7. The blockchain-based code audit system of claim 1, wherein, The system further comprises: A repair strategy binding module configured to extract a repair mode identifier of the disambiguated vulnerability feature set from the vulnerability knowledge base to generate a repair strategy instruction set; A strategy execution module configured to locate a target code segment according to the conflict path feature label of the risk path analysis module, and inject the repair strategy instruction set into the target code segment.

8. The blockchain-based code audit system of claim 7, wherein, The repair strategy binding module comprises: A strategy matching unit configured to retrieve a repair rule template library of the vulnerability knowledge base according to a vulnerability type code of the disambiguated vulnerability feature set; An instruction compiling unit configured to compile a security patch code in the repair rule template library into a blockchain smart contract instruction to generate the repair strategy instruction set.

Images