A blockchain-based edge node vulnerability scanning and auditing method

Abstract

The present invention discloses a blockchain-based edge node vulnerability scanning and auditing method, which belongs to the field of vulnerability scanning technology and solves the problems of existing vulnerability scanning methods such as audit records and scanning results being easily tampered with and prone to single point failures. The method includes: constructing a blockchain network for vulnerability scanning and auditing, defining each edge node as a node in the blockchain network, and deploying a vulnerability scanning smart contract on the blockchain network; each edge node uploads its own vulnerability scanning audit record to the blockchain network, storing it as structured vulnerability scanning audit data that matches the vulnerability scanning smart contract; and updating the vulnerability scanning strategy based on the node importance and structured vulnerability scanning data of each edge node. The method uses blockchain technology to achieve decentralized, secure, reliable, and traceable edge node vulnerability scanning and auditing, solving the problems of audit records and scanning results being easily tampered with in the existing technology.

Description

Technical Field

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

[0002] In edge computing environments, edge nodes are more vulnerable to various types of attacks. Strengthening vulnerability scanning and auditing of edge nodes can promptly identify vulnerabilities and effectively prevent attacks, greatly ensuring the security of edge nodes. However, frequent vulnerability scanning alone is not enough to effectively improve the security of edge nodes. Effective vulnerability scanning strategies and timely remediation are far more crucial for enhancing edge node security. Due to the complex and ever-changing network connections and business processes of edge nodes, effective scanning strategies can be analyzed and evaluated based on vulnerability audit records, remediation records, and scan results. By analyzing the rationality of the vulnerability scanning strategy, the compliance of scanning operations with standards, and the timeliness of vulnerability remediation, problems can be identified and system security improved.

[0003] Existing technologies rely on centralized database storage and audit rules, which pose risks of audit log and scan results being tampered with, and are prone to single points of failure. If the centralized database or audit system fails, the entire audit process will be affected. Rule-based auditing methods 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 auditing and risk management. Risk-oriented 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 datasets to identify potential security events and anomaly patterns, helping auditors discover subtle risks and enhancing the depth and breadth of overall audits. However, all these technologies rely on centralized database storage and audit rules, posing risks of audit log and scan results being tampered with, and are prone to single points of failure. Summary of the Invention

[0004] Based on the above analysis, the embodiments of the present invention aim to provide a blockchain-based edge node vulnerability scanning and auditing method to solve the problems of existing vulnerability scanning methods, such as the ease with which audit records and scan results can be tampered with and the potential for single points of failure.

[0005] This invention discloses a blockchain-based edge node vulnerability scanning and auditing method, the method comprising:

[0006] Construct 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;

[0007] Each edge node uploads its own vulnerability scanning audit records to the blockchain network and stores them as structured vulnerability scanning audit data that matches the vulnerability scanning smart contract.

[0008] The vulnerability scanning strategy is updated based on the importance of each edge node and the structured vulnerability scanning data.

[0009] Based on the above solution, the present invention also makes the following improvements:

[0010] Furthermore, during the process of uploading their own vulnerability scan audit records to the blockchain network, each edge node performs the following:

[0011] Edge nodes construct transaction proposals based on vulnerability scan audit records and upload them to the blockchain network;

[0012] The target smart contract automatically verifies the completeness and compliance of the vulnerability scan audit logs in the transaction proposal, and stores the verified vulnerability scan audit logs in the target smart contract.

[0013] Furthermore, the transaction proposal includes the ID of the target smart contract, the name and parameters of the function to be called, 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.

[0014] Furthermore, edge nodes generate digital signatures by performing the following operations:

[0015] Edge nodes use hash algorithms to convert vulnerability scan audit records into fixed-length data digests and use the data digests as hash values.

[0016] Edge nodes use their own private keys to encrypt hash values ​​and generate digital signatures.

[0017] Furthermore, 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:

[0018] The audit nodes in the blockchain network perform structured processing on the verified vulnerability scan audit records to generate structured vulnerability scan data that matches the vulnerability scan smart contract, and then store it in the blockchain network.

[0019] Furthermore, update the vulnerability scanning strategy by performing the following steps:

