Block chain-based edge node vulnerability scanning auditing method

Abstract

The invention discloses an edge node vulnerability scanning auditing method based on a block chain, belongs to the technical field of vulnerability scanning, and solves the problems that an auditing record and a scanning result are easy to tamper and a single-point fault is easy to occur in an existing vulnerability scanning mode. The method comprises the following steps: constructing a block chain network for vulnerability scanning auditing, defining each edge node as a node in the block chain network, and deploying a vulnerability scanning smart contract on the block chain network; each edge node uploads a vulnerability scanning audit record of the edge node to the block chain network, and stores the vulnerability scanning audit record as structured vulnerability scanning audit data matched with the vulnerability scanning smart contract; and updating a vulnerability scanning strategy according to the node importance of each edge node and the structured vulnerability scanning data. According to the method, decentralized, safe, reliable and traceable edge node vulnerability scanning auditing is realized by utilizing a block chain technology, and the problems that auditing records and scanning results are easy to tamper and the like in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to the field of vulnerability scanning technology, and in particular to a blockchain-based edge node vulnerability scanning and auditing method. Background Art

[0002] In edge computing environments, edge nodes are more vulnerable to various types of attacks. Strengthening vulnerability scanning and auditing at edge nodes can timely identify vulnerabilities, effectively prevent attacks, and largely ensure the security of edge nodes. However, frequent vulnerability scanning does not effectively improve edge node security. A well-defined vulnerability scanning strategy and timely remediation are more effective. Due to the complex and ever-changing network connections and services at edge nodes, an effective scanning strategy can analyze and evaluate vulnerability audit records, remediation records, and scan results. By analyzing the rationality of vulnerability scanning strategies, compliance with regulations, and timely vulnerability remediation, it can identify issues and improve system security.

[0003] Existing technologies rely on centralized database storage and audit rules, posing the risk of tampering with audit records and scan results and susceptible to single points of failure. Once a centralized database or audit system experiences issues, the entire audit process will be impacted. Rule-based auditing approaches monitor and evaluate system behavior by setting a series of security rules and policies to identify potential security violations and vulnerabilities, and are widely used in compliance audits and risk management. Risk-based auditing assesses an organization's risk exposure and potential impact, prioritizing the most critical assets and the most threatening vulnerabilities to optimize audit resource allocation and improve audit effectiveness. Data mining techniques analyze large data sets to identify potential security incidents and abnormal patterns, helping auditors uncover subtle risks and enhancing the depth and breadth of overall audits. However, these technologies all rely on centralized database storage and audit rules, posing the risk of tampering with audit records and scan results and susceptible to single points of failure. Summary of the Invention

[0004] In view of the above analysis, the embodiment of the present invention aims to provide a blockchain-based edge node vulnerability scanning and auditing method to solve the problems in existing vulnerability scanning methods, such as the easy tampering of audit records and scanning results and the easy occurrence of single point failures.

[0005] The present invention discloses a blockchain-based edge node vulnerability scanning and auditing method, the method comprising: Build a blockchain network for vulnerability scanning and auditing, define each edge node as a node in the blockchain network, and deploy vulnerability scanning smart contracts on the blockchain network; Each edge node uploads its own vulnerability scanning audit records to the blockchain network, which are stored as structured vulnerability scanning audit data that matches the vulnerability scanning smart contract. Update vulnerability scanning strategies based on the node importance of each edge node and structured vulnerability scanning data.

[0006] On the basis of the above solution, the present invention also makes the following improvements: Furthermore, each edge node, while uploading its own vulnerability scan audit records to the blockchain network, performs: The edge node constructs a transaction proposal based on the vulnerability scan audit records and uploads it to the blockchain network; The target smart contract automatically verifies the integrity and compliance of the vulnerability scan audit records in the transaction proposal and stores the verified vulnerability scan audit records in the target smart contract.

[0007] Furthermore, the transaction proposal includes the ID of the target smart contract, the name and parameters of the called function, and the identity information of the transaction initiator; wherein the parameters include the vulnerability scan audit records that need to be stored and the digital signature generated by the corresponding edge node.

[0008] Furthermore, the edge node generates a digital signature by performing the following operations: The edge node uses a hash algorithm to convert vulnerability scan audit records into a fixed-length data digest and uses the data digest as the hash value; The edge node uses its own private key to encrypt the hash value and generate a digital signature.

