Offline auditing delivery robot, auditing delivery system and auditing delivery method

Abstract

The invention relates to the technical field of information security, and discloses an offline auditing delivery robot, auditing delivery system and auditing delivery method, comprising a processor, a memory, a security module and a communication interface. And the processor runs an audit generation module, an evidence solidification module, a signature module, a chained recording module and a packaging output module. The audit generation module analyzes the code to generate a deliverable; the evidence solidification module constructs a list containing file Hash and calculates a global abstract; the signature module calls a private key in the security module to carry out digital signature on the abstract; the chain type recording module combines a previous record hash of a local account book and a current abstract to generate a chain end file and adds the chain end file to the account book; and the packaging output module packages and outputs the deliverable, the list, the signature and the chain end file. According to the method, the private key is protected through hardware isolation, and the closed-loop generation and tamper-proof solidification of the audit data in the offline environment are realized by using the standardized coding and hash chain technology, so that the problems that the audit deliverable is difficult to trace and easy to tamper are solved.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to an offline audit delivery robot, an audit delivery system, and an audit delivery method. Background Technology

[0002] Currently, code security auditing has become a critical part of software supply chain management. Various organizations widely employ static analysis techniques to examine source code in order to identify potential security vulnerabilities and compliance risks. The authenticity of the audit results and the reliability of the conclusions directly determine whether a software system can be securely deployed and delivered.

[0003] In existing audit delivery applications, analysis tools typically output test results as standalone electronic documents in PDF, HTML, or JSON format. Operators manually export these files after the task is completed and transmit them via physical media or a local area network. For multi-round processes involving initial testing, rectification, and retesting, the system often archives each report as an isolated file, and the acceptance party primarily relies on reviewing the document content to confirm the results.

[0004] However, this general document delivery model has significant shortcomings in offline or high-security scenarios. Ordinary electronic reports lack inherent anti-tampering mechanisms, allowing holders to easily modify vulnerability levels without leaving a trace. The deliverables are not cryptographically linked to the hardware identity of the generating device, making it impossible to technically verify the source of audit conclusions. Furthermore, the lack of mathematical logic between different rounds of reports stored discretely means that if substandard records are intentionally deleted or replaced, subsequent verification will fail to detect it, resulting in a lack of continuity in audit working papers and making it difficult to form a complete chain of evidence. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides an offline audit delivery robot, an audit delivery system, and an audit delivery method, which solves the technical problems that code audit deliverables are easily tampered with, lack hardware identity binding, and lack a continuous chain of evidence in offline or confidential environments, making it difficult for third parties to independently verify and trace the source.

[0006] To achieve the above objectives, the present invention provides the following technical solution: In a first aspect, the present invention provides an offline audit delivery robot, including a processor, a memory, a security module, and a communication interface; the processor executes instructions in the memory and runs an audit generation module, an intelligent interpretation module, an evidence solidification module, a signature module, a chain recording module, and a packaging output module.

[0007] The audit generation module is used to analyze the set of target code files to be audited obtained through the communication interface and generate a set of audit deliverable files containing vulnerability details and evidence fragments. The intelligent interpretation module is used to run a local large language model and generate risk interpretation documents and model traceability records in natural language format based on the audit deliverables file set. The evidence solidification module is used to calculate the hash value of each file in the audit deliverables document set and the risk interpretation document and construct a list file, and calculate a global evidence package digest for the list file; The signature module is used to send the evidence packet digest to the security module, call the device private key stored in the security module to digitally sign the evidence packet digest, and generate a signature file; The chain record module is used to read the hash of the previous record in the device's local ledger, combine it with the evidence package digest to generate a tail file containing the hash of the current record, and append the hash of the current record to the device's local ledger. The packaging output module is used to extract the evidence package digest to construct the blockchain evidence payload, and encapsulate the audit deliverables file set, the risk explanation document, the list file, the signature file, the chain tail file and the blockchain evidence payload into an evidence package, and output the evidence package through the communication interface.

[0008] By adopting the above technical solution, the present invention realizes the closed-loop generation, intelligent interpretation and anti-tampering solidification of audit data in an offline environment.

[0009] Preferably, the evidence solidification module performs a normalization encoding operation when calculating the evidence packet digest. The normalization encoding operation includes: constructing a list data object containing a list of file fingerprints, a generation timestamp, and a device hardware identifier; sorting the keys in the list data object in lexicographical ascending order and removing all whitespace characters between key-value pairs and between fields; converting the sorted and whitespace-removed list data object into a UTF-8 encoded binary byte stream, and performing a SHA-256 hash operation on the binary byte stream to obtain the evidence packet digest.

[0010] By adopting the above technical solution, the present invention ensures the consistency of abstract calculation under different environments, providing a basis for independent verification.

[0011] Preferably, the chain record module is used to generate the tail file according to the following logic: obtain the record number, task identifier, evidence package digest, and previous record hash of the current audit task; combine the obtained record number, task identifier, evidence package digest, and previous record hash and perform normalized encoding, calculate the hash value as the hash of the current record, and the device local ledger forms a sequential hash chain structure; generate the tail file containing the record number, previous record hash, evidence package digest, and current record hash.

[0012] By adopting the above technical solution, the present invention constructs an immutable local ledger, effectively preventing historical records from being maliciously modified.

[0013] Preferably, the process by which the intelligent explanation module generates the model source record includes: calculating the weight file hash, the input prompt word hash, and the input evidence fragment hash of the local large language model; combining the above hash values ​​to generate the model source record; and feeding the model source record back to the evidence solidification module to be included in the list file.

[0014] By adopting the above technical solution, the present invention achieves complete traceability of AI-generated content, ensuring the authenticity and reliability of the explanatory documents.

[0015] Preferably, the security module is a trusted platform module or a security unit chip, and the storage area of ​​the security module is physically isolated from the general file system of the processor and the memory; the security module is used to receive the evidence packet digest through a restricted hardware interface, perform signature calculations and output signature results within the security module, and prevent the device private key from being exported by external instructions.

[0016] By adopting the above technical solution, the present invention utilizes hardware physical isolation to protect the private key and eliminates the risk of key leakage.

[0017] Secondly, the present invention provides an offline audit delivery system that operates in a physically isolated offline environment, including the offline audit delivery robot described in the first aspect above, used to generate and output evidence packages; an audit target carrier used to store the set of audit target code files, connected to the offline audit delivery robot via a physical interface; and a third-party verification terminal with an independent verification module. The third-party verification terminal is used to receive the evidence packages via a physical mobile storage medium, and uses the verification module to perform integrity verification, source authenticity verification, and identity non-repudiation verification on the evidence packages without relying on the original generation environment.

[0018] By adopting the above technical solution, the present invention achieves the separation of generation and verification, meeting the secure delivery requirements of a zero-trust environment.

[0019] Thirdly, the present invention provides an audit delivery method applied to the offline audit delivery robot described in the first aspect above, comprising the following steps: A set of target code files to be audited is obtained and analyzed in an offline environment to generate a set of audit deliverable files. A local large language model is run to generate a risk explanation document in natural language format based on the audit deliverable file set. A hash value is calculated for each file in the audit deliverable file set and the risk explanation document, and a list file is constructed. The list file is normalized, and an evidence package digest is calculated. The device private key in the security module is used to digitally sign the evidence package digest, generating a signature file. The hash of the previous record in the device's local ledger is read and combined with the evidence package digest to generate a tail file containing the hash of the current record. The hash of the current record is appended to the device's local ledger. The evidence package digest and task identifier are extracted to construct a blockchain evidence payload. The audit deliverable file set, the risk explanation document, the list file, the signature file, the tail file, the blockchain evidence payload, and the public key file are encapsulated into an evidence package and output.

