A method, device and equipment for processing an audit task of a network security compliance file

Abstract

The application provides a network security compliance file audit task processing method, device and equipment, the method comprises the following steps: obtaining file data and blood relationship metadata; the hash value of the file data is stored in the chain for evidence, and a storage sequence number is obtained; according to the storage sequence number, the node of the file blood relationship graph is determined; according to the blood relationship metadata, the directed edge between the nodes is determined; according to the node and the directed edge, the file blood relationship graph is obtained; the change condition is listened to, the file hash change event is obtained, the storage sequence number list of the downstream network security compliance file is obtained by calling the file blood relationship graph for influence range analysis according to the storage sequence number; according to the storage sequence number list, a re-audit task is generated, distributed and stored in the chain for evidence; through the compliance rule intelligent contract engine, the downstream network security compliance file is verified, the audit result is generated, and the audit result is stored in the chain for evidence. The scheme realizes the association of the compliance file, and can automatically identify the influence of file change.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method, apparatus and equipment for processing audit tasks of network security compliance documents. Background Technology

[0002] With the deepening implementation of cybersecurity regulations, enterprises need to retain a large number of cybersecurity compliance documents as key evidence of compliance for regulatory inspection. Currently, the industry's auditing technologies for compliance documents mainly consist of centralized document management systems and blockchain-based data storage solutions. However, both of these methods have significant technical shortcomings in practical applications: existing blockchain storage only hashes and uploads individual files to the chain to prevent tampering, failing to establish logical relationships between related compliance documents. This makes the evidence chain for compliance audits prone to breakage, and after core documents are changed, it is impossible to automatically identify downstream related documents affected by them, making it difficult to achieve full-chain audit traceability. At the same time, existing auditing technologies can only verify whether a file has been tampered with through hash comparison, lacking the ability to verify the compliance of the file content, and also failing to achieve penetrating query of compliance documents from indicators to original documents. Ultimately, this makes the regulatory audit process overly reliant on manual operation, resulting in low audit efficiency and failing to meet the complex auditing needs of cybersecurity compliance documents. Summary of the Invention

[0003] This invention provides a method, apparatus, and device for processing audit tasks of network security compliance documents, which solves the problems of isolated compliance documents, difficulty in identifying the impact of changes, and poor content compliance verification.

[0004] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: This invention provides a method for processing audit tasks of network security compliance documents, including: Obtain the file data and metadata related to the lineage of network security compliance documents; The hash value obtained after hashing the file data is uploaded to the blockchain evidence storage network to complete the evidence storage and obtain the evidence storage serial number of the network security compliance document. Based on the evidence serial number, determine the nodes of the file lineage map; Based on the aforementioned bloodline metadata, directed edges between nodes are determined; Based on the nodes and the directed edges, a file lineage graph is obtained; Monitor changes to the blockchain evidence storage network and file lineage graph to obtain file hash change events; When a file hash change event is detected, the file lineage graph is called based on the evidence serial number to analyze the scope of impact and obtain a list of evidence serial numbers corresponding to the affected downstream network security compliance files. Based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, a re-audit task is generated and distributed, and the information of the re-audit task is stored on the blockchain. By using a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, the downstream cybersecurity compliance documents that have undergone re-audit processing are verified, audit results are generated, and the audit results are stored on the blockchain.

[0005] Optionally, obtain the file data and lineage metadata of the cybersecurity compliance documents, including: Receive the raw cybersecurity compliance documents to be processed and parse them to obtain the document data; The lineage metadata corresponding to the file data of the network security compliance documents is automatically generated according to the preset business process, or the lineage metadata is customized by manual means; the lineage metadata includes the association identifier and relationship type between the file data.

[0006] Optionally, the hash value obtained after hashing the file data is uploaded to the blockchain evidence storage network to complete the evidence storage, and an evidence storage serial number for the network security compliance document is obtained, including: Perform a hash calculation on the file data to obtain the file hash value; The file hash value is uploaded to the blockchain evidence storage network for consensus-based evidence storage, and an evidence storage sequence number is assigned and returned.

[0007] Optionally, based on the evidence storage serial number, the nodes of the document lineage map are determined, including: Based on the certificate serial number, check whether the corresponding node already exists in the file lineage map to obtain the query results; Based on the query results, the nodes of the file lineage map are obtained.

[0008] Optionally, when a file hash change event is detected, the file lineage graph is invoked based on the evidence storage serial number to perform an impact scope analysis, obtaining a list of evidence storage serial numbers corresponding to the affected downstream cybersecurity compliance documents, including: When a file hash change event is detected, start from the corresponding node of the file where the file hash change event occurred and traverse all downstream nodes in the file lineage graph that are directly or indirectly dependent on the corresponding node. The evidence storage serial numbers corresponding to the downstream nodes are summarized to obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance documents.

[0009] Optionally, based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, a re-audit task is generated and distributed, and the information of the re-audit task is stored on the blockchain, including: Based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, a re-audit task is generated. The task sequence number, associated evidence storage sequence number, responsible person, deadline, and task status of the re-audit task are hashed and then uploaded to the blockchain evidence storage network to complete the evidence storage.

[0010] Optionally, a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network verifies downstream cybersecurity compliance documents that have undergone re-audit processing, generates audit results, and stores the audit results on the blockchain for evidence storage, including: The key fields of the downstream cybersecurity compliance documents that have been re-audited are analyzed by the compliance rule smart contract engine, and the key fields are compared with the preset compliance clauses to obtain the content-level compliance verification results. Based on the association identifier of the blood relationship metadata, key fields of upstream and downstream related files of the downstream network security compliance file are retrieved to verify the logical consistency between files and obtain cross-file verification results. Based on the content-level compliance verification results and cross-document cross-verification results, an audit result is generated, and the audit result is hashed and uploaded to the blockchain evidence storage network to complete the evidence storage.

[0011] This invention also provides an audit task processing device for network security compliance documents, comprising: The acquisition module is used to acquire file data and metadata related to the lineage of network security compliance documents. The processing module is used to: hash the file data and upload the resulting hash value to the blockchain evidence storage network to complete the evidence storage, obtaining the evidence storage serial number of the network security compliance file; determine the nodes of the file lineage graph based on the evidence storage serial number; determine the directed edges between nodes based on the lineage relationship metadata; obtain the file lineage graph based on the nodes and the directed edges; monitor changes in the blockchain evidence storage network and the file lineage graph to obtain file hash change events; when a file hash change event is detected, perform an impact range analysis on the file lineage graph based on the evidence storage serial number to obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance files; generate a re-audit task based on the downstream network security compliance files corresponding to the evidence storage serial number list, distribute the task, and upload the information of the re-audit task to the blockchain for evidence storage; The generation module is used to verify the downstream cybersecurity compliance documents that have been re-audited through a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, generate audit results, and store the audit results on the blockchain.