[0009] Furthermore, the blockchain network stores the vulnerability scanning audit record as structured vulnerability scanning audit data that matches the vulnerability scanning smart contract by performing the following operations: The audit nodes in the blockchain network perform structured processing on the verified vulnerability scanning audit records, generate structured vulnerability scanning data that matches the vulnerability scanning smart contract, and store it in the blockchain network.

[0010] Furthermore, update the vulnerability scanning policy by executing the following: Define a data query interface in the vulnerability scanning smart contract to extract structured vulnerability scanning data for each edge node; Determine the node importance of each edge node; Update vulnerability scanning strategies based on the node importance of edge nodes and structured vulnerability scanning data.

[0011] Furthermore, the node importance of each edge node is determined as follows: According to the network topology, the degree centrality, betweenness centrality and closeness centrality of each edge node are calculated to obtain the importance score of each edge node; According to the importance score of each edge node, the edge nodes are divided into key nodes, important nodes and ordinary nodes.

[0012] Furthermore, edge nodes Degree centrality Expressed as: (1) in, Represents an edge node The degree of the edge node in the network topology graph The number of connected neighbor edge nodes; Indicates the total number of edge nodes in the network topology graph; edge nodes Betweenness centrality Expressed as: (2) in, Represents an edge node To the edge node The shortest path length; edge nodes Closeness centrality Expressed as: (3) in, Represents an edge node To the edge node The number of shortest paths, Represents an edge node To the edge node The shortest path passes through the edge node the number of Represents the set of all edge nodes in the network topology graph.

[0013] Furthermore, edge nodes Importance score Expressed as: (4) in, 、 、 The weight parameters representing degree centrality, closeness centrality, and proximity centrality, respectively, can be determined based on expert experience, historical data, or optimization algorithms; express The maximum normalized result of .

[0014] Furthermore, based on the node importance of edge nodes and structured vulnerability scanning data, the vulnerability scanning strategy is updated and executed: Determine whether there are high-risk vulnerabilities in the structured vulnerability scanning data of key nodes or important nodes that have not been repaired in a timely manner, or whether the number of vulnerabilities shows an increasing trend during each scan. If so, increase the scanning frequency and depth of the corresponding key nodes and important nodes.

[0015] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: This paper proposes a blockchain-based edge node vulnerability scanning and auditing method. By introducing blockchain technology and smart contract mechanisms, it effectively solves key problems in traditional vulnerability scanning systems, such as the tampering of audit records and scanning results and the risk of single point failure in the system. The specific technical effects are as follows: (1) Preventing tampering of audit records and scan results By storing vulnerability scan audit records from edge nodes as structured data on the blockchain network, leveraging the blockchain's immutability and traceability, we ensure the authenticity and integrity of each audit record. Combined with a digital signature mechanism, each record undergoes hashing and private key encryption before being uploaded to the blockchain, ensuring data security during transmission and storage, and preventing malicious tampering.

[0016] (2) Eliminate single point failure risks and improve system robustness Traditional vulnerability scanning systems typically rely on centralized servers for data storage and policy management, which poses a single point of failure risk. This invention builds a distributed blockchain network, allowing each edge node to participate in data storage and consensus as a blockchain node. This avoids the single point of failure associated with centralized architectures and improves system availability and fault tolerance.

[0017] (3) Implementing an automated and reliable vulnerability scanning and auditing process Smart contracts are used to automatically verify the integrity and compliance of vulnerability scanning audit records, and automatically perform structured processing and policy updates, thereby automating and intelligentizing the vulnerability scanning audit process, reducing human intervention, and improving audit efficiency and credibility.

[0018] (4) Dynamically optimize vulnerability scanning strategies to improve scanning efficiency and accuracy By introducing a node importance assessment mechanism, combined with network topology and historical vulnerability data, key nodes and important nodes can be dynamically identified, and the scanning frequency and depth can be adjusted accordingly to achieve reasonable resource allocation, improve the efficiency and accuracy of vulnerability discovery, and avoid resource waste.

[0019] (5) Improve system transparency and auditability All vulnerability scanning audit records are stored on the blockchain, with complete timestamps and tamper-proof features, which facilitates subsequent audits and traceability, enhances the transparency and auditability of the system, and meets compliance requirements.

[0020] In summary, the present invention aims to utilize blockchain technology to propose a decentralized, secure, reliable, and traceable edge node vulnerability scanning and auditing method. By classifying and assessing vulnerability scans, the vulnerability change trends of edge nodes can be grasped in a timely manner, and more effective vulnerability scanning strategies can be adopted.

