A software supply chain processing method, device and electronic equipment

Abstract

This application discloses a software supply chain processing method, apparatus, and electronic device, relating to the fields of blockchain and artificial intelligence. The method includes: acquiring an on-chain transaction request carrying standardized license data and metadata; verifying the legitimacy of the submitter's identity and verifying the data integrity of the standardized license data; if both verifications are successful, writing the standardized license data into the blockchain; invoking a license audit smart contract to perform at least one of compliance strategy, compatibility, and copyright statement integrity checks on the component license, obtaining the current audit result; acquiring the target risk level obtained by predicting the risk level of the component using a risk prediction model; determining the target audit strategy based on the current audit result and the target risk level, and invoking the target audit strategy to generate the final audit status. The above technical solution improves the efficiency of compliance auditing in the software supply chain.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to the fields of blockchain and artificial intelligence, specifically to a software supply chain processing method, apparatus, and electronic device. Background Technology

[0002] As software systems become increasingly complex, the software supply chain typically involves multiple vendors, third-party libraries, and open-source components, with frequent and highly interdependent data exchanges between each stage. In particular, the widespread use of open-source software exposes the software supply chain to significant compliance risks.

[0003] Software supply chain compliance risks can be broadly categorized into two types: 1. Risks of illegal use of intellectual property rights, including copying and distributing commercial software; including proprietary components or code snippets in externally released products, leading to the leakage of core technologies; and violating software usage agreements with suppliers by conducting unauthorized secondary development. Due to the lack of reliable tracking and recording of the source, usage rights, and flow of software components in traditional software management methods, these risks are often difficult to detect through audits. 2. Risks of unauthorized use of open-source licenses, including the absence of open-source licenses or missing information, such as releasing software products containing open-source components without providing the corresponding licenses; improper use, such as releasing software products without complying with the requirements of the relevant open-source license agreements, for example, statically linking a library under a General Public License in a commercial closed-source product without open-sourcing the entire product as required by the agreement, or modifying an open-source component under a license agreement without retaining the original copyright notice and license text upon redistribution.

[0004] The two types of risks mentioned above are generally difficult to avoid because traditional software supply chain compliance audits rely primarily on manual review, requiring the comparison of massive amounts of code and complex license terms, which is inefficient and prone to errors. Therefore, achieving efficient compliance audits of the software supply chain has become a key issue in the industry. Summary of the Invention

[0005] This application provides a software supply chain processing method, apparatus, and electronic device to improve the efficiency of compliance auditing in the software supply chain.

[0006] In a first aspect, embodiments of this application provide a software supply chain processing method, executed by a blockchain node, the method comprising:

[0007] Obtain an on-chain transaction request carrying standardized license data and metadata; the standardized license data is obtained by parsing the license information of the components in the software and standardizing the license information; the metadata includes at least the submitter of the on-chain transaction request and the license data hash, and the license data hash is obtained by hashing the standardized license data.

[0008] The identity of the submitter is verified, and the data integrity of the standardized license data is verified; if both verifications are successful, the standardized license data is written into the blockchain.

[0009] Call the license audit smart contract to perform at least one of the following checks on the component license: compliance policy, compatibility, and copyright statement integrity, and obtain the current audit result of the component license;

[0010] Obtain the target risk level obtained by using a risk prediction model to predict the risk level of the component;

[0011] Based on the current audit results and the target risk level, a target audit strategy is determined, and the target audit strategy is invoked to generate the final audit status of the component license.

[0012] Secondly, embodiments of this application also provide a software supply chain processing device configured on a blockchain node, the device comprising:

[0013] The transaction request acquisition module is used to acquire on-chain transaction requests carrying standardized license data and metadata. The standardized license data is obtained by parsing the license information of the components in the software and standardizing the license information. The metadata includes at least the submitter of the on-chain transaction request and the license data hash. The license data hash is obtained by hashing the standardized license data.

[0014] The permission on-chain module is used to verify the legitimacy of the submitter's identity and to verify the data integrity of the standardized permission data; if both verifications are successful, the standardized permission data is written into the blockchain.

[0015] The license audit module is used to call the license audit smart contract to perform at least one of the following processes on the component license: compliance policy, compatibility and copyright statement integrity detection, and obtain the current audit result of the component license;

[0016] The risk prediction module is used to obtain the target risk level obtained by using a risk prediction model to predict the risk level of the component;

[0017] The audit status generation module is used to determine the target audit strategy based on the current audit results and the target risk level, and to call the target audit strategy to generate the final audit status of the component license.

[0018] Thirdly, embodiments of this application also provide an electronic device, which includes:

[0019] One or more processors;

[0020] Storage device for storing one or more programs;

[0021] When one or more programs are executed by one or more processors, the one or more processors implement any of the software supply chain processing methods provided in the embodiments of this application.

[0022] Fourthly, embodiments of this application also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements any of the software supply chain processing methods provided in embodiments of this application.