[0020] Define a data query interface in the vulnerability scanning smart contract to extract structured vulnerability scanning data for each edge node;

[0021] Determine the importance of each edge node;

[0022] Update the vulnerability scanning strategy based on the importance of edge nodes and structured vulnerability scanning data.

[0023] Furthermore, the importance of each edge node is determined as follows:

[0024] Based on the network topology graph, the degree centrality, betweenness centrality, and proximity centrality of each edge node are calculated to obtain the importance score of each edge node.

[0025] Based on the importance score of each edge node, edge nodes are divided into critical nodes, important nodes, and ordinary nodes.

[0026] Furthermore, edge nodes Degree centrality Represented as:

[0027] (1)

[0028] in, Represents edge nodes The degree of an edge node in a network topology graph. The number of connected neighbor edge nodes; This represents the total number of edge nodes in the network topology graph;

[0029] edge nodes proximity centrality Represented as:

[0030] (2)

[0031] in, Represents edge nodes To edge nodes The shortest path length;

[0032] edge nodes betweenness centrality Represented as:

[0033] (3)

[0034] in, Represents edge nodes To edge nodes The number of shortest paths, Represents edge nodes To edge nodes The shortest path passes through edge nodes Quantity, It represents the set of all edge nodes in the network topology graph.

[0035] Furthermore, edge nodes Importance rating Represented as:

[0036] (4)

[0037] in, , , The weight parameters representing degree centrality, proximity centrality, and betweenness centrality can be determined based on expert experience, historical data, or optimization algorithms. express The normalized result of the maximum value.

[0038] Furthermore, based on the importance of edge nodes and structured vulnerability scanning data, the vulnerability scanning strategy is updated and executed:

[0039] Determine whether there are high-risk vulnerabilities in the structured vulnerability scan data of critical or important nodes that have not been patched in a timely manner, or whether the number of vulnerabilities shows an increasing trend in each scan. If so, increase the scanning frequency and depth of the corresponding critical and important nodes.

[0040] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0041] This invention 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 ease with which audit records and scan results can be tampered with, and the risk of single points of failure. The specific technical effects are as follows:

[0042] (1) Preventing audit records and scan results from being tampered with: By storing the vulnerability scan audit records of edge nodes in the blockchain network in the form of structured data, the immutability and traceability of the blockchain are utilized to ensure the authenticity and integrity of each audit record. Combined with the digital signature mechanism, each record is hashed and encrypted with a private key before being uploaded to the chain, ensuring the security of data during transmission and storage and preventing malicious tampering.

[0043] (2) Eliminating single point of failure risk and improving system robustness. Traditional vulnerability scanning systems usually rely on centralized servers for data storage and policy management, which poses a single point of failure risk. This invention avoids the single point of failure problem caused by centralized architecture by constructing a distributed blockchain network, in which each edge node participates in the data storage and consensus process as a blockchain node, thereby improving the availability and fault tolerance of the system.

[0044] (3) To realize an automated and reliable vulnerability scanning audit 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 realizing the automation and intelligence of the vulnerability scanning audit process, reducing human intervention, and improving audit efficiency and credibility.

[0045] (4) Dynamically optimize vulnerability scanning strategies to improve scanning efficiency and accuracy.

[0046] By introducing a node importance assessment mechanism, combined with network topology and historical vulnerability data, key and important nodes are dynamically identified, and the scanning frequency and depth are adjusted accordingly to achieve reasonable resource allocation, improve the efficiency and accuracy of vulnerability discovery, and avoid resource waste.

[0047] (5) Improve system transparency and auditability

[0048] All vulnerability scan audit records are stored on the blockchain, with complete timestamps and immutability, facilitating subsequent auditing and tracing, enhancing the system's transparency and auditability, and meeting compliance requirements.

[0049] In summary, this 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 the risks of vulnerability scans, it can promptly grasp the changing trends of edge node vulnerabilities and adopt more effective vulnerability scanning strategies.

[0050] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0051] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0052] Figure 1 A flowchart of a blockchain-based edge node vulnerability scanning and auditing method provided in an embodiment of the present invention. Detailed Implementation