[0012] This invention also provides a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when run by the processor, executes the above-described method.

[0013] This invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described method.

[0014] The technical solution of the present invention has at least the following effects: The above-mentioned solution of the present invention obtains the file data and lineage metadata of network security compliance documents; uploads the hash value obtained by hashing the file data to the blockchain evidence storage network to complete the evidence storage, and obtains the evidence storage serial number of the network security compliance document; determines the nodes of the file lineage graph based on the evidence storage serial number; determines the directed edges between the nodes based on the lineage metadata; obtains the file lineage graph based on the nodes and the directed edges; monitors changes in the blockchain evidence storage network and the file lineage graph to obtain file hash change events; when a file hash change event is detected, the file lineage graph is called to perform an impact range analysis based on the evidence storage serial number to obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance documents; generates a re-audit task based on the downstream network security compliance documents corresponding to the evidence storage serial number list, distributes it, and puts the information of the re-audit task on the blockchain for evidence storage; verifies the downstream network security compliance documents processed by the re-audit task through a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, generates an audit result, and puts the audit result on the blockchain for evidence storage. By constructing graphs, analyzing the scope of impact, and performing dual verification, the association of compliance documents can be achieved, enabling automated identification of the impact of changes and achieving smooth and reliable processing of content compliance verification. Attached Figure Description

[0015] Figure 1 This is a flowchart of the network security compliance document audit task processing method provided in this embodiment of the invention; Figure 2 This is a data interaction diagram of the network security compliance document audit task processing method provided in this embodiment of the invention; Figure 3 This is a structural diagram of the network security compliance document audit task processing device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of the computing device provided in an embodiment of the present invention. Detailed Implementation

[0016] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0017] like Figure 1 As shown, an embodiment of the present invention proposes a method for processing audit tasks of network security compliance documents, including: Step 11: Obtain the file data and metadata of the lineage of the network security compliance documents; Step 12: After performing a hash calculation on the file data, upload the hash value obtained to the blockchain evidence storage network to complete the evidence storage and obtain the evidence storage serial number of the network security compliance document; Step 13: Determine the nodes of the file lineage map based on the evidence serial number; Step 14: Determine the directed edges between nodes based on the blood relationship metadata; Step 15: Obtain the file lineage graph based on the nodes and the directed edges; Step 16: Monitor changes in the blockchain evidence storage network and file lineage graph to obtain file hash change events; Step 17: When a file hash change event is detected, the file lineage graph is called based on the evidence serial number to analyze the scope of impact and obtain a list of evidence serial numbers corresponding to the affected downstream network security compliance files. Step 18: Generate a re-audit task based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, distribute the task, and store the information of the re-audit task on the blockchain. Step 19: The downstream cybersecurity compliance documents that have been re-audited are verified by a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, an audit result is generated, and the audit result is stored on the blockchain.

[0018] In this embodiment, the technical solution determines the file lineage map based on the evidence serial number and the lineage metadata. On the basis of using blockchain to ensure the reliable evidence storage of files, it can also build an intelligent audit system that enables the lineage association between files, automatically tracks the impact of changes, and supports content-level compliance verification. This realizes that the association of compliant files is traceable, changes are perceptible, compliance is verifiable, and auditing is supervised, which significantly improves the intelligence level and credibility of the audit task processing of network security compliance files.

[0019] In an optional embodiment of the present invention, step 11, obtaining the file data and lineage metadata of the network security compliance document, may include: Step 111: Receive and parse the original network security compliance documents to be processed to obtain file data; the original network security compliance documents include vulnerability scanning reports, security remediation contact forms, retest verification reports, graded protection assessment reports, and vulnerability patch installation records, etc.

[0020] Step 112: Automatically generate lineage metadata corresponding to the file data of network security compliance documents according to the preset business process, or manually create lineage metadata; the lineage metadata includes the association identifier and relationship type between file data.

[0021] In this embodiment, the client receives the uploaded original network security compliance file and obtains the lineage metadata corresponding to the file data of the network security compliance file through automatic or manual modes. This ensures that the established lineage can fully cover the relationships between files and avoids data fragmentation or inappropriate establishment of lineage.

[0022] In step 111, the original file is obtained by providing a multi-terminal, multi-protocol receiving entry through the compliance document processing client. After preprocessing the original network security compliance file to be processed, such as encoding alignment, data cleaning, word segmentation, semantic noise reduction, and virus scanning, the key fields of the file are structured and the file content is extracted in the form of regular expressions to obtain the file data. This solves the problem of data fragmentation caused by inconsistent formats, prevents malicious files from causing damage to the system, realizes the automatic and accurate extraction of key fields, and makes the file data easy to identify and process.

[0023] In step 112, the relationships between files are defined through both automatic and manual methods, generating standardized lineage metadata. This addresses the issues of logical connections between files and broken chains of evidence in traditional auditing. The association identifier uniquely points to another related compliance document and is essentially a certificate serial number. For example, if file A is uploaded, its certificate serial number is 12345; if file B is an associated file of file A, then file B's association identifier is 12345. A single compliance document can have multiple association identifiers. The relationship type is a system-predefined type and can be set according to requirements, such as the following four: derived from, version inherited from, referenced, and verified. All automatically / manually generated metadata follows the same template to ensure data format consistency.

[0024] Based on preset compliance business processes, the system automatically matches business process rules according to the current file type and upstream triggering events to generate lineage metadata. The specific implementation process includes: (1) Pre-configure multiple core network security compliance business process rules (such as vulnerability rectification process, security level assessment process and security self-inspection process). The rules are defined in the form of IF trigger condition THEN association rule, for example: IF current file type = rectification contact form AND trigger event = vulnerability report rectification application THEN association identifier = vulnerability report evidence serial number AND relationship type = derived from; (2) When the user uploads / the system pushes a file, the corresponding rule is triggered according to the file type and operation behavior (such as clicking the "initiate rectification" button), and the evidence serial number of the upstream file is automatically retrieved from the system database / blockchain as the association identifier, and automatically filled into the lineage relationship metadata template to generate lineage relationship metadata; (3) The automatically generated metadata does not require manual intervention and is directly bound to the temporary identifier of the current file.

[0025] For document association requirements in non-standard business processes, the system provides a visual manual association interface, supporting users to drag and drop to customize and establish association relationships. The specific implementation process includes: (1) View the basic information of the currently uploaded file on the client interface, click the "Custom Association" button, and the interface loads the list of compliant files that have been registered / to be registered by the enterprise (including file name, file type, and registration serial number); (2) The user can associate the current file with the target file in the list by dragging and dropping, select the predefined relationship type, and the system will automatically fill the metadata template with the registration serial number of the target file as the association identifier; (3) The metadata created manually needs to be verified (such as avoiding circular association: file A is derived from file B, and file B is derived from file A). After the verification is passed, the final lineage metadata is generated and bound to the current file data.