[0023] This application standardizes component license information in software to obtain standardized license data, which is then written into a blockchain. Leveraging the decentralized, immutable, and traceable characteristics of blockchain, a complete and reliable license record can be built for each component in the software. This mitigates the risk of tampering and prevents attackers from deleting or forging the component's origin and license records, thereby improving the reliability of the license record. Based on this, a license audit smart contract is invoked to automatically detect component licenses and generate current audit results. According to the target risk level predicted by the component's risk level, a target audit strategy is dynamically determined. Combining the current audit results and the target audit strategy, the final audit status of the component license is generated. This achieves automated on-chain compliance auditing and intelligent risk level prediction, improving the efficiency and accuracy of software supply chain compliance auditing. Attached Figure Description

[0024] Figure 1a This is a flowchart of a software supply chain processing method according to Embodiment 1 of this application;

[0025] Figure 1b This is a schematic diagram of the data acquisition and processing module provided in Embodiment 1 of this application;

[0026] Figure 1c This is a schematic diagram of the structure of a blockchain data storage module according to Embodiment 1 of this application;

[0027] Figure 2a This is a flowchart of another software supply chain processing method provided according to Embodiment 2 of this application;

[0028] Figure 2b This is a schematic diagram of the structure of the machine learning risk prediction module provided in Embodiment 2 of this application;

[0029] Figure 3 This is a schematic diagram of a software supply chain processing device according to Embodiment 3 of this application;

[0030] Figure 4This is a schematic diagram of the structure of an electronic device that implements the software supply chain processing method of the embodiments of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first" and "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] Example 1

[0034] Figure 1a This is a flowchart of a software supply chain processing method according to Embodiment 1 of this application. This embodiment is applicable to compliance audits of the software supply chain based on smart contracts and machine learning. It can be executed by a software supply chain processing device, which can be implemented in hardware and / or software and can be configured in a blockchain node. Figure 1a As shown, the method includes:

[0035] S101. Obtain an on-chain transaction request carrying standardized license data and metadata; the standardized license data is obtained by parsing the license information of the components in the software and standardizing the license information, and the metadata includes at least the submitter of the on-chain transaction request and the license data hash, and the license data hash is obtained by hashing the standardized license data;

[0036] S102. Verify the legitimacy of the submitter's identity and verify the integrity of the standardized license data; if both verifications are successful, write the standardized license data into the blockchain.

[0037] S103. Call the license audit smart contract to perform at least one of the following processes on the component license: compliance policy, compatibility and copyright statement integrity detection, and obtain the current audit result of the component license;

[0038] S104. Obtain the target risk level obtained by using a risk prediction model to predict the risk level of the component.

[0039] S105. Determine the target audit strategy based on the current audit results and the target risk level, and call the target audit strategy to generate the final audit status of the component license.

[0040] In this embodiment of the invention, a data acquisition and processing module can collect software supply chain compliance-related information from the software development environment, and clean, standardize, and structure the collected raw data. During this process, software-related information such as software build artifacts, existing SBOM (Software Bill of Materials) files, and manually entered supplementary compliance information is acquired. Standardized license data is output, and a hash operation is performed on the standardized license data to obtain the license data hash.

[0041] refer to Figure 1b The data acquisition and processing module may include the following sub-modules: a software bill of materials (BOM) generation or import sub-module 11, a data cleaning and standardization sub-module 12, and a structuring and packaging sub-module 13. For example, the software BOM generation tool integrated through the software BOM generation or import sub-module 11 parses the license information of each component in the software during the BOM generation process. If the tool cannot automatically determine the license, the build process terminates, and compliance information must be manually added. If the component already contains a software BOM file, the uploaded software BOM file is verified to contain the necessary license declaration fields.

[0042] The data cleaning and standardization submodule 12 uses the SPDX (Software Package Data Exchange) license list as a standard to verify and standardize the parsed license content, resulting in standardized license data. For example, different expressions such as "GPLv2" and "GPL 2.0" are unified into the official SPDX identifier GPL-2.0-only; for dual or multiple licenses (such as MIT OR Apache-2.0), SPDX expressions are used for standardization. Licenses that cannot be identified are marked as high-risk signals.

[0043] The structuring and packaging submodule 13 encapsulates standardized license data into structured data, such as JSON objects, including fields such as software name, software version, component name, component version, vendor, component hash, and component license. The hash value of the standardized license data is calculated to obtain the license data hash. The submitter of the on-chain transaction request, the submission timestamp, and the license data hash are used as metadata to generate an on-chain transaction request carrying both standardized license data and metadata. This on-chain transaction request is then submitted through the blockchain network's data on-chain interface.

[0044] In a blockchain network, blockchain nodes respond to received on-chain transaction requests by verifying the legitimacy of the submitter's identity. If the identity verification is successful, the standardized license data undergoes data integrity verification. The hash value of the standardized license data is calculated and compared with the hash of the license data in the metadata. If they match, the standardized license data has not been tampered with, and the data integrity verification is successful; otherwise, the data integrity verification fails. If the data integrity verification is successful, it can also check whether the license fields conform to the SPDX format standard. The successfully verified standardized license data is written to the blockchain, triggering the license audit smart contract in the blockchain. Standardized license data is obtained by standardizing the component license information in the software; and this standardized license data is then written to the blockchain. Leveraging the decentralized, immutable, and traceable characteristics of blockchain, a complete and reliable license record can be built for each component in the software. This not only avoids the risk of tampering but also prevents attackers from deleting or forging the component's origin and license records, thereby improving the reliability of the license record.