[0053] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0054] A specific embodiment of the present invention discloses a blockchain-based edge node vulnerability scanning and auditing method, the flowchart of which is shown below. Figure 1 As shown, the method includes the following steps.

[0055] Step S1: 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.

[0056] In this embodiment, a decentralized vulnerability scanning network is constructed by defining each edge node as a node in the blockchain network. Within this network, each edge node possesses independent vulnerability detection capabilities, enabling it to autonomously scan itself or designated targets (such as local devices) and record the corresponding vulnerability scans in the network, forming an immutable distributed ledger to ensure the authenticity and traceability of audit data. Simultaneously, the encryption algorithms and consensus mechanisms of the blockchain network guarantee the security and trustworthiness 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.

[0057] Preferably, in this embodiment, the blockchain network is 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 need to be defined to ensure the security and stability of the blockchain network. For example, in the channel design process, this embodiment introduces dynamic sharding technology, storing audit data in shards across different channels based on the geographical location of edge nodes and network load. Specifically, vulnerability scan results with high security requirements are stored in private channels, while ordinary data is stored in public channels. This design effectively reduces the data processing pressure on the blockchain while improving the scalability of the entire system. For instance, 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 all nodes to view. This embodiment also introduces a consensus mechanism, combining 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 discovery and handling of high-risk vulnerabilities. For ordinary transactions, using the PoS consensus algorithm can reduce energy consumption and improve system efficiency. This hybrid consensus mechanism balances efficiency and security.

[0058] To meet vulnerability scanning and auditing requirements, this embodiment deploys a vulnerability scanning smart contract on Hyperledger Fabric. In the specific implementation process, edge nodes store vulnerability scanning and auditing information into the blockchain network by calling the vulnerability scanning smart contract. During storage, the smart contract automatically verifies the integrity and compliance of the data. Details are as follows.

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

[0060] Preferably, in this embodiment, the vulnerability scanning audit record is divided into vulnerability scanning operation record, vulnerability scanning result record, and vulnerability remediation record, which correspond to three important links in network security management. They are different but related, as explained in detail below.

[0061] (1) Vulnerability Scanning Operation Log: This log records various operations performed during the vulnerability scanning process. It includes scan time, scanning tools, and scanning strategies (scanning frequency, scan range, and scan depth). Its purpose is to trace and audit the scanning process. These records allow us to understand how the scanning task was executed and whether it followed the established strategies and plans. In case of problems, such as scan interruptions or abnormal scan results, these records can be used to investigate the cause.

[0062] (2) Vulnerability Scan Result Records: These records document the vulnerability information discovered after a vulnerability scan is completed. The vulnerability scan result records include a vulnerability list, which includes the vulnerability name, vulnerability number (CVE number), vulnerability type, vulnerability severity (high, medium, low), vulnerability location (e.g., specific server, application), and impact level (hardware / network / application) for each vulnerability detected. The purpose is to provide detailed information about the vulnerabilities so that security personnel can analyze and make decisions. These records are crucial for the security team to assess the system's security status, helping them determine which vulnerabilities require priority remediation and the urgency of remediation.

[0063] (3) Vulnerability Remediation Log: This log records the process of remediating discovered vulnerabilities. The vulnerability remediation log includes a list of vulnerabilities remediated, containing information such as the vulnerability name, vulnerability number (CVE number), remediation measures (e.g., the name of the update patch, specific steps for modifying configurations), verification results after remediation, remediation time, and personnel involved in the remediation. Its purpose is to track and manage the progress and quality of vulnerability remediation. By recording the remediation process, it can be ensured that vulnerabilities are remediated in a timely and effective manner. Simultaneously, these records can also be used for auditing and compliance checks, demonstrating that the organization has taken proactive remediation measures for cybersecurity vulnerabilities.

