Intelligent risk identification and self-adaptive repair method, system and equipment for software supply chain and medium

Abstract

The invention discloses an intelligent risk identification and self-adaptive repair method, system and device for a software supply chain and a medium, belongs to the field of network security and automatic software engineering, and aims to solve the technical problem of how to accurately and comprehensively identify software code supply chain risks including code snippets. A reliable and efficient automatic closed-loop repair scheme is provided, and the technical defects that in the prior art, the software code supply chain recognition range is limited, the repair process is rigid and the reliability is low are overcome. Analyzing the declarative dependency; meanwhile, semantic traceability based on artificial intelligence is carried out on the code snippets, and a global software material list is generated; and performing intelligent mapping on the software components in the global software bill of materials and the vulnerability database to identify risks.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network security and automated software engineering, in particular to an intelligent risk identification and adaptive repair method, system, device and medium for software supply chain. BACKGROUND

[0002] With the vigorous development of open source movement, modern software development has been generally built on a large amount of open source software. In order to ensure the security of software products, software component analysis (SCA) technology has emerged, aiming to identify third-party open source components and security vulnerabilities carried by them in software.

[0003] However, the existing technical solutions still have obvious deficiencies in ensuring the security and resilience of open source software supply chain:

[0004] ① The existing SCA technology mainly identifies components by analyzing the dependency list files predefined by the project. For code snippets copied, pasted and possibly modified from open source communities on the network for the convenience of developers, effective identification and source tracing cannot be performed. Such untracked "shadow code" has become a huge blind spot in supply chain security management.

[0005] ② When providing vulnerability repair solutions, the existing technology usually only gives simple version number upgrade suggestions. Developers cannot predict whether version upgrade will cause API incompatibility and other destructive changes, so the repair willingness is low and the risk exposure period is long. When upgrading is not feasible, the existing technology also cannot provide effective backup repair paths, causing the interruption of the security repair workflow and seriously affecting the overall resilience of the software supply chain.

[0006] Therefore, how to accurately and comprehensively identify the risks of software code supply chain including code snippets and propose reliable and efficient automated closed-loop repair solutions to overcome the technical defects of limited identification range of software code supply chain and rigid and low reliability of repair process in the existing technology is a technical problem to be solved. SUMMARY

[0007] The technical task of the present application is to provide an intelligent risk identification and adaptive repair method, system, device and medium for software supply chain to solve the problem of how to accurately and comprehensively identify the risks of software code supply chain including code snippets and propose reliable and efficient automated closed-loop repair solutions to overcome the technical defects of limited identification range of software code supply chain and rigid and low reliability of repair process in the existing technology.

[0008] The technical task of the present application is achieved in the following manner, an intelligent risk identification and adaptive repair method for software supply chain, which is specifically as follows:

[0009] Collect and preprocess the source code and dependency list file of the target software project: In a zero trust scenario, collect the source code, image layer, and runtime dynamic dependencies in a panoramic and incremental manner to generate a verifiable forensic chain and directly output Patch-Level SBOM fragments, Layer-Level SBOM fragments, and Runtime-SBOM stream data, and simultaneously merge to generate a Manifest file set, providing a high-integrity and high-timeliness data foundation for subsequent risk identification; wherein the Manifest file set includes explicit dependency lists of pom.xml, package.json, go.mod, and requirements.txt;

[0010] Parse the declarative dependencies: By calling the parsing engine matched with each programming language ecosystem, accurately parse the collected dependency list file, extract all directly dependent items and their version constraints declared in the project, and then interact with remote, public or private software package repositories (such as Maven Central, NPM Registry, PyPI, etc.) to recursively parse the transitive dependencies introduced by each direct dependency item, finally building a complete, multi-level project dependency relationship tree;

[0011] At the same time, perform semantic tracing based on artificial intelligence on the code fragments to generate a global software bill of materials (SBOM);

[0012] Intelligently map the software components in the global software bill of materials with the vulnerability database to identify risks;

[0013] For software components with risks, start a hierarchical adaptive repair decision-making process that includes automated upgrade sandbox verification and intelligent replacement component recommendation;

[0014] According to the recommended hierarchical adaptive repair decision-making process, deliver a trusted repair solution to the user that includes a verified merge request, replacement solution report, or code-level repair suggestion.

[0015] As a preferred embodiment, collecting and preprocessing the source code and dependency list of the target software project is as follows:

[0016] Forensic chain initialization, i.e., establishing an unalterable integrity proof for all source code and compressed package (image layer): Calculate the Merkle tree hash for the objects to be collected including Git repository, compressed package, and container image layer, generate a timestamped and signed collection record and write it into an immutable log to achieve tamper-proofing function, meet compliance forensics, and enable quick accountability in case of suspicion;

[0017] Version control incremental collection: Only analyze the modified part this time, generate a differential SBOM fragment, and compare the last scan result based on object hash. Only re-parsing the incremental file, while persisting the patch-level SBOM fragment and marking the source branch;

[0018] Mirror lazy loading collection, that is, only processing the changed Layer of the container image, thereby saving network and disk, occupying fewer resources and running faster: using eStargz lazy-pull technology to only decompress the modified Layer of the OCI image, and generating Layer-Digest fingerprint for each Layer;

[0019] Runtime dependency capture, that is, recording the dynamically loaded libraries or plugins during program running: injecting eBPF probes into the target host to capture dynamic loading events such as dlopen() and LoadLibrary(), and merging them into Runtime-SBOM stream data;

[0020] Language self-discovery and plugin sandbox: converting "multi-language, raw files" into "language-labeled, unified fingerprint, and source-signed" language-Meta fingerprint fragments. Language-Meta fingerprint fragments carry language labels, analysis plugin IDs, dependency Token digest hashes, and collection signatures. Based on FastText Embedding learning and K Means clustering methods, unknown language folders are automatically identified. Compared with traditional machine learning recognition components that rely on manual configuration of plugins, the language self-discovery method automatically pulls corresponding Wasm-Sandbox analysis plugins, completes cross-language unified fingerprinting, and improves the efficiency of unknown file recognition.

[0021] The incremental SBOM merging output, that is, merging all difference fragments into a unified SBOM with a provenance signature: the PatchLevel, Layer Level, Runtime SBOM fragments and language-Meta fingerprint fragments are hashed and merged to generate an incremental SBOM with a provenance field, and are written back to the backend graph database; specifically: first, the BLAKE3 value of "component specification name + version number + source path" is taken as the primary key for global hash deduplication of Patch Level, Layer Level, Runtime SBOM fragments and language-Meta fingerprint fragments; then, according to the three-dimensional topological relationship of "code branch, image layer, running state process", the dependencies are re-merged, and the provenance field is supplemented for each record; wherein, the provenance field includes the collection timestamp, the collection chain signature, the analysis plug-in ID and the model version number; finally, an incremental SBOM file conforming to the OpenSBOM JSON specification is obtained after processing, and the incremental SBOM file together with its provenance relationship is written into the backend graph database for direct reference by vulnerability scanning, license auditing and supply chain resilience assessment, while historical versions are retained to support backtracking and differential analysis.

[0022] More preferably, the language self-discovery and the plug-in sandbox are divided into an offline training phase and an online running phase.

[0023] The offline training phase specifically includes: first, a multi-language corpus is constructed, and source code of no less than 30 programming languages is selected as training samples; then, a FastText model is used for word vector training, wherein the FastText model is configured as a skip-gram structure and enables a subword(n-gram) mechanism, the word vector dimension is set to 128, and the subword length range is set to 3-6; the skip-gram structure trains the word vector by predicting the corresponding context words from the center word, so that the frequently co-occurring keywords are automatically clustered in the vector space, thereby efficiently capturing semantic adjacency relationships; the subword(n-gram) mechanism represents that each word is divided into 3-6 n-grams and the corresponding vector is learned, so that even if an unregistered or rare word is encountered, a robust representation can be combined from fragments, and fine-grained morphological information of prefixes and suffixes is retained; finally, after training is completed, each sample file is mapped to a 128-dimensional file vector through average pooling, and K-Means clustering (k≈number of languages) is performed based on the file vector, and a "cluster-language" mapping table is obtained after comparing the clustering result with the language feature library;

[0024] The online running stage specifically includes: when a file to be analyzed is scanned, the FastText model saved offline is called to convert the file into a 128-dimensional vector, and the Euclidean distance from the 128-dimensional vector to the center of each cluster is calculated; if the minimum distance is less than the preset threshold 0.7, the language to which the file belongs is directly determined, otherwise the plug-in registration center is submitted for manual annotation; after the language to which the file belongs is determined, the corresponding Wasm-Sandbox analysis plug-in is automatically pulled according to the "cluster-language" mapping table, the syntax tree of the file is parsed, the uniform Token stream is obtained, and the cross-language consistent fingerprinting is realized.

[0025] As preferred, the parsing of the declarative dependency is specifically as follows:

[0026] The Manifest file set is received, covering the mainstream formats of pom.xml, package.json, requirements.txt and go.mod, each Manifest file set is sent to the parsing engine matched with the language ecology, that is, Maven POM is verified by XML Schema, NPM list is verified by JSON Schema, Python requirements are verified by regular and PEP440 parser, and at the same time, the parsing engine internally constructs a lightweight AST, only retaining three types of nodes of dependency name, version constraint and scope, and discarding other comments and format information in time to avoid redundant data transmission;

