Security detection method and device, storage medium and electronic equipment

Abstract

The invention provides a security detection method, a security detection device, a computer storage medium and electronic equipment, and relates to the technical field of network security. The method comprises the following steps: scanning a component material set to extract a target bill of material from the component material set to obtain an initial software bill of material; obtaining evidence chain certificate information, and determining an initial hash value corresponding to the evidence chain certificate information; the evidence chain certificate information comprises one or more of acquired environment construction fingerprints, tool chain monitoring information, dependency tracking information and running environment fingerprints; and splicing the initial software bill of material with the evidence chain certificate information to obtain a target hash value, and generating a target software bill of material based on the target hash value. According to the method and the device, the credibility deficiency of the SBOM in the software supply chain can be improved, the closed-loop evidence chain is established, and the automatic credibility verification of the SBOM is carried out, so that the verification is simple, convenient and rapid.

Description

Technical Field

[0001] This disclosure relates to the field of network security technology, and in particular to a security detection method, a security detection device, a computer storage medium, and an electronic device. Background Technology

[0002] In the security testing process of the software supply chain, a common approach is to generate a Software Bill of Materials (SBOM) from static source code, followed by a vulnerability detection system that scans the SBOM. Specifically, open-source testing tools are used to scan software source code, container images, binary files, etc., to generate the SBOM, which is then subjected to security vulnerability checks to identify potential flaws. However, this method lacks verifiable records of toolchain and environment configuration, making it impossible to detect whether the toolchain has been compromised or attacked. This results in a lack of credibility and difficulty in verifying the SBOM within the software supply chain. Summary of the Invention

[0003] This disclosure provides a security testing method, security testing device, computer storage medium, and electronic device, thereby improving the credibility of SBOMs in the software supply chain and establishing a closed-loop evidence chain, enabling automated and reliable verification of SBOMs, making verification simple and fast.

[0004] In a first aspect, one embodiment of this disclosure provides a security detection method, which includes: scanning a component materials set to extract a target bill of materials from the component materials set to obtain an initial software bill of materials; obtaining evidence chain credential information and determining an initial hash value corresponding to the evidence chain credential information; the evidence chain credential information includes one or more of the collected environment build fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; concatenating the initial software bill of materials with the evidence chain credential information to obtain a target hash value, and generating a target software bill of materials based on the target hash value.

[0005] Secondly, one embodiment of this disclosure provides a security detection device, which includes: a bill of materials extraction module for scanning a component material set to extract a target bill of materials from the component material set to obtain an initial software bill of materials; a credential acquisition module for acquiring evidence chain credential information and determining an initial hash value corresponding to the evidence chain credential information; the evidence chain credential information includes one or more of the collected environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; and an information splicing module for splicing the initial software bill of materials with the evidence chain credential information to obtain a target hash value, so as to generate a target software bill of materials based on the target hash value.

[0006] Thirdly, one embodiment of this disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the security detection method described above.

[0007] Fourthly, one embodiment of this disclosure provides an electronic device, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the security detection method described above by executing the executable instructions.

[0008] Fifthly, one embodiment of this disclosure provides a computer program product, including a computer program that is executed by a processor to implement the security detection method described above.

[0009] The technical solution disclosed herein has the following beneficial effects:

[0010] The aforementioned security detection method scans the component materials set to extract the target bill of materials (SBOM) and obtain an initial software bill of materials (SBOM). It then acquires evidence chain credentials and determines the initial hash value corresponding to these credentials. The evidence chain credentials include one or more of the following: environment build fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint. The initial SBOM is concatenated with the evidence chain credentials to obtain the target hash value, which is then used to generate the target SBOM. This method utilizes dynamic environment fingerprint binding technology to collect evidence chain credentials such as compiler hashes and container configurations in the build environment in real time. These credentials are then cryptographically hashed together with the initial SBOM, avoiding the high false positive rate problem caused by environment disconnect in traditional static scanning and improving the credibility of the generated SBOM. Furthermore, this method deeply embeds trusted verification into the build execution phase. By implanting kernel-level probes into the CI / CD pipeline, it captures environment fingerprints, toolchain status, and dependency resolution processes in real time. Hardware-level evidence sealing is achieved using a TEE environment, addressing the limitation of traditional static scanning in verifying the authenticity of build behavior.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0013] Figure 1This embodiment illustrates an application architecture diagram of a security detection system.

[0014] Figure 2 This embodiment illustrates a flowchart of one of the security detection methods.

[0015] Figure 3 This embodiment illustrates a flowchart of one method for obtaining evidence chain credential information.

[0016] Figure 4 This illustrative embodiment shows a flowchart of one method for adding trusted verification.

[0017] Figure 5 This embodiment illustrates one encryption flowchart of the implementation method;