[0064] It's important to note that vulnerability scanning operation logs are the foundation of vulnerability scanning result records. The scan scope and scanning strategy information in the operation logs determine the content of the vulnerability scan results. For example, if the operation log shows that the scan scope only includes some servers, then the vulnerability scan result record will only contain vulnerability information for those servers. Vulnerability scan result records are a prerequisite for vulnerability remediation records. Only accurate vulnerability scan results can provide clear targets and a basis for remediation work. The vulnerability number, vulnerability description, and other information in the remediation record all originate from the scan result record. For example, if the scan result record shows that server A has vulnerability X, the remediation record will record vulnerability X. Together, they form a complete vulnerability management process, which helps improve system security and reduce security risks. That is, each edge node performs vulnerability scanning operations according to the corresponding vulnerability scanning operation log, obtaining vulnerability scan result records; based on the vulnerability scan result records, vulnerabilities are remediated, generating vulnerability remediation records.

[0065] The specific implementation process of step S2 is explained in detail below.

[0066] Step S21: Edge nodes construct transaction proposals based on vulnerability scan audit records and upload them to the blockchain network.

[0067] In practice, when an edge node obtains vulnerability scanning audit records (vulnerability scanning operation records, vulnerability scanning result records, or vulnerability remediation records), the edge node will construct a transaction proposal based on the vulnerability scanning audit records. The transaction proposal includes the ID of the target smart contract, the name and parameters of the function being called, and the identity information of the transaction initiator.

[0068] The target smart contract ID: The ID of the smart contract to be invoked for vulnerability scanning and auditing. In practice, a single smart contract can be used to process and store all vulnerability scanning and auditing records simultaneously, providing unified management of various records. Alternatively, separate smart contracts can be assigned to vulnerability scanning operation records, vulnerability scanning result records, or vulnerability remediation records. These respective smart contracts process and store the corresponding vulnerability record data, allowing for specialized management of different record data. Regardless of whether one or three smart contracts are used, all of these smart contracts serve as the smart contracts used for vulnerability scanning and auditing.

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

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

[0071] In practice, edge nodes use hash algorithms (such as SHA-256) to convert vulnerability scan audit records into fixed-length data digests, which are then used as hash values. 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 data's origin and integrity, edge nodes encrypt the hash value using their own private keys, generating digital signatures.

[0072] Upload the transaction proposal to one or more endorsing nodes within the appropriate channel of the blockchain network.

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

[0074] After receiving a proposal, the endorsing node will simulate the execution of the corresponding function in an isolated sandbox environment. The target smart contract undergoes the following automated verification operations: edge node identity verification and data integrity verification, and data compliance verification.

[0075] (1) Edge node authentication and data integrity verification

[0076] Edge node authentication ensures that data was indeed submitted by the claimed edge node. Data integrity verification ensures that data has not been tampered with during transmission or processing.

[0077] The smart contract extracts the initiator's identity information from the transaction proposal (such as the public key nodePubKey in 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 key data (e.g., the result of hashing operationData + resultData + repairData, called dataHash). The smart contract recalculates this hash value and verifies that it matches the hash value protected by the signature.

[0078] (2) Data compliance verification

[0079] Data compliance verification ensures that the submitted data conforms to predefined standards, formats, scopes, timeliness, and other business rules and security policies, preventing invalid or malicious data from being uploaded to the blockchain.

[0080] The smart contract contains a series of predefined verification rules and logic to perform compliance verification on the vulnerability scan audit records.

[0081] For example, different checks can be performed based on the data type.

[0082] For example, compliance verification of vulnerability scanning operation data may include:

[0083] 1) Scanner Identity / Version Verification: Check if the scanning tool is an authorized version from the specified list? Does the version number meet the minimum requirements?

[0084] 2) Timestamp validity: Is the scanning operation time within a reasonable current time window (to prevent replaying old scans)? Is it within the scheduled scanning cycle?

[0085] 3) Target Node / Scope Verification: Does the ID / IP of the target edge node being scanned belong to the node itself or to its authorized scope?

[0086] 4) Scan configuration file / policy ID verification: Is the scanning policy used valid and authorized?

[0087] Compliance verification of vulnerability scan result records (resultData) may include:

[0088] 1) Result format verification: Does the report conform to the predefined standard format (such as OWASP ZAP, Nmap XML, OpenVAS, SCAP)? Do the key fields exist and are of the correct type (such as vulnerability CVE ID, severity level Critical / High / Medium / Low, description, location, etc.)?