[0026] In an optional embodiment of the present invention, step 12, which involves uploading the hash value obtained after hashing the file data to a blockchain evidence storage network to complete the evidence storage and obtain the evidence storage serial number of the network security compliance document, may include: Step 121: Perform a hash calculation on the file data to obtain the file hash value; Step 122: Upload the file hash value to the blockchain evidence storage network for consensus evidence storage, and allocate and return the evidence storage sequence number.

[0027] In this embodiment, in step 121, the file data is serialized and concatenated to form the original data block for hash calculation, represented as follows: ;in, Represents the original data block; Represents the standard sequence function; Indicates the file type of the current cybersecurity compliance document; A collection representing key fields; This represents the complete file content; Represents a timestamp; This indicates the identifier of the entity that uploaded the file.

[0028] The original data block is processed using a hash algorithm to generate a fixed 256-bit (32-byte) hash value, represented as follows: Where Hash represents the file hash value; Indicates the encryption algorithm; This represents the original data block; any change to the file content will result in a complete change to the hash value. The binary hash result is converted into a 64-bit hexadecimal string, which serves as the file's unique content credential on the blockchain. This can be understood as the final hash, for example: This step transforms the file content into a unique and fixed-length hash value, achieving an intact representation of the file content. This compresses the file size, making it more suitable for on-chain storage and reducing the storage pressure on the blockchain. Furthermore, the resulting hexadecimal string ensures that the file content cannot be forged or tampered with.

[0029] In step 122, the file hash value, file type, file name, generation time, upload entity identifier, and business transaction number are encapsulated into a single notarization transaction. This transaction is then sent to the ledger node of the blockchain notarization network via a data interface, where it is broadcast among all nodes in the network awaiting further packaging. Specifically, this is represented as follows: ,in, This indicates that the notarized transaction will be broadcast from the access node to the entire blockchain network; T represents the current notarized transaction; This represents the i-th node; This represents the entire set of nodes in the blockchain network; after broadcasting, all nodes cache the transaction and enter the queue to be packaged.

[0030] The blockchain network subsequently verifies the legality of transactions, primarily including: verifying signature validity, verifying hash format correctness, and verifying whether the file has been repeatedly uploaded to the chain, represented as... ,in, This indicates verification of the transaction's legality; Indicates transaction signature verification; Indicates hash format verification; This indicates repeated on-chain verification; Represents the logical AND operation.

[0031] The specific process of verifying the legality of a transaction is represented as follows: This verifies whether the transaction signature was generated by a legitimate node's private key, preventing transaction forgery; among other things, This indicates transaction signature verification; T represents the current notarized transaction. Represents the signature operation function; This represents the private key of the entity uploading the file; This represents the business data in the current evidence storage transaction; This indicates the signature for the current evidence-based transaction.

[0032] The specific process of hash format verification is as follows: This ensures that the file hash is a valid 64-bit hexadecimal string; where, This indicates hash format verification; T represents the current evidence-based transaction. A function to retrieve the length of the file's hash string; This indicates whether the length of the file hash string is equal to 64 bits; This function checks whether the hash is a valid hexadecimal string; hash represents the file hash value.

[0033] The specific process of repeated on-chain verification is represented as follows: This is used to check if the same file hash already exists on the chain, avoiding duplicate notarization; among them, This indicates repeated on-chain verification; T represents the current notarized transaction. Represents the logical NOT operator; It is a logical existential quantifier, indicating that at least one exists; This indicates a historically documented transaction that already exists in the blockchain. This represents the dataset of on-chain blocks in a blockchain-based evidence storage network; This represents the on-chain hash value stored in historical evidence-based transactions; This represents the file hash value.

[0034] Once all verifications pass, the file hash value is packaged into a new block and written to disk. The blockchain assigns a global notarization sequence number to this notarization, represented as... ,in, Indicates the certificate serial number, for example: Once the data is uploaded to the blockchain, the blockchain node returns a receipt including the evidence storage sequence number, block height, upload timestamp, and transaction hash. The evidence storage sequence number is required data for many subsequent operations.

[0035] In an optional embodiment of the present invention, step 13, determining the nodes of the document lineage map based on the evidence serial number, may include: Step 131: Based on the evidence serial number, query the file lineage map to see if the corresponding node already exists, and obtain the query result; Step 132: Based on the query results, determine the nodes of the file lineage map.

[0036] In this embodiment, in step 131, each compliant document is mapped to a node in the lineage graph, with the certificate serial number serving as the unique identifier for each node. This enables node creation and version updates, ensuring a one-to-one correspondence between nodes and documents and synchronized information. Each node encapsulates the core key information of the file, forming a standardized node structure, specifically represented as follows: ,in, Represents a node structure; Indicates the certificate serial number; Indicates the file type of the current cybersecurity compliance document; Represents the file hash value; Represents a timestamp; Indicates the identifier of the entity that uploaded the file; Indicates the node status, including normal, changing, and pending audit.

[0037] The presence / absence of a node is determined by querying its certificate serial number to check if it already exists in the graph. The specific logic formula for this determination is as follows: ;in, This indicates the creation of a new node, inserting the encapsulated node information into the lineage graph, and assigning node coordinates. This indicates updating an existing node, specifically updating the Hash. , Variable information such as the certificate serial number are retained unchanged.

[0038] In step 132, if the query result is non-existent, the node is created; otherwise, the node is updated, thus obtaining the complete file lineage graph nodes. A unique mapping from file to node is achieved through the storage serial number, avoiding node confusion caused by duplicate file names or version updates, thereby ensuring the uniqueness of graph nodes. The creation or update determination logic enables dynamic synchronization of file versions, retaining old version nodes and updating new version nodes, ensuring the traceability of file version links.

[0039] In an optional embodiment of the present invention, step 14, determining the directed edges between nodes based on the blood relation metadata, may include: Step 141: Query and locate the upstream related nodes based on the association identifier in the blood relationship metadata; Step 142: Based on the upstream associated nodes, determine whether there is a duplicate directed edge between the current node and the upstream associated nodes, and obtain the determination result; Step 143: Based on the determination result, determine the directed edges between nodes.

[0040] In this embodiment, in step 141, a directed edge is established between the current node and the associated node based on the association identifier and relationship type in the blood relationship metadata, thereby clarifying the association direction and relationship attributes between files and realizing the logical association between nodes. Specifically, this includes: Extract the association identifier (i.e., the provenance sequence number of the upstream file) from the kinship metadata, query the graph nodes using the association identifier, and locate the associated upstream node. The location logic is as follows: ;in, Indicates the upstream node; For node query functions; This indicates the association identifier; if no associated node is found, the association is temporarily stored and the directed edge is automatically completed after the associated node is created. The directed edge encapsulates the core information of the association through a standardized structure, represented as... ;in, Represents a directed edge structure; This represents a unique identifier for a directed edge; Indicates the source node identifier; Indicates the target node identifier; Indicates the relation type; This represents the timestamp of a directed edge.