[0018] Figure 6 This embodiment illustrates a verification flowchart of one implementation method;

[0019] Figure 7 This embodiment illustrates a schematic diagram of the entire security detection process in one of the implementation methods;

[0020] Figure 8 This diagram schematically illustrates the structure of a safety detection device according to an embodiment.

[0021] Figure 9 This schematic diagram illustrates the structure of an electronic device in an embodiment. Detailed Implementation

[0022] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0023] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0024] The flowchart shown in the attached diagram is merely an illustrative example and does not necessarily include all steps. For example, some steps may be broken down, while others may be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0025] To help those skilled in the art better understand the technical solutions of this disclosure, the relevant content involved in the technical solutions of this disclosure will be introduced below.

[0026] 1) Software Bill of Materials (SBOM): A structured list that records all components of software to describe its constituent parts. Specifically, SBOM provides a component hierarchy graph by recording component names, versions, licenses, and dependencies, supporting dependency chain tracing (e.g., parent component → child component → underlying library), thereby enabling secure governance and transparent management of the software supply chain. Commonly used standard formats include SPDX, CycloneDX, and SWID formats.

[0027] 2) RFC 3161: The IETF (Internet Key Infrastructure Time-Stamp Protocol) standard specifies the method for obtaining digital timestamps from Trusted Time Stamp Authorities (TSAs). Its core value lies in: Time binding: binding the data hash value to an authoritative time source to form immutable time evidence. Long-term validity: even if the original signing certificate expires or is revoked, the timestamp can still prove the validity of the signature at the time of signing for subsequent verification.

[0028] 3) SHA-256: A secure hash algorithm belonging to the SHA-2 cryptographic hash function family. It can convert an input of arbitrary length into a fixed-length 256-bit (32-byte) hash value. It was designed by the National Security Agency (NSA) and approved as a federal information processing standard by the National Institute of Standards and Technology (NIST).

[0029] 4) Continuous Integration / Continuous Deployment (CI / CD): This is a core practice in modern software development, aiming to automate the rapid, efficient, and reliable delivery of code from submission to deployment. Continuous Integration (CI) requires developers to frequently integrate code changes into the main branch (e.g., the master branch) and verify them through automated processes (e.g., builds and tests) to identify and fix errors as early as possible. Continuous Deployment (CD), on the other hand, focuses on automating the release process through related continuous interaction and deployment. Continuous Delivery refers to the automatic deployment of code to pre-release or test environments after passing tests, but manual review and approval are still required for deployment. Continuous Deployment automatically triggers deployment to the production environment after code verification, without manual intervention.

[0030] 5) Hardware Security Module (HSM): A physical computing device dedicated to encryption operations, which protects key security and performs encryption operations through physical and logical protection mechanisms.

[0031] 6) Elliptic Curve Digital Signature Algorithm (ECDSA): Used to ensure data integrity, verify identity, and prevent tampering; its core principle is to use the discrete logarithm problem on elliptic curves (ECDLP) as a security basis to achieve efficient asymmetric encryption operations. Compared with traditional algorithms, it has high security and excellent efficiency, such as fast signing speed, suitable for real-time processing; low resource consumption, suitable for embedded devices and IoT environments, etc.

[0032] 7) SPDX (Software Package Data Exchange): This is an international open standard (ISO / IEC 5962:2021) for describing the composition, licenses, and security information of software components, aiming to improve the transparency and efficiency of compliance management in the software supply chain. The SPDX standard describes the Software Bill of Materials (SBOM) in a unified format (such as tags, RDF / XML), which can include component names, versions, license information, dependencies, and security vulnerability data, thereby enabling cross-organizational information exchange.

[0033] In the context of relevant technologies, the security testing process in the software supply chain typically involves generating a Software Bill of Materials (SBOM) from static source code, followed by scanning the SBOM for vulnerability detection. Specifically, open-source testing tools are used to scan the source code / container image / binary files for components, such as the syntax structure and data flow of the source code or binary files, generating a SBOM compliant with the SPDX standard. Subsequently, the SBOM is subjected to security vulnerability detection. This technical solution actually includes three core steps: first, extracting the dependency tree through file system traversal and package manager parsing; second, calculating the hash value of key files for component identification; and finally, using a rule engine to match vulnerability databases and generate corresponding risk reports. However, the above method has security drawbacks:

[0034] On the one hand, static SBOMs cannot record runtime environment information, and related evidence only covers component hash values, lacking verifiable records of the build toolchain and environment configuration, making it impossible to detect whether the toolchain has been compromised. Furthermore, after a vulnerability match is detected, manual tracing of the impact scope is still required. On the other hand, attackers may tamper with source code and inject malicious dependencies during the software build process, or forge the content of the SBOM after its generation, making downstream users (such as purchasers, operations teams, or security tools) unable to trust the received SBOM. Traditional methods rely on post-event signature verification or manual auditing, which cannot trace the authenticity of specific build stages and are cumbersome.