[0027] For each direct dependency obtained by parsing, a metadata query is initiated to the corresponding software repository, that is, MavenCentral calls the REST API to initiate a metadata query to the corresponding software repository, NPM and PyPI call the JSON Index to initiate a metadata query to the corresponding software repository; the query result includes the latest security version, the upstream license, the SHA-256 digest and the release date; if the version constraint in the Manifest file set uses "dynamic markers" (such as ~, ^ and +), the parsing engine calls the semantic version comparator to parse the dynamic markers into specific allowed intervals, and then performs intersection operation with the candidate versions returned by the repository to obtain the minimum safe version and the maximum compatible version of the corresponding dependency at the current time;

[0028] Recursive processing of each direct dependency POM, package.json or similar file until no more transitive dependencies can be resolved: throughout the entire recursive process, the results are generated BLAKE3 fingerprints based on "component name + version number + source file hash" and real-time deduplication, ensuring that the same dependency is only retained in one node in different branches or different image layers; After the recursion is completed, all nodes and edges are arranged into a directed acyclic graph; Among them, the node attributes include the specification name, parsing source path, license, version constraint interval, security recommended version, and timestamp and signature information inherited by the evidence chain; Edge attributes are used to mark "declaration relationship" or "transitive relationship", and record the propagation depth;

[0029] Obtain the dependency graph and persist it in OpenSBOM JSON-Dependencies extension format: the top meta field contains the Manifest version number used this time and the parser version, the body part stores the dependency nodes by depth, all fields are with provenance, directly for subsequent vulnerability scanning, license audit and version conflict detection calls, and write back to the backend graph database to align with the incremental SBOM merging logic.

[0030] As a preferred, the code snippet is semantically traced based on artificial intelligence to generate a global software bill of materials as follows:

[0031] Perform syntax analysis on all collected source code to structurally divide the source code into code units (functions, methods, classes) with independent functional context;

[0032] Convert the code unit into a high-dimensional vector that can deeply represent the corresponding functional semantics using the BI-SentenceBert model based on evolutionary algorithms; Among them, the evolutionary algorithm is used to continuously optimize the representation ability and retrieval efficiency of the vector model, so that the vector model has higher robustness to code perturbations such as variable renaming and comment modification, thereby accurately tracing the real source project, version, open source license and potential vulnerabilities of "shadow code";

[0033] In a pre-built database containing massive open source project code vectors, perform efficient similarity retrieval;

[0034] The BI-SentenceBert model based on the evolutionary algorithm comprises a word embedding layer, a position encoding layer, a 12-layer Bert-base encoder, a bidirectional context pooling layer, a first full-connection projection layer, a second full-connection projection layer and an output layer. The bidirectional context pooling layer is behind the 12-layer BERT-Base encoder, and the [CLS] vector and the last non-padding token vector are taken at the same time, spliced, projected and compressed to 256 dimensions through the first full-connection projection layer and the second full-connection projection layer. The [CLS] vector is used to retain the overall semantics of the segment, and the last non-padding token vector is used to make up the tail dependency information, so that the BI-SentenceBert model based on the evolutionary algorithm can still accurately capture the functional boundary in the variable renaming and annotation truncation scene. The BI-SentenceBert model based on the evolutionary algorithm automatically searches the hyperparameters by the evolutionary algorithm instead of the manual grid. The chromosome encodes the pooling structure, the vector dimension, the contrast learning temperature and the quantization strategy 16 genes at the same time. The fitness function takes the code cloning recall and the coding delay as the double targets. After 30 generations of NSGA-II evolution, the selected "elite individuals" reduce the reasoning delay and the memory occupation while maintaining the recall. The evolutionary algorithm calculation process for the parameter optimization of the BI-SentenceBert model based on the evolutionary algorithm is as follows.

[0035] (1) Chromosome coding: the gene position representation is set in the form of {Pooling method, Projection dimension, Learning rate, Batch size, Contrastive loss temperature, Quantization strategy};

[0036] (2) Initial population: 24 groups of hyperparameters are randomly sampled, and the pre-trained BERT-Base weight is taken as the common starting point;

[0037] (3) Fitness function design: NSGA-II (improved multi-objective genetic algorithm) can better process high-dimensional target space; wherein, the fitness function comprises a main target, a secondary target and a comprehensive fitness function; the main target f1 is used for maximizing the retrieval accuracy, and the specific quantification formula is: f1 = Recall@10; wherein, Recall@10 is calculated through the code cloning test set; the secondary target f2 is used for minimizing the reasoning speed, and the specific quantification formula is: f2 = -log(AvgLatency) (ms / segment); wherein, AvgLatency is obtained by measuring the single-segment processing time of the model; the comprehensive fitness function F formula is:

[0038] (4) Genetic: including genetic crossover and mutation; for genetic crossover, whole gene exchange (e.g. "Pooling+Projection" pair); for genetic mutation: randomly select a gene site and add Gaussian noise;

[0039] (5) Iteration and convergence: set the acceleration algorithm convergence speed when the Recall@10 is improved to 90% and the encoding delay is reduced to within 7ms;

[0040] (6) The final reserved "elite individual" is the network configuration listed in the above table.

[0041] As preferred, the software components in the global software bill of materials are intelligently mapped with the vulnerability database to identify risks as follows:

[0042] The declarative dependency tree is combined and de-duplicated with the code snippet information to generate a truly complete global software bill of materials (SBOM) containing all third-party components;

[0043] Intelligent vulnerability database correlation matching is performed using a bidirectional graph neural network-LSTM network: the bidirectional graph neural network-LSTM network constructs a dependency relationship graph from the global software bill of materials, learns the complex dependency relationships between components using a graph neural network (GNN), and analyzes the context of the vulnerability description text using a long short-term memory network (LSTM), thereby achieving more intelligent and accurate risk identification than traditional keyword matching, not only direct CVE matching, but also potential and not explicitly disclosed risks based on dependency context;

[0044] The input end of the bidirectional graph neural network-LSTM network includes two parallel branches of Graph branch and Text branch; the Graph branch reads the dependency relationship graph, propagates the in-edge and out-edge information using a bidirectional GNN, and obtains a global vector vg of the global software bill of materials graph reflecting the dual influence of "upstream dependency on components" and "propagation effect of components on downstream"; the Text branch reads the vulnerability description text in the official Common Vulnerability Enumeration (CVE) database, uses a bidirectional LSTM to capture the cause-and-effect semantics at the beginning and end of the sentence, and capture the complete before-and-after semantics, and finally obtains a text vector vt that has undergone deep semantic understanding; the Graph branch and the Text branch meet at the "attention fusion layer", where the learnable attention matrix highlights the high correlation information between "key dependency paths" and "high-risk predicates", and finally outputs a set of K-dimensional risk score values for labeling the known vulnerability risks and potential context risks of each component in the global software bill of materials.

[0045] As preferred, for software components with risks, a hierarchical adaptive repair decision-making process is started, including automated upgrade sandbox verification and intelligent replacement component recommendation, as follows:

[0046] The automatic upgrade sandbox verification is the first level of the adaptive repair process. When a vulnerability is identified, a temporary Docker isolated environment is prepared and the unreliable repair suggestion is converted into a verified trusted operation through automatic version upgrade; Specifically, according to the construction requirements of the project, an image is automatically pulled and a pure and isolated Docker container is created; In the Docker container, first, the version upgrade operation is automatically performed to update the vulnerable component to a safe version; Then, the preset complete test suite (including unit testing, integration testing, etc.) in the project code library is automatically called and executed to verify whether the upgrade has damaged the original function of the project, and the test results are recorded in detail and used as a key basis for decision-making repair path;

[0047] The intelligent replacement component recommendation is the second level of the adaptive repair process, which is started when direct upgrade is not feasible (i.e., sandbox verification fails). Specifically, first, static analysis is performed on the project source code to understand the specific API usage mode of the vulnerable component; Then, a knowledge graph containing multi-dimensional information such as the functionality, API signature, community activity, and license compatibility of mainstream open source components is queried, and candidate replacement components with similar functionality, high API compatibility, and no security risks are intelligently selected; Finally, a detailed recommendation report containing the pros and cons comparison and migration cost evaluation is generated;

[0048] According to the recommended hierarchical adaptive repair decision-making process, a trusted repair scheme containing a verified merge request, a replacement scheme report, or a code-level repair suggestion is delivered to the user, which is as follows:

[0049] If the automatic upgrade sandbox verification is passed, a merge request (Pull Request) containing version upgrade code and a link to the successful test log is automatically created for the developer to review and one-click merge;

[0050] If the intelligent replacement component recommendation is executed, a detailed repair suggestion report will be generated, including the pros and cons comparison of the replacement component and specific code modification suggestions;

[0051] All deliverables are seamlessly integrated into the developer's daily workflow through an IDE plug-in, forming a complete and efficient automated closed loop from risk identification to reliable disposal.

[0052] An intelligent risk identification and adaptive repair system for a software supply chain, which is used to implement the intelligent risk identification and adaptive repair method for a software supply chain as described above; The system comprises:

[0053] The project data collection and preprocessing module is configured to collect panoramic and incremental trusted data of source code, image layers and runtime dynamic dependencies in a zero trust scenario, generate a verifiable forensic chain, and directly output patch-level SBOM segments, layer-level SBOM segments and runtime-SBOM stream data, and synchronously merge to generate a manifest file set, thereby providing a high-integrity and high-timeliness data basis for subsequent risk identification; wherein the manifest file set includes explicit dependency lists of pom.xml, package.json, go.mod and requirements.txt.

[0054] The declarative dependency resolution module is configured to accurately parse the collected dependency list files through calling parsing engines matched with various programming language ecosystems, extract all directly dependent items and version constraints declared in the project, and interact with remote, public or private software package repositories (such as Maven Central, NPM Registry, PyPI, etc.) to recursively analyze the transitive dependencies introduced by each direct dependent item, and finally build a complete, multi-level project dependency relationship tree.