[0020] By adopting the above technical solution, the present invention ensures the consistency and reliability of audit delivery data throughout its entire lifecycle.

[0021] Preferably, the manifest file includes a file fingerprint list, which records the relative path, file size in bytes, and file hash value of each file in the audit deliverables file set and the risk interpretation document; the step of calculating the evidence package digest includes: performing key sorting and whitespace removal on the manifest file after excluding the evidence package digest field to obtain a normalized byte stream, and calculating the SHA-256 value of the normalized byte stream as the evidence package digest.

[0022] By adopting the above technical solution, the present invention achieves global integrity protection for all files, including AI interpretations.

[0023] Preferably, the method further includes a third-party verification step, which includes: decompressing the evidence package, calculating the actual hash value of each decompressed file and comparing it with the hash value recorded in the manifest file, and performing an integrity check; normalizing and recalculating the manifest file to obtain a recalculated digest, comparing the recalculated digest with the digest recorded in the signature file, and performing an authenticity check; using the public key file to verify the validity of the digital signature of the signature file, verifying that the fingerprint of the public key file is consistent with the record in the signature file, and performing a non-repudiation check.

[0024] By adopting the above technical solution, the present invention ensures the authenticity and non-repudiation of audit evidence through multi-dimensional verification logic.

[0025] Preferably, the method further includes a blockchain anchoring step: exporting the blockchain evidence payload to an external network environment via a one-way transmission method; writing the blockchain evidence payload into the evidence storage contract of the blockchain network to generate an evidence storage receipt containing a block timestamp; the blockchain evidence payload only contains the evidence package digest, the public key fingerprint in the signature file, and the task identifier, and does not contain the plaintext content of the audit deliverable file set.

[0026] By adopting the above technical solution, this invention protects privacy while using blockchain to give audit reports legal-level credibility.

[0027] This invention provides an offline audit delivery robot, an audit delivery system, and an audit delivery method. It offers the following advantages: 1. This invention achieves hardware-level separation between key storage and the general file system by integrating a physically isolated security module to store the private key and digitally signing the standardized evidence packet digest within the module. This technical feature ensures that the private key cannot be exported by external commands, effectively preventing the risk of private key leakage, thereby guaranteeing the non-repudiation of the identity of audit deliverables and data integrity in offline environments, and solving the problem that traditional software signatures are vulnerable to malicious software attacks.

[0028] 2. This invention utilizes a chained record module to mathematically bind the evidence package digest of the current task with the hash of the previous record in the local ledger, constructing a sequential hash chain structure. This technical feature ensures that any tampering or deletion of historical audit records will cause the subsequent chain to break, thereby achieving tamper-proof and traceable audit history on offline devices without a centralized server, and guaranteeing the temporal reliability of audit operations.

[0029] 3. This invention adopts a technical solution that encapsulates audit deliverables, standardized list documents, and signature documents into independent evidence packages, and, in conjunction with an independent verification mechanism by a third party, achieves physical decoupling between the generation environment and the verification environment. This technical feature allows the recipient to verify the integrity and authenticity of the audit results through cryptographic means using only the evidence package without needing to access the original confidential or isolated network, thus meeting the secure delivery requirements in a zero-trust environment. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the offline audit delivery system topology and robot structure according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the file hierarchy and data structure of the audit evidence package according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the audit evidence package generation process according to an embodiment of the present invention; Figure 4This is a schematic diagram of the third-party verification process in an embodiment of the present invention.

[0031] Among them, 10 is the processor; 20 is the memory; 30 is the security module; 40 is the communication interface; 100 is the audit generation module; 200 is the evidence solidification module; 300 is the signature module; 400 is the chain record module; 500 is the packaged output module; 600 is the verification module; and 700 is the intelligent interpretation module. Detailed Implementation

[0032] See attached document Figure 1 The offline audit delivery system provided in this embodiment of the invention operates in a confidential environment, an internal private network environment, or an offline environment with no network connection that is physically isolated from the public Internet. This environment is characterized by the absence of a direct bidirectional communication connection with an external wide area network, ensuring the confidentiality and security of the audited source code and sensitive data, and completely blocking the risk of data leakage through network side channels.

[0033] The offline audit delivery system logically comprises an offline audit delivery robot, an audit target carrier, and a third-party verification terminal. The offline audit delivery robot, acting as the audit generation end, is a core edge computing device or dedicated hardware unit deployed within the offline environment. Equipped with high-performance hardware resources and a closed, secure software environment, the offline audit delivery robot connects to the audit target carrier via a physical interface (such as USB or industrial bus) or a controlled LAN interface. The audit target carrier is a storage medium or storage server storing a set of audit target code files, which may include, but are not limited to, source code directories, compressed packages, compiled binary artifacts, container images, or software bill of materials (SBOM). The offline audit delivery robot is configured to unidirectionally read data from the audit target carrier, perform code security analysis, vulnerability scanning, and compliance checks locally in a closed loop, and generate an evidence package containing audit results and integrity verification.

[0034] The third-party verification terminal, acting as a verification client, is a general-purpose computing device located in this offline environment, such as a secure laptop, desktop workstation, or dedicated handheld terminal. The third-party verification terminal does not establish a continuous online network connection with the offline audit delivery robot; instead, it receives evidence packages output by the offline audit delivery robot via physical removable storage media (such as a secure USB flash drive) or single file transfers. The third-party verification terminal is equipped with independent verification tools to perform integrity verification, source authenticity verification, and identity non-repudiation verification on the received evidence packages without relying on the original generation environment or accessing the source code.

[0035] In one alternative implementation, the system topology also includes a blockchain network located in an external network environment. Since the offline audit delivery robot operates in a strictly physically isolated environment, it does not establish direct communication with the blockchain network. The system is configured to export the "minimum digest information" from the evidence package generated by the offline audit delivery robot to the external environment and write it into the blockchain evidence storage contract via manual cross-network exchange or one-way optical gate transmission. This minimum digest information contains only hash values ​​and digital signatures, and absolutely does not contain source code or the original audit report, thus achieving distributed anchoring and timestamp solidification of audit results while strictly maintaining physical isolation.

[0036] See attached document Figure 1 In this embodiment of the invention, the offline audit delivery robot is configured as a dedicated industrial control terminal that integrates computing, storage and security functions. It operates independently on a physical entity and does not rely on external cloud computing power.

[0037] The offline audit delivery robot includes a processor 10. The processor 10 is the computing core, taking the form of a central processing unit (CPU) or a heterogeneous computing chip containing a neural network processing unit (NPU). The processor 10 is configured to read and execute instructions from memory, driving the operation of audit generation, evidence preservation, and signature modules. Specifically, the processor 10 is responsible for performing rule matching operations against the target code, large-scale hash chain calculations, and evidence packet digest generation. In embodiments including intelligent interpretation capabilities, the processor 10 is also configured to run a local lightweight large language model (LLM) inference engine to perform natural language interpretation and source tracing analysis of the audit results.

[0038] The offline audit delivery robot includes a storage device 20. Storage device 20 provides persistent storage and runtime cache. It pre-stores a security-hardened operating system, code auditing toolchain, local ledger data, and device firmware. Storage device 20 is used to temporarily store source code during the audit process, as well as the generated manifest files, signature files, and final evidence packages. The data structure of storage device 20 is strictly divided into a protected system area and a user data area to prevent unauthorized writes from compromising the integrity of the auditing toolchain.