[0021] In the present invention, the above-mentioned technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of the present invention will be described in the following description, and some advantages will become apparent from the description or be learned through practice of the present invention. The objectives and other advantages of the present invention can be realized and obtained through the contents particularly pointed out in the description and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are only used for the purpose of illustrating specific embodiments and are not to be considered as limiting the present invention. Throughout the drawings, the same reference symbols denote the same components. Figure 1 Flowchart of the blockchain-based edge node vulnerability scanning and auditing method provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The preferred embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings, wherein the accompanying drawings constitute a part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, and are not used to limit the scope of the present invention.

[0024] A specific embodiment of the present invention discloses a blockchain-based edge node vulnerability scanning and auditing method, the flow chart of which is as follows: Figure 1 As shown, the method includes the following steps.

[0025] Step S1: Build a blockchain network for vulnerability scanning and auditing, define each edge node as a node in the blockchain network, and deploy a vulnerability scanning smart contract on the blockchain network.

[0026] In this embodiment, a decentralized vulnerability scanning network is constructed by defining each edge node as a node in the blockchain network. Within this vulnerability scanning network, each edge node possesses independent vulnerability detection capabilities and can autonomously scan itself or designated targets (such as local devices). These scans are recorded within the vulnerability scanning network, forming an immutable distributed ledger that ensures the authenticity and traceability of audit data. Furthermore, the blockchain network's encryption algorithms and consensus mechanisms ensure the security and reliability of the vulnerability scanning process. This architecture not only improves the efficiency and accuracy of vulnerability scanning but also effectively reduces the risk of single points of failure, enhancing the overall security of the system.

[0027] Preferably, in this embodiment, the blockchain network uses Hyperledger Fabric. As an open-source blockchain platform, Hyperledger Fabric offers high scalability and flexibility. When applying the Hyperledger Fabric blockchain platform, key elements such as nodes, channels, and consensus mechanisms must be defined to ensure the security and stability of the blockchain network. For example, during channel design, this embodiment introduces dynamic sharding technology to shard and store audit data in different channels based on the location of edge nodes and network load. Specifically, vulnerability scan results with high security requirements are stored in private channels, while general data is stored in public channels. This design effectively reduces data processing pressure on the blockchain while improving the scalability of the entire system. For example, vulnerability scan records involving sensitive information can be stored in private channels, accessible only to authorized nodes; while general vulnerability scan results can be stored in public channels for viewing by all nodes. This embodiment also introduces a consensus mechanism, combining the PBFT (Practical Byzantine Fault Tolerance) and PoS (Proof of Stake) consensus algorithms. For critical vulnerability audit transactions, the PBFT consensus algorithm is used to ensure immediate transaction consistency, which is crucial for the timely detection and resolution of high-risk vulnerabilities. For ordinary transactions, the PoS consensus algorithm can reduce energy consumption and improve system efficiency. This hybrid consensus mechanism balances efficiency and security.

[0028] To meet vulnerability scanning and auditing requirements, this embodiment deploys a vulnerability scanning smart contract on Hyperledger Fabric. During implementation, edge nodes invoke the vulnerability scanning smart contract to store vulnerability scanning and audit information on the blockchain network. During storage, the smart contract automatically verifies the integrity and compliance of the data. Details are as follows.

[0029] Step S2: Each edge node uploads its own vulnerability scanning audit record to the blockchain network and stores it as structured vulnerability scanning audit data that matches the vulnerability scanning smart contract.

[0030] Preferably, in this embodiment, vulnerability scanning audit records are divided into vulnerability scanning operation records, vulnerability scanning result records and vulnerability repair records, corresponding to three important links in network security management. They are both different and related, as described below.

[0031] (1) Vulnerability scanning operation records: used to record various operations during the vulnerability scanning process. Vulnerability scanning operation records include scan time, scanning tools, and scanning strategies (scan frequency, scan range, and scan depth). Its purpose is to trace and audit the scanning process. Through these records, you can understand how the scanning task is executed and whether it is carried out in accordance with the established strategy and plan. When problems arise, such as interruption of the scanning task or abnormal scanning results, these records can be used to identify the cause.