[0055] The intelligent code snippet semantic tracing module is configured to perform semantic tracing on code snippets based on artificial intelligence, and generate a global software bill of materials (SBOM).

[0056] The global software bill of materials generation and risk mapping module is configured to intelligently map software components in the global software bill of materials with a vulnerability database through a bidirectional graph neural network-LSTM network to identify risks.

[0057] The automated upgrade sandbox verification module is configured to, for software components with risks, prepare and automatically upgrade through a temporary Docker isolation environment to convert unreliable repair suggestions into verified trusted operations.

[0058] The intelligent alternative component recommendation module is configured to, after sandbox verification fails, first perform static analysis on the project source code to understand the specific API usage mode of the vulnerability component; then query a knowledge graph containing multi-dimensional information of mainstream open source component functions, API signatures, community activity and license compatibility, intelligently filter out candidate alternative components with similar functions, high API compatibility and no such security risks; and finally generate a detailed recommendation report containing pros and cons comparison and migration cost evaluation.

[0059] The repairable solution delivery module is configured to deliver a trusted repair solution including verified merge requests, alternative solution reports or code-level repair suggestions to the user according to the recommended hierarchical adaptive repair decision-making process.

[0060] An electronic device, comprising: a memory and at least one processor;

[0061] Wherein the memory has stored thereon a computer program;

[0062] The at least one processor executes the computer program stored in the memory, so that the at least one processor executes the intelligent risk identification and adaptive repair method of the software supply chain as described above.

[0063] A computer-readable storage medium having stored therein a computer program, the computer program being executable by a processor to implement the intelligent risk identification and adaptive repair method of the software supply chain as described above.

[0064] The intelligent risk identification and adaptive repair method, system, device and medium of the software supply chain of the present application have the following advantages:

[0065] (I) The present application can comprehensively and accurately identify the supply chain risks including code fragments, and provide reliable and efficient automated closed-loop repair capability, solving the technical problems of limited identification range and unreliable repair recommendations of the prior art;

[0066] (II) The present application adopts a new BI-SentenceBert model based on evolutionary algorithm proposed in the present patent, which solves the fundamental defect that the traditional SCA technology cannot identify "shadow code", and realizes accurate identification of the modified copy-paste code;

[0067] (III) Compared with the algorithm process of the traditional sentencebert model, the bidirectional pooling provided by the BI-SentenceBERT model based on evolutionary optimization proposed in the present application provides a more complete semantic view, the evolutionary hyperparameter order model achieves Pareto optimality between precision and efficiency, and the two-point cooperation can further improve the semantic understanding of the model, further improve the accuracy of classification, reduce the reasoning delay, and improve the comprehensive technical effect of generalization.

[0068] (Four) Compared with the traditional graph neural network method of matching CVE by only making information transmission on a one-way dependency graph, reusing keywords or simple vector addition, the bidirectional graph neural-LSTM model of the application has improved in three aspects: first, the bidirectional GNN simultaneously aggregates in edges and out edges in the same layer, enabling the component to perceive the conduction of upstream defects and capture the potential impact of its own hidden dangers on the downstream, further mining deep semantic features; second, the bidirectional LSTM that fuses the semantics before and after can completely parse the version boundary words and impact range sentences, automatically focusing on high-risk predicates such as "remote code execution" and "privilege escalation" with the attention mechanism, significantly improving the distinguishability of vulnerability semantics; finally, after alignment by the cross-modal attention layer, the model can fully match the high-order correspondence between the dependency topology and the vulnerability semantics in the unified embedding space, theoretically eliminating the semantic missing problem caused by the traditional GNN's dependence on keywords or shallow vector splicing, and further obtaining more interpretable risk inference and component-level labeling results;

[0069] (Five) The application adopts the global SBOM dynamic generation technology to fuse declarative dependency analysis and code semantic tracing, accurately identifying explicit dependencies and "shadow code" of copy and paste;

[0070] (Six) The BI-SentenceBert code clone detection model of the application optimizes the semantic vector model through an evolutionary algorithm, resists disturbances such as variable renaming, and realizes high-robustness code tracing;

[0071] (Seven) The bidirectional graph neural-LSTM risk mapping network of the application combines the dependency graph based on bidirectional GNN with the vulnerability text analysis based on bidirectional attention mechanism LSTM, identifying direct vulnerabilities and potential propagation risks;

[0072] (Eight) The hierarchical adaptive repair closed loop of the application adopts sandbox verification, intelligent replacement recommendation, and repair scheme delivery to form an automated repair link. BRIEF DESCRIPTION OF DRAWINGS

[0073] The application will be further described below with reference to the accompanying drawings.

[0074] FIG. 1 is a flowchart of the intelligent risk identification and adaptive repair method for a software supply chain of the application; Figure 1 FIG. 2 is a flowchart of collecting and preprocessing the source code and dependency list file of the target software project;

[0075] FIG. 3 is a flowchart of the intelligent risk identification and adaptive repair system for a software supply chain of the application; Figure 2 FIG. 4 is a flowchart of the intelligent risk identification and adaptive repair device for a software supply chain of the application; DETAILED DESCRIPTION

[0076] The intelligent risk identification and adaptive repair method, system, device and medium for a software supply chain of the application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0077] Embodiment 1

[0078] As shown in the accompanying Figure 1 The embodiment provides a method for intelligent risk identification and adaptive repair of a software supply chain, and the method specifically comprises the following steps:

[0079] S1, collecting and preprocessing source code and dependency list files of a target software project: in a zero trust scenario, collecting source code, image layer and runtime dynamic dependencies in a panoramic and incremental manner to generate a verifiable evidence chain and directly output Patch-Level SBOM segments, Layer-Level SBOM segments and Runtime-SBOM stream data, and synchronously merging to generate a Manifest file set, thereby providing a high-integrity and high-timeliness data basis for subsequent risk identification; wherein the Manifest file set includes explicit dependency lists of pom.xml, package.json, go.mod and requirements.txt;

[0080] S2, parsing declarative dependencies: by calling a parsing engine matched with each programming language ecosystem, accurately parsing the collected dependency list files, extracting all directly dependent items and version constraints declared in the project, and then interacting with remote, public or private software package repositories (such as Maven Central, NPM Registry, PyPI, etc.) to recursively parse the transitive dependencies introduced by each direct dependency item, and finally building a complete, multi-level project dependency relationship tree;

[0081] S3, simultaneously performing semantic tracing based on artificial intelligence on code segments to generate a global software bill of materials (SBOM);

[0082] S4, intelligently mapping software components in the global software bill of materials with a vulnerability database to identify risks;

[0083] S5, for software components with risks, starting a hierarchical adaptive repair decision-making process including automated upgrade sandbox verification and intelligent replacement component recommendation;

[0084] S6, according to the recommended hierarchical adaptive repair decision-making process, delivering a trusted repair solution including a verified merge request, a replacement solution report or a code-level repair suggestion to the user.

[0085] As shown in the accompanying Figure 2 The embodiment provides a method for intelligent risk identification and adaptive repair of a software supply chain, and the method specifically comprises the following steps:

[0086] S101, Forensic chain initialization, that is, to establish an unalterable integrity proof for all source code, compressed package, and image layer: calculate the Merkle tree hash of the to-be-collected objects including Git repository, compressed package, and container image layer, generate a collection record with timestamp and signature, and write it into an immutable log to realize tamper-proofing function, meet the compliance forensics, and quickly trace responsibility in case of doubt;

[0087] S102, Version control incremental collection: only analyze the modified part this time, generate a differentiated SBOM segment, and compare the object hash with the last scan result, only re-block parse the incremental file, while persisting the Patch-Level SBOM segment and marking the source branch;

[0088] S103, Image lazy loading collection, that is, only process the changed Layer for the container image, thereby realizing network and disk saving, less resource occupation, and faster speed: use eStargz lazy-pull technology for OCI image to only decompress the modified Layer, and generate Layer-Digest fingerprint for each Layer;

[0089] S104, Runtime dependency capture, that is, record the libraries or plugins dynamically loaded during program running: inject eBPF probes into the target host to capture the dynamic loading events of dlopen() and LoadLibrary(), and merge them into Runtime-SBOM stream data;

[0090] S105, Language self-discovery and plugin sandbox: convert "multi-language, raw file" into "language-Meta fingerprint segment with language tag, unified fingerprint, and source signature", which carries language tag, analysis plugin ID, dependency Token digest hash, and collection signature at the same time, and realizes automatic identification of unknown language folder based on FastText Embedding learning and K Means clustering method; compared with the traditional machine learning recognition component method which relies on manual configuration of plugins, the language self-discovery method automatically pulls the corresponding Wasm-Sandbox analysis plugin, completes cross-language unified fingerprinting, and improves the identification efficiency of unknown files;

[0091] S106, the incremental SBOM is merged and output, that is, all difference fragments are merged into a unified SBOM with a provenance signature: the Patch Level, Layer Level, Runtime SBOM fragments and language-Meta fingerprint fragments are merged after hash deduplication to generate an incremental SBOM with a provenance field, and are written back to the backend graph database; Specifically: first, the BLAKE3 value of "component specification name + version number + source path" is taken as the primary key for global hash deduplication of the Patch Level, Layer Level, Runtime SBOM fragments and language-Meta fingerprint fragments; Then, according to the three-dimensional topological relationship of "code branch, image layer, running state process", the dependencies are re-merged, and the provenance field is supplemented for each record; Wherein, the provenance field includes the collection timestamp, the collection chain signature, the analysis plug-in ID and the model version number; Finally, an incremental SBOM file conforming to the OpenSBOM JSON specification is obtained after processing, and the incremental SBOM file is written into the backend graph database together with its provenance relationship, which is directly referenced for vulnerability scanning, license auditing and supply chain resilience assessment, while historical versions are retained to support backtracking and differential analysis.