[0035] In summary, the aforementioned technical solutions are highly susceptible to problems such as a lack of credibility and difficulty in verification of SBOMs in the software supply chain. Therefore, there is an urgent need for a secure testing method that improves the credibility of SBOMs and provides simple verification.

[0036] This disclosure addresses the aforementioned issues by proposing a security detection method applicable to any application scenario requiring security testing of the software supply chain. This method utilizes dynamic environment fingerprinting technology to collect evidence chain credentials such as compiler hashes and container configurations in the build environment in real time. These credentials are then cryptographically hashed together with the initial SBOM, avoiding the high false positive rate problem caused by environmental disconnect in traditional static scanning and improving the credibility of the generated SBOM. Furthermore, this method deeply embeds trusted verification into the build execution phase. By implanting kernel-level probes into the CI / CD pipeline, it captures environment fingerprints, toolchain states, and dependency resolution processes in real time, and leverages the TEE environment to achieve hardware-level evidence sealing, overcoming the limitation of traditional static scanning in verifying the authenticity of build behavior.

[0037] This disclosure presents a security detection method and apparatus, which can be applied to... Figure 1 In the system architecture of the exemplary application environment shown.

[0038] like Figure 1 As shown, the system architecture 100 may include: a terminal device 101 and a server 102. The terminal device 101 communicates with the server 102 via a network 103, and the data storage system 104 can store the data that the server 102 needs to process. Furthermore, the data storage system 104 can be integrated onto the server 102, or it can be located in the cloud or on another server.

[0039] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, there can be any number of terminal devices, networks, and servers. For example, server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0040] The terminal device 101 may include, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices may include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices, while portable wearable devices may include smartwatches, smart bracelets, and head-mounted devices. It should be noted that the security detection method provided in this embodiment can be executed independently on the server 102; correspondingly, the security detection device is generally located in the server 102. The security detection method provided in this embodiment can also be executed independently on the terminal device 101; correspondingly, the security detection device can also be located in the terminal device 101. The security detection method provided in this embodiment can also be executed collaboratively by the terminal device 101 and the server 102, for example, partially executed on the server 102 and partially executed on the terminal device 101. Correspondingly, some modules of the security detection device can be located in the server 102, and some modules can be located in the terminal device 101.

[0041] For example, in one exemplary embodiment, server 102 may scan a component material set to extract a target bill of materials from the component material set to obtain an initial software bill of materials; obtain evidence chain credential information, which includes one or more of the collected environment build fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; and concatenate the initial software bill of materials with the evidence chain credential information to obtain a target hash value, so as to generate a target software bill of materials based on the target hash value.

[0042] However, those skilled in the art will readily understand that the above application scenarios are merely illustrative and are not intended to limit the scope of this exemplary embodiment.

[0043] Next, we will take the aforementioned server 102 as the execution subject and illustrate the application of this security detection method to the aforementioned server 102. Figure 2 A flowchart illustrating a security detection method in this exemplary embodiment is shown below. Figure 2 The security detection method provided in this embodiment includes the following steps S201-S203:

[0044] Step S201: Scan the component material set to extract the target bill of materials from the component material set and obtain the initial software bill of materials.

[0045] Step S202: Obtain the evidence chain credential information and determine the initial hash value corresponding to the evidence chain credential information; the evidence chain credential information includes one or more of the collected environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint.

[0046] Step S203: Concatenate the initial software bill of materials with the evidence chain voucher information to obtain the target hash value, and generate the target software bill of materials based on the target hash value.

[0047] exist Figure 2 The provided technical solution utilizes dynamic environment fingerprinting to collect evidence chain credentials such as compiler hashes and container configurations in the build environment in real time. This information is then cryptographically combined with the initial SBOM for hash calculation, avoiding the high false positive rate issue caused by environmental disconnect in traditional static scanning and improving the credibility of the generated SBOM. Furthermore, this method deeply embeds trusted verification into the build execution phase. By implanting kernel-level probes into the CI / CD pipeline, it captures environment fingerprints, toolchain states, and dependency resolution processes in real time. Hardware-level evidence sealing is achieved using a TEE environment, overcoming the limitation of traditional static scanning in verifying the authenticity of build behavior.

[0048] The following will describe in conjunction with specific embodiments Figure 2 The specific implementation methods of each step in the illustrated embodiment are described in detail below:

[0049] In step S201, the component material set is scanned to extract the target bill of materials from the component material set, thereby obtaining the initial software bill of materials.

[0050] The initial software bill of materials (SBOM) represents the basic SBOM skeleton.