[0045] This invention proposes a layered smart contract architecture that transforms complex compliance audit logic into license audit smart contracts through code. When new software license information is recorded on the blockchain, the system automatically triggers and invokes the license audit smart contract, which executes a series of preset audit operation processes. This automates the compliance audit process, effectively improving the efficiency and accuracy of compliance audit results.

[0046] The compliance policy is used to determine whether a component license is permissible; compatibility testing is used to determine whether different components within the same software are compatible; and copyright statement integrity testing is used to ensure that the component license includes necessary legal statement fields such as the copyright owner, license text, and disclaimers. For example, a license audit smart contract is invoked to perform at least one of the following checks on the standardized license data: compliance policy testing, compatibility testing, or copyright statement integrity testing, to obtain the current audit result for the component license. If any of these checks fails, the current audit result is considered a failure, and subsequent checks are terminated.

[0047] This approach not only audits standardized licensing data within the blockchain by invoking license audit smart contracts, but also employs a risk prediction model to assess the risk level of components and determine the target risk level. After obtaining the target risk level, blockchain nodes dynamically determine the target audit strategy based on it, and generate the final audit status of the component's license by combining the current audit results on the blockchain with the target audit strategy. By dynamically determining the target audit strategy based on the target risk level predicted for the component, and combining the automatically generated current audit results on the blockchain with the target audit strategy to generate the final audit status of the component's license, this approach achieves automated in-chain compliance auditing and intelligent risk level prediction. It effectively solves problems such as excessive reliance on manual operation, low audit efficiency, and untimely risk detection in traditional compliance auditing, improving the efficiency and accuracy of software supply chain compliance auditing and ensuring the compliance of the software supply chain.

[0048] The technical solution of this embodiment standardizes the component license information in the software to obtain standardized license data, which is then written into the blockchain. Leveraging the decentralized, immutable, and traceable characteristics of blockchain, a complete and reliable license record can be built for each component in the software. This avoids the risk of tampering and prevents attackers from deleting or forging the component's source and license records, thereby improving the reliability of the license record. Based on this, a license audit smart contract is invoked to automatically detect component licenses and generate the current audit result. According to the target risk level obtained from the risk level prediction of the component, a target audit strategy is dynamically determined. Combining the current audit result and the target audit strategy, the final audit status of the component license is generated. This achieves automated on-chain compliance auditing and intelligent risk level prediction, improving the efficiency and accuracy of software supply chain compliance auditing.

[0049] In one optional implementation, the standardized license data includes at least one of the following: software name, software version, component name, component version, vendor, component hash, or component license; writing the standardized license data into the blockchain includes: hashing the software name, software version, and component license identifier respectively to obtain the hash value of the software name, the hash value of the software version, and the hash value of the license identifier; the key of the standardized license data is a path structure formed by concatenating the hash value of the software name, the hash value of the software version, the component hash, and the hash value of the license identifier; the value of the standardized license data includes at least one of the following: component name, component version, vendor, component hash, or component license.

[0050] This invention proposes a blockchain data storage architecture based on an improved Merkle Patricia Tree (MPT). Standardized licensing data from the software supply chain is structured and stored on the blockchain. Leveraging the decentralized, immutable, and traceable characteristics of blockchain, a complete and reliable record is constructed for each software and its components. The standardized licensing data includes at least one of the following: component name, component version, supplier, component hash, or component license.

[0051] This invention optimizes the Merkle tree key, abandoning the use of a single hash and instead adopting a segmented path structure. The specific structure of the key is as follows:

[0052] hash(ProjectID):hash(Version):ComponentHash:hash(LicenseID)

[0053] In this structure, ComponentHash refers to the component hash, used to uniquely identify the component; LicenseID is used to uniquely identify the component license; hash() represents the hash function, which binds the component hash with the hash value of the component license identifier and stores it in an immutable blockchain ledger. Meanwhile, ProjectID corresponds to the software name, and Version corresponds to the software version, using the hash values ​​of the software name and version together as a path prefix. Since an organization may own multiple software programs, and the same software program may have multiple versions, by using the software name and version number as path prefixes for component license data, the system can directly traverse all components and their licenses under that version of the software during the component license data query process, without traversing the entire state tree, thus improving the efficiency of license data query. When new license data is added to the chain, a key with the above structure can be generated for each component, and the component name, component version, supplier information, component hash, or component license information can be used as the value, and then the key-value pair (Key->Value) is inserted into the Merkle tree.