[0032] (2) Vulnerability scan result record: used to record vulnerability information found after the vulnerability scan is completed. The vulnerability scan result record includes a vulnerability scan list, which includes the vulnerability name, vulnerability number (CVE number), vulnerability type, vulnerability severity (high risk, medium risk, low risk), vulnerability location (such as specific server, application, etc.) and impact level (hardware / network / application) of each vulnerability scanned. Its purpose is to provide detailed information on the vulnerability so that security personnel can analyze and make decisions. These records are an important basis for the security team to assess the security status of the system, helping them determine which vulnerabilities need to be repaired first and the urgency of the repair.

[0033] (3) Vulnerability repair records: used to record the process of repairing discovered vulnerabilities. Vulnerability repair records include a vulnerability repair list, which includes the vulnerability name, vulnerability number (CVE number), repair measures (such as the name of the update patch, specific steps for modifying the configuration, etc.), verification results after the vulnerability repair, repair time, repair personnel and other information for each vulnerability repaired. Its purpose is to track and manage the progress and quality of vulnerability repairs. By recording the repair process, it can ensure that vulnerabilities are repaired in a timely and effective manner. At the same time, these records can also be used for audits and compliance checks to prove that the organization has taken active repair measures for network security vulnerabilities.

[0034] It's important to note that vulnerability scan operation records form the foundation of vulnerability scan result records. Information such as the scan scope and scan policy in the scan operation record determines the content of the vulnerability scan result. For example, if the scan operation record indicates that the scan scope only includes a subset of servers, the vulnerability scan result record will only include vulnerability information for those servers. Vulnerability scan result records are a prerequisite for vulnerability remediation records. Only accurate vulnerability scan results can provide clear objectives and a basis for remediation efforts. Information such as the vulnerability number and description in the remediation record all originates from the scan result record. For example, if the scan result record indicates that server A has vulnerability X, the remediation record will record this vulnerability. These functions together form a complete vulnerability management process, helping to improve system security and reduce security risks. Specifically, each edge node performs a vulnerability scan operation according to the corresponding vulnerability scan operation record, generating a vulnerability scan result record. Vulnerabilities are then remediated based on the vulnerability scan result record, generating a vulnerability remediation record.

[0035] The specific implementation process of step S2 is described in detail below.

[0036] Step S21: The edge node constructs a transaction proposal based on the vulnerability scan audit record and uploads it to the blockchain network.

[0037] During the specific implementation process, when an edge node obtains a vulnerability scan audit record (vulnerability scan operation record, vulnerability scan result record or vulnerability repair record), the edge node will construct a transaction proposal based on the vulnerability scan audit record. The transaction proposal includes the ID of the target smart contract, the called function name and parameters, and the identity information of the transaction initiator.

[0038] Target Smart Contract ID: The ID of the smart contract to be invoked for vulnerability scanning and auditing. During implementation, a single smart contract can simultaneously process and store all vulnerability scanning and auditing records, providing unified management of various records. Alternatively, a corresponding smart contract can be assigned to vulnerability scanning operation records, vulnerability scanning result records, or vulnerability remediation records. These smart contracts can then process and store the corresponding vulnerability record data, providing specialized management for each record type. Regardless of whether one or three smart contracts are used, these smart contracts all serve as the smart contract for vulnerability scanning and auditing.

[0039] Called function name and parameters: In a blockchain network, called functions implement specific business logic. Specifically, when a new vulnerability scan audit record is received, a function call is triggered to trigger a notification so that the smart contract can execute subsequent operations. Since all called functions are pre-programmed, calling a function only requires declaring the function name and parameters. In this embodiment, the call parameters include the vulnerability scan audit record to be stored (vulnerability scan operation record, vulnerability scan result record, or vulnerability remediation record) and the digital signature generated by the corresponding edge node.

[0040] Transaction initiator identity information: a verifiable identity within the Hyperledger Fabric channel (such as an X.509 certificate).

[0041] During implementation, edge nodes use a hashing algorithm (such as SHA-256) to convert vulnerability scan audit records into a fixed-length data digest and use the data digest as the hash value. This process not only simplifies the data but also ensures its integrity, as any minor modification will result in a significant change in the hash value. To verify the source and integrity of the data, the edge node encrypts the hash value using its own private key to generate a digital signature.

[0042] Upload the transaction proposal to one or more endorsing nodes in the corresponding channel of the blockchain network.

[0043] Step S22: The target smart contract automatically verifies the integrity and compliance of the vulnerability scan audit records in the transaction proposal, and stores the verified vulnerability scan audit records in the target smart contract.

[0044] After receiving the proposal, the endorsing node simulates the execution of the corresponding function in an isolated sandbox environment. The target smart contract undergoes automatic verification operations: edge node identity verification, data integrity verification, and data compliance verification.