[0051] For example, the component material set can be scanned using open-source detection tools such as Syft and Trivy to automatically extract the complete target material list, thereby obtaining the initial software material list (initial SBOM).

[0052] In one optional embodiment of this disclosure, the component material set includes at least one of the following: a container image component, a binary file, and a source code repository component.

[0053] The container image component is the core component of container technology. Essentially, it's a read-only, standardized template file containing all the dependencies required for an application to run (code, runtime environment, system tools, library files, etc.). Binary files refer to compiled machine code or intermediate code files, such as executable files (EXE), bytecode (like Java's .class files), or firmware images (like the .bin files of embedded devices). These files no longer contain human-readable source code but are binary instruction sets generated by the compiler, directly executed by the hardware or virtual machine. The source code repository component is the core platform for storing, managing, and collaboratively developing software source code; it contains the software source code.

[0054] In one optional embodiment of this disclosure, the target bill of materials includes at least one of the following: a list of file information; a component dependency topology diagram; and a file cryptographic hash.

[0055] The file information list is a list of information contained in the file, such as file name, file version, file license, etc.

[0056] A component dependency topology graph is used to represent the topological relationships between components. For example, the Maven tree structure refers to a hierarchical representation of dependencies in a Maven project, showing the nested relationships of all direct and transitive dependencies in the project. For instance, when a program project introduces a dependency (such as dependency A), its corresponding dependencies (such as dependencies B and C) automatically become transitive dependencies of that project, thus forming a tree-like chain structure: Project → Dependency A → Dependency B → Dependency C.

[0057] File cryptographic hashes, such as SHA256, are one-way functions that convert input data of arbitrary length (such as files) into a fixed-length output value (called a hash value or hash code). They are designed for security scenarios to ensure data integrity and tamper resistance.

[0058] For example, a target bill of materials can be extracted from a set of component materials (such as container image components, binary files, and source code repository components) and output in a standardized format such as SPDX / CycloneDX to obtain an initial software bill of materials that conforms to the standard.

[0059] In step S202, evidence chain credential information is obtained, and the initial hash value corresponding to the evidence chain credential information is determined; the evidence chain credential information includes one or more of the collected environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint.

[0060] The environment build fingerprint can be obtained by extracting the container image hash and runtime configuration using `crictl inspect` or `docker inspect`; or by executing a pre-built script in a virtual machine / physical machine to collect the OS kernel version, thereby outputting an environment snapshot in JSON format. It should be noted that the OS kernel version is used to record updates to core functions, vulnerability fixes, and security patches.

[0061] For example, here is a sample script for collecting fingerprints in an environment.

[0062] A. Script example for container environments:

[0063] CONTAINER_ID=$(crictl inspect-f'{{.status.id}}'$POD_ID)KERNEL_HASH=$(sha256sum / boot / vmlinuz-$(uname-r))

[0064] ENV_SNAPSHOT={"container":"$CONTAINER_ID","kernel":"$KERN EL_HASH"}

[0065] B. Script examples for physical machines / virtual machines:

[0066] DMIDECODE> / tmp / hw_fingerprint

[0067] TPM_QUOTE=$(tpm2_quote-c 0x81000000-l sha256:all-q"QUOTE")

[0068] The toolchain monitoring information is obtained by monitoring binary paths and command lines to obtain the precise version of the compiler / packaging tools.

[0069] The monitoring scope corresponding to toolchain monitoring information includes: compilers (gcc / clang / javac), package managers (npm / pip / mvn / gradle), and build tools (make / cmake / msbuild).

[0070] Correspondingly, the data captured through toolchain monitoring information includes one or more of the following: binary file path ( / usr / bin / gcc), file hash value (sha256sum / usr / bin / gcc), and complete command-line arguments (gcc-O2-o appmain.c).

[0071] For example, here is a script example of toolchain monitoring information for a compiler:

[0072]

[0073] The script example of the toolchain monitoring information corresponding to the compiler mentioned above shows that after capturing the compiler version, the output results are merged and the hash value is calculated using the sha256() function. Finally, the hash value is encrypted and stored in the TEE.

[0074] For dependency tracking information, package manager logs can be parsed, for example, monitoring dependency directories: node_modules (Node.js) ~ / .m2 / repository (Maven) __pycache__ (Python).

[0075] For runtime environment fingerprints, environment variables and security policies can be obtained through kernel monitoring.

[0076] Environment variable: PATH = / usr / local / bin (environment variables are used to record runtime paths);

[0077] Security policy: seccomp = DENY(ptrace,mount) (This security policy is used to protect against configuration snapshots).

[0078] In one optional embodiment of this disclosure, Figure 3 This embodiment illustrates a flowchart of a method for obtaining evidence chain credential information according to one implementation method; see reference. Figure 3 As shown, after collecting one or more of the following: environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint, evidence chain credential information is obtained, including the following steps S301 to S303:

[0079] Step S301: Based on the collected environment build fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint, one or more build log fragments are collected.

[0080] Step S302: Encrypt the log fragment in a trusted execution environment and upload the encrypted log fragment to the evidence chain service center to obtain the evidence chain credential information.

[0081] Step S303: Obtain evidence chain certificate information from the evidence chain service center.

[0082] For example, information related to the component material set can be extracted to construct log fragments, namely, one or more build log fragments based on the collected environment build fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint. The captured data is then packaged into raw JSON format, and the initial hash value corresponding to the evidence chain credential information is calculated using the SHA256 hash algorithm. For example, the code for calculating the initial hash value using the SHA256 hash algorithm is as follows: init_hash = sha256(raw_data).

[0083] Finally, the evidence is encrypted using a Trusted Execution Environment (TEE) and uploaded to the evidence chain service center, enabling the server to obtain the evidence chain credential information from the evidence chain service.

[0084] Furthermore, when uploading evidence to the evidence chain credential information, a unique locator tag is automatically generated, enabling the server to quickly locate the required evidence chain credential information from the evidence chain service center based on the locator tag. Specific steps can be combined with... Figure 5 The steps are shown below.

[0085] In this embodiment, reference is made to Figure 5 The steps shown, by embedding kernel-level probes into the CI / CD pipeline to capture one or more of the aforementioned environment build fingerprints, toolchain monitoring information, dependency tracking information, and runtime environment fingerprints in real time, and combining them with the executable environment TEE to achieve hardware-level evidence sealing, can solve the technical problem that traditional static scanning methods cannot verify the authenticity of behavior during the build process.

[0086] In step S203, the initial software bill of materials is concatenated with the evidence chain voucher information to obtain the target hash value, and the target software bill of materials is generated based on the target hash value.

[0087] For example, the initial software bill of materials is concatenated with the evidence chain credential information to obtain a new target hash value, and then the target software bill of materials is generated based on the target hash value.

[0088] In this step, key fingerprint information such as compiler hashes and container configurations in the build environment will be collected in real time and cryptographically hashed together with the standard SBOM. This avoids the high false positive problem caused by the disconnect between the environment and traditional static scanning, and improves the accuracy and reliability of the generated SBOM.

[0089] Furthermore, to improve the reliability of the generated SBOM, trusted verification can be deeply embedded in the build execution phase based on the following embodiments.

[0090] Figure 4 This schematically illustrates a flowchart of adding trusted verification in this exemplary embodiment. Please refer to [link to flowchart illustration]. Figure 4 This includes the following steps S401-S404:

[0091] Step S401: Generate an asymmetric key pair locally at the node level, store the private key in the asymmetric key pair in the executable environment, and bind the public key in the asymmetric key pair to the node identity information.

[0092] In this system, the node level corresponds to the device or user level. Asymmetric key pairs are generated on the local terminal at the device or user level, for example, using the RSA-4096 algorithm. The private key is stored in a secure environment (such as a TEE trusted execution environment), while the public key is publicly released for verification.

[0093] In this step, the private key is encrypted and stored to prevent unauthorized access, while the public key is bound to node identity information (such as device ID or certificate) for subsequent verification processes.

[0094] Step S402: Generate hash digest information of the initial software bill of materials and evidence chain voucher information, and encrypt the hash digest information using a private key to generate the first digital signature.

[0095] For example, the first digital signature is generated as follows:

[0096] a) Data hashing: Apply hash functions such as SHA-256 to the initial software bill of materials and evidence chain credential information (such as files or logs) to generate digests, ensuring data integrity.

[0097] b) Private Key Encryption Signature: The node uses its private key to encrypt the hash digest, generating the first digital signature. This process is performed in a secure, isolated environment to prevent man-in-the-middle tampering.

[0098] c) Output signature with evidence: The first digital signature is transmitted together with the initial software bill of materials and the evidence chain credential information. The recipient decrypts the signature using the public key and compares the calculated hash value to verify the authenticity of the source and that the data has not been tampered with.

[0099] Step S403: Add a hardware security mode HSM key signature at the organization level to generate a second digital signature within the HSM.

[0100] For example, an organization-grade HSM, as a hardware device, provides full lifecycle key management and highly secure signing.