[0054] refer to Figure 1c Blockchain nodes utilize the blockchain data storage module to store standardized licensing data on the blockchain. The blockchain data storage module comprises the following sub-modules: a data on-chain connection interface sub-module 21, an improved MPT construction sub-module 22, and an on-chain data query interface sub-module 23. Blockchain nodes receive on-chain transaction requests from the data acquisition and processing module through the data on-chain connection interface sub-module 21. Using the improved MPT construction sub-module 22, which employs a novel key structure based on segmented paths, they write the standardized licensing data of components into the blockchain. The on-chain data query interface sub-module 23 provides a read interface function. This function returns a list of licenses for all components in a software project version, which can be directly called by the license audit smart contract. Blockchain nodes provide blockchain transaction receipts, including transaction status, block number, and the updated MPT root hash.

[0055] Example 2

[0056] Figure 2a This is a flowchart of another software supply chain processing method provided according to Embodiment 2 of this application. The technical solution of this embodiment is further refined based on the above technical solution. See also Figure 2a A software supply chain processing method shown includes:

[0057] S201. Obtain an on-chain transaction request carrying standardized license data and metadata; the standardized license data is obtained by parsing the license information of the components in the software and standardizing the license information, and the metadata includes at least the submitter of the on-chain transaction request and the license data hash, and the license data hash is obtained by hashing the standardized license data;

[0058] S202. Verify the legitimacy of the submitter's identity and verify the integrity of the standardized license data; if both verifications are successful, write the standardized license data into the blockchain.

[0059] S203. Extract component licenses from standardized licensing data, and use the license blacklist and license whitelist stored on the chain to perform compliance policy checks on the component licenses;

[0060] S204. If the component license is not in the license blacklist but exists in the license whitelist, then the compliance audit result of the component license is determined to be compliant, and compatibility testing is performed on different component licenses in the software to obtain the compatibility test result.

[0061] S205. If the compatibility test result is compliant, then the copyright statement integrity test is performed on the component license to obtain the current audit result of the component license;

[0062] S206. Obtain the target risk level obtained by using a risk prediction model to predict the risk level of the component;

[0063] S207. Determine the target audit strategy based on the current audit results and the target risk level, and call the target audit strategy to generate the final audit status of the component license.

[0064] During the on-chain audit process where a blockchain node invokes a license audit smart contract, all software components can be traversed for policy checks. For each component, the corresponding component license field is extracted from standardized license data, and the existence of the component license is checked. If the component license exists, the on-chain license blacklist is further queried. If the component license is in the license blacklist, the compliance audit result of the component license is marked as "non-compliant," and subsequent detection processes are stopped. If the component license is not in the license blacklist, the license whitelist is queried. If the component license exists in the license whitelist, the compliance audit result is marked as "compliant." In other words, if the component license is not in the license blacklist and exists in the license whitelist, the compliance audit result of the component license is determined to be "compliant," and compatibility checks are triggered.

[0065] If the compliance audit result is "compliant," a compatibility test is performed on the licenses of different components within the software to determine whether there are compatibility issues between licenses of different components within the same software. If the compatibility test passes, meaning there are no compatibility issues, a copyright statement integrity test is further performed to verify whether the component license fully includes the copyright owner, license text, disclaimers, and other necessary legal statements, ultimately determining the current audit result of the component license. If the current audit result is non-compliant, a non-compliance notification can be sent to the blockchain account address of the software system user. Compliance policy checks on component licenses are performed by calling the pre-stored license blacklist and license whitelist on the blockchain. If a component license is not on the license blacklist but is on the license whitelist, a compatibility test on different components within the same software is automatically triggered. If the compatibility test result is compliant, a copyright statement integrity test on the component license is further automatically triggered, resulting in the current audit result of the component license. This series of operations achieves automated, code-based, layered auditing of component licenses, effectively improving the efficiency and accuracy of the audit work.

[0066] In one optional implementation, compatibility testing is performed on the licenses of different components in the software. The compatibility testing results include: obtaining the component licenses of multiple components in the same software, combining different components in pairs to form component license pairs; calling a preset license compatibility rule matrix to perform compatibility testing on the two component licenses in the component license pairs, and obtaining the compatibility testing results.

[0067] In the license compatibility rule matrix, the value of the element in the i-th row and j-th column represents the compatibility between the i-th and j-th preset license protocols. There are only a fixed number (e.g., N) of preset license protocols, where i, j, and N are all natural numbers. For compatibility testing, license information for all components in the same software is extracted and stored in an array. Different components in the array are paired to form component license pairs. The compatibility value of each component license pair is then retrieved from the license compatibility rule matrix. If the compatibility value is the first value (e.g., 0), the compatibility test result for the component license pair is considered compatible; if the compatibility value is the second value (e.g., 1), the compatibility test result is considered incompatible. For example, if one component license in a component license pair requires open source and the other requires closed source, they are incompatible, and the compatibility value is 1. By pairing different components in the same software to form component license pairs and calling the license compatibility rule matrix to determine the compatibility test result for the component license pairs, fast and accurate compatibility testing is achieved.

[0068] In one optional implementation, the component license is subjected to a copyright statement integrity check to obtain the current audit result of the component license, including: determining whether the component license includes an unmodifiable statement; if it includes an unmodifiable statement, then calling the genuine component hash library, comparing the component hash with the genuine component hash, and generating the current audit result of the component license based on the comparison result.