[0092] The language self-discovery in step S105 of the embodiment and the plug-in sandbox are divided into an offline training phase and an online running phase;

[0093] The offline training phase is specifically: first, a multilingual corpus is constructed, and source code of no less than 30 programming languages is selected as training samples; Then, word vector training is performed using the FastText model, wherein the FastText model is configured as a skip-gram structure and enables a subword(n-gram) mechanism, the word vector dimension is set to 128, and the subword length range is set to 3-6; The skip-gram structure trains the word vector by predicting the corresponding context words from the center word, so that the frequently co-occurring keywords are automatically clustered in the vector space, thereby efficiently capturing semantic adjacency relationships; The subword(n-gram) mechanism represents that each word is divided into 3-6 n-grams and the corresponding vector is learned, so that even if an unregistered or rare word is encountered, a robust representation can be combined from fragments, and fine-grained morphological information of prefixes and suffixes is retained; Finally, after training is completed, each sample file is mapped to a 128-dimensional file vector through average pooling, and K-Means clustering is performed based on the file vector (k≈number of languages), and a "cluster-language" mapping table is obtained after comparing the clustering result with the language feature library;

[0094] The online running stage specifically comprises: when a file to be analyzed is scanned, the FastText model saved offline is called to convert the file into a 128-dimensional vector, and the Euclidean distance from the 128-dimensional vector to the center of each cluster is calculated; if the minimum distance is less than a preset threshold 0.7, the language to which the file belongs is directly determined, otherwise the plug-in registration center is submitted for manual labeling; after the language to which the file belongs is determined, the corresponding Wasm-Sandbox analysis plug-in is automatically pulled according to the "cluster-language" mapping table, the syntax tree of the file is parsed, the uniform Token stream is obtained, and the fingerprinting consistent across languages is realized.

[0095] The parsing of the declarative dependency in step S2 of the embodiment is specifically as follows:

[0096] S201, receive a Manifest file set covering the mainstream formats of pom.xml, package.json, requirements.txt and go.mod, and send each Manifest file set to a parsing engine matched with the language ecology, that is, Maven POM is checked by XML Schema, NPM list is checked by JSON Schema, and Python requirements are confirmed by regular and PEP 440 parser, and the parsing engine internally constructs a lightweight AST, only retaining three types of nodes of dependency name, version constraint and scope, and discarding other comments and format information in time to avoid redundant data transmission;

[0097] S202, for each direct dependency obtained by parsing, initiate a metadata query to the corresponding software repository, that is, Maven Central calls a REST API to initiate a metadata query to the corresponding software repository, and NPM and PyPI call JSONIndex to initiate a metadata query to the corresponding software repository; the query result includes the latest security version, the upstream license, the SHA-256 digest and the release date; if the version constraint in the Manifest file set uses "dynamic markers" (such as ~, ^ and +), the parsing engine calls a semantic version comparator to parse the dynamic markers into specific allowed intervals, and then performs intersection operation on the candidate versions returned by the repository to obtain the minimum safe version and the maximum compatible version of the corresponding dependency at the current time;

[0098] S203, recursively process each directly dependent POM, package.json or similar file until there are no more transitive dependencies that can be resolved: throughout the entire recursive process, the resolution results are all generated BLAKE3 fingerprints according to "component name + version number + source file hash" and real-time deduplication, ensuring that the same dependency is only retained in one node in different branches or different image layers; after the recursion ends, all nodes and edges are arranged into a directed acyclic graph; wherein the node attributes include the canonical name, the parsing source path, the license, the version constraint interval, the security recommended version, and the timestamp and signature information inherited by the chain of evidence; the edge attribute is used to mark "declaration relationship" or "transitive relationship", and record the propagation depth;

[0099] S204, obtain the dependency relationship graph and persist in OpenSBOM JSON-Dependencies extension format: the top meta field contains the Manifest version number used this time and the parser version, and the body part stores the dependency nodes in depth hierarchy, all fields are with provenance, directly for subsequent vulnerability scanning, license audit and version conflict detection calling, and writing back to the backend graph database, in order to align with the incremental SBOM merging logic.

[0100] The code snippet in step S3 of the embodiment is semantically traced based on artificial intelligence to generate a global software bill of materials as follows:

[0101] S301, syntax analysis is performed on all collected source codes, and the source codes are structured and divided into code units (functions, methods, classes) with independent functional context;

[0102] S302, the BI-SentenceBert model based on evolutionary algorithm is used to convert the code units into high-dimensional vectors that can deeply represent the corresponding functional semantics; wherein the evolutionary algorithm is used to continuously optimize the representation ability and retrieval efficiency of the vector model, so that the vector model has higher robustness to code perturbations such as variable renaming and annotation modification, thereby accurately tracing the real source project, version, open source license and potential vulnerabilities of "shadow code";

[0103] S303, perform efficient similarity retrieval in a pre-constructed database containing massive open source project code vectors;

[0104] The BI-SentenceBert model based on the evolutionary algorithm comprises a word embedding layer, a position encoding layer, a 12-layer Bert-base encoder, a bidirectional context pooling layer, a first full-connection projection layer, a second full-connection projection layer and an output layer. The bidirectional context pooling layer is behind the 12-layer BERT-Base encoder, and the [CLS] vector and the last non-padding token vector are taken at the same time, spliced, projected and compressed to 256 dimensions through the first full-connection projection layer and the second full-connection projection layer. The [CLS] vector is used to retain the overall semantics of the segment, and the last non-padding token vector is used to make up the tail dependency information, so that the BI-SentenceBert model based on the evolutionary algorithm can still accurately capture the functional boundary in the variable renaming and annotation truncation scene. The BI-SentenceBert model based on the evolutionary algorithm automatically searches the hyperparameters by the evolutionary algorithm instead of the manual grid. The chromosome encodes the pooling structure, the vector dimension, the contrast learning temperature and the quantization strategy 16 genes at the same time. The fitness function takes the code cloning recall and the coding delay as the double targets. After 30 generations of NSGA-II evolution, the selected "elite individuals" reduce the reasoning delay and the memory occupation while maintaining the recall. The evolutionary algorithm calculation process for the parameter optimization of the BI-SentenceBert model based on the evolutionary algorithm is as follows.

[0105] (1) Chromosome coding: the gene position representation is set in the form of {Pooling method, Projection dimension, Learning rate, Batch size, Contrastive loss temperature, Quantization strategy};

[0106] (2) Initial population: 24 groups of hyperparameters are randomly sampled, and the pre-trained BERT-Base weight is taken as the common starting point;

[0107] (3) Fitness function design: the NSGA-II (improved multi-objective genetic algorithm) can better process the high-dimensional target space; wherein, the fitness function comprises a main target, a secondary target and a comprehensive fitness function; the main target f1 is used for maximizing the retrieval accuracy, and the specific quantification formula is: f1 = Recall@10; wherein, the Recall@10 is calculated through the code cloning test set; the secondary target f2 is used for minimizing the reasoning speed, and the specific quantification formula is: f2 = -log(AvgLatency) (ms / segment); wherein, the AvgLatency is obtained by measuring the model single-fragment processing time; and the comprehensive fitness function F formula is:

[0108] (4) Genetic: including genetic crossover and mutation; for genetic crossover, whole gene exchange (e.g. "Pooling+Projection" pair); for genetic mutation: randomly select a gene site and add Gaussian noise;

[0109] (5) Iteration and convergence: set the acceleration algorithm convergence speed when the recall@10 is improved to 90% and the encoding delay is reduced to within 7ms;

[0110] (6) The final reserved "elite individual" is the network configuration listed in the above table.

[0111] The intelligent mapping of software components in the global software bill of materials and the vulnerability database in step S4 of the embodiment to identify risks is as follows:

[0112] S401, merge and deduplicate the declarative dependency tree with the code snippet information to generate a truly complete global software bill of materials (SBOM) containing all third-party components;

[0113] S402, intelligent vulnerability database correlation matching using bidirectional graph neural-LSTM network: the bidirectional graph neural-LSTM network constructs the global software bill of materials into a dependency relationship graph, learns the complex dependency relationship between components using a graph neural network (GNN), and analyzes the context of the vulnerability description text using a long short-term memory network (LSTM), thereby achieving more intelligent and accurate risk identification than traditional keyword matching, not only direct CVE matching, but also potential and not explicitly disclosed risks based on dependency context;

[0114] Among them, the input end of the bidirectional graph neural-LSTM network includes two parallel branches of Graph branch and Text branch; the Graph branch reads the dependency relationship graph, propagates the in-edge and out-edge information using the bidirectional GNN, and obtains the global vector vg of the global software bill of materials graph reflecting the double influence of "upstream dependency on the component" and "the propagation effect of the component on the downstream"; the Text branch reads the vulnerability description text in the official common vulnerability enumeration (CVE) database, uses the bidirectional LSTM to capture the cause-and-effect semantics at the beginning and end of the sentence, and captures the complete before-and-after semantics, and finally obtains the text vector vt after deep semantic understanding; The Graph branch and the Text branch meet at the "attention fusion layer", where the learnable attention matrix highlights the high correlation information between the "key dependency path" and the "high-risk predicate", and finally outputs a set of K-dimensional risk score values for labeling the known vulnerability risks and potential context risks of each component in the global software bill of materials.

[0115] The layered adaptive repair decision-making process for software components at risk in step S5 of the embodiment includes automated upgrade sandbox verification, intelligent replacement component recommendation, and is as follows:

[0116] S501, the automated upgrade sandbox verification is the first layer of the adaptive repair process. When a vulnerability is identified, a temporary Docker isolated environment is prepared and an automatic version upgrade converts unreliable repair suggestions into verified trusted operations. Specifically, according to the construction requirements of the project, an image is automatically pulled and a pure and isolated Docker container is created. In the Docker container, the version upgrade operation is first automatically performed to update the vulnerable component to a safe version. Then, the pre-set complete test suite (including unit testing, integration testing, etc.) in the project code library is automatically called and executed to verify whether the upgrade has damaged the original function of the project. The test results are recorded in detail and used as a key basis for decision-making repair path;

[0117] S502, the intelligent replacement component recommendation is the second layer of the adaptive repair process, which is started when direct upgrade is not feasible (i.e., sandbox verification fails). Specifically, static analysis is first performed on the project source code to understand the specific API usage mode of the vulnerable component. Then, a knowledge graph containing multi-dimensional information such as mainstream open source component functionality, API signature, community activity, and license compatibility is queried. The candidate replacement components with similar functionality, high API compatibility, and no security risks are intelligently screened. Finally, a detailed recommendation report containing the pros and cons comparison and migration cost evaluation is generated.

[0118] According to the recommended layered adaptive repair decision-making process in step S6 of the embodiment, a trusted repair solution containing a verified merge request, a replacement solution report, or a code-level repair suggestion is delivered to the user, which is as follows:

[0119] S601, if the automated upgrade sandbox verification is passed, a merge request (Pull Request) containing version upgrade code and a link to successful test logs is automatically created for developers to review and one-click merge;

[0120] S602, if the intelligent replacement component recommendation is executed, a detailed repair suggestion report will be generated, including the pros and cons comparison of the replacement component and specific code modification suggestions;

[0121] S603, all deliverables are seamlessly integrated into the developer's daily workflow through an IDE plug-in, forming a complete and efficient automated closed loop from risk identification to reliable disposal.

[0122] Embodiment 2:

[0123] The embodiment provides a kind of intelligent risk identification and adaptive repair system of software supply chain, which is used to realize the intelligent risk identification and adaptive repair method of software supply chain as in embodiment 1;The system includes:

[0124] Project data acquisition and pretreatment module, for panoramic and incremental trusted collection of source code, image layer and runtime dynamic dependence under zero trust scene, to generate verifiable forensic chain and directly output Patch-Level SBOM segment, Layer-Level SBOM segment and Runtime-SBOM flow data, and synchronously merge to generate Manifest file set, provide high integrity, high timeliness data basis for subsequent risk identification;Wherein, Manifest file set includes the explicit dependency list of pom.xml, package.json, go.mod, requirements.txt;

[0125] Declarative dependency analysis module, for accurately parsing the syntax of collected dependency list file by calling the parsing engine matched with each programming language ecology, extracting all directly dependent items and version constraints declared in the project, and then interacting with remote, public or private package repository (such as Maven Central, NPM Registry, PyPI, etc.) to recursively analyze the transitive dependencies introduced by each direct dependent item, and finally build a complete, multi-level project dependency relationship tree;

[0126] Intelligent code snippet semantic tracing module, for performing semantic tracing on code snippets based on artificial intelligence to generate a global software bill of materials (SBOM);

[0127] Global software bill of materials generation and risk mapping module, for bidirectional graph neural network-LSTM network to intelligently map software components in global software bill of materials with vulnerability database to identify risks;

[0128] Automatic upgrade sandbox verification module, for software components with risks, to prepare and automatically upgrade through temporary Docker isolation environment to convert unreliable repair suggestions into verified trusted operations;

[0129] Intelligent alternative component recommendation module, for after sandbox verification fails, first perform static analysis on project source code to understand specific API usage patterns for vulnerability components;Then query a knowledge graph containing multi-dimensional information of mainstream open source component functions, API signatures, community activity and license compatibility, intelligently filter out candidate replacement components with similar functions, high API compatibility and no such security risks;Finally generate a detailed recommendation report containing pros and cons comparison and migration cost evaluation.

[0130] A fix delivery module for delivering a trusted fix to the user containing a validated merge request, alternative fix report or code-level fix suggestion according to the recommended hierarchical adaptive fix decision flow.

[0131] The working process of the project data collection and preprocessing module in the embodiment is specifically as follows:

[0132] (1) Forensic chain initialization: Establish an unalterable integrity proof for all source codes, compressed packages, and image layers. Specifically, calculate the Merkle tree hash of the object to be collected (Git repository, compressed package, container image layer); generate a timestamped and signed collection record and write it into an immutable log. Therefore, the anti-tampering function can be realized, the compliance forensics can be met, and once there is doubt, the responsibility can be quickly traced.

[0133] (2) Version control incremental collection: Only analyze the modified part this time, and generate a differential SBOM segment. Based on the object hash comparison with the last scan result, only the incremental files are re-parsed by block; at the same time, the Patch-Level SBOM segment is persisted and the source branch is labeled.

[0134] (3) Image lazy loading collection: Only the changed Layer is processed for the container image, thereby realizing the saving of network and disk, occupying fewer resources and being faster. Specifically, the eStargz lazy-pull technology is used for the OCI image, only the modified Layer is decompressed, and the Layer-Digest fingerprint is generated for each layer.

[0135] (4) Runtime dependency capture: Mainly record the libraries or plug-ins dynamically loaded during program running. Specifically, the eBPF probe is injected into the target host to capture the dlopen(), LoadLibrary() and other dynamic loading events; and the events are merged into Runtime-SBOM stream data.

[0136] (5) Language self-discovery and plug-in sandbox: The "multi-language, raw file" is converted into a language-Meta fingerprint segment with a language tag, a unified fingerprint, and a source signature. The segment simultaneously carries the language tag, the analysis plug-in ID, the dependency Token digest hash, and the collection signature. A method based on FastText Embedding learning and K-Means clustering is proposed to automatically identify unknown language folders. Compared with the traditional machine learning recognition component method which depends on manual configuration of plug-ins, the language self-discovery method automatically pulls the corresponding Wasm-Sandbox analysis plug-in, completes cross-language unified fingerprinting, and improves the recognition efficiency of unknown files. The specific process includes an offline training phase and an online running phase.

[0137] 1) Offline training phase: In the offline phase, first build a multilingual corpus, select no less than 30 programming languages of source code as training samples. Then use FastText algorithm for word vector training, where the model is configured as skip-gram structure and subword(n-gram) mechanism is enabled, the word vector dimension is set to 128, and the subword length range is set to 3-6. Among them, the Skip-gram architecture trains the word vector by predicting the context words of the center word, so that the frequently co-occurring keywords are automatically close in the vector space, thereby efficiently capturing the semantic adjacency relationship. Subword(n-gram subword) representation is to break each word into 3-6 n-gram characters and learn its vector, even if it encounters unregistered or rare words, it can also use fragments to combine a robust representation, and retain fine-grained morphological information such as case, prefix, etc.

[0138] After training, each sample file is mapped to a 128-dimensional file vector by average pooling, and K-Means clustering is performed based on the file vector (k≈language number). After comparing the clustering results with the language feature library, the "cluster-language" mapping table is obtained.

[0139] 2) Online running phase: When the file to be analyzed is scanned, the system calls the offline saved FastText model to convert the file into a 128-dimensional vector, and calculates the Euclidean distance of the vector to each cluster center; if the minimum distance is less than the preset threshold 0.7, directly determine the language of the file, otherwise submit to the plug-in registration center for manual labeling. After determining the language, the system automatically pulls the corresponding Wasm-Sandbox analysis plug-in according to the "cluster-language" mapping table, performs syntax tree analysis on the file, outputs a unified Token stream, and realizes cross-language consistent fingerprinting.

[0140] (6) Incremental SBOM merge output: Merge all difference fragments into a unified SBOM with provenance signature. Specifically, after hashing and deduplicating Patch-Level, Layer-Level, Runtime-SBOM fragments and language-Meta fingerprint fragments, an incremental SBOM with provenance field is generated and written back to the backend graph database. Specifically:

[0141] First, the BLAKE3 value of "component specification name + version number + source path" is taken as the primary key, and the four types of fragments are globally hashed and deduplicated; then, according to the three-dimensional topological relationship of "code branch, image layer, running state process", the dependencies are re-merged, and the provenance field (including collection timestamp, collection chain signature, analysis plug-in ID, model version number) is supplemented for each record. After processing, an incremental SBOM file conforming to the OpenSBOM JSON specification is obtained. This file is written into the backend graph database together with its provenance relationship, which is directly referenced for vulnerability scanning, license auditing, and supply chain resilience assessment, while historical versions are retained to support backtracking and differential analysis.

[0142] The declarative dependency parsing module in this embodiment accurately parses the collected dependency manifest files by calling parsing engines matched with each programming language ecosystem, extracts all directly dependent items and their version constraints explicitly declared in the project. Then, by interacting with remote, public or private software package repositories (such as Maven Central, NPM Registry, PyPI, etc.), the system recursively parses the transitive dependencies introduced by each direct dependency, and finally constructs a complete, multi-level project dependency relationship tree. The specific process is as follows:

[0143] First, receive the Manifest file set, covering pom.xml, package.json, requirements.txt, go.mod, etc. Each Manifest is sent to the parsing engine matched with its language ecosystem: Maven POM is checked by XMLSchema, NPM manifest is checked by JSON Schema, and Python requirements are confirmed by regular expressions and PEP 440 parser. The parsing engine internally builds a lightweight AST, retaining only three types of nodes: dependency name, version constraint, and scope, discarding other annotations and format information to avoid unnecessary data transmission.