[0101] It should be explained that the HSM has a built-in true random number generator that dynamically creates the master key (such as RSA-4096 or the national cryptographic standard SM2), and the plaintext of the key never leaves the HSM hardware. When an organization calls the HSM API (such as the PKCS#11 interface) for signature operations, the private key calculation is completely completed within the tamper-proof chip, resisting physical and side-channel attacks.

[0102] Step S404: Based on the first digital signature and the second digital signature, form a joint digital signature for the target software bill of materials.

[0103] In this step, a dual-security system of "node authentication + institutional authority verification" is constructed through the collaboration of the two digital signature methods described above. First, node signature serves as the entry point: after generating an evidence signature, the node submits it to the organization's HSM system. Then, the HSM performs secondary signature authentication: the organization's HSM uses its private key to re-sign the node signature result (or sign the node certificate), adding a timestamp and organizational identifier.

[0104] Finally, the verification chain is executed. That is, the recipient first verifies the authenticity of the original evidence using the node's public key, and then confirms the authority of the institution using the organization's public key (CA certificate verification).

[0105] In this embodiment, a dual-signature layered authentication system is adopted. The building node performs lightweight identity signing, which is then superimposed with authoritative encryption authentication using organization-level HSM hardware, forming a hardware-level trust chain. This significantly enhances the defense against supply chain attacks such as toolchain contamination. An evidence chain traceability mechanism is designed, enabling on-demand verification through unique evidence identifiers, greatly reducing data transmission requirements and effectively supporting offline auditing in network isolation scenarios. By synergistically forming a closed loop through these three technologies, a paradigm shift from passive detection to proactive immunity is achieved, providing a feasible and trustworthy approach for high-security scenarios.

[0106] In one optional embodiment of this disclosure, TSA timestamp information is added to the first digital signature and the second digital signature via the RFC3161 protocol.

[0107] For example, the core of the RFC 3161 protocol is to provide time-based proof for digital signatures, resolving validity disputes after certificate expiration or revocation. Its workflow consists of two steps:

[0108] Step 1: Client Request: The user calculates a hash value (usually SHA-256 algorithm) on the data (such as files or logs) and sends the hash value to the TSA server, instead of the original data, to protect privacy.

[0109] Step 2, TSA Processing and Signing: After receiving the request, the server binds the precise time from an authoritative time source (such as the National Time Service Center), generates a token containing a hash value and a timestamp, and digitally signs it using the TSA private key to generate an encrypted timestamp token. This process ensures that the timestamp is immutable and independently verifiable.

[0110] Through this embodiment, timestamp solidification is a technology used to prove that electronic data exists at a specific point in time and has not been tampered with, ensuring the integrity and legal validity of the data. It is implemented based on the RFC3161 protocol, which was developed by the IETF and defines the interaction standard between the client and the timestamp server (TSA) to provide independent and verifiable timestamp services.

[0111] In one optional embodiment of this disclosure, after generating the target software bill of materials based on the target hash value, in response to receiving a verification instruction for the target software bill of materials, the joint digital signature of the target software bill of materials is verified according to the pre-configured organization public key, and the TSA timestamp information is verified according to the pre-configured timestamp agency certificate, and a verification result is obtained; in response to the verification result being that the verification failed, a re-acquisition instruction for the target software bill of materials is triggered.

[0112] For example, when a verification instruction for the target software bill of materials is received, the target SBOM file (which may contain the original component list and trust anchor data) can be loaded; and the trust certificate, such as the organization root certificate or the timestamp authority certificate, is pre-installed therein.

[0113] In this step, to verify the integrity and timeliness of the target SBOM, the federated signature of the SBOM can be verified using a pre-set organization public key (e.g., using the RSA-PSS 4096 algorithm) and the validity of the timestamp can be verified through the TSA certificate chain (e.g., the RFC3161 protocol).

[0114] In one optional embodiment of this disclosure, in response to a verification result indicating that the verification passed, an evidence chain is obtained to determine whether the hash value in the evidence chain matches the target hash value; in response to a match between the hash value in the evidence chain and the target hash value, the consistency of the contents of the target software bill of materials is verified to obtain the target verification result; and a handling strategy is output for the target verification result.

[0115] For example, the evidence package is constructed based on the unique identifier of the evidence embedded in the target SBOM, and an integrity check is performed.

[0116] After the integrity check passes, the contents of the obtained evidence package can be audited, including toolchain trust verification: verifying whether the compiler / package manager hash is trustworthy, if they do not match, it means that the toolchain has been contaminated; and component consistency: comparing the versions and file hashes of SBOM components with those of the evidence package to see if there is any supply chain tampering; and environment compliance: checking whether the OS / container configuration meets the security baseline.

[0117] For details of the above process, please refer to [link / reference]. Figure 6 As shown, cryptographic verification, evidence chain verification, and consistency verification are performed in sequence.

[0118] Finally, a handling strategy can be output based on the verification results for the target.

[0119] For example, the SBOM verification result report is output for automated security processing. Details are as follows:

[0120] Toolchain contamination was detected. The security measure taken was to block the deployment process and issue an alert.

[0121] If a component version inconsistency is found, the security approach is to mark it as requiring manual review.

[0122] If the full verification is successful, a compliance report can be issued.

[0123] The following will refer to Figure 7 The entire security detection process of the security detection method according to the exemplary embodiments of this disclosure will be described in detail.

[0124] Reference Figure 7 As shown, firstly, data is collected during the build process, including one or more of the following: environment build fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; then, the captured data is encrypted and uploaded.

[0125] Next, based on tools such as Syft / Trivy, the software artifacts (container images / binary packages / source code repositories) are scanned, and a complete bill of materials is automatically extracted, including: file-level component list (name, version, license), component dependency topology (such as Maven tree structure), key file cryptographic hash (SHA256), and output in standardized formats such as SPDX / CycloneDX to form the initial SBOM;

[0126] Then, obtain the relevant credentials for this build from the evidence chain service center: including the build environment fingerprint (OS / container hash), toolchain authentication record (compiler / package manager signature), and proof of the source of dependent components (download source URL + file hash). Anchor the credentials to the SBOM through the unique evidence ID, so as to merge the initial SBOM and the evidence credentials to generate the target hash value.

[0127] Simultaneously, the first and second digital signatures are combined for trusted verification, and the target SBOM is finally output.

[0128] Finally, the target SBOM is distributed to the SBOM verification process for reference. Figure 6 The verification process shown implements cryptographic verification, evidence chain checking, and consistency verification, thereby outputting a verification report.

[0129] To implement the above-mentioned security detection method, one embodiment of this disclosure provides a security detection device. Figure 8 The schematic diagram illustrates the architecture of a safety detection device.

[0130] The safety detection device includes a bill of materials extraction module 801, a voucher acquisition module 802, and an information splicing module 803.

[0131] The bill of materials extraction module 801 is used to scan the component material set to extract the target bill of materials from the component material set and obtain the initial software bill of materials; the voucher acquisition module 802 is used to acquire evidence chain voucher information and determine the initial hash value corresponding to the evidence chain voucher information; the evidence chain voucher information includes one or more of the collected environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; the information splicing module 803 is used to splice the initial software bill of materials with the evidence chain voucher information to obtain the target hash value, and generate the target software bill of materials based on the target hash value.

[0132] In one optional embodiment of this disclosure, the component material set includes at least one of the following:

[0133] Container image components, binary files, and source code repository components;

[0134] The target bill of materials includes at least one of the following:

[0135] Document information list;

[0136] Component dependency topology graph;

[0137] File cryptographic hashing.

[0138] In an optional embodiment of this disclosure, the credential acquisition module 802 is used to acquire one or more build log fragments from the collected environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; to encrypt the log fragments using a trusted execution environment, and to upload the encrypted log fragments to the evidence chain service center to obtain evidence chain credential information; and to obtain the evidence chain credential information from the evidence chain service center.

[0139] In an optional embodiment of this disclosure, the apparatus further includes a signature generation module, which is used to generate an asymmetric key pair locally at the node level, store the private key in the asymmetric key pair in the executable environment, bind the public key in the asymmetric key pair to the node identity information; generate hash digest information of the initial software bill of materials and evidence chain credential information, and encrypt the hash digest information using the private key to generate a first digital signature; and add a Hardware Security Mode (HSM) key signature at the organization level to generate a second digital signature within the HSM; and form a joint digital signature of the target software bill of materials based on the first digital signature and the second digital signature.

[0140] In an optional embodiment of this disclosure, the device further includes a timestamp adding module, which is used to add TSA timestamp information to the first digital signature and the second digital signature via the RFC3161 protocol.

[0141] In an optional embodiment of this disclosure, the apparatus further includes a verification module, which is configured to, in response to receiving a verification instruction for the target software bill of materials, verify the joint digital signature of the target software bill of materials based on a pre-configured organization public key, and verify the TSA timestamp information based on a pre-configured timestamp authority certificate, to obtain a verification result; and in response to a verification result indicating that the verification failed, trigger a re-acquisition instruction for the target software bill of materials.

[0142] In an optional embodiment of this disclosure, the verification module is further configured to, in response to a verification result of verification passing, obtain an evidence chain to determine whether the hash value in the evidence chain matches the target hash value; in response to a hash value in the evidence chain matching the target hash value, verify the consistency of the contents of the target software bill of materials to obtain a target verification result; and output a handling strategy for the target verification result.

[0143] The security detection device 800 provided in this embodiment can execute the technical solution of the security detection method in any of the above embodiments. Its implementation principle and beneficial effects are similar to those of the security detection method. Please refer to the implementation principle and beneficial effects of the security detection method. It will not be repeated here.

[0144] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0145] According to embodiments of the present invention, a program product for implementing the above-described method may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0146] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0147] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0148] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, radio frequency (RF), or any suitable combination thereof.