[0069] Some open-source components are not modifiable. For example, the component license is parsed to check the license scope and determine if it includes a non-modifiable declaration. If it does, a copyright notice integrity check is triggered. A legitimate component hash library can be called to compare the component hash with the hash of the original component. If the comparison result is inconsistent, it indicates that the component has been modified. A smart contract can be called to further check whether the component's metadata still includes the hash value of the original copyright notice text. If the hash value of the copyright notice text is missing or changed, a warning of "potentially missing license information" is issued. If the comparison result is consistent, the current audit result of the component license is compliant. In cases where the component license includes a non-modifiable declaration, a fast and accurate copyright notice integrity check is achieved by comparing the component hash with the hash of the original component and based on the comparison result.

[0070] The technical solution in this embodiment performs compliance policy checks on component licenses by calling pre-stored license blacklists and whitelists on the blockchain. If a component license is not on the blacklist but is on the whitelist, compatibility checks on different components within the same software are automatically triggered, enabling fast and accurate compatibility testing. If the compatibility check is compliant, a copyright statement integrity check on the component license is further automatically triggered. If the component license contains an unmodifiable statement, the check is completed quickly and accurately by comparing the component hash with the hash of the genuine component, thus obtaining the current audit result of the component license. This series of operations achieves automated, code-based, layered auditing of component licenses, effectively improving the efficiency and accuracy of auditing work.

[0071] In one optional implementation, the target risk level is obtained through the following processing: Determining component characteristics based on the component name; the component characteristics include at least one of the following: component age, number of referenced projects, number of historical vulnerabilities, or average repair time; determining license characteristics based on the standardized license data; the license characteristics include at least one of the following: license category, whether it is a non-standard license, whether there are complex exception clauses, or whether copying is permitted; determining supplier characteristics based on the component supplier; the supplier characteristics include at least one of the following: supplier reputation score, code submission frequency, community activity, or supplier historical submission behavior data; and performing code analysis on the component code. Fingerprint extraction is performed and compared with open-source code repositories to calculate the maximum code fragment similarity. Software project characteristics are determined based on the software name, component name, and software bill of materials. These characteristics include at least one of the following: project complexity, development team size, or historical compliance pass rate. The historical compliance pass rate is obtained by querying historical audit statuses in the blockchain. Graph features of components in the dependency graph are determined based on the software bill of materials. These graph features include centrality or whether the component is on a critical path. The component features, license features, supplier features, maximum code fragment similarity, software project characteristics, and graph features are input into a risk prediction model trained using machine learning to obtain the target risk level.

[0072] For example, at least one of the following component characteristics can be obtained based on the component name: component age, number of referenced projects, number of historical vulnerabilities, or average fix time. License characteristics may include at least one of the following: license type, whether the license is a non-standard license, whether there are complex exception clauses, or whether a copying license is available. Supplier characteristics may include at least one of the following: supplier reputation score, code submission frequency, community activity, and supplier historical submission behavior data. The supplier reputation score can be calculated based on a comprehensive score from multiple data sources such as historical litigation and community reputation; supplier historical submission behavior data can be obtained by analyzing whether the supplier has frequent license change behavior in its historical submission records. Furthermore, code fingerprints can be extracted from the component code, and the component's code fingerprint can be compared with open-source code repositories with known licenses to calculate the maximum code segment similarity between the two. If the similarity is high but the licenses do not match, it indicates a potential risk of "code plagiarism" or "unauthorized use."

[0073] Software project characteristics can include project complexity (such as lines of code, number of components), development team size, or historical compliance pass rate. For example, a query key can be constructed using the software name, software version, component hash, and component license identifier of the component to be queried. The value corresponding to this key is retrieved from the blockchain to obtain the component name, component version, vendor, component hash, and component license. Based on the component name, component version, vendor, component hash, and component license, the historical audit status of the component can be further queried, and its historical compliance pass rate can be calculated based on the historical audit status. Network characteristics include the centrality of a component in the dependency graph and whether it is on a critical path. The software bill of materials is stored in a specific data structure and marked with dependencies. These dependencies are abstracted into a dependency graph, thereby obtaining the centrality of a component in the dependency graph and whether it is on a critical path.

[0074] By inputting component features, license features, supplier features, maximum code snippet similarity, software project features, and graph features into a risk prediction model trained based on machine learning, the target risk level is obtained. By combining component features, license features, supplier features, maximum code snippet similarity, software project features, and graph features, the risk level of a component is predicted, achieving intelligent prediction of the target risk level and identifying potential compliance risks.

[0075] In this embodiment of the invention, a machine learning risk prediction module can be used to predict the risk level of components in the software supply chain, obtaining a target risk level. The machine learning risk prediction module runs in an off-chain environment, trains the risk prediction model offline, and interacts with smart contracts on the blockchain to predict the target risk level of newly uploaded standardized permissioned data on the blockchain, feeding back the target risk level to the automated strategy adjustment contract layer on the blockchain.