[0045] (1) Edge node identity verification and data integrity verification Edge node authentication ensures that data is indeed submitted by the claimed edge node. Data integrity verification ensures that data has not been tampered with during transmission or processing.

[0046] The smart contract extracts the initiator's identity information from the transaction proposal (such as the public key nodePubKey from the certificate). The smart contract uses nodePubKey to decrypt and verify the digital signature in the transaction proposal parameters. The verification object is typically the hash value of the key data (for example, the hash result of operationData + resultData + repairData, called dataHash). The smart contract recalculates this hash value and verifies that it matches the hash value protected by the signature.

[0047] (2) Data compliance verification Through data compliance verification, we ensure that the submitted data content complies with pre-defined business rules and security policies such as standards, format, scope, timeliness, etc., and prevent invalid or malicious data from being uploaded to the chain.

[0048] The smart contract contains a series of predefined verification rule logic to perform compliance verification on vulnerability scanning audit records.

[0049] For example, different checks may be performed depending on the data type.

[0050] For example, the compliance verification of vulnerability scanning operation records (operationData) may include: 1) Scanner identity / version verification: Check whether the scanning tool is an authorized version from a specified list? Does the version number meet the minimum requirements? 2) Timestamp validity: Is the scan operation time within a reasonable current time window (to prevent replaying old scans)? Is it within the scheduled scan period? 3) Target node / range verification: Does the scanned target edge node ID / IP belong to the node itself or the authorized range? 4) Scan Profile / Policy ID Verification: Is the scan policy used valid and authorized? Compliance verification of vulnerability scan result records (resultData) can include: 1) Result format verification: Does the report conform to a predefined standard format (e.g., OWASP ZAP, Nmap XML, OpenVAS, SCAP)? Are key fields present and correctly typed (e.g., vulnerability CVE ID, severity ratings Critical / High / Medium / Low, description, location, etc.)? 2) Vulnerability Existence Verification: Is it possible to simply verify through the internal database (on-chain state or off-chain oracle integration) whether the reported CVE ID actually exists (but it cannot be verified that it actually exists on the target node, which is the responsibility of the scanning behavior itself)? 3) Severity threshold: Does the highest severity reported in the result meet the alarm threshold? 4) Association with operation records: Does the result point to a valid operation record ID (such as ScanID) submitted previously (or at the same time)? Compliance verification of vulnerability repair records (repairData): 1) Correspondence Verification: Does the fix point to a valid scan result record ID (such as VulnID or ResultID) that exists on the chain? 2) Verification of fix timeliness: Is the fix time after the vulnerability report is released and within the specified fix time window (for example, a critical vulnerability must be marked as fixed within X hours)? 3) Remediation Status and Evidence: Is the status provided (e.g., fixed, mitigated, false positive) valid? If evidence is required (e.g., screenshot hash of the patched version number, configuration file change hash), have you provided the corresponding hash value? If the smart contract executes all of the above validation rules without throwing an exception (i.e., all validations pass), the simulated execution is successful. The smart contract may also need to execute other business logic (such as updating state variables). The endorsing peer returns the simulated execution read-write set, a success response, and an endorsement signature based on its own identity to the edge peer that submitted the proposal.

[0051] After collecting a sufficient number of valid endorsement signatures (meeting channel policies, such as majority), the edge node combines these signatures into a complete, signed transaction. This transaction is then submitted to the ordering service. The ordering service sorts the transactions and packages them into a new block. The new block is then distributed to all peer nodes (endorsing nodes) within the channel. After receiving the block, the peer node performs another validity check during the commit phase (including verifying endorsement policies and read-write set dependency conflicts). Only transactions that pass all checks during the commit phase will have their resulting state changes officially recorded in the immutable blockchain ledger. This means that data verified by the smart contract (including vulnerability operation records, results records, and fix records) is permanently and reliably stored.

[0052] Step S23: The audit node in the blockchain network structures the verified vulnerability scanning audit records, generates structured vulnerability scanning data that matches the vulnerability scanning smart contract, and stores it in the blockchain network.

[0053] During the specific implementation, structured processing can be achieved as follows.

[0054] Step S231: Identify the type of scanning tool used in the vulnerability scanning audit record and load an adapted parsing plug-in.