[0041] In steps 142 and 143, the existence of duplicate directed edges is determined using the directed edge structure. The specific logic for this determination is as follows: ;in, This indicates the creation of a new directed edge, with the direction of the edge defined according to the relation type; This indicates updating existing directed edges, only updating... Variable information, etc., are retained. The target node and relationship type remain unchanged to ensure the stability of the association. That is, if there is no directed edge between two nodes, a new directed edge is created; if there is a directed edge between them, the directed edge attributes are updated.

[0042] By locating associated nodes through association identifiers, the current node can be accurately associated with the upstream file node, ensuring the accuracy of directed edges. At the same time, the directed edges carry the relationship type, clarifying the association logic between files, giving the graph a clear business logic. It also supports the pre-storage of relationships when associated nodes have not been created, so as to realize the dynamic completion of the graph, ensuring that no file association relationship is missed and forming a complete logical link.

[0043] In an optional embodiment of the present invention, step 15, obtaining the file lineage graph based on the nodes and the directed edges, may include: Step 151: Integrate the nodes and the directed edges to obtain the original file lineage graph; Step 152: Render the original file lineage map to obtain the file lineage map.

[0044] In this embodiment, in step 151, a complete file lineage graph is formed by creating directed edges for integration, and the graph is simultaneously verified and synchronized. Specifically, this includes: integrating nodes and directed edges using a graph structure model to form a complete original file lineage graph, specifically represented as follows: ,in, This represents the pedigree chart of the original file; E represents the set of nodes; E represents the set of directed edges; through the integration process, the consistency of the association between nodes and directed edges is automatically verified (such as no isolated directed edges or no invalid nodes), ensuring the integrity of the graph structure.

[0045] In step 152, the original file lineage map is visualized and rendered to obtain the file lineage map, specifically represented as follows: ;in, Indicates the lineage of the document; This represents the rendering function, used to calculate the coordinate distribution of nodes; This represents the pedigree chart of the original file; This function represents the visualization style of a node; Style(Edge) represents the visualization style of a directed edge. This represents a set of visual interactive parameters.

[0046] The rendering function calculates the two-dimensional coordinates of each node to ensure uniform node distribution and prevents excessive intersections of directed edges. The core calculation logic is expressed as follows: , This represents the i-th node; Represents the two-dimensional coordinates of the i-th node; Represents the coordinate calculation function; E represents the set of nodes; E represents the set of directed edges; k represents the preset balance coefficient. Indicates the preset number of iterations.

[0047] The coordinate calculation function obtains the two-dimensional coordinates of each node through the balance of attractive and repulsive forces. The attractive force is achieved through... It means that, among them, This represents the gravitational force between the i-th node and the j-th node; This represents the distance between the i-th node and the j-th node; k represents the preset balance coefficient. Repulsive force passes through... It means that, among them, This represents the repulsive force between the i-th node and the j-th node; This represents the distance between the i-th node and the j-th node; k represents the preset balance coefficient. Gravity acts on directly related nodes, bringing them closer together and highlighting the relationships between files; repulsion acts on all nodes, keeping them apart and preventing overlap.