[0039] The offline audit delivery robot includes a security module 30. Security module 30 is a dedicated component providing hardware-level root of trust and key management, specifically a Trusted Platform Module (TPM) or Security Element (SE). It integrates a random number generator and a cryptographic coprocessor to generate and store the device's private key internally. The storage area of ​​security module 30 is physically isolated from the general file system, ensuring that the device's private key cannot be exported, copied, or dumped from memory. Security module 30 only receives data digests through a restricted interface, performs internal signing, and only outputs the signature result, achieving a strong security constraint that the private key does not leave the security module.

[0040] The offline audit delivery robot includes a communication interface 40. Communication interface 40 provides a channel for interaction with the physical world, in the form of a USB interface or a Gigabit Ethernet interface. It is used to mount an external hard drive containing code or connect to an internal classified network, and also serves as an output port for evidence packets. Communication interface 40 does not support connection to the public internet at the physical and protocol levels to ensure physical isolation.

[0041] See attached document Figure 1 The collaborative work of each module constitutes the core process of generating and solidifying audit evidence.

[0042] The offline audit delivery robot includes an audit generation module 100. This module receives the code to be audited (source code, image, etc.), loads the pre-built Static Application Security Testing (SAST) rule set and Software Composition Analysis (SCA) dependency library, and performs syntax tree parsing and feature matching. The audit generation module 100 generates raw audit deliverables, including vulnerability details in JSON format, a visualized HTML report, risk statistics, and attached evidence fragments.

[0043] The offline audit delivery robot includes an evidence solidification module 200. This module reads all audit deliverables, calculates their SHA-256 hash values ​​one by one, and writes the file path, size, and hash to a manifest file (manifest.json). Subsequently, the module performs normalization encoding processing on the manifest file (lexicographical sorting of key-value pairs and removal of spaces) and calculates the normalized global evidence bundle digest (bundle_hash), ensuring that any minor tampering with the file will result in a significant change to the digest.

[0044] The offline audit delivery robot includes a signature module 300. This module establishes a trusted channel with the security module and sends the evidence packet digest to the security module. The signature module 300 uses the device's private key to perform a digital signature, obtains the ciphertext signature, and encapsulates it along with the algorithm identifier, device ID, and public key fingerprint into a signature file (signature.json). This module is responsible for exporting the verification public key, but exporting the private key is strictly prohibited.

[0045] The offline audit delivery robot includes a chained record module 400. This module maintains a local append-only ledger. Each time a new evidence package is generated, the hash of the last record in the ledger is read as the preceding hash (prev_hash), and combined with the current task summary to construct a new record. This module calculates the hash of the new record and appends it to the ledger, while simultaneously exporting a tail file (ledger_tail.json) containing key information to ensure the temporal continuity and immutability of evidence generation.

[0046] The offline audit delivery robot includes a packaging output module 500. This module collects audit deliverables, manifest files, signature files, public key files, and tail files, uses a compression algorithm to encapsulate them into a standard ZIP format evidence bundle, and outputs it through the communication interface.

[0047] The offline audit delivery robot includes a verification module 600. This module provides independent verification logic that can run on robot self-checks or third-party terminals. Its execution process includes: decompressing and recalculating the file hash and comparing it with the manifest, normalizing and recalculating the manifest digest, and verifying the digital signature using a public key. The module ultimately outputs a deterministic conclusion of whether the verification passed or failed.

[0048] The offline audit delivery robot includes an intelligent explanation module 700. This module loads a local large language model, reads structured JSON reports, and converts descriptions of technical vulnerabilities into remediation suggestions and risk explanations in natural language. Simultaneously, it generates an explanation trace file containing model hashes, prompt word hashes, and input evidence hashes. The explanation document and trace trace are fed back to the evidence solidification module 200, triggering a new round of solidification and signing, thereby incorporating the AI-generated content into the integrity protection scope of the evidence package.

[0049] See attached document Figure 2 The audit evidence package provided by this invention uses a standard compressed archiving format as its physical storage carrier, with ZIP format being preferred in specific embodiments. The file naming convention uses the prefix "evidence_bundle_" combined with a unique task identifier to ensure the uniqueness and identifiability of the evidence package when stored in the file system. The decompressed evidence package is logically divided into an audit deliverable area and a verification metadata area, which together constitute a self-contained delivery unit with integrity verification capabilities.

[0050] The audit deliverables area is located at the core of the evidence package directory structure, storing the raw technical documents generated by the offline audit delivery robot. This area includes a structured audit report file (report.json), recording machine-readable data such as vulnerability details, dependencies, and scan results; a visual audit report file (report.html), providing web-formatted results that are easy for humans to read; a risk statistics file (report_risk_stats.json), recording a summary of risk statistics; and an audit evidence fragment file (report_evidence.md), recording specific code snippets or vulnerability snapshots. These files constitute the main content to be verified and are the direct output of the audit work.

[0051] The verification metadata area contains a series of control files used to verify the integrity, authenticity, and generation sequence of documents. This area includes at least a manifest file (manifest.json), recording the relative path, byte size, and hash fingerprint of each file in the deliverables area; a signature file (signature.json), storing the ciphertext and public key fingerprint of the evidence packet digest digitally signed using the device's private key; a ledger tail file (ledger_tail.json), recording the last record of the current task in the device's local ledger and its preceding and following hash links; and a public key file (e.g., ed25519_public.pem), used by third parties to directly verify the signature validity in an offline environment. During the generation process, the robot first writes the audit deliverables to a temporary directory, and then generates the metadata files. The manifest file establishes a file index and hash mapping, the signature file locks the manifest content, the ledger tail file locks the task sequence, and the public key file provides the basis for computation, thereby achieving integrated delivery of audit and verification data.

[0052] See attached document Figure 2 This invention also provides a manifest file construction protocol, defining a metadata structure describing the integrity of deliverables. The manifest file (manifest.json) adopts a structured format, and its root object contains basic metadata fields that identify the audit context: the structure version number field indicates the specification version; the generation timestamp field records the UTC time accurate to the second; the task unique identifier field associates the specific audit batch; the device hardware identifier field records the robot's unique hardware feature code to achieve hardware-level binding; and the audit tool information field records the engine name and version to ensure that the results are reproducible.

[0053] The manifest file's data structure includes a file fingerprint list field. Each element in this array structure corresponds to an audit deliverable file, recording its path relative to the root directory, exact byte count, and SHA-256 hash value. The bot iterates through all deliverable files and populates this list during generation, ensuring that all technical documents within the evidence package are indexed and constrained.

[0054] To ensure the uniqueness of the digest calculation, this invention defines standardized encoding rules: when serializing list data objects, they must be sorted in ascending lexicographical order by key name, all whitespace characters such as spaces and newlines must be removed, and UTF-8 encoding must be enforced. This process eliminates serialization differences, ensuring that identical content produces a consistent binary stream.

[0055] The manifest file also includes an evidence package summary field, which stores the global integrity check value of the entire evidence package. The calculation logic for this value employs a recursive inclusion and self-exclusion mechanism. Specifically, the offline audit delivery robot first constructs a manifest data object containing all fields except the evidence package summary field, denoted as the object to be calculated. Then, the above-mentioned normalization encoding operation is performed on the object to be calculated to obtain normalized binary data. Finally, a hash calculation is performed on the normalized binary data to obtain the evidence package summary value, and this value is written into the evidence package summary field of the manifest file, completing the final construction of the manifest file. The formula for calculating the evidence package summary is as follows: ;in, This represents the calculated summary value of the evidence package; This represents the selected cryptographic hash function, specifically the SHA-256 algorithm in this embodiment; This represents the aforementioned normalized coding operation; This represents the inventory underlying data object that does not contain the evidence package summary field. Through this calculation process, the evidence package summary value can indirectly override and lock all metadata recorded in the inventory file and all audit deliverable files indexed by the file fingerprint list.