[0144] Then, for each direct dependency parsed, the system initiates a metadata query to the corresponding software repository: Maven Central calls the REST API, NPM and PyPI use JSON Index; the query result includes the latest security version, upstream license, SHA-256 digest, and release date. If the version constraint in the Manifest uses "dynamic markers" (such as ~, ^, +), the parsing engine will call a semantic version comparator to parse it into a specific allowed interval, and then perform an intersection operation with the candidate versions returned by the repository to obtain the minimum safe version and maximum compatible version available for this dependency at the current time.

[0145] Subsequently, each directly dependent POM, package.json or similar file is recursively processed until no more transitive dependencies can be resolved. Throughout the process, the resolution results are hashed with BLAKE3 according to the "component name + version number + source file hash" and real-time deduplicated to ensure that the same dependency is only retained in one node in different branches or different image layers. After the recursion ends, the system sorts all nodes and edges into a directed acyclic graph, and the node attributes include the specification name, resolution source path, license, version constraint interval, security recommended version, and timestamp and signature information inherited from the forensic chain; the edge attributes mark "declaration relationship" or "transitive relationship", and record the propagation depth.

[0146] The final dependency graph is persisted in the OpenSBOM JSON-Dependencies extension format: the top meta field contains the Manifest version number and resolver version used for this resolution, and the body part stores the dependency nodes by depth, all fields are with provenance, and can be directly called for subsequent vulnerability scanning, license audit and version conflict detection, while writing back to the backend graph database to align with the incremental SBOM merging logic.

[0147] The intelligent code snippet semantic tracing module in the embodiment adopts a BI-SentenceBert model based on an evolutionary algorithm, solves the fundamental defect that traditional SCA technology cannot identify "shadow code", and realizes accurate identification of the copied and pasted code that has been modified. The workflow of the intelligent code snippet semantic tracing module is as follows: first, the syntax of all source codes is analyzed, and the source codes are structured and divided into units (functions, methods, and classes) with independent functional contexts; then, the BI-SentenceBert model based on the evolutionary algorithm is used to convert the code units into high-dimensional vectors that can deeply represent the functional semantics of the code units; finally, in a pre-constructed database containing massive open source project code vectors, efficient similarity retrieval is performed. The evolutionary algorithm is used to continuously optimize the representation ability and retrieval efficiency of the vector model, so that the vector model has higher robustness to code perturbations such as variable renaming and comment modification, thereby accurately tracing the real source project, version, open source license and potential vulnerabilities of the "shadow code".

[0148] The network architecture of the BI-SentenceBert model is shown in Table 1 (B = batch size, L = actual Token number).

[0149] Table 1 Network architecture of BI-SentenceBert model

[0150]

[0151] The evolutionary algorithm calculation process for BI-SentenceBert model parameter optimization is as follows:

[0152] 1) Chromosome coding: gene position setting: {Pooling method, Projection dimension, learning rate, Batchsize, Contrastive loss temperature, quantization strategy}

[0153] 2) Initial population: 24 groups of hyperparameters are randomly sampled, and the pre-trained BERT-Base weight is used as the common starting point.

[0154] 3) Fitness function design: NSGA-II (improved multi-objective genetic algorithm) can better handle high-dimensional target space. The fitness function includes the following core objectives:

[0155] ① Main objective f1: maximize retrieval accuracy, specific quantification formula as follows:

[0156] f1 = Recall@10;

[0157] Where, Recall@10 is calculated by code cloning the test set.

[0158] ② Secondary objective f2: minimize inference speed, specific quantification formula as follows:

[0159] f2 = -log(AvgLatency) (ms / segment);

[0160] Where, AvgLatency is obtained by measuring the single-fragment processing time of the model.

[0161] ③ Comprehensive fitness function F is:

[0162]

[0163] 4) Genetic: includes genetic crossover and mutation. For genetic crossover: whole gene exchange (e.g. "Pooling + Projection" pair); for genetic mutation: this method randomly selects Gaussian noise for gene position.

[0164] 5) Iteration and convergence: to accelerate the convergence speed, this method sets that when Recall@10 is improved to 90% and encoding delay is reduced to within 7ms, the algorithm is ready to converge;

[0165] 6) The final "elite individual" reserved is the network configuration listed in the table above.

[0166] Compared with mainstream Sentence-BERT, BI-SentenceBERT makes three key improvements in architecture and training strategy.

[0167] First, we introduce bidirectional context pooling: after the 12-layer BERT-Base encoder, we concatenate the [CLS] vector and the last non-padding token vector and project them to 256 dimensions with two layers. The former preserves the overall semantics of the snippet, and the latter complements the tail dependency information, enabling the model to accurately capture the functional boundaries in variable renaming, annotation truncation, and other scenarios. Experiments show that the Recall@10 of single-sentence clone retrieval increases from 86% to 92%.

[0168] Second, the model hyperparameters are automatically searched by evolutionary algorithms rather than manually gridding. The chromosome encodes 16 genes such as pooling structure, vector dimension, contrast learning temperature, and quantization strategy, and the fitness function takes code clone recall and encoding delay as dual objectives. After 30 generations of NSGA-II evolution, the selected "elite individuals" reduce reasoning delay and memory usage while maintaining recall.

[0169] In summary, compared to the traditional sentencebert model algorithm process, the BI-SentenceBERT model based on evolutionary optimization proposed in this patent provides a more complete semantic view through bidirectional pooling, and the evolutionary hyperparameters achieve Pareto optimality between precision and efficiency. The two points synergize to further improve the semantic understanding of the model, further improve the accuracy of classification, reduce the reasoning delay, and improve the comprehensive technical effect of generalization.

[0170] The global software bill of materials (SBOM) generation and risk mapping module of this embodiment aims to integrate the analysis results of the previous steps to form a comprehensive and dynamic risk view. First, the declarative dependency tree and code snippet information are merged and de-duplicated to generate a truly complete global software bill of materials (SBOM) that includes all third-party components. Then, a bidirectional graph neural-LSTM network is used for intelligent vulnerability database correlation matching. The bidirectional graph neural-LSTM network constructs the SBOM as a dependency graph, learns the complex dependency relationships between components using a graph neural network (GNN), and analyzes the context of vulnerability description text using a long short-term memory network (LSTM), thereby achieving more intelligent and accurate risk identification than traditional keyword matching. It can not only find direct CVE matches, but also warn about potential and not explicitly disclosed risks based on dependency context. The specific architecture of the bidirectional graph neural-LSTM network is shown in Table 2.

[0171] Table 2 Specific architecture of bidirectional graph neural-LSTM network

[0172]

[0173]

[0174] In Table 2, the input end of the bidirectional graph neural-LSTM network has two parallel branches: a Graph branch and a Text branch. The Graph branch reads the dependency graph converged by S1-S3, propagates the in-edge and out-edge information using a bidirectional GNN, and obtains a SBOM graph global vector vgthat reflects the dual influence of “upstream dependency on the component” and “the propagation effect of the component on the downstream”. The Text branch reads the vulnerability description text in the official Common Vulnerabilities and Exposures (CVE) database, captures the cause-and-effect semantics at the beginning and end of the sentence using a bidirectional LSTM, and captures the complete before-and-after semantics, finally obtaining a text vector vtunderstood in depth. The two are joined in the “attention fusion layer”, where the learnable attention matrix highlights the highly relevant information between the “key dependency path” and the “high-risk predicate”, and finally outputs a set of K-dimensional risk score values for labeling the known vulnerability risk and potential context risk of each component in the SBOM.

[0175] Compared with the traditional graph neural network method of only doing information transmission on a one-way dependency graph, and then matching CVE using keywords or simple vector addition, the bidirectional graph neural-LSTM model in this paper has improved in three aspects: first, the bidirectional GNN simultaneously aggregates in-edges and out-edges in the same layer, enabling the component to perceive both the conduction of upstream defects and the potential impact of its own hidden dangers on the downstream, and further mining deep semantic features; second, the bidirectional LSTM that fuses before-and-after semantics can completely parse version boundary words and impact range sentences, and automatically focus on high-risk predicates such as “remote code execution” and “privilege escalation” with the attention mechanism, significantly improving the distinguishability of vulnerability semantics; finally, after the two branches are aligned by the cross-modal attention layer, the model can fully match the high-order correspondence between the dependency topology and the vulnerability semantics in a unified embedding space, theoretically eliminating the semantic missing problem caused by the traditional GNN's dependence on keywords or shallow vector concatenation, and further obtaining more interpretable risk inference and component-level labeling results.

[0176] The automated upgrade sandbox verification module in this embodiment is the first level of the adaptive repair process, aiming to convert unreliable repair suggestions into verified trusted operations. The core technology of this module lies in the preparation of a temporary Docker isolated environment and automatic version upgrade when a vulnerability is identified.

[0177] Specifically, according to the construction requirements of the project, the image is automatically pulled and a pure and isolated Docker container is created. Inside the container, the version upgrade operation is automatically performed to update the vulnerable component to a safe version. Subsequently, the system automatically invokes and executes the preset complete test suite (including unit testing, integration testing, etc.) in the project code library to verify whether the upgrade has caused damage to the original functions of the project. The test results will be recorded in detail and serve as a key basis for decision-making repair path.

[0178] The intelligent alternative component recommendation module in the embodiment is the second level of the adaptive repair process and is started when direct upgrade is not feasible (i.e., sandbox verification fails). First, the project source code is statically analyzed to understand the specific API usage mode of the vulnerable component. Then, a knowledge graph containing multi-dimensional information such as mainstream open source component functions, API signatures, community activity, license compatibility, etc. is queried, and candidate alternative components with similar functions, high API compatibility, and no security risks are intelligently screened. Finally, the system generates a detailed recommendation report containing pros and cons comparison and migration cost evaluation.