[0089] 2) Vulnerability Existence Verification: Simply verify the existence of the reported CVE ID through an internal database (on-chain state or off-chain oracle integration) (but cannot verify whether it actually exists on the target node, which is the responsibility of the scanning behavior itself).

[0090] 3) Severity threshold: Does the highest severity reported in the results meet the alarm threshold?

[0091] 4) Relevance to operation record: Does the result point to a valid operation record ID (such as ScanID) that was submitted previously (or simultaneously)?

[0092] Compliance verification of vulnerability remediation records (repairData):

[0093] 1) Correspondence verification: Fix whether it points to a valid scan result record ID (such as VulnID or ResultID) that exists on the chain.

[0094] 2) Timeliness verification of remediation: Is the remediation time after the vulnerability report and within the specified remediation time window (e.g., a critical vulnerability must be marked for remediation within X hours)?

[0095] 3) Repair Status and Evidence: Is the provided status (e.g., fixed, mitigated, false positive) valid? If evidence is required (e.g., screenshot hash of patch version number, hash of configuration file change), have the corresponding hash values ​​been provided?

[0096] If the smart contract does not throw an exception after executing all the above verification rules (i.e., all verifications pass), the mock execution is successful. The smart contract may also need to execute other business logic (such as updating state variables). The endorsing node returns the mock read-write set, the success response, and an endorsement signature based on its own identity to the edge node that submitted the proposal.

[0097] Once edge nodes collect a sufficient number of valid endorsement signatures (satisfying channel policies such as majority), they combine these signatures into a complete, signed transaction. This transaction is then submitted to the Ordering Service. The Ordering Service orders the transactions and packages them into a new block. The new block is distributed to all peer nodes (i.e., endorsement nodes) within the channel. Upon receiving the block, the peer nodes perform another validity check during the commit phase (including verifying the endorsement policy, read-write set dependency conflicts, etc.). Only transactions that pass all checks during the commit phase will have their resulting state changes officially written to the immutable blockchain ledger. This means that data verified by the smart contract (vulnerability operation records, result records, and fix records) is permanently and reliably stored.

[0098] Step S23: The audit nodes in the blockchain network perform structured processing on the verified vulnerability scan audit records to generate structured vulnerability scan data that matches the vulnerability scan smart contract, and store it in the blockchain network.

[0099] In the specific implementation process, structured processing can be achieved in the following manner.

[0100] Step S231: Identify the type of scanning tool used in the vulnerability scan audit log and load the appropriate parsing plugin.

[0101] For example, different edge nodes use different scanning tools (such as Nmap, OpenVAS, Nessus, and proprietary tools), and their output formats are inconsistent (XML / JSON / CSV / custom text). Therefore, data normalization is necessary. The audit node has a built-in extensible adapter plugin library that provides lightweight parsing plugins (such as Nmap-Adapter and OpenVAS-Adapter) for each mainstream scanning tool.

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

[0103] Specifically, automated parsing can be achieved through the following process: The scanning tool type is determined based on the report file header characteristics or content patterns (such as specific tags or keywords). Matching parsing plugins (such as "Nmap adapter" or "OpenVAS parsing engine") are automatically loaded to parse the scanning records of the scanning tool in the vulnerability scan audit log. For other content in the scan records and vulnerability scan audit logs, appropriate parsing rules are selected for automated parsing. For example, for XML / JSON formats, key fields (target IP, port, 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.

[0104] Subsequently, the scanning information from different scanning tools in the automated parsing results is standardized by field naming and normalization to generate intermediate structured data.

[0105] For example, the "risk_level" in different tools can be uniformly mapped to "severity" to achieve standardized field naming. "High / Critical" can be unified as "Critical" to achieve data normalization.

[0106] Step S232: Use a predefined vulnerability domain ontology model to perform semantic upgrades on the intermediate structured data. After performing data hash calculations on the semantic upgrade results, generate structured vulnerability scanning data that matches the vulnerability scanning smart contract and store it in the blockchain network.

[0107] In practical 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 (defining attributes such as timestamp, tool ID, and target node ID), Vulnerability entities (associated with CVE number, affected components, severity level, etc.), and Remediation entities (recording status (remediated / unremediated), remediation time, and proof document hash). The entity association rule is 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 triple), such as: "Scan_001 → detected → Vuln_CVE20214428", "Vuln_CVE20214428 → affected component → TCP / 443".