[0056] See attached document Figure 2 This invention provides a signature file and key binding protocol. This protocol defines a data structure for carrying digital signatures and their verification parameters, thereby ensuring the non-repudiation of the evidence package and its binding to the device identity. The signature file is typically named signature.json, and it contains basic information fields for determining the signature context, an encryption algorithm identifier field, a public key index field, and a digital signature ciphertext field.

[0057] The basic information fields in the signature file mainly include the structure version number, generation timestamp, task identifier, and device identifier. The structure version number indicates the format version of the signature file itself; the generation timestamp records the Coordinated Universal Time (UTC) at which the signing operation was completed; the task identifier and device identifier fields must be completely consistent with their corresponding fields in the manifest file to ensure the logical association between the signature file and a specific audit task and a specific offline audit delivery robot. The signature file must contain an evidence package digest copy field, the value of which must be exactly equal to the evidence package digest value calculated in the manifest file. The existence of this field clearly indicates that the signature object points to the current evidence package state; the verifier must first compare this field with the digest calculation value in the manifest file before verifying the signature.

[0058] The signature file explicitly specifies the cryptographic algorithm used to generate the signature through the signature algorithm field, such as the Ed25519 algorithm or the Elliptic Curve Digital Signature Algorithm. To accurately identify and verify the public key in multi-key or key rotation scenarios, the signature file includes a public key fingerprint field. This fingerprint field stores the digest value obtained by hashing the content of the public key file published by the offline audit delivery robot. During verification, the third-party terminal calculates the hash value of the public key file carried in the evidence package and compares it with this fingerprint field, thereby confirming that the public key used is indeed the one intended by the signer, achieving an index binding between the public key and the signature.

[0059] The core digital signature generation logic is based on a private key protected by the device's internal security module. The offline audit delivery robot reads the evidence packet digest value calculated from the manifest file, converts it into a standard UTF-8 byte sequence as the message to be signed, and uses the device's private key to perform an encrypted signature operation on the message. The generated binary signature result is Base64 encoded and written to the signature ciphertext field of the signature file. The mathematical expression of this signature generation process is as follows: ;in, This represents the generated digital signature value, which corresponds to the ciphertext field content in the signature file. Represents the unique hardware private key used by the device. Performing asymmetric signature operations; Represents character set encoding conversion operation; This represents the digest value of the evidence package. Through this protocol, the integrity verification value of the audit evidence package is encrypted and bound to the physical identity of the offline audit delivery robot. Any entity that does not hold the hardware private key cannot generate a valid signature file, thereby achieving hardware-level traceability and anti-counterfeiting of audit deliverables.

[0060] See attached document Figure 2 This invention provides a chain-record structure protocol, which defines a data organization format to ensure the temporal continuity of audit tasks and the immutability of historical records. The evidence package contains a chain-record end file named ledger_tail.json, whose content is generated in real-time by the chain-record module of the offline audit delivery robot upon completion of the audit task, and serves as the temporal location certificate for that audit task throughout the device's entire lifecycle.

[0061] The last file in the chain contains a record sequence number field, a previous record hash field, a current evidence package digest field, and a current record hash field. The record sequence number field stores a strictly incrementing integer starting from zero, identifying the position of the current audit task in the device's historical operation sequence. The previous record hash field stores the hash value of the previous record in the device's local ledger, establishing a cryptographic link between the current task and historical tasks. If the current record is the first record during device initialization, this field is set to a preset genesis hash value. The current evidence package digest field stores the evidence package digest value calculated from the manifest file, thus strongly binding the chain structure to the currently delivered set of entity files.

[0062] The offline audit delivery robot maintains a full ledger file named `ledger.jsonl` in its internal storage. This full ledger file is an append-only log file, with each line corresponding to a chain of records for a historical audit task. The last record in the evidence package is a copy of the most recently appended line of data in this full ledger file. By including this last record in a single delivery's evidence package, the system can show the verifier the relative position of the task in the device's operation history and allows for the reconstruction of the device's audit job timeline when multiple evidence packages from different time points are aggregated, thereby detecting whether there are missing intermediate records or concealed tasks.

[0063] The core anti-tampering mechanism of the chained record relies on the calculation logic of the hash field of the current record. The chained record module combines the record sequence number, the hash of the previous record, the current evidence packet digest, and metadata including timestamps and device identifiers into a single object to be calculated. After normalization and encoding, a hash operation is performed, and the result is the hash of the current record. This value also serves as the input to the hash of the previous record when the next record is generated, forming a sequential hash chain structure. The mathematical expression of this calculation process is as follows: ;in, Representing the The hash value of this record generated by this audit task; This represents a one-way cryptographic hash function consistent with the manifest file generation process, such as SHA-256. This represents a normalized serialization function, used to sort input fields in a fixed lexicographical order and convert them into a standard byte stream to ensure the determinism of the computation results; Representing the The record number of the sub-task; Representing the The hash value of the previous record referenced in the next task record is strictly equal to the hash value of the previous record. The hash value of this record generated by the secondary task Representing the The evidence package summary value for this task; This represents a set of metadata including task identifier, device identifier, and generation timestamp. Based on this formula, any [database / database] targeting historical records... Or the currently delivered content Any alteration will result in the calculated... This ensures a mismatch between the recorded value and the audit history, thus providing dual integrity protection for both the audit history and the delivered content.

[0064] See attached document Figure 3 , Figure 3 This is a schematic diagram of the audit evidence package generation process according to an embodiment of the present invention. The present invention provides an audit delivery method for an offline audit delivery robot, which mainly includes two core steps in the audit job initiation and generation stages: obtaining a set of target code files to be audited and generating a set of audit deliverable files.

[0065] In the step of obtaining the set of code files to be audited, the offline audit delivery robot establishes a physical or logical connection with an external data source through communication interface 40. The specific form of this external data source includes, but is not limited to, removable storage media, read-only optical discs, or file servers connected via an offline local area network. Processor 10 receives audit task instructions input by the user, which contain path information of the target to be audited. In response to this instruction, processor 10 calls audit generation module 100 to preprocess the data under the specified path. Audit generation module 100 first identifies the file organization of the target to be audited. When the target to be audited is a source code directory, audit generation module 100 directly traverses the directory structure to build a file index; when the target to be audited is a software artifact compressed package or disk image, audit generation module 100 first performs decompression or mounting operations, mapping the data stream to a readable file system structure. During this process, audit generation module 100 filters non-code files and extracts a valid set of code files to be audited, preparing data for subsequent security analysis.

[0066] In the step of generating the audit deliverables file set, the audit generation module 100 reads the static analysis rule base and dependency vulnerability database stored in the memory 20 and performs automated security checks on the code file set to be audited. This check process is performed entirely offline, cutting off any data interaction with the Internet. The audit generation module 100 performs abstract syntax tree parsing, control flow analysis, and software composition analysis on the code file set to be audited, identifying security vulnerabilities, compliance risks, and open-source component dependencies in the code. The audit generation module 100 outputs all analysis results in a structured format to a specified output directory, forming the audit deliverables file set.