[0048] The node coordinates are calculated by balancing the resultant forces of attraction and repulsion. The specific calculation process includes: (1) Initial coordinate assignment: Assign random initial two-dimensional coordinates to each node ( The initial coordinate range is [0, 1000] to ensure a uniform initial distribution. (2) Calculation of resultant force: For each node, traverse all other nodes and calculate the repulsive force respectively; at the same time, traverse all nodes directly related to this node and calculate the attractive force; combine all repulsive and attractive forces into a vector to obtain the resultant force of the node, specifically expressed as: ; (3) Coordinate Iteration Update: Update the coordinates of the nodes according to the resultant force, specifically expressed as follows: ;in, and Represents the node coordinates in the (t+1)th iteration; and Let be the node coordinates in the t-th iteration; and The resultant force at the node is represented by the components along the x-axis and y-axis. Indicates the preset number of iterations.

[0049] (4) Coordinate determination: Repeat steps 2 and 3 until the preset number of iterations is reached, or the resultant force of all nodes tends to 0. The node coordinates obtained at this time are the final two-dimensional coordinates.

[0050] The node visualization style function can differentiate nodes by color and size based on file type, and determine the displayed information of the nodes; the directed edge visualization style function can differentiate nodes by color and size based on relation type, and determine whether to display specific type labels. The set of visual interactive parameters can be represented as: ; in, This indicates the node drag-and-drop functionality; This indicates the map zoom function; This indicates the node search function; This indicates the function of penetrating the query.

[0051] By using specific styles for fixed nodes and directed edges, combined with interactive functions such as dragging and zooming, an intuitive and interactive file lineage map can be output, visualizing the file relationships and providing basic support for subsequent impact analysis.

[0052] In an optional embodiment of the present invention, step 16, monitoring changes in the blockchain evidence storage network and file lineage graph to obtain file hash change events, may include: Step 161: Monitor the on-chain file and hash changes in the blockchain evidence storage network to obtain on-chain change events; Step 162: Based on the on-chain change event, trigger the change of the file lineage graph to obtain the file hash change event.

[0053] In this embodiment, in step 161, the blockchain event listening interface can subscribe to new block generation events and evidence storage transaction events from the blockchain network. The listening interface acquires all evidence storage transactions within the new block in real time and extracts key information. If a new file is added to the chain, a new type of on-chain change event is generated due to the discovery of a new evidence storage sequence number. If an old file is updated, the hash of the previous moment is compared with the hash of the next moment based on the evidence storage sequence number. If a change is found, it is determined that the file content has been changed, and an update type of on-chain change event is generated. This step enables real-time proactive listening of blockchain evidence storage data, ensuring that changes to file content can be detected immediately. Hash comparison can identify whether the file has been tampered with, thereby avoiding false positives and false negatives.

[0054] In step 162, when an on-chain change event occurs, it triggers a change in the file lineage graph, which in turn causes a file hash change event. The system subscribes to node change and directed edge change messages in the file lineage graph database and determines changes in attributes such as file type, hash value, status, and timestamp of the nodes. At the same time, it detects whether the relationships between nodes have been added, deleted, or modified. When the node attributes or relationships change, a file hash change event is obtained.

[0055] This step enables real-time monitoring of changes in file lineage graph nodes and relationships, ensuring that the graph status is traceable. It achieves automatic detection of changes in file content and graph structure, providing an event source for subsequent analysis of the impact of changes and triggering of re-auditing tasks.

[0056] In an optional embodiment of the present invention, in step 17, when a file hash change event is detected, the file lineage graph is invoked based on the evidence storage serial number to perform an impact range analysis, and a list of evidence storage serial numbers corresponding to the affected downstream network security compliance files is obtained. This may include: Step 171: When a file hash change event is detected, start from the corresponding node of the file where the file hash change event occurred and traverse all downstream nodes in the file lineage graph that are directly or indirectly dependent on the corresponding node. Step 172: Summarize the evidence storage serial numbers corresponding to the downstream nodes to obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance documents.

[0057] In this embodiment, in step 171, based on the file hash change event, the starting node of the change in the lineage graph is located, and its downstream nodes are found. The downstream nodes refer to all child nodes that directly or indirectly depend on the current node. The specific traversal rules can be preset, for example, they can be represented as follows: ,in, Indicates the downstream node; This represents a graph traversal function; This represents the pedigree chart of the original file; Indicates a change in the starting node; This indicates traversing along the outgoing edges from upstream to downstream.

[0058] The specific traversal process can be as follows: obtain the direct downstream nodes of the starting point node of the change; for each direct downstream node, continue to obtain its downstream nodes, recursively / iterate until there are no new nodes, forming a complete set of downstream nodes. By accurately locating the starting point of the change, the source of the impact range analysis can be ensured to be correct. Through directed edge traversal, all directly / indirectly affected downstream nodes can be automatically identified, enabling automatic identification of the impact range of the change without manual intervention.

[0059] In step 172, the evidence storage sequence number of each node is extracted from the downstream node set obtained by traversal; the evidence storage sequence numbers of all downstream nodes are summarized into an ordered list, and the system automatically removes duplicates and sorts the list to ensure that there are no duplicates and no omissions, thereby outputting a standard list that can be directly used to trigger re-audit, compliance verification and notification reminders.

[0060] When the content of a document changes, the system can automatically identify all downstream cybersecurity compliance documents that are directly or indirectly affected, and generate a list of evidence serial numbers. This provides a basis for subsequent re-audits, compliance verifications, and risk tracing, effectively improving the automation level and response efficiency of cybersecurity compliance audits.

[0061] In an optional embodiment of the present invention, step 18, generating a re-audit task and distributing it based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, and storing the information of the re-audit task on the blockchain, may include: Step 181: Generate a re-audit task based on the downstream cybersecurity compliance documents corresponding to the evidence storage serial number list; Step 182: Hash at least one of the following: task sequence number of the re-audit task, associated evidence storage sequence number, responsible person, deadline, and task status, and upload it to the blockchain evidence storage network to complete the evidence storage.

[0062] In this embodiment, the generation, distribution and on-chain evidence storage of the re-audit task in step 181 is essentially based on the list of evidence storage serial numbers of the affected downstream files. It automatically generates standardized re-audit tasks and distributes them to the corresponding responsible parties. At the same time, it hashes the key information of the task and puts it on the blockchain to ensure that the re-audit process is traceable and the task information is tamper-proof, providing reliable support for the audit closed loop.

[0063] The list of affected files is transformed into a standardized re-audit task, which is then matched with the corresponding responsible parties and distributed. The specific process includes: obtaining information about the affected files, specifically as follows: ,in, This represents complete information about the k-th affected file; This represents the k-th certificate serial number; This represents a function for querying file information. It generates a re-audit task, specifically as follows: ;in, This indicates the re-audit task for the k-th affected file; Indicates the task sequence number; This represents the k-th certificate serial number; Indicate the file type of the affected file; This indicates the audit content that matches the file type. Indicate the person responsible; Indicates the deadline; Indicates the task status.

[0064] When multiple affected documents correspond to the same responsible party and the audit rules are consistent, they can be merged into a single batch audit task to avoid task redundancy. The specific judgment rule is as follows: ,in, This indicates a re-audit task following the merger. and These respectively indicate the persons responsible for the two comparative re-audit tasks; and These represent the audit content of the two comparative re-audit tasks.

[0065] The merged task status and deadline remain consistent, and a multi-channel distribution mechanism is adopted to distribute the generated re-audit tasks to the corresponding responsible entities. Distribution channels include internal system notifications, emails, enterprise office system interfaces, and regulatory audit platform interfaces. After distribution, the system receives a receipt from the responsible entity. If the receipt is unsuccessful, the system will re-distribute the task according to the preset retry interval.

[0066] In step 182, the relevant information for the re-audit task is uploaded to the blockchain evidence storage network for evidence storage, ensuring that the evidence storage process is consistent with the evidence storage process for the file data. Through the generation and distribution of re-audit tasks, the automated deployment of audit tasks affected by changes is achieved, ensuring that affected files are re-audited in a timely manner. Simultaneously, by hashing key task information onto the blockchain, trusted evidence storage of the re-audit task is achieved, ensuring that task information is tamper-proof and the process is traceable.

[0067] In an optional embodiment of the present invention, step 19, which verifies the downstream cybersecurity compliance document after re-audit processing by a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, generates an audit result, and stores the audit result on the blockchain, may include: Step 191: The key fields of the downstream cybersecurity compliance documents that have been re-audited are parsed by the compliance rule smart contract engine, and the key fields are compared with the preset compliance terms to obtain the content-level compliance verification results. Step 192: Based on the association identifier of the blood relationship metadata, retrieve the key fields of the upstream and downstream related files of the downstream network security compliance file, verify the logical consistency between the files, and obtain the cross-file verification result. Step 193: Based on the content-level compliance verification results and cross-file cross-verification results, generate audit results, perform hash calculation on the audit results, and upload them to the blockchain evidence storage network to complete the evidence storage.

[0068] In this embodiment, in step 191, the content-level compliance verification of a single file is completed through a smart contract engine, thereby obtaining the matching degree between the file's key fields and preset compliance clauses, and realizing the automated determination of whether the file content meets regulatory requirements. Specifically, this involves triggering a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network by calling an interface through a blockchain smart contract, which can be represented as follows: ,in, This indicates the specific function being called; CC indicates a compliance-based smart contract engine pre-deployed on the blockchain evidence storage network. Indicates functional parameters; This represents the parsing and verification function; Indicates the input parameters; This represents the k-th evidence storage sequence number. The smart contract engine uses this sequence number to retrieve the complete data of the corresponding downstream file from the blockchain evidence storage network. It can extract key fields and then parse out fields related to compliance verification. The smart contract engine also retrieves preset compliance clauses corresponding to the current file type from its built-in compliance clause library. The smart contract engine retrieves the complete data of the corresponding file using the input notarization serial number. Combining this with file type matching and parsing rules, it extracts the key fields required for compliance verification, forming a standardized set of key fields. Based on the file type, the engine retrieves corresponding preset compliance clauses from its built-in compliance clause library. These clauses all contain clear judgment criteria to ensure the standardization of the comparison. A one-to-one comparison is performed between fields and clauses, and the clause type (e.g., numerical, enumerated, and textual) is used for matching and verification. The results are then summarized to obtain the content-level compliance verification results. For example, if the vulnerability scan report shows 0 "vulnerabilities," a 100% "rectification completion rate," and rectification measures include "vulnerability repair + retesting verification," then the content-level compliance verification is considered passed. If the report shows a "vulnerability level" of high risk and no rectification deadline is specified, then the verification is considered failed. The verification report clearly indicates the violation fields as "vulnerability level" and "rectification deadline," explaining the reason for the violation and the rectification requirements.

[0069] In step 192, based on the file lineage graph, the logical consistency between the affected file and its upstream and downstream related files is verified to avoid situations where a single file is compliant but the overall logic is contradictory, thus achieving end-to-end compliance verification. Specifically, this includes: extracting the association identifier (i.e., the provenance sequence number of the upstream and downstream related files) of the currently affected file from the lineage metadata; locating all upstream and downstream related files using this association identifier; parsing the key fields of all related files one by one through the compliance rule smart contract engine to ensure the consistency and accuracy of the parsing results; and using the smart contract engine's built-in cross-file logical consistency rules, which, based on various relationship types, yield differentiated verification rules, represented as follows: ;in, Represents a consistency rule function; Indicates the target key field of the currently affected downstream file; This indicates the corresponding key fields of upstream related files that are associated with the currently affected downstream files; Indicates the relation type; Indicates inclusion; This indicates logical consistency; This indicates that it is included.

[0070] For example, in version inheritance relationships, the "vulnerability ID" of the current file must be completely consistent with the upstream version file; in derivative relationships, the "number of vulnerabilities" in the remediation contact form must include the "number of vulnerabilities" in the vulnerability scanning report; in verification relationships, the "vulnerability remediation result" in the retest report must match the "remediation target" in the remediation contact form, i.e., logical consistency; in referenced relationships, the "vulnerability information" referenced in the audit report must be included within the scope of the "vulnerability information" in the original vulnerability scanning report. Defining differentiated logical rules according to the type of association relationship can ensure the rationality and relevance of the logical verification of cross-file cross-validation, thereby covering the file association needs under different business scenarios.

[0071] In step 193, the dual-dimensional verification results are integrated to generate standardized audit results and store them on the blockchain, thus forming a complete audit closed loop. Specifically, this includes: the smart contract engine integrating content-level compliance verification results and cross-document cross-verification results; if both are qualified, the audit is deemed passed; if one is unqualified or both are unqualified, the audit is deemed to require rectification, and the audit must be resubmitted after rectification; an audit result is generated, including core information such as the storage serial number, associated document identifier, and audit conclusion, to ensure the traceability of the results; and the key audit information is assembled in a fixed order and stored on the blockchain.

[0072] like Figure 2 As shown, the specific implementation process of the embodiments of the present invention includes: Step 21: The compliance document processing client supports manual / automatic lineage association. Automatic association automatically fills in the parent file ID based on business processes (such as initiating rectification). Manual association provides an interface for users to drag and drop to establish custom relationships between files. When submitting the file hash to the blockchain, the client sends the lineage metadata to the graph construction module.

[0073] Step 22, the file lineage graph construction module, is an off-chain analysis service built on a graph database, used to store and manage complex relationships between files. Each node in the graph corresponds to a file (uniquely identified by the blockchain notarization sequence number), and each edge represents a relationship type. The following relationship types are defined: Derived from: File B is generated from file A (e.g., a rectification report is derived from a vulnerability report); Version inherited from: File It is a file The new version; referenced: File C references File D (e.g., a vulnerability report ID is referenced in a rectification contact form); verified: File E confirms the content of File F (e.g., a retest report verifies that rectification is complete). It is mainly used to receive metadata lineage identifiers submitted by clients, automatically create file nodes and directed edges; supports automatic version tree management; supports evidence chain integrity verification (checking whether key evidence is complete according to a preset template); and periodically calculates hashes of key graph structures (such as the adjacency relationships of important nodes) and stores them on the blockchain to ensure that the relationships themselves are immutable.

[0074] Step 23, the lineage-driven collaborative auditing engine, deployed between the blockchain and the graph, is an intelligent event monitoring and task distribution engine that implements the following functions: Event monitoring: Monitors on-chain change events on the blockchain and file hash change events that occur in the graph. Impact scope analysis: When a file change is detected, the graph traversal algorithm (such as depth-first traversal) of the graph module is invoked to return a list of all "descendant files" that directly or indirectly depend on that file.

[0075] Step 24, Re-audit Task Distribution: For the list of affected files, automatically generate re-audit tasks, assign them to relevant responsible persons, and record information such as task status, responsible persons, and deadlines on the blockchain; Closed-loop verification: Monitor whether the associated files are resubmitted and audited within the specified time. If they are not completed within the time limit, trigger an alert and record it on the blockchain.

[0076] Step 25: Compliance rule smart contract engine, a programmable module deployed on the blockchain, with open and transparent rule code, and rule updates requiring consensus from multiple parties.

[0077] Step 26 supports linkage with lineage graphs. When auditing a file, key fields of its upstream and downstream files can be retrieved simultaneously for cross-validation (e.g., verifying whether the vulnerability ID in the remediation report exists in the original vulnerability report). Audit conclusions (compliant / non-compliant / pending review) and supporting evidence are stored on the blockchain.

[0078] Step 27: The blockchain evidence storage network is a consortium blockchain jointly maintained by regulators, auditors, and auditees. It stores core evidence such as file hashes, metadata hashes, key field hashes, lineage hash snapshots, audit task status, and audit results; and generates a unique and trusted timestamp and evidence storage serial number for each file.

[0079] Step 28, the regulatory audit gate, provides a visual interactive interface for the lineage graph, supporting click-to-expand / collapse, highlighting the complete path by evidence chain template, and penetrating to view the original content of files (retrieving on-chain hashes via evidence IDs and comparing them with local files). All displayed data can be verified for on-chain authenticity in real time.

[0080] The connections between the components are as follows: After parsing the file, the client submits the file hash to the blockchain for notarization and submits the kinship identifier to the graph construction module to update the graph. The linked audit engine monitors blockchain and graph events, calls the graph module to perform impact scope analysis, and distributes audit tasks to the contract engine to execute compliance verification. The verification results are returned to the client and uploaded to the blockchain. The regulatory portal obtains data from the graph module and the blockchain, providing visualized and transparent queries.

[0081] Operation process: Graph initialization: The system predefines a "vulnerability remediation evidence chain template": This must include... Vulnerability Report Rectification Notice [Retest Report] Level 3 document, and the time sequence must comply with regulations.

[0082] File upload and blockchain registration: Generate a vulnerability scan report, calculate the hash on the client side, submit it to the blockchain, and obtain a storage serial number. At the same time, the file information (evidence serial number = The file type (vulnerability report) and lineage identifier (parent ID is empty) are sent to the graph module to create node N1.

[0083] Initiating rectification and establishing blood ties: Targeting Upon initiating rectification, the system automatically generates a "Rectification Contact Form." The client calculates its hash and submits it to the blockchain to obtain a notarization serial number. When submitting metadata, automatically fill in "parent file ID= The relation type is "derived from". The graph module creates node N2 and establishes a directed edge N2→[derived from]→N1.

[0084] Complete rectification and establish multi-level lineage: After rectification, generate a "Retest Report", and hash the ID on the blockchain. When submitting metadata, enter "Parent file ID= Associated file ID= The relation type is "verification". The graph module creates node N3 and establishes two edges: N3→[verification]→N1, N3→[association]→N2. At this point, a triangular chain of evidence is constructed in the graph. The graph module periodically calculates the hash of this subgraph structure and stores it on the chain.

[0085] Changes to core documents trigger a coordinated audit: (1) One day, the original vulnerability report was modified, generating a new version v2.0. The client hashed it and uploaded it to the blockchain to obtain the new evidence ID. And mark it as "version inherited from". (Lineage identifier). Graph module update: Create node N1v2, edge N1v2 → [Version inherited from] → N1.

[0086] (2) The linkage audit engine detected When a version update event occurs (actually, a new node N1v2 is added), the influence range analysis interface of the graph module is immediately invoked, and the input is... .

[0087] (3) The graph module starts from node N1 (including all its versions), performs a depth-first traversal, and returns all downstream nodes: [N2, N3].

[0088] (4) The engine automatically generates two re-audit tasks: "Please confirm the rectification contact form". "Does it still apply to the new version vulnerability report?" "Please confirm whether the retest report 0x003 needs to be updated", assign the person in charge, and put the task details (task ID, associated files, person in charge, deadline) on the blockchain for evidence storage.

[0089] (5) At the same time, on the regulatory portal, the status of the evidence chain changes to "requires review".

[0090] Regulatory penetration query: Regulatory personnel log in to the portal to view the vulnerability management lineage diagram of the organization. The system automatically highlights green paths indicating "complete evidence chain" and yellow paths indicating "requires review." Regulators can click on a node requiring review to directly view the latest version of the original report. Compared with the old version of the rectification order The association issue can be resolved, and the hashes and lineage snapshots of the two documents can be verified through blockchain to ensure data credibility.

[0091] This embodiment of the invention uses a pioneering document lineage mapping technique to link isolated documents into a complete chain of evidence, automatically verifying the "discovery" process. Rectification The "retesting" process ensures complete documentation, maintaining a logical closed loop for compliance auditing and enabling change linkage: A unique lineage-driven linkage audit mechanism achieves "one file change, full-chain awareness." When core evidence is updated, it automatically identifies all affected downstream files and triggers a re-audit, completely resolving the inconsistency in compliance status caused by file relationships. Intelligent auditing: Combining lineage graphs with smart contracts supports cross-file verification (e.g., the vulnerability ID in the retesting report must exist in the original report), achieving an intelligent upgrade from "single-file anti-tampering" to "multi-file logical consistency verification." Regulatory penetration: Providing a visualized lineage graph allows regulators to intuitively view complex relationships between files, penetrate to the original content with one click, quickly locate weak points in the evidence chain, and significantly improve audit efficiency. Rule adaptability: Compliance rules are dynamically deployed in the form of smart contracts and can be updated with upgrades to the security standards, ensuring the system's long-term viability. Dual trust guarantees: Blockchain ensures the immutability of file hashes and lineage snapshots, while graph analysis ensures the computability of relationship logic; the combination of these two forms a dual guarantee of "data trustworthiness + relationship trustworthiness."

[0092] The network security compliance document audit task processing method proposed in this invention realizes the interrelation of compliance documents through document on-chain evidence storage, constructing a lineage graph, automatically analyzing the scope of impact, and dual audit verification. This enables the automatic identification of the impact of changes and achieves smooth and reliable content compliance verification.

[0093] like Figure 3As shown, this embodiment of the invention also provides an audit task processing device 30 for network security compliance documents, including: Module 31 is used to acquire file data and metadata related to the lineage of network security compliance documents. Processing module 32 is used to upload the hash value obtained after hashing the file data to the blockchain evidence storage network to complete the evidence storage and obtain the evidence storage serial number of the network security compliance file; determine the nodes of the file lineage graph based on the evidence storage serial number; determine the directed edges between nodes based on the lineage relationship metadata; obtain the file lineage graph based on the nodes and the directed edges; monitor changes in the blockchain evidence storage network and the file lineage graph to obtain file hash change events; when a file hash change event is detected, call the file lineage graph based on the evidence storage serial number to perform an impact range analysis and obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance files; generate a re-audit task based on the downstream network security compliance files corresponding to the evidence storage serial number list, distribute it, and upload the information of the re-audit task to the blockchain for evidence storage; The generation module 33 is used to verify the downstream network security compliance documents that have been re-audited through a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, generate audit results, and store the audit results on the blockchain.

[0094] Optionally, the acquisition module 31 is specifically used to: receive the original network security compliance document to be processed and parse it to obtain the file data; The lineage metadata corresponding to the file data of the network security compliance documents is automatically generated according to the preset business process, or the lineage metadata is customized by manual means; the lineage metadata includes the association identifier and relationship type between the file data.

[0095] Optionally, the processing module 32 is specifically used to: perform a hash calculation on the file data to obtain a file hash value; The file hash value is uploaded to the blockchain evidence storage network for consensus-based evidence storage, and an evidence storage sequence number is assigned and returned.

[0096] Optionally, the processing module 32 is specifically used to: query whether a corresponding node already exists in the file lineage map based on the evidence serial number, and obtain the query result; Based on the query results, the nodes of the file lineage map are obtained.

[0097] Optionally, the processing module 32 is specifically used to: when a file hash change event is detected, starting from the corresponding node of the file where the file hash change event occurred, traverse all downstream nodes in the file lineage graph that are directly or indirectly dependent on the corresponding node; The evidence storage serial numbers corresponding to the downstream nodes are summarized to obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance documents.

[0098] Optionally, the processing module 32 is further specifically used to: generate a re-audit task based on the downstream cybersecurity compliance documents corresponding to the list of evidence storage serial numbers; The task sequence number, associated evidence storage sequence number, responsible person, deadline, and task status of the re-audit task are hashed and then uploaded to the blockchain evidence storage network to complete the evidence storage.

[0099] Optionally, the generation module 33 is specifically used to: parse the key fields of the downstream cybersecurity compliance documents that have been re-audited by the compliance rule smart contract engine, compare the key fields with the preset compliance clauses, and obtain the content-level compliance verification results; Based on the association identifier of the blood relationship metadata, key fields of upstream and downstream related files of the downstream network security compliance file are retrieved to verify the logical consistency between files and obtain cross-file verification results. Based on the content-level compliance verification results and cross-document cross-verification results, an audit result is generated, and the audit result is hashed and uploaded to the blockchain evidence storage network to complete the evidence storage.

[0100] It should be noted that this device is a device corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0101] like Figure 4 As shown, this embodiment of the invention also provides a computing device 40, including a processor 41, a memory 42, and a program or instructions stored in the memory 42 and executable on the processor 41. When the program or instructions are executed by the processor 41, they implement the various processes of the above-described method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here. It should be noted that the computing device in this embodiment of the invention includes the aforementioned mobile electronic devices and non-mobile electronic devices.

[0102] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0103] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