[0149] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0150] In an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided.

[0151] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: entirely hardware implementations, entirely software implementations (including firmware, microcode, etc.), or implementations combining hardware and software aspects, collectively referred to herein as “circuits,” “modules,” or “systems.”

[0152] The following reference Figure 9 To describe an electronic device 900 according to this embodiment of the present invention. Figure 9 The electronic device 900 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0153] like Figure 9 As shown, the electronic device 900 is presented in the form of a general-purpose computing device. The components of the electronic device 900 may include, but are not limited to: at least one processing unit 910, at least one storage unit 920, a bus 930 connecting different system components (including storage unit 920 and processing unit 910), and a display unit 940.

[0154] The storage unit stores program code, which can be executed by the processing unit 910 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 910 can perform actions such as... Figure 2 Steps S201 to S203 are shown in the figure.

[0155] Storage unit 920 may include readable media in the form of volatile storage units, such as random access memory (RAM) 9201 and / or cache memory 9202, and may further include read-only memory (ROM) 9203.

[0156] Storage unit 920 may also include a program / utility 9204 having a set (at least one) program module 9205, such program module 9205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0157] Bus 930 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0158] Electronic device 900 can also communicate with one or more external devices 1000 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 900, and / or with any device that enables electronic device 900 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 950. Furthermore, electronic device 900 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 960. As shown, network adapter 960 communicates with other modules of electronic device 900 via bus 930. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) systems, tape drives, and data backup storage systems.