[0067] The audit deliverables collection consists of multiple electronic files with specific filenames and formats to ensure standardized evidence. This collection includes structured audit reports, risk statistics files, and audit evidence extracts. The structured audit report file, named `report.json`, records all details of each detected vulnerability in JavaScript object notation, including vulnerability type, severity level, remediation recommendations, and involved file paths. The risk statistics file, named `report_risk_stats.json`, aggregates statistical values ​​for different risk levels and vulnerability categories to quantitatively assess the overall security posture of the project. The audit evidence extract file, named `report_evidence.md`, records the specific source code snippets that triggered security rules, their corresponding line number contexts, and function call stack information in markup language format, serving as direct technical evidence supporting the audit conclusions.

[0068] In addition, the audit generation module 100 generates a visual audit report file named report.html. This file renders the data in report.json into Hypertext Markup Language format for easy human reading and review. After generating all the above files, the audit generation module 100 completes the audit job generation phase and stores the audit deliverables file set, including report.json, report.html, report_risk_stats.json, and report_evidence.md, in the file system, serving as the input data basis for the subsequent evidence solidification module 200 to generate the inventory and calculate the summary. This process ensures that the source of the audit data is closed and controlled, not only solidifying the content of the audit results but also defining the data boundaries protected by the subsequent verification process.

[0069] See attached document Figure 3 This invention provides an audit delivery method for an offline audit delivery robot. Following the audit job initiation and generation phase, the method enters the evidence consolidation and summary calculation phase. In this phase, the offline audit delivery robot uses the evidence consolidation module 200 to perform integrity encapsulation on the set of audit deliverable files generated in the previous steps, generating a list file containing the digital fingerprints of all deliverables, and calculating a global summary to characterize the integrity of the entire evidence package.

[0070] During the manifest file generation process, the evidence consolidation module 200 first traverses the specific directory in the memory 20 that stores the set of audit deliverable files. For each audit deliverable file in this directory, the evidence consolidation module 200 reads the file's binary data stream and calculates the file's hash value using the secure hash algorithm SHA-256. This calculation process ensures that the content of each file is uniquely mapped to a fixed-length hexadecimal string. The evidence consolidation module 200 constructs a manifest data structure to be serialized in memory, which contains a file list field. For each file traversed, the evidence consolidation module 200 writes the file's relative path, file size in bytes, and the calculated file hash value as a file object item into the aforementioned file list field.

[0071] Subsequently, the evidence solidification module 200 injects metadata information into the manifest data structure to achieve traceability binding of the audit task. The injected metadata includes the device's unique identifier obtained from the operating system's underlying layer, the unique task identifier for this audit task, the UTC generation timestamp conforming to the ISO 8601 standard, and the name and version number of the audit tool used to perform this audit. At this point, the manifest data structure contains full information describing all output files of this audit and their generation environment. However, at this moment, the evidence package summary field in the manifest data structure is temporarily empty or not included in the serialization scope to avoid circular dependency issues when calculating hashes.

[0072] After constructing the manifest data structure, the evidence solidification module 200 performs normalization encoding. Because the order of key-value pairs may be inconsistent during default serialization of JSON data, and differences in spaces and newline characters can lead to different hash calculation results, normalization must be performed to ensure the determinism of the digest calculation. The evidence solidification module 200 sorts all keys in the manifest data structure lexicographically and converts the data structure into a compact format by removing spaces and newline characters between all key-value pairs and fields, thus converting the data structure into a binary byte stream.

[0073] Based on the normalized binary byte stream, the evidence consolidation module 200 calculates the evidence package digest. This digest is the root fingerprint for verifying whether the entire audit deliverables set has been tampered with. The evidence consolidation module 200 performs a SHA-256 hash operation on the normalized byte stream of the manifest data after removing the evidence package digest field. The formula for calculating the evidence package digest is as follows: in, This represents a summary of the calculated evidence package; This represents the original inventory data object that has not yet been populated with the evidence package summary field; This represents the normalized encoding function for key sorting and whitespace removal mentioned above. This represents a secure hash algorithm. After calculation, the evidence solidification module 200 will obtain... A hexadecimal string is filled into the evidence package digest field of the original manifest data structure to form the final manifest file data object. Finally, the evidence solidification module 200 serializes this object and writes it to the storage 20, naming it manifest.json. At this point, the evidence solidification module 200 has completed the solidification of the audit deliverables and their metadata. The generated manifest.json not only records the integrity verification value of each file, but its own evidence package digest also provides a unique subject for subsequent digital signature steps.

[0074] See attached document Figure 3 This invention provides an audit delivery method for an offline audit delivery robot. After completing the evidence solidification and digest calculation stages, it enters the digital signature and chain locking stage. In this stage, the offline audit delivery robot uses a hardware-level encryption mechanism to digitally sign the evidence package digest and constructs a hash chain based on a local append-only ledger, thereby achieving identity authentication of the entity that generates the audit deliverable and tamper-proof locking of the generation sequence.

[0075] The signature module 300 first receives the calculated evidence packet digest from the evidence solidification module 200. To ensure the non-repudiation of the evidence packet, the signature module 300 sends a signature command to the security module 30. The security module 30 is a trusted computing unit or secure unit chip integrated on the robot's hardware circuit board. Its internal secure storage area has a unique device asymmetric encryption private key pre-set, which is configured not to be read or exported from outside the chip. The signature module 300 inputs the UTF-8 encoded byte stream of the evidence packet digest as the data to be signed to the security module 30. The security module 30 uses the pre-set private key inside the chip to perform calculations on the input data using the Ed25519 signature algorithm or the elliptic curve digital signature algorithm, and outputs the corresponding digital signature value.

[0076] The signature module 300 receives the digital signature value and constructs a signature file data object by combining it with the audit task's metadata. This object contains a structure version number, UTC generation time, task identifier, device identifier, a digest of the evidence packet that is completely identical to that in the manifest file, a signature algorithm identifier, the signer's public key fingerprint, and a Base64-encoded digital signature value. The public key fingerprint is a SHA-256 digest calculated based on the device's public key file byte stream, used for quickly indexing the public key required for verification. The signature module 300 serializes the constructed data object into a signature.json file and stores it in the audit deliverables directory. This file establishes a unique cryptographic binding between the evidence packet digest and the physical device identity.

[0077] After completing the signing operation, the chain record module 400 initiates a chain locking process to ensure the continuity and traceability of evidence generation. The chain record module 400 accesses the local ledger file in the storage 20, which is an append-only log file recording summary information of all audit tasks historically performed by the device. The chain record module 400 reads the last record in the local ledger file and extracts its record hash value as the preceding hash for this operation. If the local ledger file does not exist or is empty, the chain record module 400 uses a predefined genesis hash value as the preceding hash.

[0078] The chained record module 400 constructs a chained record object for this audit task in memory. This object contains an incrementing record sequence number, the current UTC record time, device identifier, task identifier, a digest of the evidence packet generated by this task, and the obtained preceding hash. To form a tamper-proof hash chain structure, the chained record module 400 needs to calculate the record hash of the current record. The calculation process first normalizes all fields in the chained record object except the record hash field, generating a normalized byte stream, and then performs a SHA-256 hash operation on this byte stream. The formula for calculating the chained record hash is as follows: ;in, This represents the record hash of the current entry; This represents a collection of metadata including serial number, timestamp, and device ID; This indicates a summary of the evidence package used in this audit; This represents the hash value of the previous record; Indicates the concatenation or combination of data fields; This represents a normalized serialization function.