[0108] Next, the semantic data is grouped by vulnerability entity and hashed (SHA-256 algorithm). Using the hash value as the leaf node, the final Merkle root hash value is generated by pairwise hashing layer by layer. The original report is uploaded to the IPFS network to obtain a unique content identifier (CID). The audit node submits a transaction to the smart contract, including: the Merkle root hash value (32 bytes), the IPFS content identifier CID (46-byte variable length), and the audit node's digital signature.

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

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

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

[0112] In practice, the vulnerability scanning smart contract supports retrieving data 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 invoked to obtain the required structured vulnerability scanning data. Finally, the data verification contract is invoked to compare the on-chain hash with the locally calculated hash value, ensuring the integrity and credibility of the data.

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

[0114] Preferably, in this embodiment, the importance of each edge node is determined as follows: based on the network topology, the degree centrality, betweenness centrality, and proximity centrality of each edge node are calculated to obtain the importance score of each edge node; based on the importance score of each edge node, the edge nodes are divided into critical nodes, important nodes, and ordinary nodes.

[0115] Degree centrality measures the number of directly connected neighboring edge nodes of an edge node. In edge node networks, nodes with high degree often play a crucial role in local communication. Degree centrality Represented as:

[0116] (1)

[0117] in, Represents edge nodes The degree of an edge node in a network topology graph. The number of connected neighbor edge nodes; This represents the total number of edge nodes in the network topology graph.

[0118] Proximity centrality measures the reciprocal of the average shortest path length from an edge node to all other edge nodes in a network topology. It reflects how "close" an edge node is to other edge nodes in the network topology; a higher value indicates that the edge node can communicate with other edge nodes more quickly. Edge node proximity centrality Represented as:

[0119] (2)

[0120] in, Represents edge nodes To edge nodes The shortest path length.

[0121] Betweenness centrality measures 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 the network topology.

[0122] edge nodes betweenness centrality Represented as:

[0123] (3)

[0124] in, Represents edge nodes To edge nodes The number of shortest paths, Represents edge nodes To edge nodes The shortest path passes through edge nodes Quantity, This represents the set of all edge nodes in the network topology graph. The betweenness centrality of the edge nodes is normalized to its maximum value to obtain the normalized result of the betweenness centrality of the corresponding edge nodes.

[0125] edge nodes Importance rating Represented as:

[0126] (4)

[0127] in, , , The weight parameters representing degree centrality, proximity centrality, and betweenness centrality can be determined based on expert experience, historical data, or optimization algorithms. express The normalized result of the maximum value.

[0128] In practice, edge nodes can be classified according to the distribution of their overall scores. For example, the following classification method can be used: edge nodes with the highest overall scores in the top 20% are designated as critical nodes; edge nodes with overall scores between the top 20% and 60% are designated as important nodes; and edge nodes with the lowest overall scores in the bottom 40% are designated as ordinary nodes.

[0129] Step S33: Update the vulnerability scanning strategy based on the importance of edge nodes and structured vulnerability scanning data.

[0130] Determine if there are high-risk vulnerabilities in the structured vulnerability scan data of critical or important nodes that have not been patched in a timely manner, or if the number of vulnerabilities shows an increasing trend in each scan. If so, it indicates that the current vulnerability scanning strategy may not be effectively covering the vulnerability detection of these important nodes, and the vulnerability scanning strategy needs to be updated to increase the scanning frequency and depth of these critical and important nodes.