[0055] For example, different edge nodes use different scanning tools (such as Nmap, OpenVAS, Nessus, and proprietary tools), and their output formats vary (XML / JSON / CSV / custom text). Therefore, data normalization is necessary. Audit nodes have a built-in, extensible adapter plugin library, with pre-installed lightweight parsing plugins for each mainstream scanning tool (such as Nmap-Adapter and OpenVAS-Adapter).

[0056] Step S232: Combine the parsing plug-in and the parsing rules to automatically parse the vulnerability scan audit records; and generate intermediate structured data based on the automated parsing results.

[0057] Specifically, automated parsing can be achieved using the following process: The scanning tool type is determined based on report file header features or content patterns (such as specific tags or keywords), and a matching parsing plugin (such as the "Nmap Adapter" or "OpenVAS Parsing Engine") is automatically loaded to parse the scanning tool's scan records within vulnerability scan audit records. For scan records and other content in vulnerability scan audit records, corresponding parsing rules are used for automated parsing. For example, for XML / JSON formats, key fields (target IP address, port number, CVE number, risk level) are extracted using pre-defined path rules (similar to XPath). For text logs, regular expression matching and semantic segmentation techniques are used to locate valid information.

[0058] Afterwards, the scanning information of different scanning tools in the automated analysis results is standardized in field naming and normalized to generate intermediate structured data.

[0059] For example, "risk_level" in different tools is uniformly mapped to "severity" to achieve standardized field naming. "High / Critical" is unified into "Critical" level to achieve data normalization.

[0060] Step S232: Use the predefined vulnerability domain ontology model to perform semantic upgrade on the intermediate structured data, perform data hash calculation on the semantic upgrade result, generate structured vulnerability scanning data that matches the vulnerability scanning smart contract, and store it in the blockchain network.

[0061] During implementation, a predefined vulnerability domain ontology model can be used for semantic upgrades. For example, the vulnerability domain ontology model can include three types of entities: scan operation entities (which define attributes such as timestamp, tool ID, and target node ID), vulnerability entities (which associate CVE numbers, affected components, and severity levels), and remediation entities (which record status (fixed / unresolved), remediation time, and document hash). The entity association rule states that a single scan operation can detect multiple vulnerability entities, and each vulnerability entity can be associated with zero or one remediation entity. The output is a machine-understandable semantic network (RDF triples), such as "Scan_001 → Detected → Vuln_CVE20214428" and "Vuln_CVE20214428 → Affected Component → TCP / 443."

[0062] The semantic data is then grouped by vulnerability entity and hashed (using the SHA-256 algorithm). The hash values ​​are then hashed pairwise, layer by layer, to generate the final Merkle root hash. The original report is uploaded to the IPFS network, obtaining a unique content identifier (CID). The audit node submits a transaction to the smart contract, containing the Merkle root hash (32 bytes), the IPFS content identifier (CID) (46 bytes, variable length), and the audit node's digital signature.

[0063] After the smart contract verifies the audit node's signature, it writes the Merkle root hash and CID to the blockchain ledger. In the event of a dispute, the disputing parties download the original report from IPFS, independently perform structured processing, and locally calculate the Merkle root hash. The smart contract is then called to compare the on-chain value. The consistency result is confirmed through blockchain consensus, enabling authenticity arbitration in a zero-trust environment.

[0064] Step S3: Update the vulnerability scanning strategy based on the node importance of each edge node and the structured vulnerability scanning data.

[0065] Step S31: Define a data query interface in the vulnerability scanning smart contract to extract the structured vulnerability scanning data of each edge node.

[0066] In practice, the vulnerability scanning smart contract supports data retrieval based on criteria such as edge node, vulnerability number, or time range. A connection is established using the blockchain platform's SDK (such as the Hyperledger Fabric Client SDK), and the smart contract's query method is called to retrieve the required structured vulnerability scan data. Finally, the data verification contract is called to compare the on-chain hash with the locally calculated hash value to ensure data integrity and credibility.

[0067] Step S32: Determine the node importance of each edge node.

[0068] Preferably, in this embodiment, the node importance of each edge node is determined in the following manner: according to the network topology diagram, the degree centrality, betweenness centrality and closeness centrality of each edge node are calculated respectively to obtain the importance score of each edge node; according to the importance score of each edge node, the edge nodes are divided into key nodes, important nodes and ordinary nodes.

[0069] Degree centrality is used to measure the number of neighboring edge nodes that an edge node is directly connected to. In an edge node network, nodes with high degrees often play a key role in local communication. Degree centrality Expressed as: (1) in, Represents an edge node The degree of the edge node in the network topology graph The number of connected neighbor edge nodes; Indicates the total number of edge nodes in the network topology graph.