[0079] Calculated Subsequently, the chain record module 400 fills it into the chain record object, forming a complete chain entry. The chain record module 400 performs two output operations: First, it appends the complete chain entry to the local ledger file in the storage 20, ensuring the persistent storage of the evidence chain on the device, so that any modification to the history will cause all subsequent record hash verifications to fail; second, it serializes the complete chain entry into a separate ledger_tail.json file and places it in the audit deliverables directory. This last record file serves as the anchor link between the offline device history and the currently delivered evidence package, enabling third parties to verify the chronological position of the current evidence package in the device's operational history.

[0080] See attached document Figure 3This invention provides an audit delivery method for an offline audit delivery robot. After the digital signature and chain locking stages are completed, the method enters the packaging and delivery stage. In this stage, the packaging output module 500 performs the final encapsulation operation, integrating the scattered audit evidence files and verification metadata files into a single standardized delivery carrier to facilitate physical transfer and subsequent verification in an offline environment.

[0081] The packaging output module 500 first creates a collection structure of files to be packaged in memory or temporary storage area. This collection gathers all original audit deliverables from the audit generation module 100, specifically including JSON files of code audit results, visual HTML report files, risk statistics files, and Markdown files of audit evidence fragments. Simultaneously, the packaging output module 500 adds the manifest.json file generated by the evidence solidification module 200, the signature.json file generated by the signature module 300, and the ledger_tail.json file, the last record of the chain generated by the chain record module 400, to this collection of files to be packaged. Furthermore, the packaging output module 500 extracts the device public key file or public key certificate file from the storage 20, adding it to the collection as a necessary component for third-party offline signature verification.

[0082] The output packaging module 500 adheres to a strict key isolation strategy when performing file collection. This module is configured to only have the right to read and contain public key information, while being unable to access or extract the device's private key stored internally in the security module 30 at either the hardware or software level. This physical and logical isolation mechanism ensures that the evidence package contains only the public key and absolutely no private key, so that even if the evidence package circulates in an uncontrolled third-party environment, the device's identity credentials will not be leaked, thus maintaining the unforgeability of the digital signature and the long-term trustworthiness of the device.

[0083] After confirming that all necessary files are ready and the private key has been strictly excluded, the packaging output module 500 calls the standard ZIP compression algorithm to perform lossless compression and packaging of the file set. The packaging output module 500 reads the task identifier recorded in the manifest file and names the output compressed file with a fixed prefix of `evidence_bundle_` followed by the specific task identifier string and the `.zip` extension. This naming convention ensures the uniqueness and easy identification of different audit task deliverables at the file system level. The generated ZIP evidence package is transmitted to the communication interface 40 of the offline audit delivery robot, allowing operators to copy it via USB or download it via the offline LAN, thus completing the complete delivery process for a single offline audit task.

[0084] See attached document Figure 4This invention provides a third-party verification method for offline audit evidence. Before executing specific verification logic, it first performs a verification environment preparation step. In this step, the third-party verification terminal is in an independent offline environment physically isolated from the offline audit delivery robot. This terminal does not have internet connectivity to ensure the independence and security of the evidence verification process. The verification module 600, as a set of pre-compiled executable programs or scripts, is pre-installed or temporarily loaded into the memory of the third-party verification terminal. The verification module 600 incorporates hash calculation algorithm standards, standardized encoding rules, and digital signature verification algorithm libraries that are completely consistent with those of the offline audit delivery robot.

[0085] The third-party verification terminal receives the compressed evidence package to be verified from the communication interface 40 of the offline audit delivery robot via a universal serial bus interface or a controlled unidirectional offline network interface. This evidence package file is encapsulated in ZIP format, and the filename contains a unique task identifier. Upon receiving the evidence package, the verification module 600 first performs a decompression operation in the restricted sandbox environment or temporary working directory of the third-party verification terminal, restoring all files within the evidence package to independent file entities in the file system. During the decompression process, the verification module 600 verifies the integrity of the ZIP container itself, ensuring that the compressed package does not contain bit flipping or truncation errors.

[0086] After decompression, the verification module 600 performs a basic compliance scan of the decompressed directory structure. The verification module 600 traverses the file list in the directory, checking for the presence of key metadata files defining the validity of the audit evidence package. These include the manifest.json file, the signature.json file, the ledger_tail.json file (the last record in the chain), and the public key file used for authentication. Simultaneously, the verification module 600 checks whether the directory contains the audit deliverable entity files referenced in the manifest file, such as the audit report JSON file, risk statistics files, and audit evidence Markdown files. If the verification module 600 detects any missing key metadata files or a file directory structure that does not conform to the preset evidence package protocol specifications, it will directly output a format error message and terminate the verification process. Only when the file structure is complete and all key files are present will the verification module 600 initialize subsequent cryptographic calculations and logical verification subroutines.

[0087] See attached document Figure 4 The present invention provides a third-party verification method for offline audit evidence, specifically including a triple verification logic executed by the verification module 600, which sequentially verifies the integrity, authenticity and non-repudiation of the evidence package at the mathematical and cryptographic levels.

[0088] After the basic environment verification passes, the verification module 600 first performs a first-level integrity verification to confirm that the audit deliverable entity files within the evidence package have not undergone any bit-level tampering or corruption during transmission and storage. The verification module 600 reads the manifest.json file in the decompressed directory and parses the files field, which contains the file fingerprint list. For each file record in the list, the verification module 600 locates the corresponding entity file in the local file system based on the relative path in the record and reads the full byte stream of the entity file in binary read-only mode. The verification module 600 uses the SHA-256 hash algorithm to calculate the actual hash value of the entity file and compares this actual hash value bit-by-bit with the SHA256 field value recorded in the manifest file. Simultaneously, the verification module 600 also verifies whether the actual byte size of the entity file strictly matches the bytes field value recorded in the manifest file. If the hash values ​​and file sizes of all audit deliverable entity files match, the first layer of verification passes; if the hash value or size of any file does not match, the verification module 600 will determine that the integrity of the evidence package is compromised.

[0089] Subsequently, the verification module 600 performs a second layer of authenticity verification to verify the integrity of the manifest.json file itself and its consistency with the signature file signature.json, preventing the manifest file from being maliciously replaced or modified. The verification module 600 preprocesses the manifest file data object in memory, removing the stored bundle_hash_sha256 evidence packet digest field to break the self-referencing cycle of hash calculation. Next, the verification module 600 performs normalization encoding on the processed manifest file data object. Normalization encoding includes sorting the keys lexicographically, removing all meaningless whitespace and newline characters, and forcing the use of UTF-8 character set encoding, thereby converting the structured data into a unique normalized byte sequence. The verification module 600 then calls the SHA-256 algorithm again on this normalized byte sequence to calculate the recalculated evidence packet digest. The verification module 600 reads the bundle_hash_sha256 field value recorded in the signature file signature.json and compares it with the recalculated evidence packet digest. Only when the two are completely consistent can it be proven that the inventory document has not been tampered with and accurately reflects the status of the original audit deliverables.