[0131] More specifically, vulnerability scanning strategies can be updated as follows: For high-importance nodes with high vulnerability exposure, if a high-risk vulnerability is detected in a recent scan and the remediation rate is low, significantly increase the scanning frequency (e.g., scan once per hour), increase the scan depth (including full port deep scans), and trigger an alarm mechanism if the vulnerability is not remediated in a timely manner. For high-importance nodes with low vulnerability exposure, if the node has a low vulnerability risk (e.g., only a few low-to-medium risk vulnerabilities) and a high remediation rate, maintain a high-frequency scan (e.g., once every 12 hours), but reduce the scan depth (scan only for high-risk vulnerabilities) to avoid putting excessive pressure on business load. For low-importance nodes with high vulnerability exposure, if the node has many vulnerabilities (e.g., unremediated high-risk vulnerabilities) and is not of high importance, increase the scanning frequency (e.g., once per day). If the vulnerability is not remediated after multiple scans, the node can be isolated or forcibly taken offline. For low-importance nodes with low vulnerability exposure, if the node has a good security status and is of low importance, reduce the scanning frequency (e.g., once every three days), and perform only simple checks to reduce system resource consumption. Simultaneously, the strategy is dynamically adjusted based on historical repair time: nodes with a repair cycle of <24 hours have their scan frequency reduced by 20%; nodes with a repair cycle of >72 hours have their scan frequency increased by 50%; and the scan intensity is automatically reduced by 30% during peak business hours.

[0132] If most nodes in the network have serious vulnerabilities, and the vulnerability remediation records show significant problems with the remediation work, such as untimely remediation or ineffective remediation measures, then it may be necessary to comprehensively update the vulnerability scanning strategy, improve the comprehensiveness and accuracy of the scan, and strengthen the management and supervision of vulnerability remediation.

[0133] In summary, this embodiment provides a blockchain-based edge node vulnerability scanning and auditing method. This method utilizes 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 importance of the edge node and structured vulnerability scanning data, making the vulnerability scanning strategy more effective.

[0134] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0135] The above description is only a preferred 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 conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within 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 includes: Construct 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 and stores them as structured vulnerability scanning audit data that matches the vulnerability scanning smart contract. Update the vulnerability scanning strategy based on the importance of each edge node and the structured vulnerability scanning data; The importance of each edge node is determined as follows: Based on the network topology graph, the degree centrality, betweenness centrality, and proximity centrality of each edge node are calculated to obtain the importance score of each edge node. Based on the importance score of each edge node, the edge nodes are divided into critical nodes, important nodes, and ordinary nodes; edge nodes Importance rating Represented as: (1) in, , , These represent the weight parameters for degree centrality, proximity centrality, and betweenness centrality, respectively. express The normalized result of the maximum value; , , Representing edge nodes respectively Degree centrality, proximity centrality, and betweenness centrality; Based on the 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 scan data of critical or important nodes that have not been patched in a timely manner, or whether the number of vulnerabilities shows an increasing trend in each scan. If so, increase the scanning frequency and depth of the corresponding critical and important nodes.

2. The blockchain-based edge node vulnerability scanning and auditing method according to claim 1, characterized in that, During the process of uploading their vulnerability scan audit records to the blockchain network, each edge node performs the following: Edge nodes construct transaction proposals based on vulnerability scan audit records and upload them to the blockchain network; The target smart contract automatically verifies the completeness and compliance of the vulnerability scan audit logs in the transaction proposal, and stores the verified vulnerability scan audit logs in the target smart contract.

3. The blockchain-based edge node vulnerability scanning and auditing method according to claim 2, characterized in that, The transaction proposal includes the ID of the target smart contract, the name and parameters of the function to be called, 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 blockchain-based edge node vulnerability scanning and auditing method according to claim 3, characterized in that, Edge nodes generate digital signatures by performing the following operations: Edge nodes use hash algorithms to convert vulnerability scan audit records into fixed-length data digests and use the data digests as hash values. Edge nodes use their own private keys to encrypt hash values ​​and generate digital signatures.

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

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

7. The blockchain-based edge node vulnerability scanning and auditing method according to claim 6, characterized in that, edge nodes Degree centrality Represented as: (2) in, Represents edge nodes The degree of an edge node in a network topology graph. The number of connected neighbor edge nodes; This represents the total number of edge nodes in the network topology graph; edge nodes proximity centrality Represented as: (3) in, Represents edge nodes To edge nodes The shortest path length; edge nodes betweenness centrality Represented as: (4) in, Represents edge nodes To edge nodes The number of shortest paths, Represents edge nodes To edge nodes The shortest path passes through edge nodes Quantity, It represents the set of all edge nodes in the network topology graph.

Images