[0106] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0108] Furthermore, it should be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Moreover, the steps performing the above series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve by using their basic programming skills after reading the description of the present invention.

[0109] Therefore, the object of the present invention can also be achieved by running a program or a set of programs on any computing device. The computing device can be a known general-purpose device. Therefore, the object of the present invention can also be achieved simply by providing a program product containing program code for implementing the method or apparatus. That is, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future. It should also be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent to the present invention. Furthermore, the steps for performing the above series of processes can naturally be performed in the order described, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel or independently of each other.

[0110] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for processing audit tasks of network security compliance documents, characterized in that, include: Obtain the file data and metadata related to the lineage of network security compliance documents; The hash value obtained after hashing the file data is uploaded to the blockchain evidence storage network to complete the evidence storage and obtain the evidence storage serial number of the network security compliance document. Based on the evidence serial number, determine the nodes of the file lineage map; Based on the aforementioned bloodline metadata, directed edges between nodes are determined; Based on the nodes and the directed edges, a file lineage graph is obtained; Monitor changes to the blockchain evidence storage network and file lineage graph to obtain file hash change events; When a file hash change event is detected, the file lineage graph is called based on the evidence serial number to analyze the scope of impact and obtain a list of evidence serial numbers corresponding to the affected downstream network security compliance files. Based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, a re-audit task is generated and distributed, and the information of the re-audit task is stored on the blockchain. By using a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, the downstream cybersecurity compliance documents that have undergone re-audit processing are verified, audit results are generated, and the audit results are stored on the blockchain.