[0090] Finally, the verification module 600 performs a third layer of non-repudiation verification to confirm that the evidence package was indeed generated by the offline audit delivery robot holding the specific private key, and that the signature has not been forged. The verification module 600 reads the public key file attached to the evidence package, calculates the SHA-256 fingerprint of the public key file, and compares it with the signer_pubkey_fingerprint_sha256 field in the signature file signature.json to ensure that the public key itself has not been replaced. After confirming the validity of the public key, the verification module 600 extracts the signature algorithm identifier signature_alg (e.g., Ed25519) and the Base64 encoded signature value signature_base64 from the signature file. Using the extracted public key, signature value, and the evidence package digest (i.e., the message to be signed) confirmed in the second layer of verification, the verification module 600 executes the digital signature verification algorithm. The above verification process can be represented by the following core logic formula: ;in, This is the final verification result; Total number of files; Use the SHA-256 hash function; For the first One entity file; For the first recorded in the inventory file The hash value of each file; For normalized coding functions; For the manifest file object after removing the summary field; A summary of the evidence package recorded in the signature file; This is a function for verifying digital signatures. For public keys; This is the digital signature value. The verification module 600 only determines that the evidence package has passed all verifications if all three logical judgments in the formula are true.

[0091] See attached document Figure 4 This invention provides a third-party verification method for offline audit evidence, specifically including verification result determination logic executed by verification module 600. This logic, located after the three verification steps, serves as the final decision gating stage, responsible for summarizing the intermediate states of integrity verification, authenticity verification, and non-repudiation verification, and outputting the final binary verification conclusion based on a preset logic decision tree. Verification module 600 is configured to recognize the evidence package as valid only when all preceding verification steps return positive results, and to recognize the evidence package as invalid if any preceding verification step returns a negative result.

[0092] The verification module 600 first checks the output status of the integrity check. If, during the file-by-file hash comparison, the calculated hash value of any entity file is inconsistent with the hash value recorded in the manifest file, or the file sizes do not match, the verification module 600 will generate an integrity error flag. Secondly, the verification module 600 checks the output status of the authenticity check. If, during the manifest file normalization reconstruction and digest recalculation process, the calculated evidence packet digest is not exactly equal to the digest recorded in the signature file, the verification module 600 will generate an authenticity error flag. Thirdly, the verification module 600 checks the output status of the non-repudiation check. If the public key fingerprint comparison fails, or the cryptographic verification result of the digital signature algorithm on the signature value is false, the verification module 600 will generate a non-repudiation error flag.

[0093] The verification module 600 performs a logical OR operation to identify the presence of any error flags. If any one or more of the integrity error flag, authenticity error flag, or non-repudiation error flag are detected, the verification module 600 determines that the entire verification process has failed. In this case, the verification module 600 outputs a verification failure flag to the user interface and outputs a detailed error log indicating the verification stage and specific file object that caused the failure, thereby prompting the user that the evidence package may have been tampered with, corrupted, or of untrustworthy origin.

[0094] Conversely, only when no errors are generated in the integrity verification, authenticity verification, and non-repudiation verification stages—that is, when the hash values ​​of all files match, the evidence package digest is recalculated consistently, and the digital signature verification passes—will the verification module 600 execute logic and operations to confirm the closed-loop integrity of the evidence chain. In this case, the verification module 600 determines that the entire verification process is successful and outputs a verification pass flag to the user interface. This verification pass flag indicates that all data in the evidence package has not been modified since its generation by the offline audit delivery robot and was indeed signed by a device holding a specific private key. The above verification result determination logic is defined by the following formula: ;in, This indicates the final verification result output; This represents the integrity verification status value, with a value of 1 indicating success and 0 indicating failure. This represents the status value of the authenticity verification, with a value of 1 indicating success and 0 indicating failure. This represents the status value of the non-repudiation check, with a value of 1 indicating success and 0 indicating failure. This represents a logical AND operation. This formula ensures that the system will only output a PASS result if the evidence package satisfies all security attributes.

[0095] See attached document Figure 1 and appendix Figure 3This invention provides a reliable explanation and tracing method based on a local large model. This method, as an extended implementation of the offline audit delivery process, is executed by the intelligent explanation module 700 in the offline audit delivery robot. The intelligent explanation module 700 is configured to load a pre-built lightweight large language model inference engine from memory 20 in an offline environment without network connectivity. This inference engine and model weight file are permanently stored on the local device and do not rely on external online services.

[0096] The intelligent explanation module 700 first reads the structured audit report file, such as report.json, output by the audit generation module 100. The intelligent explanation module 700 parses this report file, extracting risk statistics, vulnerability details fields, and relevant source code snippet references. Subsequently, the intelligent explanation module 700 calls locally stored prompt word templates, using the extracted structured data as input context to the large language model inference engine. The inference engine performs calculations, outputting a risk summary file (explain_summary) in natural language format and detailed discovery explanation files (explain_findings) for specific vulnerability entries. During the generation process, the intelligent explanation module 700 forces the model to retain anchor references to the original evidence files in the output text. These anchor references include the file path, line number, and hash identifier of the corresponding code snippet.

[0097] While generating the aforementioned explanatory text, the intelligent explanation module 700 simultaneously constructs a traceability file, `explain_trace`. This traceability file aims to record all deterministic input factors upon which the generated explanatory text depends, preventing the explanatory content from being forged or replaced by an unauthorized model. The intelligent explanation module 700 calculates the hash value of the currently loaded large language model weight file, the hash value of the prompt word template used, and the hash value of the original audit evidence fragment input to the model. The intelligent explanation module 700 writes these hash values, along with the hyperparameters used in the inference process (including temperature coefficient, random seed, and maximum token count), into the traceability file. The logic for generating the traceability file is defined by the following formula: ;in, This represents the generated traceability record data structure. This represents the SHA-256 digest of the local large language model weight file. This represents the SHA-256 digest of the prompt word template file. This represents the SHA-256 digest of the audit evidence data used as context input. This represents the set of inference configuration parameters. This represents the UTC timestamp of the generation operation.

[0098] After the explanation and source tracing documents are generated, the offline audit delivery robot automatically triggers a re-signature process to ensure the consistency of the evidence package. The evidence consolidation module 200 adds the newly generated risk summary document, detailed discovery explanation document, and source tracing document to the document set to be delivered. The evidence consolidation module 200 performs a traversal operation on the updated document set, recalculates the SHA-256 hash value of all documents, including the explanation document, and generates a new manifest.json file containing the fingerprints of all documents.

[0099] Subsequently, the evidence solidification module 200 performs normalized encoding on the new manifest file and calculates the updated evidence packet digest `bundle_hash`. The signature module 300 calls the device private key in the security module 30 to digitally sign the updated evidence packet digest, generating an updated signature file `signature.json`. The chain record module 400 generates a new chain record `ledger_tail.json` based on the updated evidence packet digest. Finally, the packaging and output module 500 encapsulates the original audit report, explanation file, traceability file, new manifest file, new signature file, chain record, and public key file into a compressed package. This process ensures that the explanatory content generated by the model is included in the scope of evidence solidification and tamper-proof protection, and third parties can verify the source of the explanatory content by verifying the hash value in the traceability file.

[0100] See attached document Figure 1 and appendix Figure 3 This invention provides a blockchain digest anchoring method. This method, as an extended implementation of the offline audit delivery process, is executed by the blockchain anchoring module within the offline audit delivery robot. The blockchain anchoring module is configured to extract key digest information to generate an anchoring data payload for blockchain notarization after the evidence solidification module 200 completes the evidence package digest calculation and the signing module 300 completes the digital signature.