[0070] Betweenness centrality is used to measure the inverse of the average shortest path length from an edge node to all other edge nodes in the network topology. It reflects the "closeness" of the edge node in the network topology. The higher the value, the faster the edge node can communicate with other edge nodes in the network topology. Betweenness centrality Expressed as: (2) in, Represents an edge node To the edge node The shortest path length.

[0071] Betweenness centrality is used to measure the number of times an edge node appears as an intermediate node in all shortest path pairs in a network topology. It reflects the ability of an edge node to control the flow of information in a network topology.

[0072] edge nodes Closeness centrality Expressed as: (3) in, Represents an edge node To the edge node The number of shortest paths, Represents an edge node To the edge node The shortest path passes through the edge node the number of Represents the set of all edge nodes in the network topology. The maximum normalization of the closeness centrality of the edge nodes is performed to obtain the maximum normalization result of the closeness centrality of the corresponding edge nodes.

[0073] edge nodes Importance score Expressed as: (4) in, 、 、 The weight parameters representing degree centrality, closeness centrality, and proximity centrality, respectively, can be determined based on expert experience, historical data, or optimization algorithms; express The maximum normalized result of .

[0074] In the specific implementation process, edge nodes can be classified according to the distribution of their comprehensive scores. For example, the following classification method can be used: edge nodes with comprehensive scores in the top 20% are classified as key nodes; edge nodes with comprehensive scores between the top 20% and 60% are classified as important nodes; and edge nodes with comprehensive scores in the bottom 40% are classified as ordinary nodes.

[0075] Step S33: Update the vulnerability scanning strategy according to the node importance of the edge node and the structured vulnerability scanning data.

[0076] Determine whether there are high-risk vulnerabilities in the structured vulnerability scanning data of key nodes or important nodes that have not been repaired in a timely manner, or whether the number of vulnerabilities shows an increasing trend during each scan. If so, it means that the current vulnerability scanning strategy may not be able to effectively cover the vulnerability detection of these important nodes. It is necessary to update the vulnerability scanning strategy and increase the scanning frequency and depth of these key nodes and important nodes.

[0077] More specifically, vulnerability scanning policies can be updated as follows: For high-importance nodes with high vulnerability exposure, if a high-risk vulnerability was detected in a recent scan and the patch rate is low, scan frequency should be significantly increased (e.g., hourly), scan depth should be increased (including full-port deep scans), and alerts should be triggered if the vulnerability is not promptly patched. For high-importance nodes with low vulnerability exposure, if the vulnerability risk is low (e.g., only a few medium- and low-risk vulnerabilities exist) and the patch rate is high, scan frequency should be maintained (e.g., every 12 hours), but scan depth should be reduced (only scanning for high-risk vulnerabilities) to avoid excessive workload. For low-importance nodes with high vulnerability exposure, if the vulnerability is high (e.g., unpatched high-risk vulnerabilities) and the node is not critical, scan frequency should be increased (e.g., daily). If the node remains unpatched after multiple scans, the node may be isolated or forced offline. For low-importance nodes with low vulnerability exposure, if the node is in good security and of low importance, scan frequency should be reduced (e.g., every three days), with scans limited to simple checks to reduce system resource consumption. At the same time, the strategy is dynamically adjusted based on historical repair time: the scanning frequency of nodes with a repair cycle of <24 hours is reduced by 20%; the scanning frequency of nodes with a repair cycle of >72 hours is increased by 50%; and the scanning intensity is automatically reduced by 30% during peak business hours.

[0078] If the vulnerabilities of most nodes in the network are serious and the vulnerability repair records show major problems with the repair work, such as untimely repairs and ineffective repair measures, then it may be necessary to comprehensively update the vulnerability scanning strategy to improve the comprehensiveness and accuracy of the scan, while strengthening the management and supervision of vulnerability repairs.

[0079] In summary, this embodiment provides a blockchain-based edge node vulnerability scanning and auditing method, which uses blockchain technology to achieve decentralized, secure, reliable, and traceable edge node vulnerability scanning and auditing. At the same time, it can update the vulnerability scanning strategy based on the node importance of the edge node and structured vulnerability scanning data, making the vulnerability scanning strategy more effective.

[0080] Those skilled in the art will appreciate that all or part of the process steps of the above-described embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, such as a magnetic disk, an optical disk, a read-only memory, or a random access memory.