2. The method for processing audit tasks of network security compliance documents according to claim 1, characterized in that, Obtain the file data and lineage metadata of cybersecurity compliance documents, including: Receive the raw cybersecurity compliance documents to be processed and parse them to obtain the document data; The lineage metadata corresponding to the file data of the network security compliance documents is automatically generated according to the preset business process, or the lineage metadata is customized by manual means; the lineage metadata includes the association identifier and relationship type between the file data.

3. The method for processing audit tasks of network security compliance documents according to claim 1, characterized in that, The hash value obtained after hashing the file data is uploaded to the blockchain evidence storage network to complete the evidence storage, and the evidence storage serial number of the network security compliance document is obtained, including: Perform a hash calculation on the file data to obtain the file hash value; The file hash value is uploaded to the blockchain evidence storage network for consensus-based evidence storage, and an evidence storage sequence number is assigned and returned.

4. The method for processing audit tasks of network security compliance documents according to claim 1, characterized in that, Based on the evidence serial number, the nodes of the file lineage map are determined, including: Based on the certificate serial number, check whether the corresponding node already exists in the file lineage map to obtain the query results; Based on the query results, the nodes of the file lineage map are obtained.

5. The method for processing audit tasks of network security compliance documents according to claim 1, characterized in that, When a file hash change event is detected, the file lineage graph is invoked based on the evidence storage serial number to analyze the scope of impact, obtaining a list of evidence storage serial numbers corresponding to the affected downstream cybersecurity compliance files, including: When a file hash change event is detected, start from the corresponding node of the file where the file hash change event occurred and traverse all downstream nodes in the file lineage graph that are directly or indirectly dependent on the corresponding node. The evidence storage serial numbers corresponding to the downstream nodes are summarized to obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance documents.