[0101] The blockchain anchoring module first accesses the generated manifest.json file, reading the evidence packet digest that has been normalized, encoded, and calculated. Simultaneously, the module accesses the signature.json file, reading the public key fingerprint used to verify the device's identity. The blockchain anchoring module combines the evidence packet digest, public key fingerprint, and task identifier to construct a standardized evidence storage data structure. This data structure strictly adheres to the principle of minimum on-chain data storage, containing only a fixed-length hash value and metadata identifier, and excluding any audit report text, source code snippets, or vulnerability statistics details. This construction method ensures that sensitive information and intellectual property of the audit target are not leaked when storing evidence through public blockchain networks or industry consortium blockchains. The construction logic of the evidence storage data structure is defined by the following formula: ;in, This represents the payload of the evidence storage data to be uploaded to the blockchain. A unique identifier representing this audit task; This represents the SHA-256 digest value of the evidence packet; A fingerprint representing the device's public key; This indicates the UTC timestamp generated by the evidence package.

[0102] After generating the evidence delivery payload, since the offline audit delivery robot operates in a physically isolated environment, the blockchain anchoring module outputs the evidence delivery payload to a mobile storage medium or a one-way transmission gateway via communication interface 40. An external networked terminal receives the evidence delivery payload and encapsulates it into a blockchain transaction, sending it to the target blockchain network. After the blockchain network node confirms the transaction and packages it into a block, it generates an evidence delivery receipt containing the transaction hash, block height, and block timestamp. This receipt serves as supplementary verification material, independent of the compressed evidence package, to prove that the audit deliverable existed at a specific point in time and has not been tampered with. When verifying the evidence, a third party, in addition to performing local hash verification, can also query records on the blockchain to compare the evidence package digest stored on-chain with the locally recalculated evidence package digest, thereby achieving integrity anchoring based on the distributed ledger.

Claims

1. An offline audit delivery robot, characterized in that, It includes a processor (10), a memory (20), a security module (30), and a communication interface (40). The processor (10) executes and runs the instructions in the memory (20): The audit generation module (100) is used to analyze the set of target code files to be audited obtained through the communication interface (40) and generate a set of audit deliverable files containing vulnerability details and evidence fragments; The intelligent explanation module (700) is used to run a local large language model and generate risk explanation documents and model traceability records in natural language format based on the audit deliverables file set. The evidence solidification module (200) is used to calculate the hash value of each file in the audit deliverables file set and the risk interpretation document and construct a list file, and calculate a global evidence package summary for the list file; The signature module (300) is used to send the evidence packet digest to the security module (30), call the device private key stored in the security module (30) to digitally sign the evidence packet digest, and generate a signature file; The chain record module (400) is used to read the hash of the previous record in the device's local ledger, combine it with the evidence package digest to generate a chain tail file containing the hash of the current record, and append the hash of the current record to the device's local ledger. The packaging output module (500) is used to extract the evidence package digest to construct the blockchain evidence payload, and encapsulate the audit deliverable file set, the risk interpretation document, the list file, the signature file, the chain tail file and the blockchain evidence payload into an evidence package, which is then output via the communication interface (40).

2. The offline audit delivery robot according to claim 1, characterized in that, The evidence solidification module (200) performs a normalization encoding operation when calculating the evidence package digest. The normalization encoding operation includes: Construct a manifest data object containing a list of file fingerprints, a generation timestamp, and a device hardware identifier; Sort the keys in the list data object in lexicographical ascending order and remove all whitespace characters between key-value pairs and between fields; The sorted and blank-removed list data object is converted into a UTF-8 encoded binary byte stream, and a SHA-256 hash operation is performed on the binary byte stream to obtain the evidence packet digest.

3. The offline audit delivery robot according to claim 1, characterized in that, The chain record module (400) is used to generate the tail file according to the following logic: Obtain the record number, task identifier, evidence package summary, and previous record hash of the current audit task; The obtained record sequence number, task identifier, evidence package digest, and previous record hash are combined and normalized, and the hash value is calculated as the hash of the current record. The device local ledger forms a sequential hash chain structure. Generate the tail file containing the record number, the hash of the previous record, the evidence package digest, and the hash of the current record.

4. The offline audit delivery robot according to claim 1, characterized in that, The process by which the intelligent explanation module (700) generates the model tracing record includes: Calculate the weight file hash, input prompt word hash, and input evidence fragment hash of the local large language model; The above hash values ​​are combined to generate the model traceability record, and the model traceability record is fed back to the evidence solidification module (200) to be included in the list file, so as to ensure that the source of the risk explanation document is traceable and has not been tampered with.

5. The offline audit delivery robot according to claim 1, characterized in that, The security module (30) is a trusted platform module or a security unit chip, and the storage area of ​​the security module (30) is physically isolated from the general file system of the processor (10) and the memory (20); The security module (30) is used to receive the evidence packet digest through a restricted hardware interface, perform signature calculations and output signature results within the security module (30), and prevent the device private key from being exported by external instructions.

6. An offline audit delivery system, characterized in that, The offline audit delivery robot, as described in any one of claims 1 to 5, operates in a physically isolated offline environment, comprising: The offline audit delivery robot is used to generate and output evidence packages; The audit target carrier is used to store the set of audit target code files and is connected to the offline audit delivery robot through a physical interface. Third-party verification terminal with independent verification module (600). The third-party verification terminal is used to receive the evidence package through a physical mobile storage medium, and uses the verification module (600) to perform integrity verification, source authenticity verification and identity non-repudiation verification on the evidence package without relying on the original generation environment.

7. An audit delivery method, characterized in that, The offline audit delivery robot applied to any one of claims 1 to 5 includes the following steps: Obtain the set of target code files to be audited, analyze them in an offline environment, and generate a set of audit deliverable files. Run a local large language model to generate risk interpretation documents in natural language format based on the aforementioned set of audit deliverables documents; Calculate the hash value for each file in the audit deliverables document set and the risk interpretation document, construct a list file, normalize the list file, and calculate the evidence package digest; The device private key within the security module (30) is used to digitally sign the evidence packet digest, generating a signature file; Read the hash of the previous record in the device's local ledger, combine it with the evidence packet digest to generate a tail file containing the hash of the current record, and append the hash of the current record to the device's local ledger; extract the evidence packet digest to construct the blockchain evidence storage payload; The audit deliverables, risk explanation documents, inventory files, signature files, chain tail files, blockchain evidence payload, and public key files are packaged into an evidence package and output.

8. The audit delivery method according to claim 7, characterized in that, The manifest file contains a list of file fingerprints, which records the relative path, file size in bytes, and file hash value of each file in the audit deliverables file set and the risk interpretation document; The steps for calculating the evidence packet summary include: The manifest file, excluding the evidence packet digest field, is sorted by key and blanks are removed to obtain a normalized byte stream. The SHA-256 value of the normalized byte stream is then calculated as the evidence packet digest.

9. The audit delivery method according to claim 7, characterized in that, It also includes a third-party verification step, which includes: Decompress the evidence package, calculate the actual hash value of each decompressed file, compare it with the hash value recorded in the manifest file, and perform an integrity check. The list file is normalized and recalculated to obtain a recalculation digest. The recalculation digest is then compared with the digest recorded in the signature file to perform an authenticity check. The public key file is used to verify the validity of the digital signature of the signature file, and to verify that the fingerprint of the public key file matches the record in the signature file, thereby performing a non-repudiation verification.

10. The audit delivery method according to claim 7, characterized in that, It also includes the blockchain anchoring step: The blockchain evidence storage payload is exported to an external network environment via a one-way transmission method; The blockchain evidence storage payload is written into the evidence storage contract of the blockchain network to generate an evidence storage receipt containing a block timestamp. The blockchain evidence payload only includes the evidence package digest, the public key fingerprint in the signature file, and the task identifier, and does not include the plaintext content of the audit deliverables file set.

Images