[0076] refer to Figure 2bThe machine learning risk prediction module may include a data synchronization submodule 41, a feature engineering submodule 42, a model training submodule 43, a risk prediction submodule 44, and an early warning notification submodule 45. The data synchronization submodule 41 monitors data submissions on the blockchain and synchronizes compliant data stored on-chain to an off-chain data warehouse in real-time or periodically. This method constructs the training dataset required for machine learning, avoiding large-scale data queries directly on the blockchain and preventing performance degradation due to queries. The feature engineering submodule 42 extracts and constructs component features, license features, supplier features, maximum code snippet similarity, software project features, and graph features from the data synchronized by the data synchronization submodule 41. The model training submodule 43 trains a multivariate classifier based on the diversity of features and the characteristics of the prediction task to predict the target risk level. When new data is synchronized from the blockchain, the risk prediction submodule 44 loads the trained risk prediction model, extracts features from the new data, performs real-time prediction, and outputs the target risk level. The early warning notification submodule 45 sends early warning notifications based on the target risk level.

[0077] In one optional implementation, the step of determining the target audit strategy based on the current audit result and the target risk level, and invoking the target audit strategy to generate the final audit status of the component license, includes: if the target risk level is low, then using the current audit result as the final audit status of the component license; if the target risk level is medium, then generating a warning message and sending a review notice to a designated auditor, and determining the final audit status of the component license based on the review result; if the target risk level is high, then creating a multi-signature transaction requiring at least two management personnel signatures, and determining the final audit status of the component license based on the execution result of the multi-signature transaction.

[0078] The smart contract on the blockchain pre-defines the correlation between candidate risk levels and candidate audit strategies. The target risk level is matched against this correlation to determine the target audit strategy, and the dynamically matched target audit strategy is executed. If the target risk level is low, the smart contract is invoked, and the current audit result on the blockchain is used as the final audit status of the component license. For example, the relevant component is automatically marked as "compliant," and the audit process ends. If the target risk level is determined to be medium, the smart contract is invoked to automatically generate a warning message and notify the designated auditor to review the component.

[0079] If the target risk level is determined to be high, such as when a component originates from a supplier with a poor track record or when code snippets show suspected infringement, a smart contract is invoked to create a multi-signature transaction requiring a system administrator's signature. Only after this multi-signature transaction is successfully confirmed will the component's final audit status be determined to be compliant. In other words, once the target risk level is high, the system will automatically execute a more stringent operating procedure, marking the component's compliance status as "pending manual review" even if it has already passed the license compliance audit. Only after the multi-signature transaction confirmation step can the final audit status of the object change from "pending manual review" to "compliant." By dynamically determining the target audit strategy based on the target risk level and generating the final audit status of the component license based on the current audit results and the target audit strategy, the audit intensity for high-risk components is upgraded, forcing manual intervention and effectively preventing and managing compliance risks in the software supply chain.

[0080] Example 3

[0081] Figure 3 This is a schematic diagram of a software supply chain processing device according to Embodiment 3 of this application. This embodiment is applicable to compliance audits of the software supply chain based on smart contracts and machine learning. The software supply chain processing device can be implemented in hardware and / or software, and can be configured in a blockchain node. (Reference) Figure 3 The specific structure of the software supply chain processing device 300 is as follows:

[0082] The transaction request acquisition module 310 is used to acquire on-chain transaction requests carrying standardized license data and metadata; the standardized license data is obtained by parsing the license information of the components in the software and standardizing the license information; the metadata includes at least the submitter of the on-chain transaction request and the license data hash, and the license data hash is obtained by hashing the standardized license data.

[0083] The permission on-chain module 320 is used to verify the legitimacy of the submitter's identity and to verify the data integrity of the standardized permission data; if both verifications are successful, the standardized permission data is written into the blockchain.

[0084] The license audit module 330 is used to call the license audit smart contract to perform at least one of the following processes on the component license: compliance policy, compatibility and copyright statement integrity detection, and obtain the current audit result of the component license;

[0085] Risk prediction module 340 is used to obtain the target risk level obtained by using a risk prediction model to predict the risk level of the component;

[0086] The audit status generation module 350 is used to determine the target audit strategy based on the current audit results and the target risk level, and to call the target audit strategy to generate the final audit status of the component license.

[0087] In one alternative implementation, the standardized license data includes at least one of the following: software name, software version, component name, component version, vendor, component hash, or component license;

[0088] The permissioned on-chain module 320 is specifically used for:

[0089] The software name, the software version, and the component license identifier are hashed respectively to obtain the hash value of the software name, the hash value of the software version, and the hash value of the license identifier;

[0090] The key of the standardized license data is a path structure formed by concatenating the hash value of the software name, the hash value of the software version, the component hash, and the hash value of the license identifier;

[0091] The standardized license data includes at least one of the following: component name, component version, supplier, component hash, or component license.

[0092] In one alternative implementation, the license audit module 330 includes:

[0093] The policy detection unit is used to extract component licenses from standardized licensing data and call the license blacklist and license whitelist stored on the chain to perform compliance policy detection on the component licenses;