6. The method for processing audit tasks of network security compliance documents according to claim 1, characterized in that, Based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, a re-audit task is generated and distributed, and the information of the re-audit task is stored on the blockchain, including: Based on the downstream cybersecurity compliance documents corresponding to the list of stored evidence serial numbers, a re-audit task is generated. The task sequence number, associated evidence storage sequence number, responsible person, deadline, and task status of the re-audit task are hashed and then uploaded to the blockchain evidence storage network to complete the evidence storage.

7. The method for processing audit tasks of network security compliance documents according to claim 1, characterized in that, By using a compliance rule smart contract engine pre-deployed on a blockchain evidence storage network, the downstream cybersecurity compliance documents that have undergone re-audit processing are verified, audit results are generated, and the audit results are stored on the blockchain for evidence storage, including: The key fields of the downstream cybersecurity compliance documents that have been re-audited are analyzed by the compliance rule smart contract engine, and the key fields are compared with the preset compliance clauses to obtain the content-level compliance verification results. Based on the association identifier of the blood relationship metadata, key fields of upstream and downstream related files of the downstream network security compliance file are retrieved to verify the logical consistency between files and obtain cross-file verification results. Based on the content-level compliance verification results and cross-document cross-verification results, an audit result is generated, and the audit result is hashed and uploaded to the blockchain evidence storage network to complete the evidence storage.

8. A device for processing audit tasks of network security compliance documents, characterized in that, include: The acquisition module is used to acquire file data and metadata related to the lineage of network security compliance documents. The processing module is used to upload the hash value obtained after hashing the file data to the blockchain evidence storage network to complete the evidence storage and obtain the evidence storage serial number of the network security compliance document. Based on the evidence serial number, determine the nodes of the file lineage map; Based on the aforementioned bloodline metadata, directed edges between nodes are determined; Based on the nodes and the directed edges, a file lineage graph is obtained; changes in the blockchain evidence storage network and the file lineage graph are monitored to obtain file hash change events; When a file hash change event is detected, the file lineage graph is called based on the evidence storage serial number to analyze the scope of impact and obtain a list of evidence storage serial numbers corresponding to the affected downstream network security compliance files; a re-audit task is generated and distributed based on the downstream network security compliance files corresponding to the evidence storage serial number list, and the information of the re-audit task is stored on the blockchain. The generation module is used to verify the downstream cybersecurity compliance documents that have been re-audited through a compliance rule smart contract engine pre-deployed on the blockchain evidence storage network, generate audit results, and store the audit results on the blockchain.

9. A computing device, characterized in that, include: A processor, a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The system stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images