[0179] The trusted repair scheme delivery module in the embodiment is responsible for delivering the repair scheme in the most friendly way to the developer. If the automated upgrade sandbox verification is passed, the trusted repair scheme delivery module will automatically create a merge request (Pull Request) containing the version upgrade code and the link to the successful test log for the developer to review and one-click merge. If the process enters the intelligent alternative component recommendation module, the trusted repair scheme delivery module will generate a detailed repair recommendation report containing the pros and cons comparison of the alternative components and specific code modification suggestions. All deliverables are seamlessly integrated into the developer's daily workflow through the IDE plug-in, forming a complete and efficient automated closed loop from risk identification to reliable disposal.

[0180] Embodiment 3:

[0181] The embodiment also provides an electronic device, comprising a memory and a processor.

[0182] The memory stores computer execution instructions.

[0183] The processor executes the computer execution instructions stored in the memory, so that the processor executes the intelligent risk identification and adaptive repair method of the supply chain in any embodiment of the application.

[0184] The processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, etc. The processor can be a microprocessor or the processor can be any conventional processor.

[0185] The memory can be used to store computer programs and / or modules, and the processor can realize various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store operating systems, application programs required by at least one function, etc.; and the data storage area can store data created according to the use of the terminal, etc. In addition, the memory can also include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a secure digital (SD) card, a flash memory card, at least one disk storage period, a flash memory device, or other volatile solid-state memory devices.

[0186] Embodiment 4:

[0187] The embodiment also provides a computer-readable storage medium, in which a plurality of instructions are stored, the instructions are loaded by a processor to make the processor execute the method for intelligent risk identification and adaptive repair of a supply chain in any embodiment of the application. Specifically, a system or device provided with a storage medium can be provided, and the storage medium stores software program codes for realizing the functions of any embodiment of the above embodiments, and the computer (or CPU or MPU) of the system or device reads and executes the program codes stored in the storage medium.

[0188] In this case, the program codes read from the storage medium can realize the functions of any one of the above embodiments, and therefore the program codes and the storage medium storing the program codes constitute a part of the application.

[0189] The storage medium for providing the program codes includes floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program codes can be downloaded from a server computer through a communication network.

[0190] Furthermore, it should be understood that, not only the program codes read by the computer can be executed to complete the actual operation, but also the operating system and the like operating on the computer can be instructed based on the program codes to complete part or all of the actual operation, thereby realizing the function of any one of the above embodiments.

[0191] Furthermore, it should be understood that, not only the program codes read by the computer can be executed to complete the actual operation, but also the operating system and the like operating on the computer can be instructed based on the program codes to complete part or all of the actual operation, thereby realizing the function of any one of the above embodiments.

[0192] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the above embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for intelligent risk identification and adaptive repair of a software supply chain, characterized in that, The method is as follows: Collect and preprocess the source code and dependency list file of the target software project: in the zero trust scenario, collect the source code, image layer and runtime dynamic dependency in a panoramic and incremental manner, generate a verifiable evidence chain, and directly output Patch-Level SBOM segment, Layer-Level SBOM segment and Runtime-SBOM flow data, and synchronize and merge to generate a Manifest file set; Parse the declarative dependency: by calling the parsing engine matched with each programming language ecology, accurately parse the collected dependency list file, extract all directly dependent items and version constraints in the project, and interact with remote, public or private software package repositories to recursively parse the transitive dependencies introduced by each direct dependency item, and finally build a complete, multi-level project dependency relationship tree; At the same time, the code segment is parsed based on artificial intelligence, and a global software bill of materials is generated; Intelligently map the software components in the global software bill of materials with the vulnerability database to identify risks; For software components with risks, start a hierarchical adaptive repair decision-making process that includes automated upgrade sandbox verification and intelligent replacement component recommendation; According to the recommended hierarchical adaptive repair decision-making process, deliver a trusted repair solution to the user, which includes a verified merge request, replacement solution report or code-level repair suggestion.

2. The intelligent risk identification and adaptive repair method of the software supply chain according to claim 1, characterized in that, The collection and preprocessing of the source code and dependency list of the target software project are as follows: Evidence chain initialization, that is, establishing an unalterable integrity proof for all source code and compressed package image layers: calculate the Merkle tree hash of the objects to be collected including Git repository, compressed package and container image layer, generate a timestamped and signed collection record and write it into an immutable log; Version control incremental collection: only analyze the modified part, generate a differential SBOM segment, and compare the object hash with the last scan result, only reparse the incremental file, and persist the Patch-Level SBOM segment and mark the source branch; Image lazy loading collection, that is, only processing the changed Layer of the container image: using eStargzlazy-pull technology to only decompress the modified Layer of the OCI image, and generating Layer-Digest fingerprint for each Layer; Runtime dependency capture, that is, recording the libraries or plugins loaded during program runtime: injecting eBPF probes into the target host to capture dlopen() and LoadLibrary() dynamic loading events, and merging into Runtime-SBOM flow data; Language self-discovery and plugin sandbox: convert "multi-language, raw files" into "language-labeled, unified fingerprints, and source-signed language-Meta fingerprint fragments" that carry language labels, analysis plugin IDs, dependency Token digest hashes, and collection signatures simultaneously, and automatically identify unknown language folders based on FastText Embedding learning and K Means clustering methods; Incremental SBOM merging output, i.e., merging all difference fragments into a unified, source-signed SBOM: hash and remove duplicates of Patch Level, Layer Level, Runtime SBOM fragments, and language-Meta fingerprint fragments, and then merge them to generate an incremental SBOM with a provenance field, and write it back to the backend graph database; Specifically: First, use the BLAKE3 value of "component specification name + version number + source path" as the primary key to globally hash and remove duplicates of Patch Level, Layer Level, Runtime SBOM fragments, and language-Meta fingerprint fragments; Then, re-merge dependencies according to the three-dimensional topological relationship of "code branch, image layer, and running state process", and complete the provenance field for each record; The provenance field includes collection timestamp, collection chain signature, analysis plugin ID, and model version number; Finally, after processing, an incremental SBOM file that meets the OpenSBOM JSON specification is obtained, and the incremental SBOM file along with its provenance relationship is written into the backend graph database for direct reference by vulnerability scanning, license auditing, and supply chain resilience assessment, while historical versions are retained to support backtracking and differential analysis.

3. The method for intelligent risk identification and adaptive repair of software supply chain according to claim 2, characterized in that, Language self-discovery and plugin sandbox are divided into offline training and online running stages; Among them, the offline training stage is specifically: First, build a multi-language corpus, and select source code of no less than 30 programming languages as training samples; Then, perform word vector training using the FastText model, where the FastText model is configured with a skip-gram structure and a subword(n-gram) mechanism, the word vector dimension is set to 128, and the subword length range is set to 3-6; The skip-gram structure trains word vectors by predicting the corresponding context words from the center word, allowing frequently co-occurring keywords to automatically cluster in the vector space, thereby efficiently capturing semantic adjacency relationships; The subword(n-gram) mechanism represents the learning of corresponding vectors by breaking each word into 3-6 n-grams, allowing robust representations even for unregistered or rare words, while preserving fine-grained morphological information such as case and prefix / suffix; Finally, after training is complete, map each sample file to a 128-dimensional file vector through average pooling, and perform K-Means clustering based on the file vector, and obtain a "cluster-language" mapping table after comparing the clustering results with the language feature library; The online running stage specifically includes: when a file to be analyzed is scanned, the FastText model saved offline is called to convert the file into a 128-dimensional vector, and the Euclidean distance from the 128-dimensional vector to the center of each cluster is calculated; if the minimum distance is less than a preset threshold, the language to which the file belongs is directly determined, otherwise the plug-in registration center is submitted for manual labeling; after the language to which the file to be analyzed belongs is determined, the corresponding Wasm-Sandbox analysis plug-in is automatically pulled according to the "cluster-language" mapping table, the syntax tree of the file is parsed, the uniform Token stream is obtained, and the fingerprinting consistent across languages is realized.

4. The method for intelligent risk identification and adaptive repair of software supply chain according to claim 1, characterized in that, The parsing of the declarative dependency is specifically as follows: The Manifest file set is received, the mainstream formats of pom.xml, package.json, requirements.txt and go.mod are covered, each Manifest file set is sent to the parsing engine matched with the language ecology, that is, Maven POM is verified by XML Schema, NPM list is verified by JSON Schema, and Python requirements are verified by regular and PEP440 parser, and at the same time, the parsing engine internally constructs a lightweight AST, only retaining three types of nodes of dependency name, version constraint and scope, and discarding other comments and format information in time to avoid redundant data transmission; For each direct dependency obtained by parsing, metadata query is initiated to the corresponding software repository, that is, MavenCentral calls REST API to initiate metadata query to the corresponding software repository, NPM and PyPI call JSON Index to initiate metadata query to the corresponding software repository; The query result includes the latest security version, upstream license, SHA-256 digest and release date; if the version constraint in the Manifest file set uses "dynamic tag", the parsing engine calls the semantic version comparator to parse the dynamic tag into a specific allowed interval, and then performs intersection operation with the candidate version returned by the repository to obtain the minimum safe version and the maximum compatible version of the corresponding dependency at the current time; The POM, package.json or similar file of each direct dependency is processed recursively until there are no more transitive dependencies to be parsed: during the entire recursive processing, the parsing result is generated BLAKE3 fingerprint according to "component name+version number+source file hash" and real-time deduplication, ensuring that the same dependency is only retained in one node in different branches or different image layers; after the recursion ends, all nodes and edges are arranged into a directed acyclic graph; the node attributes include specification name, parsing source path, license, version constraint interval, security recommended version and timestamp and signature information inherited by the evidence chain; the edge attribute is used to mark "declaration relationship" or "transitive relationship", and record the propagation depth; Acquire dependency graph and persist in OpenSBOM JSON-Dependencies extension format: The top meta field contains the Manifest version number used this time and the parser version, and the body part stores the dependency nodes in depth hierarchy, all fields with provenance, directly for subsequent vulnerability scanning, license audit and version conflict detection calls, while writing back to the backend graph database to align with the incremental SBOM merging logic.