[0159] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0160] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0161] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0162] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0163] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is defined only by the appended claims.

Claims

1. A security detection method, characterized in that, include: The component material set is scanned to extract the target bill of materials from the component material set, thus obtaining an initial software bill of materials; Obtain evidence chain credential information and determine the initial hash value corresponding to the evidence chain credential information; the evidence chain credential information includes one or more of the collected environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; The initial software bill of materials is concatenated with the evidence chain credential information to obtain a target hash value, and a target software bill of materials is generated based on the target hash value.

2. The method according to claim 1, characterized in that, The component material set includes at least one of the following: Container image components, binary files, and source code repository components; The target bill of materials includes at least one of the following: Document information list; Component dependency topology graph; File cryptographic hashing.

3. The method according to claim 1 or 2, characterized in that, After collecting one or more of the following: environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint, the acquisition of evidence chain credential information includes: Based on one or more build log fragments from the collected environment build fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; The log fragment is encrypted using a trusted execution environment, and the encrypted log fragment is uploaded to the evidence chain service center to obtain the evidence chain credential information; Obtain the evidence chain certificate information from the evidence chain service center.

4. The method according to claim 1, characterized in that, The method further includes: Asymmetric key pairs are generated locally at the node level, and the private key in the asymmetric key pair is stored in the executable environment. The public key in the asymmetric key pair is bound to the node identity information. Generate hash digest information of the initial software bill of materials and the evidence chain credential information, and encrypt the hash digest information using the private key to generate a first digital signature; Additionally, add hardware security mode HSM key signing at the organization level to generate a second digital signature within the HSM; A joint digital signature is formed based on the first digital signature and the second digital signature, constituting the bill of materials for the target software.

5. The method according to claim 4, characterized in that, The method further includes: TSA timestamp information is added to the first digital signature and the second digital signature using the RFC3161 protocol.

6. The method according to claim 5, characterized in that, After generating the target software bill of materials based on the target hash value, the method further includes: In response to receiving the verification instruction of the target software bill of materials, the joint digital signature of the target software bill of materials is verified according to the pre-configured organization public key, and the TSA timestamp information is verified according to the pre-configured timestamp agency certificate, and the verification result is obtained. In response to the verification result being a failure, a re-acquisition instruction for the target software bill of materials is triggered.

7. The method according to claim 6, characterized in that, The method further includes: In response to the verification result being successful, an evidence chain is obtained to determine whether the hash value in the evidence chain matches the target hash value. In response to the hash value in the evidence chain matching the target hash value, the consistency of the contents of the target software bill of materials is verified to obtain the target verification result; Based on the target verification results, output the handling strategy.

8. A safety detection device, characterized in that, The device includes: The bill of materials extraction module is used to scan the component material set to extract the target bill of materials from the component material set and obtain the initial software bill of materials; The credential acquisition module is used to acquire evidence chain credential information and determine the initial hash value corresponding to the evidence chain credential information; the evidence chain credential information includes one or more of the collected environment construction fingerprint, toolchain monitoring information, dependency tracking information, and runtime environment fingerprint; The information splicing module is used to splice the initial software bill of materials with the evidence chain credential information to obtain a target hash value, and to generate a target software bill of materials based on the target hash value.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the security detection method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the security detection method according to any one of claims 1 to 7 by executing the executable instructions.

Images