[0094] The compatibility detection unit is used to determine that the compliance audit result of the component license is compliant if the component license is not in the license blacklist and exists in the license whitelist, and to perform compatibility detection on different component licenses in the software to obtain the compatibility detection result.

[0095] The copyright declaration integrity detection unit is used to perform a copyright declaration integrity detection on the component license if the compatibility detection result is compliant, and obtain the current audit result of the component license.

[0096] In one alternative implementation, the compatibility detection unit is specifically used for:

[0097] Obtain component licenses for multiple components within the same software, and combine different components in pairs to form component license pairs;

[0098] The pre-set license compatibility rule matrix is ​​invoked to perform compatibility checks on the two component licenses in the component license pair, and the compatibility check results are obtained.

[0099] In one optional implementation, the declaration integrity detection unit is specifically used for:

[0100] Determine whether the component license includes an unmodifiable declaration;

[0101] If an unmodifiable declaration is included, the genuine component hash library is invoked to compare the component hash with the genuine component hash, and the current audit result of the component license is generated based on the comparison result.

[0102] In one alternative implementation, the target risk level is obtained through the following processing:

[0103] Based on the component name, the component characteristics are determined; the component characteristics include at least one of the following: component age, number of referenced projects, number of historical vulnerabilities, or average repair time;

[0104] Based on the standardized licensing data, license characteristics are determined; the license characteristics include at least one of the following: license category, whether it is a non-standard license, whether there are complex exception clauses, or whether copying is permitted.

[0105] Based on the component supplier, supplier characteristics are determined; the supplier characteristics include at least one of the following: supplier reputation score, code submission frequency, community activity, or supplier historical submission behavior data;

[0106] Extract code fingerprints from component code and compare them with open-source code libraries to calculate the maximum code segment similarity.

[0107] Based on the software name, component names, and software bill of materials, the characteristics of the software project are determined. The software project characteristics include at least one of the following: project complexity, development team size, or historical compliance pass rate. The historical compliance pass rate is obtained by querying the historical audit status in the blockchain.

[0108] Based on the software bill of materials, determine the graph features of the components in the dependency graph; the graph features include centrality or whether they are on the critical path;

[0109] By inputting component features, license features, supplier features, maximum code snippet similarity, software project features, and graph features into a risk prediction model trained based on machine learning, the target risk level is obtained.

[0110] In one optional implementation, the audit status generation module 350 is specifically used for:

[0111] If the target risk level is low, then the current audit result will be taken as the final audit status of the component license;

[0112] If the target risk level is medium, a warning message is generated and a review notice is sent to the designated auditor. The final audit status of the component license is determined based on the review result.

[0113] If the target risk level is high, a multi-signature transaction requiring at least two administrator signatures is created, and the final audit status of the component license is determined based on the execution result of the multi-signature transaction.

[0114] The software supply chain processing apparatus provided in this application embodiment can execute the software supply chain processing method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the software supply chain processing method.

[0115] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements any software supply chain processing method provided in any embodiment of the present invention.

[0116] Example 4

[0117] Figure 4 This is a schematic diagram of the structure of an electronic device 410 implementing the software supply chain processing method of the embodiments of this application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0118] like Figure 4 As shown, the electronic device 410 includes at least one processor 411 and a memory, such as a read-only memory (ROM) 412 or a random access memory (RAM) 413, communicatively connected to the at least one processor 411. The memory stores computer programs executable by the at least one processor. The processor 411 can perform various appropriate actions and processes based on the computer program stored in the ROM 412 or loaded from storage unit 418 into the RAM 413. The RAM 413 may also store various programs and data required for the operation of the electronic device 410. The processor 411, ROM 412, and RAM 413 are interconnected via a bus 414. An input / output (I / O) interface 415 is also connected to the bus 414.

[0119] Multiple components in electronic device 410 are connected to I / O interface 415, including: input unit 416, such as keyboard, mouse, etc.; output unit 417, such as various types of displays, speakers, etc.; storage unit 418, such as disk, optical disk, etc.; and communication unit 419, such as network card, modem, wireless transceiver, etc. Communication unit 419 allows electronic device 410 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0120] Processor 411 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 411 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 411 performs the various methods and processes described above, such as software supply chain processing methods.

[0121] In some embodiments, the software supply chain processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 418. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 410 via ROM 412 and / or communication unit 419. When the computer program is loaded into RAM 413 and executed by processor 411, one or more steps of the software supply chain processing method described above may be performed. Alternatively, in other embodiments, processor 411 may be configured as the software supply chain processing method by any other suitable means (e.g., by means of firmware).

[0122] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0123] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0124] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, 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 of the foregoing.

[0125] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0126] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0127] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0128] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0129] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A software supply chain processing method, characterized in that, The method, executed by a blockchain node, includes: Obtain an on-chain transaction request carrying standardized license data and metadata; the standardized license data is obtained by parsing the license information of the components in the software and standardizing the license information; the metadata includes at least the submitter of the on-chain transaction request and the license data hash, and the license data hash is obtained by hashing the standardized license data. The identity of the submitter is verified, and the data integrity of the standardized license data is verified; if both verifications are successful, the standardized license data is written into the blockchain. Call the license audit smart contract to perform at least one of the following checks on the component license: compliance policy, compatibility, and copyright statement integrity, and obtain the current audit result of the component license; Obtain the target risk level obtained by using a risk prediction model to predict the risk level of the component; Based on the current audit results and the target risk level, a target audit strategy is determined, and the target audit strategy is invoked to generate the final audit status of the component license.