5. The method for intelligent risk identification and adaptive repair of software supply chain according to claim 1, characterized in that, The AI-based semantic tracing of the code snippet generates a global software bill of materials as follows: Syntax analysis of all collected source code to structure the source code into code units with independent functional context; Using the BI-SentenceBert model based on evolutionary algorithm to convert the code units into high-dimensional vectors that can deeply represent the corresponding functional semantics; the evolutionary algorithm is used to continuously optimize the representation ability and retrieval efficiency of the vector model, making the vector model more robust to code perturbations such as variable renaming and comment modification, so as to accurately trace the real source project, version, open source license and potential vulnerabilities of "shadow code"; In a pre-built database containing massive open source project code vectors, efficient similarity retrieval is performed; The BI-SentenceBert model based on evolutionary algorithm includes a word embedding layer, a position encoding layer, a 12-layer BERT-Base encoder, a bidirectional context pooling layer, a first fully connected projection layer, a second fully connected projection layer, and an output layer. The bidirectional context pooling layer is behind the 12-layer BERT-Base encoder, which takes the [CLS] vector and the last non-Padding Token vector simultaneously, concatenates them, and then projects and compresses them to 256 dimensions through the first fully connected projection layer and the second fully connected projection layer. The [CLS] vector is used to retain the overall semantics of the snippet, and the last non-Padding Token vector is used to supplement the tail dependency information, so that the BI-SentenceBert model based on evolutionary algorithm can accurately capture the functional boundaries in the context of variable renaming and comment truncation. The BI-SentenceBert model based on evolutionary algorithm automatically searches for hyperparameters through the evolutionary algorithm, which encodes the pooling structure, vector dimension, contrastive learning temperature, and quantization strategy in the chromosome. The fitness function has two objectives: code clone recall and encoding delay. After 30 generations of NSGA-II evolution, the selected "elite individuals" reduce reasoning delay and memory usage while maintaining recall. The evolutionary algorithm for parameter optimization of the BI-SentenceBert model based on evolutionary algorithm is as follows: (1) Chromosome encoding: gene site representation is set as {Pooling method, Projection dimension, Learning rate, Batch size, Contrastive loss temperature, Quantization strategy}. (2) Initial population: 24 groups of hyperparameters are randomly sampled, and the pre-trained BERT-Base weights are used as the common starting point; (3) Fitness function design: NSGA-II can better handle high-dimensional objective space; among them, the fitness function includes the main objective, the secondary objective and the comprehensive fitness function; the main objective f1 is used for the maximum retrieval accuracy, and the specific quantitative formula is: f1 = Recall@10; wherein, Recall@10 is calculated by code clone test set; the secondary objective f2 is to minimize the reasoning speed, and the specific quantitative formula is: f2 = -log(AvgLatency)(ms / segment); wherein, AvgLatency is obtained by measuring the single-fragment processing time of the model; the comprehensive fitness function F formula is: (4) Genetic: including genetic crossover and mutation; for genetic cross, the whole gene is exchanged; for genetic mutation: Gaussian noise is added to the gene site randomly; (5) Iteration and convergence: when the Recall@10 is improved to 90% and the encoding delay is reduced to within 7ms, the algorithm convergence speed is accelerated; (6) The final reserved "elite individual" is the network configuration listed in the table above.

6. The method for intelligent risk identification and adaptive repair of software supply chain according to claim 1, characterized in that, The software components in the global software bill of materials are intelligently mapped to the vulnerability database to identify risks as follows: Combine and deduplicate the declarative dependency tree and code snippet information to generate a truly complete global software bill of materials that includes all third-party components; Intelligent vulnerability database correlation matching is performed using a bidirectional graph neural-LSTM network: the bidirectional graph neural-LSTM network constructs a dependency relationship graph from the global software bill of materials, learns the complex dependency relationships between components using a graph neural network, and analyzes the context of the vulnerability description text using a long short-term memory network, thereby achieving more intelligent and accurate risk identification than traditional keyword matching. It can not only find direct CVE matches, but also warn about potential, not explicitly disclosed risks based on dependency context; Among them, the input end of the bidirectional graph neural-LSTM network includes two parallel branches of Graph branch and Text branch; the Graph branch reads the dependency relationship graph, propagates the in-edge and out-edge information using a bidirectional GNN, and obtains the global vector vg of the global software bill of materials graph reflecting the "upstream dependency influence on the component" and "the propagation effect of the component on the downstream"; the Text branch reads the vulnerability description text in the official universal vulnerability number narrative word sequence database, uses a bidirectional LSTM to capture the cause-and-effect semantics at the beginning and end of the sentence, and captures the complete before-and-after semantics, finally obtaining a text vector vt that has undergone deep semantic understanding; the Graph branch and the Text branch meet at the "attention fusion layer", where the learnable attention matrix highlights the highly relevant information between "key dependency paths" and "high-risk predicates", and finally outputs a set of K-dimensional risk score values for labeling the known vulnerability risks and potential context risks of each component in the global software bill of materials.

7. The method for intelligent risk identification and adaptive repair of software supply chain according to claim 1, characterized in that, For software components with risks, a hierarchical adaptive repair decision-making process is started, which includes an automated upgrade sandbox verification and intelligent replacement component recommendation as follows: The automated upgrade sandbox verification is the first level of the adaptive repair process. When a vulnerability is identified, a temporary Docker isolation environment is prepared and automatic version upgrade is used to convert unreliable repair suggestions into verified trusted operations; specifically: according to the project's build requirements, an image is automatically pulled and a pure and isolated Docker container is created; in the Docker container, the version upgrade operation is automatically performed first to update the vulnerable component to a secure version; Then, the complete test suite preset in the project code library is automatically invoked and executed to verify whether the upgrade has caused damage to the original functions of the project, and the test results are recorded in detail and used as a key basis for decision-making repair path; The intelligent alternative component recommendation is the second level of the adaptive repair process, which is started when direct upgrade is not feasible. Specifically, the specific API usage mode of the vulnerability component is understood by performing static analysis on the project source code. Then, a knowledge graph containing multi-dimensional information of mainstream open source component functions, API signatures, community activity, and license compatibility is queried, and candidate alternative components with similar functions, high API compatibility, and no security risks are intelligently screened. Finally, a detailed recommendation report containing the pros and cons comparison and migration cost evaluation is generated. According to the recommended hierarchical adaptive repair decision-making process, a reliable repair scheme containing a verified merge request, an alternative scheme report, or a code-level repair suggestion is delivered to the user, as follows: If the automated upgrade sandbox verification is passed, a merge request containing the version upgrade code and a link to the successful test log is automatically created for the developer to review and merge; If the intelligent alternative component recommendation is executed, a detailed repair suggestion report will be generated, including the pros and cons comparison of the alternative components and specific code modification suggestions; All deliverables are seamlessly integrated into the developer's daily workflow through an IDE plugin, forming a complete and efficient automated closed loop from risk identification to reliable disposal.

8. An intelligent risk identification and adaptive remediation system for software supply chain, characterized in that, The system is used to implement the intelligent risk identification and adaptive repair method of the software supply chain according to any one of claims 1 to 7; the system comprises: A project data acquisition and preprocessing module is used to acquire panoramic and incremental trusted data of source code, image layers, and runtime dynamic dependencies in a zero-trust scenario, generate a verifiable evidence chain, and directly output Patch-Level SBOM fragments, Layer-Level SBOM fragments, and Runtime-SBOM stream data, and synchronize and merge to generate a Manifest file set; A declarative dependency parsing module is used to accurately parse the syntax of the collected dependency list file by calling a parsing engine matched with the programming language ecosystem, extract all directly dependent items and their version constraints in the project, and interact with remote, public or private software package repositories to recursively parse the transitive dependencies introduced by each direct dependency item, and finally build a complete, multi-level project dependency relationship tree; An intelligent code snippet semantic tracing module is used to perform semantic tracing of code snippets based on artificial intelligence to generate a global software bill of materials; A global software bill of materials generation and risk mapping module is used to map software components in the global software bill of materials with a vulnerability database through a bidirectional graph neural-LSTM network to identify risks; An automated upgrade sandbox verification module is used to prepare and automatically upgrade the unreliable repair suggestions to verified reliable operations through a temporary Docker isolation environment for software components with risks. The intelligent alternative component recommendation module is configured to, after the sandbox verification fails, perform static analysis on the project source code to understand the specific API usage mode of the vulnerability component, query a knowledge graph including multi-dimensional information of functions, API signatures, community activity and license compatibility of mainstream open source components, intelligently screen out candidate alternative components with similar functions, high API compatibility and no security risks, and finally generate a detailed recommendation report including advantages and disadvantages comparison and migration cost evaluation. The repairable solution delivery module is configured to deliver a trusted repairable solution including a verified merge request, an alternative solution report or a code-level repair suggestion to the user according to a recommended hierarchical adaptive repair decision-making process.

9. An electronic device, comprising: The software supply chain intelligent risk identification and adaptive repair method comprises the following steps: a memory and at least one processor; wherein the memory has stored thereon a computer program; the at least one processor executes the computer program stored in the memory, so that the at least one processor executes the software supply chain intelligent risk identification and adaptive repair method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program stored in the computer readable storage medium can be executed by the processor to realize the software supply chain intelligent risk identification and adaptive repair method according to any one of claims 1 to 7.

Images