[0081] The above description is only a preferred specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any technician familiar with this technical field within the technical scope disclosed by the present invention should be covered by the scope of protection of the present invention.

Claims

1. A blockchain-based edge node vulnerability scanning and auditing method, characterized in that: The method comprises: Build a blockchain network for vulnerability scanning and auditing, define each edge node as a node in the blockchain network, and deploy vulnerability scanning smart contracts on the blockchain network; Each edge node uploads its own vulnerability scanning audit records to the blockchain network, which are stored as structured vulnerability scanning audit data that matches the vulnerability scanning smart contract. Update vulnerability scanning strategies based on the node importance of each edge node and structured vulnerability scanning data.

2. The edge node vulnerability scanning and auditing method based on blockchain according to claim 1 is characterized in that: When uploading its vulnerability scan audit records to the blockchain network, each edge node performs the following operations: The edge node constructs a transaction proposal based on the vulnerability scan audit records and uploads it to the blockchain network; The target smart contract automatically verifies the integrity and compliance of the vulnerability scan audit records in the transaction proposal and stores the verified vulnerability scan audit records in the target smart contract.

3. The edge node vulnerability scanning and auditing method based on blockchain according to claim 2 is characterized in that: The transaction proposal includes the ID of the target smart contract, the name and parameters of the called function, and the identity information of the transaction initiator; wherein the parameters include the vulnerability scan audit records that need to be stored and the digital signature generated by the corresponding edge node.

4. The edge node vulnerability scanning and auditing method based on blockchain according to claim 3 is characterized in that: The edge node generates a digital signature by performing the following operations: The edge node uses a hash algorithm to convert vulnerability scan audit records into a fixed-length data digest and uses the data digest as the hash value; The edge node uses its own private key to encrypt the hash value and generate a digital signature.

5. The edge node vulnerability scanning and auditing method based on blockchain according to claim 4 is characterized in that: The blockchain network stores vulnerability scan audit records as structured vulnerability scan audit data that matches the vulnerability scan smart contract by performing the following operations: The audit nodes in the blockchain network perform structured processing on the verified vulnerability scanning audit records, generate structured vulnerability scanning data that matches the vulnerability scanning smart contract, and store it in the blockchain network.

6. The edge node vulnerability scanning and auditing method based on blockchain according to claim 5 is characterized in that: Update the vulnerability scanning policy by doing the following: Define a data query interface in the vulnerability scanning smart contract to extract structured vulnerability scanning data for each edge node; Determine the node importance of each edge node; Update vulnerability scanning strategies based on the node importance of edge nodes and structured vulnerability scanning data.

7. The edge node vulnerability scanning and auditing method based on blockchain according to claim 6 is characterized in that: The node importance of each edge node is determined as follows: According to the network topology, the degree centrality, betweenness centrality and closeness centrality of each edge node are calculated to obtain the importance score of each edge node; According to the importance score of each edge node, the edge nodes are divided into key nodes, important nodes and ordinary nodes.

8. The edge node vulnerability scanning and auditing method based on blockchain according to claim 7 is characterized in that: edge nodes Degree centrality Expressed as: (1) in, Represents an edge node The degree of the edge node in the network topology graph The number of connected neighbor edge nodes; Indicates the total number of edge nodes in the network topology graph; edge nodes Betweenness centrality Expressed as: (2) in, Represents an edge node To the edge node The shortest path length; edge nodes Closeness centrality Expressed as: (3) in, Represents an edge node To the edge node The number of shortest paths, Represents an edge node To the edge node The shortest path passes through the edge node the number of Represents the set of all edge nodes in the network topology graph.

9. The edge node vulnerability scanning and auditing method based on blockchain according to claim 8 is characterized in that: edge nodes Importance score Expressed as: (4) in, 、 、 The weight parameters representing degree centrality, closeness centrality, and proximity centrality, respectively, can be determined based on expert experience, historical data, or optimization algorithms; express The maximum normalized result of .

10. The edge node vulnerability scanning and auditing method based on blockchain according to claim 9 is characterized in that: Based on the node importance of edge nodes and structured vulnerability scanning data, update the vulnerability scanning strategy and execute: Determine whether there are high-risk vulnerabilities in the structured vulnerability scanning data of key nodes or important nodes that have not been repaired in a timely manner, or whether the number of vulnerabilities shows an increasing trend during each scan. If so, increase the scanning frequency and depth of the corresponding key nodes and important nodes.

Images