2. The method according to claim 1, characterized in that, The standardized license data includes at least one of the following: software name, software version, component name, component version, vendor, component hash, or component license; Writing the standardized permission data into the blockchain includes: The software name, the software version, and the component license identifier are hashed respectively to obtain the hash value of the software name, the hash value of the software version, and the hash value of the license identifier; The key of the standardized license data is a path structure formed by concatenating the hash value of the software name, the hash value of the software version, the component hash, and the hash value of the license identifier; The standardized license data includes at least one of the following: component name, component version, supplier, component hash, or component license.

3. The method according to claim 1, characterized in that, The license audit smart contract is invoked to perform at least one of the following checks on the component license: compliance policy, compatibility, and copyright statement integrity, to obtain the current audit result of the component license, including: Extract component licenses from standardized licensing data, and use the license blacklist and license whitelist stored on the blockchain to perform compliance policy checks on the component licenses; If the component license is not in the license blacklist but exists in the license whitelist, the compliance audit result of the component license is determined to be compliant, and compatibility testing is performed on different component licenses in the software to obtain the compatibility test result; If the compatibility test result is compliant, then the copyright statement integrity test is performed on the component license to obtain the current audit result of the component license.

4. The method according to claim 3, characterized in that, Compatibility testing was performed on the licenses of different components in the software. The compatibility test results include: Obtain component licenses for multiple components within the same software, and combine different components in pairs to form component license pairs; The pre-set license compatibility rule matrix is ​​invoked to perform compatibility checks on the two component licenses in the component license pair, and the compatibility check results are obtained.

5. The method according to claim 3, characterized in that, Perform a copyright statement integrity check on the component license to obtain the current audit result of the component license, including: Determine whether the component license includes an unmodifiable declaration; If an unmodifiable declaration is included, the genuine component hash library is invoked to compare the component hash with the genuine component hash, and the current audit result of the component license is generated based on the comparison result.

6. The method according to claim 1, characterized in that, The target risk level is obtained through the following process: Based on the component name, the component characteristics are determined; the component characteristics include at least one of the following: component age, number of referenced projects, number of historical vulnerabilities, or average repair time; Based on the standardized licensing data, license characteristics are determined; the license characteristics include at least one of the following: license category, whether it is a non-standard license, whether there are complex exception clauses, or whether copying is permitted. Based on the component supplier, supplier characteristics are determined; the supplier characteristics include at least one of the following: supplier reputation score, code submission frequency, community activity, or supplier historical submission behavior data; Extract code fingerprints from component code and compare them with open-source code libraries to calculate the maximum code segment similarity. Based on the software name, component names, and software bill of materials, determine the characteristics of the software project; software Project characteristics include at least one of the following: project complexity, development team size, or historical compliance pass rate; the historical compliance pass rate is obtained by querying the historical audit status in the blockchain; Based on the software bill of materials, determine the graph features of the components in the dependency graph; the graph features include centrality or whether they are on the critical path; By inputting component features, license features, supplier features, maximum code snippet similarity, software project features, and graph features into a risk prediction model trained based on machine learning, the target risk level is obtained.

7. The method according to claim 1, characterized in that, The step of determining the target audit strategy based on the current audit results and the target risk level, and then invoking the target audit strategy to generate the final audit status of the component license, includes: If the target risk level is low, then the current audit result will be taken as the final audit status of the component license; If the target risk level is medium, a warning message is generated and a review notice is sent to the designated auditor. The final audit status of the component license is determined based on the review result. If the target risk level is high, a multi-signature transaction requiring at least two administrator signatures is created, and the final audit status of the component license is determined based on the execution result of the multi-signature transaction.

8. A software supply chain processing device, characterized in that, Configured on a blockchain node, the device includes: The transaction request acquisition module is used to acquire on-chain transaction requests carrying standardized license data and metadata. The standardized license data is obtained by parsing the license information of the components in the software and standardizing the license information. The metadata includes at least the submitter of the on-chain transaction request and the license data hash. The license data hash is obtained by hashing the standardized license data. The permission on-chain module is used to verify the legitimacy of the submitter's identity and to verify the data integrity of the standardized permission data; if both verifications are successful, the standardized permission data is written into the blockchain. The license audit module is used to call the license audit smart contract to perform at least one of the following processes on the component license: compliance policy, compatibility and copyright statement integrity detection, and obtain the current audit result of the component license; The risk prediction module is used to obtain the target risk level obtained by using a risk prediction model to predict the risk level of the component; The audit status generation module is used to determine the target audit strategy based on the current audit results and the target risk level, and to call the target audit strategy to generate the final audit status of the component license.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the software supply chain processing method as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the software supply chain processing method according to any one of claims 1-7.

Images