Software supply chain security risk analysis and detection method and system, medium and product

Abstract

The invention discloses a software supply chain security risk analysis and detection method and system, a medium and a product, and relates to the technical field of data processing. According to the method, dependency configuration files of a current version and a historical version are extracted by analyzing product library information, and a corresponding SBOM list is generated. And determining newly added and continuously reserved dependent components by comparing the lists, and matching the dependent components with a vulnerability information library to identify vulnerability components. And for the newly-added vulnerability component, based on the successive relationship between the component introduction time and the vulnerability disclosure time, judging that the newly-added vulnerability component is introduced as a known or unknown vulnerability, and endowing a corresponding risk identifier. And assigning different risk identifiers to the persistently reserved vulnerability components according to whether the retention duration exceeds a preset threshold value or not. And finally, based on the risk identifier and the dependency relationship of the vulnerability component, generating a risk propagation path and visually displaying the risk propagation path. By implementing the technical scheme provided by the invention, the software supply chain security risk analysis and detection accuracy can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a software supply chain security risk analysis and detection method, system, medium and product. BACKGROUND

[0002] With the development of software development towards componentization and modularization, modern software systems increasingly rely on open source components and third-party dependent libraries. According to statistics, most of the code in enterprise-level applications comes from open source components or third-party dependencies. This development mode significantly improves software development efficiency, but at the same time, software supply chain security risks are increasingly prominent.

[0003] At present, the industry usually adopts software composition analysis (SCA) technology to identify and manage dependent components and their potential vulnerabilities in software projects. The existing SCA technology mainly scans the dependency configuration files of software projects, compares the detected components with the known vulnerability database, and finds components with security vulnerabilities.

[0004] However, in practical applications, it is found that the existing detection method is too superficial in analyzing software supply chain security risks. Due to the lack of in-depth analysis of the evolution history of components, and the complex dependency relationship between components, which may lead to the spread of security risks, it is difficult for security teams to fully assess the actual risk situation in the software supply chain. This makes it difficult to accurately judge the impact of each vulnerability on the overall security of the software supply chain when facing a large number of component vulnerabilities, ultimately affecting the prevention and control effect of supply chain security risks, therefore, it is urgent to provide a more accurate software supply chain security risk analysis and detection method. SUMMARY

[0005] The present application provides a software supply chain security risk analysis and detection method, system, medium and product, which can improve the accuracy of software supply chain security risk analysis and detection.

[0006] In a first aspect of the present application, a software supply chain security risk analysis and detection method is provided, comprising: obtaining artifact library information of a software project to be detected; extracting a first dependency configuration file of a current version software and a second dependency configuration file of at least two historical version softwares from the artifact library information, and respectively parsing the first dependency configuration file and the second dependency configuration file to generate a first SBOM list of the current version and a second SBOM list of the historical version; comparing the first SBOM list and the second SBOM list to determine newly added dependent components and continuously retained dependent components in the current version; matching each component in the first SBOM list with a vulnerability intelligence library, determining a vulnerability component and extracting a corresponding vulnerability disclosure time; For a vulnerability component belonging to a newly added dependent component, the release time of the current version is obtained as the component introduction time, when the component introduction time is later than the vulnerability disclosure time, it is determined that the vulnerability component is a known vulnerability introduction and is assigned a first risk identifier, when the component introduction time is earlier than or equal to the vulnerability disclosure time, it is determined that the vulnerability component is an unknown vulnerability introduction and is assigned a second risk identifier; For a vulnerability component belonging to a continuously retained dependent component, the retention duration of the vulnerability component in the historical version is obtained, when the retention duration exceeds a preset threshold, a third risk identifier is assigned, and when the retention duration does not exceed the preset threshold, a second risk identifier is assigned; Based on the risk identifier corresponding to each vulnerability component and the dependency relationship between each vulnerability component, a risk propagation path is generated and sent to a visualization page.

[0007] By adopting the above technical solution, first, the dependency configuration files of the current version and the historical version are obtained and parsed based on the artifact library information, the corresponding SBOM list is generated, the newly added and continuously retained dependent components are identified by comparing the SBOM lists of different versions, and the vulnerability components therein are determined by matching with the vulnerability intelligence library. For the vulnerabilities in the newly added dependent components, by comparing the relationship between the component introduction time and the vulnerability disclosure time, it can be determined whether the vulnerability is known or unknown at the time of component introduction, so as to assign different risk identifiers; for the vulnerabilities in the continuously retained dependent components, the retention duration thereof in the historical version is analyzed to identify the risk hidden danger that has existed for a long time but has not been handled in time. Finally, based on the risk identifier of the vulnerability component and the dependency relationship between the components, a risk propagation path is generated and visualized, so that the security team can fully master the distribution of the vulnerability component in the software supply chain and its potential diffusion trend. This multi-dimensional analysis method based on the evolution history and dependency relationship of the components can not only accurately identify the risk attributes of various vulnerabilities, but also clearly show the propagation trend of the risks in the supply chain, thereby helping the security team to more accurately assess and control the security risks in the software supply chain.

[0008] Optionally, a version list of the software item to be detected is extracted from the product library information; a latest version is selected as a current version and a preset number of versions in a reverse order of time are selected as historical versions from the version list; software packages of the current version and the historical versions are downloaded respectively; dependency configuration files are extracted from the software packages, the dependency configuration file of the current version is marked as a first dependency configuration file, and the dependency configuration file of the historical versions is marked as a second dependency configuration file; component names, component version numbers and inter-component dependency relationships in the first dependency configuration file are parsed to generate a first SBOM list; component names, component version numbers and inter-component dependency relationships in the second dependency configuration files are parsed to generate second SBOM lists corresponding to the historical versions respectively.

[0009] Optionally, component names of all components in the first SBOM list are extracted to construct a current version component set; component names of all components in the second SBOM lists are extracted to construct historical version component sets respectively; difference set operation is performed on the current version component set and a latest historical version component set to determine components existing only in the current version, and the components existing only in the current version are marked as newly added dependent components; intersection set operation is performed on the current version component set and all historical version component sets to obtain components existing in the current version and all historical versions, and the components existing in the current version and all historical versions are marked as continuously retained dependent components.

[0010] Optionally, each component in the first SBOM list is traversed to obtain a component name and a component version number of the component; a vulnerability record matched with the component name is queried in a vulnerability intelligence library; an affected version range is extracted from the vulnerability record to judge whether the component version number falls within the affected version range; if the component version number falls within the affected version range, the component corresponding to the component version number is determined as a vulnerability component, and a vulnerability disclosure time corresponding to the vulnerability component is extracted from the vulnerability record.

[0011] Optionally, dependency relationship information between each of the vulnerability components is extracted from the first SBOM list; a dependency relationship graph is constructed according to the dependency relationship information, the dependency relationship graph including component nodes and dependency edges, the component nodes representing vulnerability components, and the dependency edges representing dependency relationships between components; each component node in the dependency relationship graph is traversed, and a risk identifier of a corresponding vulnerability component is labeled on the component node; based on the dependency relationship graph and the second SBOM list, a version evolution path of each of the vulnerability components from an earliest appearing historical version to a current version and a component propagation path between each of the vulnerability components are traced; the version evolution path and the component propagation path are path fitted to obtain a risk propagation path; in the version evolution path, release time nodes of each of the historical versions and the current version are labeled on a time axis, a propagation connection line between each of the vulnerability components in different versions is drawn, and a change in a component version number and a vulnerability disclosure time point are labeled on the propagation connection line; in the component propagation path, a dependency propagation chain between each of the vulnerability components is determined according to the dependency relationship graph, and the first risk identifier, the second risk identifier, and the third risk identifier are labeled with corresponding color identifiers to display corresponding propagation paths; the risk propagation path is converted into visual graphic data, and the visual graphic data is sent to a visualization page for display.

[0012] Optionally, release time nodes of each of the historical versions and the current version are labeled in chronological order on a preset time axis; for each of the vulnerability components, a component start point marker and a component end point marker are created at a corresponding release time node position; a propagation connection line is drawn between the component start point marker and the component end point marker; a component version number of the vulnerability component in the earliest appearing version is labeled at a start point position of the propagation connection line; a component version number of the vulnerability component in the current version is labeled at an end point position of the propagation connection line; if the vulnerability component has a version number change in adjacent historical versions, a changed component version number is labeled at a corresponding release time node position; a vulnerability disclosure time point of the vulnerability component is labeled on the propagation connection line, and the vulnerability disclosure time point is distinguished from the version release time node by a preset identifier.

[0013] Optionally, the vulnerability component with the first risk identifier selected by the user in the visualization page is received, and a target component name of the selected vulnerability component is obtained; a target component matching the target component name is queried in a second SBOM list of a latest historical version; if the matching target component is queried, a component version number of the target component is extracted as a rollback target version number, and a rollback repair suggestion is generated, the rollback repair suggestion including a component version number of the selected vulnerability component in a current version and the rollback target version number; if the matching target component is not queried, a repair suggestion of removing the selected vulnerability component is generated; the repair suggestion or the rollback repair suggestion is superimposed into the risk propagation path, and a target version position to be executed for a repair operation is marked by a preset indication arrow.

[0014] In a second aspect, an embodiment of the present application provides a software supply chain security risk analysis and detection system, which comprises one or more processors and a memory; the memory is coupled with the one or more processors, and the memory is configured to store computer program code, the computer program code comprising computer instructions, and the one or more processors are configured to invoke the computer instructions to enable the software supply chain security risk analysis and detection system to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0015] In a third aspect, an embodiment of the present application provides a computer readable storage medium comprising instructions, which, when executed on a software supply chain security risk analysis and detection system, enable the software supply chain security risk analysis and detection system to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0016] In a fourth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a software supply chain security risk analysis and detection system, enable the software supply chain security risk analysis and detection system to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0017] In summary, the one or more technical solutions provided by the present application have at least the following technical effects or advantages: By adopting the technical scheme, firstly, the dependency configuration files of the current version and the historical version are obtained and parsed based on the product library information, and the corresponding SBOM list is generated, the newly added and continuously retained dependent components are identified by comparing the SBOM lists of different versions, and the vulnerability components are determined by combining the vulnerability intelligence library matching. For the vulnerability in the newly added dependent component, by comparing the chronological relationship between the component introduction time and the vulnerability disclosure time, it can be determined whether the vulnerability is a known or unknown problem at the time of component introduction, thereby distinguishing different risk identifications; for the vulnerability in the continuously retained dependent component, the risk hidden danger that has existed for a long time but has not been handled in time is identified by analyzing the retention time length in the historical version. Finally, based on the risk identification of the vulnerability component and the dependency relationship between the components, the risk propagation path is generated and visualized, so that the security team can fully master the distribution status and potential diffusion trend of the vulnerability component in the software supply chain. This multi-dimensional analysis method based on the component evolution history and the dependency relationship can not only accurately identify the risk attributes of various vulnerabilities, but also clearly show the propagation trend of the risk in the supply chain, thereby helping the security team to more accurately evaluate and control the security risks in the software supply chain. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 is a flow diagram of a software supply chain security risk analysis and detection method disclosed by an embodiment of the present application; Figure 2 is another flow diagram of a software supply chain security risk analysis and detection method disclosed by an embodiment of the present application; Figure 3 is a structural diagram of a system provided by an embodiment of the present application.

[0019] Marked for explanation: 301, central processing unit; 302, read-only memory; 303, random access memory; 304, bus; 305, input / output interface; 306, input part; 307, output part; 308, storage part; 309, communication part; 310, driver; 311, detachable medium. DETAILED DESCRIPTION

[0020] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be described clearly and completely in conjunction with the drawings in the embodiments of the specification. Obviously, the described embodiments are only part of the embodiments of the present application, not all embodiments.

[0021] In the description of the embodiments of the present application, the words "for example" or "such as" are used to represent an example, an illustration, or an exposition. Any embodiment or design scheme described as "for example" or "such as" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words "for example" or "such as" are intended to present the relevant concept in a specific manner.

[0022] In the description of the embodiments of the present application, the term "a plurality of" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. In addition, the terms "first" and "second" are used only for the purpose of description, and should not be interpreted as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features. The terms "include", "contain", "have" and their variants mean "include but are not limited to", unless otherwise specifically emphasized.

[0023] The present application provides a method, referring to Figure 1 , Figure 1 is a flowchart of a software supply chain security risk analysis and detection method provided by the embodiments of the present application. The method is applied to a system, the system can execute a program, and the method comprises steps 101 to 107, and the above steps are as follows: Step 101: Obtain artifact repository information of a software project to be detected.

[0024] The artifact repository refers to a special warehouse for storing release packages of each version of a software project, which contains source code, dependency configuration files, build products and other contents of the software project. The artifact repository information includes project identification, version number list, release time, dependency configuration files and other metadata. The software project to be detected refers to a target software project that needs to be analyzed for supply chain security risks, which is usually a complete application program or component library. For example, a certain web application project publishes multiple versions on the Maven central repository, and each version contains corresponding pom.xml dependency configuration files, jar packages and other artifacts.

[0025] Specifically, first, the project information is queried using the unique identifier (such as groupId: artifactId) through the API interface or SDK of the artifact repository. For Maven artifact repository, the Maven Repository API is called to obtain the version list and component information of the project; for npm artifact repository, the npm registry API is used to obtain the historical version information of the package. Then the project component files stored in the artifact repository are downloaded, mainly including dependency configuration files (such as pom.xml, package.json) and build products (such as jar package, npm package). The metadata information of each version such as release time and version number also needs to be extracted, which is stored in the index data of the artifact repository. Finally, the obtained artifact repository information is saved as structured data, including version number, release time, dependency configuration file path, etc. fields, which is convenient for subsequent processing. This step provides basic data support for subsequent dependency analysis and vulnerability detection. The specific implementation can use the REST API provided by the artifact repository for query, or use a special artifact repository client tool for information acquisition. For example, the implementation code of Maven API: query project information through RepositorySystem, download components using ArtifactRequest, and parse metadata to obtain release time, etc.

[0026] Step 102: Extract the first dependency configuration file of the current version software and the second dependency configuration file of at least two historical version software from the artifact repository information, and parse the first dependency configuration file and the second dependency configuration file respectively to generate the first SBOM list of the current version and the second SBOM list of the historical version.

[0027] Dependency configuration file refers to the configuration file describing the dependency relationship of software project, such as pom.xml of Maven project and package.json of Node.js project. The first dependency configuration file specifically refers to the dependency configuration file of the current version software, and the second dependency configuration file refers to the dependency configuration file of the historical version software. SBOM (Software Bill of Materials) list is a software bill of materials, which records all component information used in software, including component name, version number, license information, etc. The first SBOM list is the component list of the current version, and the second SBOM list is the component list of the historical version. For example, the pom.xml file of the latest version 2.0.0 of a Java project declares the dependency relationship of Spring Framework 5.3.20 and other components, and the pom.xml of the historical version 1.9.0 uses Spring Framework 5.2.22.

[0028] Specifically, first, the version list of the project is obtained from the artifact repository information, and the versions are sorted in descending order of release time. The latest released version is selected as the current version, and the two latest historical versions are selected for comparison and analysis. Download the software packages corresponding to these versions and extract the dependency configuration files from them. For Maven projects, parse the pom.xml file; for Node.js projects, parse the package.json file. The parsing process includes: extracting the groupId / artifactId / version (Maven) or name / version (Node.js) of the direct dependency components, parsing the transitive dependency relationship, and building a complete dependency tree. Convert the parsing results into a standard SBOM format, including the following fields: component identifier, component name, component version number, component type, upstream dependency list, license information, etc. Repeat the same parsing process for each historical version to generate the corresponding SBOM list. In specific implementation, dependency parsing tools for each language ecosystem can be used, such as Aether parser for Maven and dependency resolver for npm. After parsing, store the SBOM data in a standard format (such as CycloneDX, SPDX) for subsequent version comparison and vulnerability analysis. Parsing example: use MavenXpp3Reader of Maven to parse pom.xml to obtain dependency declaration, use DependencyResolver to parse complete dependency tree, and finally convert to SBOM in CycloneDX format.

[0029] In one possible implementation, the first dependency configuration file of the current version software and the second dependency configuration file of at least two historical versions of software are extracted from the artifact repository information, and the first dependency configuration file and the second dependency configuration file are parsed respectively to generate the first SBOM list of the current version and the second SBOM list of the historical versions, specifically including steps 1021-1024, which are as follows: Step 1021: Extract the version list of the software project to be detected from the artifact repository information; select the latest version as the current version from the version list, and select the first preset number of versions in reverse chronological order as the historical versions.

[0030] The version list refers to a collection of all released versions of a software project, each version containing a version number and a release time. The current version refers to the latest released version of a software project, and the historical version refers to a version released before the current version. The preset number of versions refers to the number of historical versions preset to limit the range of historical versions for analysis. The time reverse order refers to the sorting method from new to old according to the release time. For example, the version list of a certain project contains version information such as 2.0.0 (2023-10-01), 1.9.0 (2023-08-15), 1.8.0 (2023-07-01), etc. If the preset number of historical versions is 2, 1.9.0 and 1.8.0 are selected as historical versions for analysis.

[0031] Specifically, first, the version information of the software project is queried through the API interface of the artifact library. For Maven artifact library, the versions interface of Maven Repository API is called to obtain all versions of the project; for npm artifact library, the versions field of registry API is used to obtain the version list. The obtained version information contains version number (such as 2.0.0) and corresponding release time (such as 2023-10-01 10:00:00). The version list is sorted in descending order according to the release time, and the first version after sorting is marked as the current version. From the remaining versions, a preset number (such as 2 or 3) of versions are selected as historical versions in time reverse order. The version selection needs to filter out non-official release versions such as alpha, beta, RC, and only select stable versions of official release. In specific implementation, first, the version information is stored in a list structure, and each element contains two fields of version number and release time. The version list is sorted using the timestamp as the sorting key value, and the first element is taken as the current version. Then, from the sorted list, the second element is taken as the preset number of versions as historical versions. The selected results are stored as two lists: the current version list (containing only the latest version) and the historical version list (containing the selected historical versions).

[0032] Step 1022: Download the software package of the current version and the historical version respectively; extract the dependency configuration file from each software package, and mark the dependency configuration file of the current version as the first dependency configuration file, and mark the dependency configuration file of the historical version as the second dependency configuration file.

[0033] A software package refers to a release artifact of a software project, containing source code, dependency configuration files and other resource files in a compressed package. For Java projects, it is usually in jar / war format, and for Node.js projects, it is in tgz format. Dependency configuration files refer to files that define the dependency relationships of a project, such as pom.xml or package.json, containing declarations of direct dependencies and transitive dependencies. The first dependency configuration file specifically refers to the current version of the dependency configuration file, and the second dependency configuration file refers to the historical version of the dependency configuration file. For example, the jar package of Spring Boot project version 2.0.0 contains a pom.xml file, which declares dependencies on components such as spring-core and spring-context.

[0034] Specifically, first, according to the download address provided by the artifact library, use the HTTP client or the dedicated artifact library client tool to download the software package. For Maven projects, download the jar package through the download interface of Maven Repository; for npm projects, download the tgz package through the tarball URL of npm registry. After downloading, decompress the software package to a temporary directory. The decompression process uses decompression tools corresponding to the format, such as jar command or zip library for jar package, tar command or gzip library for tgz package. In the directory after decompression, locate the dependency configuration file, Maven project searches for pom.xml file, usually located in META-INF / maven directory; npm project searches for package.json file, located in the root directory of the package. For the current version of the software package, copy the extracted dependency configuration file to the specified directory and mark it as the first dependency configuration file; for each historical version of the software package, copy the extracted dependency configuration file to the corresponding version directory and mark it as the second dependency configuration file. The marking process is implemented through file naming or metadata annotation, such as renaming the pom.xml of the current version to pom-current.xml, and renaming the historical version to pom-1.9.0.xml, pom-1.8.0.xml, etc. After extraction and marking, clean up the temporary decompression directory to release storage space.

[0035] Step 1023: Parse the component name, component version number and inter-component dependency relationship in the first dependency configuration file to generate a first SBOM list.

[0036] The component name refers to the unique identifier of the dependent component, which is composed of groupId and artifactld in Maven projects and package name in npm projects. The component version number refers to the string that defines the specific version of the component, which follows the semantic versioning specification. The inter-component dependency describes the reference relationship between components, including direct dependencies and transitive dependencies. The first SBOM list is a standardized list that describes all component information in the current version of the software, including component identifier, version information and dependency relationship. For example, the Spring Boot project depends on spring-core: 5.3.20, and spring-core depends on commons-logging: 1.2, forming a dependency chain.

[0037] Specifically, for pom.xml of Maven project, use DOM parser or SAX parser to read XML document, traverse dependencies and dependencyManagement nodes, extract groupId, artifactld and version information declared in each dependency element. For package.json of npm project, use JSON parser to read file, extract dependency declarations in dependencies and devDependencies objects. Then use dependency resolver to analyze transitive dependencies, Maven project uses Aether resolver to recursively parse transitive dependency tree of each direct dependency, npm project uses npm dependency resolver to build complete dependency graph. The information obtained by parsing includes: component complete identifier (such as org.springframework: spring-core), component actual version number (such as 5.3.20), component direct dependency list, component complete dependency path. Convert the parsing result to standard SBOM format, including the following fields: component ID, component name, component version, dependency type (direct / transitive), upstream dependency list, license information (if any). Finally, serialize SBOM data to standard format (such as CycloneDXXML or JSON), save as first SBOM list file. The parsing result also includes the hierarchical relationship of the dependency tree, which records the hierarchical position and dependency path of each component in the dependency graph.

[0038] Step 1024: parse the extracted component name, component version number and inter-component dependency in each second dependency configuration file, and generate the second SBOM list corresponding to the historical version respectively.

[0039] The second dependency configuration file refers to the dependency configuration file of the historical version software, and each historical version corresponds to a dependency configuration file. The component name, component version number and inter-component dependency relationship have the same meaning as the current version, but reflect the dependency state in the historical version. The second SBOM list is a software bill of materials for each historical version, which records all component information used in each historical version. For example, a Java project 1.9.0 version depends on spring-core: 5.2.22, and a 1.8.0 version depends on spring-core: 5.2.20, which is recorded in the SBOM list of the corresponding version.

[0040] Specifically, first, a version mapping table is established to record the historical version number corresponding to each second dependency configuration file. Each second dependency configuration file is traversed, and for Maven projects, MavenXpp3Reader is used to load the pom.xml file content, extract the version information of the project element, and parse all dependency declarations under the dependencies and dependencyManagement nodes. For npm projects, JSON.parse is used to parse package.json and read the version field and dependencies object. Then the dependency resolver is used to analyze the transitive dependencies of each direct dependency, and Maven projects parse the dependency tree recursively through DependencyResolver, and npm projects use npm-dependency-tree to build a dependency relationship graph. The parsing process records the following information of each component: component identifier, declared version range, actually parsed version number, dependency type, dependency level, and dependency path. The parsing results are converted into a standard SBOM format, and an independent SBOM list file is generated for each historical version, and the file name contains the corresponding historical version number. The SBOM list contains the following fields: component identifier, component version, dependency type, upstream dependency list, license information, etc. The release time of each historical version is also recorded for subsequent time series analysis. Finally, all the SBOM lists of the historical versions are sorted into a version set for easy comparison and analysis with the current version.

[0041] Step 103: Compare the first SBOM list with the second SBOM list to determine the newly added dependent components and the continuously retained dependent components in the current version.

[0042] The first SBOM list is a component list of the current version, containing component identifiers, version numbers and dependency relationships. The second SBOM list is a set of component lists of historical versions, each historical version corresponding to an SBOM list. The newly added dependent component refers to a component that first appears in the current version and does not exist in the most recent historical version. The continuously retained dependent component refers to a component that exists in the current version and all historical versions. For example, a project adds a log4j-core:2.17.0 component in the current version 2.0.0, and the spring-core component has existed since version 1.8.0, so log4j-core is a newly added dependent component, and spring-core is a continuously retained dependent component.

[0043] Specifically, first, all component identifiers of the current version are extracted from the first SBOM list to construct a component set A. The second SBOM list set is traversed to extract component identifiers from the SBOM list of the most recent historical version to construct a component set B. Set operation A-B (difference set operation) is performed to obtain a set of component identifiers that exist only in set A, and these components are the newly added dependent components. Then, the SBOM lists of all historical versions are traversed to extract the component identifiers of each historical version to construct component sets C1, C2...Cn. Set operation A∩C1∩C2∩...∩Cn (multi-set intersection operation) is performed to obtain a set of component identifiers that exist in all versions, and these components are the continuously retained dependent components. For the newly added dependent components, record their complete information in the current version: component identifier, version number, introduction position (direct dependency or transitive dependency), and dependency path. For the continuously retained dependent components, record their version evolution history: version number used in each historical version, version change time, and dependency relationship change. The analysis results are stored as structured data, including two main parts: a list of newly added dependent components (component identifier, version number, introduction information) and a list of continuously retained dependent components (component identifier, version history, retention duration). These information is used for subsequent risk analysis and evaluation.

[0044] In a possible implementation, based on the matching result, the fault time prediction range of each battery monomer is determined, and a warning report corresponding to the fault time prediction range is generated. Specifically, steps 1031-1033 are included, and the above steps are as follows: Step 1031: Extract the component names of all components in the first SBOM list to construct a current version component set; extract the component names of all components in each second SBOM list to construct a historical version component set.

[0045] The component name is a unique identifier of the dependent component, which is composed of groupId:artifactld in the Maven ecosystem and package name in the npm ecosystem. The current version component set is a collection data structure containing all component names of the current version. The historical version component set is a sequence of multiple sets, each of which corresponds to the component name set of a historical version. For example, the current version component set of the Spring Boot project contains component names such as org.springframework.boot:spring-boot-starter-web, and the historical version component set contains component names used in each historical version.

[0046] Specifically, first process the first SBOM manifest, read the manifest content using an XML parser or a JSON parser. Traverse each component node in the manifest, extract the component identification information. For Maven projects, concatenate groupId and artifactld with a colon to form the component name (such as org.springframework:spring-core); for npm projects, directly use the package name. Create a HashSet data structure as the current version component set, and add the extracted component name to the set, which will automatically remove duplicates. Then process the second SBOM manifest set, create a separate HashSet for each historical version as the corresponding historical version component set. Traverse each historical version SBOM manifest in order of version number, parse the manifest content, extract the component name, and add the component name to the corresponding version set. Store all historical version component sets in List<Set<String>> historicalVersionComponentSets. <string>In the structure, each element of the List corresponds to a historical version of the component set, and the order of the set is consistent with the time order of the version. The version number and time information corresponding to each historical version of the component set are recorded at the same time for subsequent analysis. In this way, a current version of the component set and a list containing a plurality of historical version component sets are obtained, providing basic data for subsequent set operation and component analysis.

[0047] Step 1032: Perform a difference set operation on the current version component set and the most recent historical version component set to determine components that only exist in the current version, and identify the components that only exist in the current version as newly added dependent components.

[0048] The current version component set contains the identifiers of all components in the current version. The most recent historical version component set contains the identifiers of all components in the immediately preceding version of the current version. The difference set operation is a set operation that removes all elements existing in the second set from the first set to obtain elements existing only in the first set. The newly added dependent component refers to a component first introduced in the current version. For example, the project 2.0.0 version (current version) depends on the commons-text:1.9 component, while the 1.9.0 version (most recent historical version) does not contain this component. By difference set operation, it can be identified that commons-text is a newly added dependent component.

[0049] Specifically, first, the current version component set (set as set A) and the most recent historical version component set (set as set B) are obtained. The difference set operation method (such as the HashSet.removeAll() method in Java) of the set is used to perform A-B operation. In specific implementation, a new HashSet is created as the difference set result set, all elements of the current version component set A are copied to the result set, and then all elements existing in the historical version component set B are removed from the result set. For each component in the difference set result, the complete information of the component is found from the first SBOM list, including: component identifier, currently used version number, component type (direct dependency / transitive dependency), and introduction path (from which upstream components). These components are marked as newly added dependent components, and a newly added component information object is created, containing the following fields: component name, version number, introduction version (current version number), introduction time (current version release time), introduction method (direct / transitive), and dependency path. All newly added dependent component information objects are stored in List <newdependency>In the structure, components are sorted by name for subsequent query and analysis. This list contains all newly introduced components in the current version and their detailed information Step 1033: Perform intersection operation on the current version component set and all historical version component sets to obtain components that exist in both the current version and all historical versions, and identify these components as persistent dependency components.

[0050] The current version component set is a set containing all component identifiers of the current version. The historical version component set is a sequence of sets, each containing all component identifiers of a corresponding historical version. The intersection operation is an operation performed on multiple sets to obtain elements that exist in all sets. Persistent dependency components refer to components that persist in the current version and all analyzed historical versions. For example, the project depends on the spring-core component from version 1.8.0 to 2.0.0, and through intersection operation, spring-core can be identified as a persistent dependency component.

[0051] Specifically, first prepare the current version component set (set as set A) and all historical version component sets (set sequence B1, B2,..., Bn) for intersection operation. Create a new HashSet as the intersection result set, initialized as a copy of the current version component set A. Traverse each historical version component set in turn, use the retainAll() method of the set to perform intersection operation, each operation will retain elements that exist in both the current result set and the set to be compared. After the operation is completed, the elements retained in the intersection result set are the persistent component identifiers. For each component in the intersection result, extract the complete information of the component from all SBOM lists, including: component identifier, version number sequence used in each version, first introduction time, version change history. Create a persistent component information object containing the following fields: component name, current version number, historical version number list, existence duration (time span from first introduction to current), version change number, dependency relationship change record. Store all persistent component information objects in List <retaineddependency>In the structure, the components are sorted in descending order of the length of their existence. This list records the core dependent components used in the project for a long time and their evolution history, providing an important basis for subsequent risk assessment. It is particularly important to keep the version evolution history of the components for identifying potential security risks, because the vulnerabilities of these components often have a long-term impact on the project.

[0052] Step 104: Match each component in the first SBOM list with the vulnerability intelligence library to determine the vulnerability components and extract the corresponding vulnerability disclosure time.

[0053] The vulnerability intelligence library is a database that collects and stores information about known software security vulnerabilities, such as the NVD (National Vulnerability Database). Vulnerable components refer to software components that contain known security vulnerabilities. The vulnerability disclosure time refers to the time when the vulnerability is publicly released to the vulnerability intelligence library. For example, the log4j component version 2.14.1 has a CVE-2021-44228 vulnerability, which was publicly disclosed in the NVD database on 2021-12-09.

[0054] Specifically, first, the identification information of all components is extracted from the first SBOM list, including component name and version number. For each component, a standardized component identification format is constructed. Maven components use the groupId:artifactId:version format (such as org.apache.logging.log4j:log4j-core:2.14.1), and npm components use the package@version format (such as lodash@4.17.15). Then, the vulnerability information of each component is queried through the API interface of the vulnerability intelligence library. The query process includes: calling the REST API of NVD, matching the component identification using CPE (Common Platform Enumeration); querying the OSV (Open Source Vulnerabilities) database, matching using the exact package name and version number; querying the GitHub Security Advisories, matching using the ecosystem-specific package identifier. For each component that matches a vulnerability, the following information is extracted: vulnerability identifier (such as CVE-ID), vulnerability description, CVSS score, vulnerability disclosure time, affected version range, patch version information. The extracted information is stored as structured data, creating a vulnerability component information object, containing fields: component identification, current version, vulnerability list (each vulnerability contains ID, disclosure time, severity, etc.). The vulnerability list is sorted by vulnerability disclosure time, and the earliest vulnerability disclosure time is recorded as the first vulnerability exposure time of the component. A vulnerability component list is generated, containing all components detected with vulnerabilities and their corresponding vulnerability information, providing basic data for subsequent risk assessment.

[0055] In one possible implementation, each component in the first SBOM list is matched with the vulnerability intelligence library to determine the vulnerability components and extract the corresponding vulnerability disclosure time, specifically including steps 1041-1043, as follows: Step 1041: Traverse each component in the first SBOM list to obtain the component name and component version number of the component.

[0056] Specifically, first, select the corresponding parser according to the format of the SBOM list. For CycloneDX format XML documents, use the DOM parser to load the document object; for JSON format, use the JSON parser to load the document content. Create a component information set to store the parsing results, define the component information data structure, which includes two necessary fields: component name and version number. For XML format, use XPath expression to locate all component nodes, such as the " / / component" path; for JSON format, locate the components array. Create an iterator to traverse each component node. For Maven project components, extract groupId and artifactId from the node attributes, concatenate them with a colon to form the component name, and get the version number from the version attribute; for npm project components, get the package name from the name attribute and the version number from the version attribute. Encapsulate the extracted component name and version number into a component information object and add it to the component information set. Perform data verification during the traversal process to ensure that the component name and version number conform to the standard format, and record any data that does not conform to the format. Finally, generate a list containing the basic information of all components, sorted in alphabetical order by component name, to facilitate subsequent vulnerability matching operations. Each list item contains the standardized name and normalized version number of the component.

[0057] Step 1042: Query the vulnerability records in the vulnerability intelligence library that match the component name; extract the affected version range from the vulnerability records and determine whether the component version number falls within the affected version range; if the component version number falls within the affected version range, determine the component as a vulnerability component.

[0058] Specifically, first construct the query condition to access the vulnerability intelligence library. For Maven components, use the groupId:artifactld format to construct the query key; for npm components, directly use the package name. Execute the query through the API interface of the vulnerability intelligence library, support batch query to improve efficiency. When querying the NVD database, use the CPE matching rule to convert the component identifier, such as converting org.apache.logging.log4j:log4j-core to cpe:2.3:a:apache:log4j: : : : : : :. When querying the OSV database, use the package identifier specific to the ecosystem. For each returned vulnerability record, parse the version range information in the affected field. The version range may be represented in multiple formats: Maven uses the [2.0.0, 2.14.1] format, npm uses the ^2.0.0 format, and needs to be uniformly converted to the standard version constraint expression. Use the version comparator to check if the component version number meets the version constraint expression. The version comparison follows the semantic versioning specification, considering the priority of the major version number, the minor version number, and the revision number. If the component version meets the version constraint of any vulnerability record, mark the component as a vulnerability component. Create a vulnerability component object, record the following information: component identifier, version number used, list of matched vulnerabilities (each vulnerability contains CVE number, affected version range, CVSS score). Store all vulnerability component objects in the vulnerability component set, sort by the number of vulnerabilities and severity. This process needs to handle special cases of version ranges, such as version interval, version prefix matching, version exclusion, etc.

[0059] Step 1043: Extract the affected version range from the vulnerability record, and determine whether the component version number falls within the affected version range; if the component version number falls within the affected version range, determine the component corresponding to the component version number as a vulnerability component, and extract the vulnerability disclosure time corresponding to the vulnerability component from the vulnerability record.

[0060] The affected version range is the version interval affected by the vulnerability defined in the vulnerability record, described using the version constraint expression. The component version number is a version identifier following the semantic versioning specification. The vulnerability component is a software component that uses the affected version. The vulnerability disclosure time is the timestamp when the vulnerability is publicly published to the vulnerability database. For example, a vulnerability record shows that the log4j-core component in the version range "> = 2.0.0, <= 2.14.1" has CVE-2021-44228 vulnerability, and the disclosure time is 2021-12-09T10: 15: 00Z, and the log4j-core component using version 2.14.0 will be marked as a vulnerability component.

[0061] Specifically, first, the version range information in the vulnerability record is parsed. For different formats of version range representation, it is uniformly converted into a standard version constraint object. The Maven format version range such as "[2.0.0, 2.14.1]" is converted into the minimum version 2.0.0 (inclusive) and the maximum version 2.14.1 (inclusive); the npm format version range such as "^2.0.0" is converted into the minimum version 2.0.0 (inclusive) and the maximum version 3.0.0 (not inclusive). A version comparator is created to implement the size comparison logic of the version number. The version comparison first splits the version number by the point to get the version array, such as "2.14.1" split into [2, 14, 1]. The numbers at the corresponding positions in the array are compared in turn to determine the size relationship of the version number. It is judged whether the component version number falls within the affected version range: whether the version number is greater than or equal to the minimum version (considering the inclusive relationship), and whether it is less than or equal to the maximum version (considering the inclusive relationship). For components that meet the version range, a vulnerability component object is created to record component information (component identifier, version number) and vulnerability information. The publishedDate field in the vulnerability record is extracted as the vulnerability disclosure time and converted into a standard timestamp format. In the case of multiple vulnerability records for the same component, the disclosure times of all matching vulnerabilities are extracted, and the earliest disclosure time is recorded as the first vulnerability exposure time of the vulnerability component. The vulnerability component object is added to the vulnerability component set, including the following fields: component identifier, version number, vulnerability ID list, disclosure time of each vulnerability, and earliest vulnerability disclosure time. Finally, the vulnerability component set is sorted by the earliest vulnerability disclosure time for subsequent risk analysis.

[0062] Step 105: For the vulnerability components belonging to the newly added dependent components, the release time of the current version is obtained as the component introduction time. When the component introduction time is later than the vulnerability disclosure time, it is determined that the vulnerability component is a known vulnerability introduction and is assigned a first risk identifier. When the component introduction time is earlier than or equal to the vulnerability disclosure time, it is determined that the vulnerability component is an unknown vulnerability introduction and is assigned a second risk identifier.

[0063] The newly added dependent component is a component that is first introduced in the current version. The vulnerability component is a component that contains a known security vulnerability. The component introduction time is the time when the component is first added to the project, which is equivalent to the release time of the current version. The vulnerability disclosure time is the time when the vulnerability is publicly disclosed. Known vulnerability introduction refers to the introduction of a component that has a vulnerability after the vulnerability is disclosed. Unknown vulnerability introduction refers to the introduction of a component that is later found to have a vulnerability before the vulnerability is disclosed. The first risk identifier and the second risk identifier are markers used to distinguish the type of vulnerability introduction. For example, a project introduces the log4j-core:2.14.1 component in the version released on 2023-10-01, and the CVE-2021-44228 vulnerability existing in this component was disclosed on 2021-12-09, which belongs to known vulnerability introduction.

[0064] Specifically, first, the components that exist in both the newly added dependent component set and the vulnerability component set are filtered out from the newly added dependent component set to obtain a newly added vulnerability component list. The release time of the current version is read as the component introduction time, and the time format is uniformly converted to UTC timestamp. Time comparison is performed for each newly added vulnerability component: the vulnerability disclosure time in the vulnerability record corresponding to the component is extracted and converted to the same timestamp format. Timestamp comparison is performed using the compareTo method or timestamp numerical comparison. When the component introduction timestamp is greater than the vulnerability disclosure timestamp, it indicates that the component is introduced after the vulnerability is disclosed, and a risk object is created, containing fields: component identifier, version number, vulnerability ID, vulnerability disclosure time, component introduction time, risk type (first risk identifier), time difference (introduction time minus disclosure time). When the component introduction timestamp is less than or equal to the vulnerability disclosure timestamp, it indicates that the component is introduced before the vulnerability is disclosed, and a risk object is created, with the risk type set to the second risk identifier, and the time difference (disclosure time minus introduction time) is calculated. The risk object is added to the risk component set, sorted by risk type and time difference. For components with the first risk identifier (known vulnerability introduction), the time difference represents the delay in repair time; for components with the second risk identifier (unknown vulnerability introduction), the time difference represents the usage time before the vulnerability is exposed. A risk analysis report is generated, containing detailed information of the two types of risk components, providing a basis for subsequent repair decisions.

[0065] Step 106: For vulnerability components belonging to continuously retained dependent components, obtain the retention duration of the vulnerability component in historical versions. When the retention duration exceeds the preset threshold, assign a third risk identifier; when the retention duration does not exceed the preset threshold, assign a second risk identifier.

[0066] Continuously retained dependent components are components that exist continuously in the current version and all analyzed historical versions. Vulnerability components are components that contain known security vulnerabilities. Retention duration is the time span of a component from its first introduction to the current version, calculated in days. The preset threshold is a time limit for judging the retention duration of a component, such as 180 days. The third risk identifier represents a long-term retained vulnerability component, and the second risk identifier represents a short-term retained vulnerability component. For example, the spring-core:5.3.20 component has been continuously used for 273 days since the project 1.8.0 version (released on 2023-01-01) was introduced until now (2023-10-01), which exceeds the 180-day threshold, and if the component has a vulnerability, it is assigned a third risk identifier.

[0067] Specifically, first, the components that exist in both the vulnerability component set and the continuously retained dependency component set are filtered from the continuously retained dependency component set to obtain a continuously retained vulnerability component list. For each continuously retained vulnerability component, the earliest version of the component is found from the historical version SBOM list. The release time of the earliest version is extracted as the first introduction time of the component, and the release time of the current version is extracted as the termination time, which is converted into UTC timestamp format. The number of days between the two timestamps is calculated as the retention period using the Duration class of Java or similar tools. A time comparator is created to compare the retention period with a preset threshold (such as 180 days). When the retention period is greater than the preset threshold, a risk object is created, and the following fields are set: component identifier, current version number, first introduction version number, first introduction time, retention period (days), vulnerability information list, and risk type (third risk identifier). When the retention period is less than or equal to the preset threshold, a risk object is created, and the risk type is set to the second risk identifier. For each risk object, the version change history of the component in each historical version is recorded: version number, change time, and whether a version upgrade has been performed. The risk object is added to the risk component set, which is sorted by risk type and retention period. A continuously retained risk analysis report is generated, containing detailed information of two types of risk components: long-term retained components (third risk) and short-term retained components (second risk), providing a basis for component update policy formulation.

[0068] It should be noted that the first risk identifier, the second risk identifier, and the third risk identifier constitute a hierarchical risk classification system, and there are clear differences in risk level and impact range between them. The first risk identifier represents the highest level of risk and is applicable to components that have direct vulnerabilities and the vulnerabilities have been disclosed. Such components contain known vulnerabilities and have immediate security threats that can be exploited. They are the source nodes of risk propagation and need to be prioritized for handling and repair. For example, a version of a component has a disclosed remote code execution vulnerability.

[0069] The second risk identifier represents a medium level of risk and is applicable to components that directly depend on components with the first risk identifier. Such components do not contain vulnerabilities themselves, but are easily affected by upstream vulnerability components due to direct dependency. They are the first level of spread nodes of risk propagation and need to update the dependency version in a timely manner. For example, an application directly depends on a log component that has a vulnerability.

[0070] The third risk identifier represents a lower level of risk and is applicable to components that are associated with components with the first risk identifier through indirect dependency. Such components may be affected by vulnerabilities through transitive dependencies. They are the second and further spread nodes of risk propagation and need to evaluate the dependency chain and consider updating. For example, an application depends on a framework, which in turn depends on a component that has a vulnerability.

[0071] The three risk identifications form a progressive risk propagation chain, reflecting the process of vulnerability spreading from the source component to the outside through the dependency relationship. The risk level decreases with the increase of the dependency level, but still needs to be managed and handled comprehensively.

[0072] Step 107: Based on the risk identifications corresponding to each vulnerability component and the dependency relationships between each vulnerability component, generate a risk propagation path and send the risk propagation path to a visualization page.

[0073] The risk identification is a classification label for the risk type of the vulnerability component, including the first risk identification (known vulnerability introduction), the second risk identification (unknown vulnerability introduction or short-term retention), and the third risk identification (long-term retention). The dependency relationship describes the reference relationship between components, including direct dependency and transitive dependency. The risk propagation path is a dependency chain formed from the component with a vulnerability to all its upstream dependent components. The visualization page is a Web interface that displays the risk propagation path, usually represented by a directed graph. For example, the project directly depends on component A, component A depends on component B with the first risk identification, forming the risk propagation path of project -> A -> B.

[0074] Specifically, first, a complete dependency relationship graph is constructed. A directed graph is created using a graph data structure (such as the JGraphT library), with each node representing a component containing the fields: component identifier, version number, risk identification (if present), and component type (direct dependency / transitive dependency). The edges between nodes represent dependency relationships, and the properties of the edges contain dependency types and dependency ranges. Dependency relationship data is read from the SBOM list, and an adjacency list or adjacency matrix is used to represent the dependency graph. Using a depth-first search algorithm, start from each node marked as a risk component and backtrack upstream to identify all possible affected component paths. Perform risk assessment on each path: calculate the path length (number of dependency levels), record the risk identification of each node on the path, and determine the overall risk level of the path according to the priority of the risk identification (first risk > third risk > second risk). Generate visualization data in JSON format, containing the following structures: node array (each node contains ID, name, version, risk identification, risk level), edge array (contains source node ID, target node ID, dependency type). Use D3.js or ECharts library to create an interactive directed graph on the Web page: nodes are represented by different colors to represent risk identification (such as red for first risk, orange for third risk, and yellow for second risk), and node size represents the scope of influence (the number of upstream components that depend on this component), and the thickness of the edge represents the directness / indirectness of the dependency relationship. Implement interactive functions of the graph: click on the node to display detailed information (component details, vulnerability information, risk assessment), support path highlighting, node filtering, risk level filtering, and other operations. Add a legend and risk statistical information to help users understand the risk propagation situation.

[0075] In a possible implementation, based on the risk identification corresponding to each vulnerability component and the dependency relationship between each vulnerability component, a risk propagation path is generated, and after the risk propagation path is sent to the visualization page, steps 1071-1073 are further included, and the steps are as follows: Step 1071: receiving a vulnerability component with a first risk identification selected by a user in the visualization page, and obtaining a target component name of the selected vulnerability component; and querying a target component matching the target component name in a second SBOM list of a latest historical version.

[0076] The visualization page is a web interface for displaying the risk propagation path and supports user interaction. The first risk identification indicates a vulnerability component introduced after the vulnerability is disclosed. The target component name is an identifier of the vulnerability component selected by the user. The second SBOM list is a software bill of materials of a latest historical version. The target component is a component record matching the selected component name in the historical version. For example, the user selects the log4j-core component with the first risk identification in the visualization page, and the system needs to find a component record named org.apache.logging.log4j:log4j-core in the SBOM list of the historical version 1.9.0.

[0077] Specifically, first, the interactive function of the visualization page is implemented, and JavaScript is used to listen to the node click event. When the user clicks on a node in the graph, the risk identification attribute of the node is checked. Only in response to the selection of a node with the first risk identification, the component information object of the selected node is extracted. The target component name is obtained from the component information object. For Maven components, the complete groupId: artifactld identifier is extracted, and for npm components, the package name is extracted. An SBOM query processor is created, and the second SBOM list of the latest historical version is loaded. According to the SBOM format, the corresponding parsing method is selected: for the CycloneDX format, the XPath query " / / component[name='target component name']" is used; for the SPDX format, the record matching the name attribute in the Package node is found; for the JSON format, the components array is traversed to find the object matching the name field. The query result contains the complete information of the target component: component name, version number, license, dependency relationship, etc. A target component object is created to store the component information obtained by querying, including the fields: component identifier, version number in the historical version, historical version number, and version release time. If a matching component record is not found in the historical version, set the query state to not found for subsequent processing. The query result is sent back to the front end through Ajax or WebSocket, and the component detail panel of the visualization interface is updated to display the usage of the component in the historical version. This query result will be used for subsequent version comparison and upgrade suggestion generation.

[0078] Step 1072: If a matching target component is found, extract the component version number of the target component as the rollback target version number, and generate a rollback repair suggestion. The rollback repair suggestion contains the component version number of the selected vulnerability component in the current version and the rollback target version number.

[0079] The target component is the component that matches the selected vulnerability component name in the historical version. The rollback target version number is the version number used by the target component in the historical version. The rollback repair suggestion is a repair scheme that suggests rolling back the component version from the current version to the historical version. For example, if the current version of a project uses log4j-core:2.14.1 and the historical version uses version 2.13.3, the generated rollback repair suggestion is "Suggest rolling back log4j-core from version 2.14.1 to version 2.13.3".

[0080] Specifically, when a matching target component is queried in the historical version, first extract the version attribute value from the target component object as the rollback target version number. Create a version comparator to compare the new and old relationship of the current version number and the rollback target version number. Build a rollback repair suggestion object, including the following fields: component identifier, current version number, rollback target version number, repair type (version rollback), historical version number, version release time. If the component uses version range declaration, analyze the compatibility of the version range to ensure that the rollback version meets the version constraints. Generate specific text for rollback repair suggestions, including: component full identifier, current version, suggested rollback version, dependent path involved, possible impact range. If there are transitive dependencies, you also need to analyze the impact of the rollback operation on the dependency tree and identify other components that may be affected. Serialize the rollback repair suggestion object to JSON format and prepare to send it to the front end for display.

[0081] Step 1073: If no matching target component is queried, generate a repair suggestion for removing the selected vulnerability component; superimpose the repair suggestion or rollback repair suggestion into the risk propagation path, and mark the target version position of the repair operation to be performed by a preset indication arrow.

[0082] The removal repair suggestion is a repair scheme that suggests deleting a certain vulnerability component from the project. The preset indication arrow is a visual element used to mark the target position of the repair operation in the visualization diagram. The target version position of the repair operation to be performed refers to the position of the version node involved in the repair suggestion in the dependency graph.

[0083] Specifically, when no matching target component is queried, create a removal repair suggestion object, including the fields: component identifier, current version number, repair type (component removal), impact assessment. Analyze the dependency relationship of the component to identify upstream components that depend on the component and downstream components that are dependent on the component. Evaluate the impact range of the removal operation, including: modules directly dependent on the component, components in the transitive dependency chain, and functions that may need to be replaced. Generate specific text for the removal repair suggestion to explain the removal reason and impact range. Add the repair suggestion object to the data structure of the risk propagation path and add the repair suggestion attribute in the dependency graph data. Update the visualization diagram using D3.js or ECharts: add an indication mark (such as a red border) on the component node that needs to be repaired, use a dashed line with an arrow to connect the current version node and the target version node (for rollback suggestions) or use a special mark to represent the removal operation (for removal suggestions). Add interactive functions: click on the repair suggestion arrow to display detailed repair instructions and hover to prompt the impact range. Push repair suggestion updates to the front end in real time through WebSocket to ensure that the visualization interface reflects the latest repair scheme in a timely manner.

[0084] In the above embodiment, the basic vulnerability risk propagation path generation framework is realized through basic risk identification and dependency analysis. To further improve the adaptability of multi-scenario software vulnerability risk propagation analysis and reduce the influence of component type difference on risk propagation analysis accuracy, the application further provides another software supply chain security risk analysis method. The method intelligently constructs the propagation path by identifying component version evolution mode and analyzing the dependency relationship between components, so that the system can more accurately process the risk analysis requirements of complex dependency relationships and heterogeneous component combinations. The following describes the another software supply chain security risk analysis method in the embodiments of the application in combination with Figure 2 The another software supply chain security risk analysis method in the embodiments of the application is described as follows: Please refer to Figure 2 The another software supply chain security risk analysis method in the embodiments of the application is described as follows:

[0085] Step 201: Extract the dependency relationship information between each vulnerability component from the first SBOM list; construct a dependency relationship graph according to the dependency relationship information, the dependency relationship graph including component nodes and dependency edges, the component nodes representing the vulnerability components, and the dependency edges representing the dependency relationship between the components.

[0086] Specifically, first, the dependency relationship data in the first SBOM list is parsed. For the CycloneDX format, the dependencies node is parsed; for the SPDX format, the relationships node is parsed; and for the JSON format, the dependencies object is parsed. A graph data structure is created, which is represented by an adjacency list or an adjacency matrix. Each component node contains attributes: component identifier, version number, component type (direct dependency / transitive dependency), and component coordinates (Maven coordinates or npm package name). The dependency edge contains attributes: dependency type (compile / runtime / test), version range, and optional. The dependency relationship is processed using a graph construction algorithm (such as the JGraphT library): first, all vulnerability components are added as nodes, and then the edges are added by traversing the dependency relationship. For transitive dependencies, a complete dependency chain is constructed using depth-first search. The case of circular dependency is handled, and the circular dependency path is marked. The in-degree (number of dependencies) and out-degree (number of dependencies) of each node are calculated for subsequent impact analysis. The adjacency matrix representation of the graph is generated to facilitate fast querying of the dependency relationship between any two components.

[0087] Step 202: Traverse each component node in the dependency relationship graph and mark the risk identification of the corresponding vulnerability component on the component node.

[0088] Specifically, first select the graph traversal algorithm, you can use breadth-first search (by level traversal) or depth-first search (by path traversal). Create a traversal object, record the set of visited nodes to avoid repeated access. For each visited component node, get the component identifier from the node attribute. Query the risk component set to get the risk identifier corresponding to the component. Add risk attributes to the node object: risk type (first / second / third risk identifier), risk description, risk score. Update the visual attributes of the node: set the node color (such as red for first risk, orange for third risk, and yellow for second risk), node shape (such as a circle for direct dependency and a diamond for transitive dependency), and node size (scaled according to the impact range). Add risk labels to the node to display the risk type and key information. Calculate the risk weight of the node: the first risk has the highest weight, the third risk has the second highest weight, and the second risk has the lowest weight. Adjust the layout position of the node in the graph according to its risk weight, with high-risk nodes placed in more prominent positions. Serialize the traversal results into JSON format, including the complete attributes and risk information of the nodes, ready for visualization.

[0089] Step 203: Based on the dependency graph and the second SBOM list, trace the version evolution path of each vulnerability component from the earliest appearing historical version to the current version and the component propagation path between each vulnerability component.

[0090] Specifically, first load all historical versions of the second SBOM list in chronological order, creating a version timeline. For each vulnerability component, find the matching record in each historical version. Build a version evolution chain table, recording fields: version number, release time, change type (add, upgrade, remove), and dependent component list. Use time series analysis to identify version change patterns: version upgrade frequency, version span, and version rollback. Build a dependency graph in each historical version and use graph comparison algorithms to analyze dependency changes. Identify component propagation chains: starting from leaf nodes (bottom-level dependencies), build propagation paths using depth-first search, and record the introduction time, propagation delay, and impact range of each propagation node. Perform metric calculations on each propagation path: path length (number of propagation levels), propagation time (time difference between the introduction of the first node and the introduction of the last node), and number of affected nodes (number of components on the path). Store the version evolution path and component propagation path as a directed acyclic graph, with node attributes including: component information, version information, timestamp, and propagation indicators Step 204: Perform path fitting on the version evolution path and component propagation path to obtain the risk propagation path.

[0091] Specifically, first create a path fitting processor, load the version evolution path and component propagation path graph data. Execute the path merging algorithm: identify common nodes (components that appear in both paths) as anchor points for path fitting. Build a space-time propagation matrix: rows represent the time dimension (version evolution), columns represent the spatial dimension (dependency propagation), and matrix elements represent the risk state of components at specific space-time locations. Apply path optimization algorithm: remove redundant paths (there are shorter paths connecting the same endpoints), merge similar paths (paths with a space-time distance less than a threshold). Calculate path weights: consider risk level (first / second / third risk), propagation distance (path length), time span (version evolution period), and impact range (number of affected components). Generate a normalized risk propagation index for path sorting and risk rating. Build the final risk propagation path graph: nodes represent component version states, edges represent risk propagation relationships, and edge weights represent propagation strength. Add path attributes: risk level, propagation direction, propagation speed, and key nodes. Generate JSON-formatted path data containing complete node information, edge information, and path attributes for visualization. Implement path query interface: support filtering paths by component, version, time range, risk level, and other conditions.

[0092] Step 205: In the version evolution path, mark the release time nodes of each historical version and the current version on the time axis, draw the propagation connection lines between each vulnerability component in different versions, and mark the version number changes and vulnerability disclosure time points on the propagation connection lines.

[0093] Specifically, first create a time axis data structure using JavaScript's Date object to store time information. Sort all versions by release time and calculate the time span to determine the time axis range. Use D3.js's time scale to map time values to view coordinates. Draw version nodes on the horizontal time axis: use circles to represent version release times, node sizes are proportional to version change scales, and node colors represent version types (historical versions / current versions). For each vulnerability component, collect its information in each version: version number, release time, and change type. Use a Bezier curve to draw the propagation connection lines between versions, and the curve thickness represents the change importance. Add version labels on the connection lines to display version number changes: start version -> target version. Draw the vulnerability disclosure time points as lines perpendicular to the time axis using prominent colors (such as red dashed lines). Add interactive functions: mouseover displays detailed time information, and clicking on a node expands version details. Implement time axis scaling and panning to support time range filtering. Generate SVG-formatted visualization images to ensure image clarity and scalability.

[0094] In one possible implementation, the release dates of each historical version and the current version are marked on a timeline in the version evolution path. A propagation line is drawn between different versions for each vulnerable component, and the changes in component version numbers and vulnerability disclosure dates are marked on the propagation line. Specifically, steps 2051-2054 are included, as follows: Step 2051: Mark the release time nodes of each historical version and the current version in chronological order on the preset timeline; for each vulnerable component, create a component start mark and a component end mark at the corresponding release time node position.

[0095] Specifically, first, create a timeline plotter and define the timeline range: use the earliest version release time as the start time and the current version release time as the end time. Use a linear scale to map time to pixel coordinates: the start time is mapped to x=100 pixels, and the end time is mapped to x=1100 pixels. Set the timeline style: the axis uses a 2-pixel wide solid line, and the ticks use 1-pixel wide vertical lines. Draw the time ticks: the main ticks represent the year (10 pixels high), the secondary ticks represent the month (5 pixels high), and the tick labels use a 10-pixel font. For each version release time node, calculate its x-coordinate position on the timeline and draw version node markers: circles represent historical versions (radius 5 pixels), and diamonds represent the current version (side length 10 pixels). Add version labels: display the version number and release date 10 pixels above the node. Traverse all vulnerability components and find the first version and current version of each component. Create component markers at the corresponding version node positions: the start marker uses a solid circle (color corresponding to the risk type), and the end marker uses a hollow circle. Add hover tooltips to each component tag, displaying complete component information: component name, version number, import date, and risk type. Implement interactive functionality for the tags: clicking the tag highlights the relevant propagation path.

[0096] Step 2052: Draw a propagation line between the component start mark and the component end mark; mark the component version number of the vulnerable component in the earliest version at the start position of the propagation line; mark the component version number of the vulnerable component in the current version at the end position of the propagation line.

[0097] Specifically, first, create a connection drawer, draw the propagation connection line using a cubic Bezier curve: calculate the control point position according to the start and end point coordinates to ensure smooth and beautiful curves. Set the connection line style: 2-pixel width, use a semi-transparent color (transparency 0.6), and the color corresponds to the component risk type. Draw the version number label at the start of the connection line: get the version number of the component in the earliest version, create a text label 5 pixels above the start point, and use a 12-pixel size font. Draw the version number label at the end of the connection line: get the version number of the component in the current version, create a text label 5 pixels above the end point. Calculate the number of version number changes and add intermediate version markers evenly on the connection line: small dots represent version update nodes, and the marker size is proportional to the version change scale. Add connection line animation effects: use a dashed line animation to represent the version evolution direction, with an animation period of 3 seconds. Implement connection line interaction: mouseover displays version change details, and clicking the connection line triggers the version comparison function. When multiple connection lines overlap, adjust the control points to display the connection lines staggered. Add arrow markers to the connection lines to indicate the direction of version evolution. Implement the connection line filtering function: filter and display according to time range, version span, and risk type.

[0098] Step 2053: If the vulnerability component has a version number change in adjacent historical versions, mark the changed component version number at the corresponding release time node position.

[0099] Specifically, first, create a version change detector, and traverse the historical version sequence of each vulnerability component. For each version, get its release time and component version number. Compare the version numbers of adjacent versions using a semantic version comparison algorithm: decompose the version number into major version number, minor version number, and revision number. When a version number change is found, locate the corresponding release time node on the timeline: calculate the x-coordinate using the time mapping function. Create a version label: add a text label 15 pixels above the node position to display the new version number. Set the label style: use a 12-pixel font, and the color is the same as the propagation connection line. Analyze the version change type: use bold font for major version updates, normal font for minor version updates, and thin font for revision version updates. When version label positions overlap, adjust the label positions: calculate the label spacing and display vertically staggered. Add a version change prompt: mouseover displays version change details, including change content and impact range. Implement version filtering: support filtering and displaying according to version number rules, such as displaying only major version updates.

[0100] Step 2054: Mark the vulnerability disclosure time point of the vulnerability component on the propagation connection line, and distinguish the vulnerability disclosure time point from the version release time node using a preset identifier.

[0101] Specifically, first create a time point annotation processor, load the vulnerability disclosure time data. For each vulnerability component, get its associated vulnerability information and disclosure time. Position the vulnerability disclosure time point on the timeline: calculate the x-coordinate using the time mapping function. Create a vulnerability identifier: use a red triangle symbol (base 8 pixels, height 10 pixels), with the vertex pointing upwards. Place the vulnerability identifier 5 pixels above the propagation link. Set the version release node identifier: use a blue circular symbol (diameter 6 pixels). Add an identifier legend: display the identifier type description below the timeline. Add information tips for vulnerability identifiers: mouseover displays vulnerability details, including CVE number, CVSS score, impact range. Implement time point correlation analysis: calculate the interval between vulnerability disclosure time and the latest version release time, evaluate vulnerability response time. Adjust the identifier position to avoid overlapping when multiple vulnerability time points are close: calculate the minimum distance and display vertically. Provide time point filtering function: support filtering by vulnerability type, severity. Implement time point interaction: click on the identifier to trigger the display of related vulnerability information, support jumping to the vulnerability detail page.

[0102] Step 206: In the component propagation path, determine the dependent propagation chain between each vulnerability component according to the dependency graph, and mark the corresponding color identifier for the first risk identifier, the second risk identifier and the third risk identifier to display the corresponding propagation path.

[0103] Specifically, first extract complete dependency information from the dependency graph. Use the depth-first search algorithm to build the dependent propagation chain: start from each vulnerability component, traverse along the dependency edge, and record all components on the path. Create a propagation path renderer, define visual properties: node shape (circle for direct dependency, diamond for transitive dependency), node size (proportional to impact range), edge style (solid line for direct dependency, dashed line for transitive dependency). Set the color mapping of the risk identifier: the first risk identifier uses red (#FF0000), the second risk identifier uses yellow (#FFFF00), and the third risk identifier uses orange (#FFA500). For each propagation chain node, get its risk identifier and apply the corresponding color identifier. Use force-directed graph layout algorithms (such as D3.js's force-directed layout) to calculate node positions to ensure visual clarity. Draw the propagation path: connect adjacent nodes on the dependency chain, with arrows pointing to the dependent components. Add labels on the path: component name, version number, risk type. Implement path animation: use gradient colors to show the risk propagation process. Add interactive controls: risk type filter, path highlight, node search. Generate a legend: risk type color meaning, node shape meaning, edge type meaning. Export the visualization result as an interactive Web component, supporting zoom, drag, click to expand, etc.

[0104] Step 207: convert the risk propagation path into visual graphic data, and send the visual graphic data to a visualization page for display.

[0105] Specifically, first, a data converter is constructed to process the original data of the risk propagation path. The node data is converted: node attributes (component identifier, version number, risk identifier, influence range) are extracted, visual attributes (node size, color, shape, label) are added, and node positions are calculated (using a force-directed layout algorithm). The node data contains necessary fields: a unique identifier (generated using the component name and version number), a risk type (1 / 2 / 3 corresponding to three risk identifiers), a node label (displaying the component name and version number), a node size (calculated based on the influence range), a node color (red for the first risk, yellow for the second risk, and orange for the third risk), a node shape (a circle for direct dependency and a diamond for transitive dependency), and node coordinates (calculated by the layout algorithm). The edge data is converted: edge attributes (source node, target node, dependency type) are extracted, and visual attributes (edge thickness, color, arrow style, curve type) are added. The edge data contains fields: source node identifier, target node identifier, dependency type (direct / transitive), edge weight (based on dependency importance), edge style (solid line for direct dependency and dashed line for transitive dependency), edge color (gray base color with highlighted selected path), and curve type (smooth curve for improved visual effect). Layout information is added: the canvas size (1200 pixels wide and 800 pixels high), the initial zoom ratio (1.0), the viewport position (displayed in the center), and the legend position (upper left corner) are set. Interaction parameters are set: node dragging, canvas zooming, path highlighting, and other functions are enabled. The converted data is sent to the front end using WebSocket or HTTP POST requests. In the front-end page, the visualization library is initialized, and the chart properties are configured: the force-directed layout is used, node styles and labels are set, edge styles and arrows are configured, and a legend is added. Interaction functions are implemented: clicking a node displays component details, dragging a node adjusts the layout, the scroll wheel zooms the view, and a selected path is highlighted. A data update mechanism is added: data updates pushed by the back end are listened to, and the view is refreshed in real time. Image export is implemented: the current view can be exported as SVG or PNG format. Finally, performance optimization is performed: for large-scale data, batch rendering is used, view cropping is implemented to only render the visible area, and node aggregation is used to reduce rendering pressure.

[0106] Next, a software supply chain security risk analysis and detection system in the embodiment of the application is described from the perspective of hardware processing. Please refer to Figure 3 , which is a structural schematic diagram of the software supply chain security risk analysis and detection system in the embodiment of the application.

[0107] It should be noted that, Figure 3 The structure of the software supply chain security risk analysis and detection system shown is only one example and should not bring any limitation to the function and use range of the embodiments of the present application.

[0108] As shown in Figure 3 A software supply chain security risk analysis and detection system includes a central processing unit (CPU) 301 which can perform various appropriate actions and processes, such as executing the method in the above embodiments, according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage section 308 into a random access memory (RAM) 303. In the RAM 303, various programs and data required for system operation are also stored. The CPU 301, the ROM 302, and the RAM 303 are connected to each other through a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0109] The following components are connected to the I / O interface 305: an input section 306 including an audio input device, a push button switch, and the like; an output section 307 including a liquid crystal display (LCD), an audio output device, an indicator lamp, and the like; a storage section 308 including a hard disk and the like; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, a modem, and the like. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the I / O interface 305 as necessary. A removable medium 311 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like is attached to the drive 310 as necessary so that a computer program read therefrom is installed in the storage section 308 as necessary.

[0110] In particular, according to the embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments of the present application include a computer program product including a computer program carried on a computer-readable medium, the computer program containing a computer program for executing the method shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication section 309 and / or installed from the removable medium 311. When the computer program is executed by the central processing unit (CPU) 301, various functions defined in the present application are performed.

[0111] Note that specific examples of computer-readable storage media can include but are not limited to an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer-readable storage medium can be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0112] The flow diagrams and the block diagrams in the drawings are illustrations of possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. It will be understood that each block of the flow diagrams and the block diagrams, and combinations of blocks in the flow diagrams and the block diagrams, can be implemented by a computer program instruction or code. Such instructions can be generated by a computer program product that causes a processor to perform functions described in the embodiments of the present disclosure. Also, it will be understood that each block of the flow diagrams and the block diagrams, and combinations of blocks in the flow diagrams and the block diagrams, can be implemented by special purpose hardware-based computer systems which perform the specified functions or operations.

[0113] Specifically, the software supply chain security risk analysis and detection system of the embodiment includes a processor and a memory, and the memory stores a computer program. When the computer program is executed by the processor, the software supply chain security risk analysis and detection method provided in the above embodiment is implemented.

[0114] As another aspect, the present disclosure also provides a computer-readable storage medium. The storage medium can be included in the software supply chain security risk analysis and detection system described in the above embodiment, or can exist independently without being assembled into the software supply chain security risk analysis and detection system. The storage medium carries one or more computer programs. When the one or more computer programs are executed by a processor of the software supply chain security risk analysis and detection system, the software supply chain security risk analysis and detection system implements the software supply chain security risk analysis and detection method based on Internet of Things data encryption transmission provided in the above embodiment.< / retaineddependency> < / newdependency> < / string>

Claims

1. A software supply chain security risk analysis detection method, characterized in that, The method comprises: acquiring artifact library information of a software project to be detected; extracting a first dependency configuration file of a current version software and second dependency configuration files of at least two historical version softwares from the artifact library information, and respectively parsing the first dependency configuration file and the second dependency configuration files to generate a first SBOM list of the current version and second SBOM lists of the historical versions; comparing the first SBOM list and the second SBOM lists to determine newly added dependency components and continuously retained dependency components in the current version; matching each component in the first SBOM list with a vulnerability intelligence library to determine vulnerability components and extract corresponding vulnerability disclosure times; for the vulnerability components belonging to the newly added dependency components, acquiring a release time of the current version as a component introduction time, when the component introduction time is later than the vulnerability disclosure time, determining that the vulnerability component is a known vulnerability introduction and giving a first risk identification, when the component introduction time is earlier than or equal to the vulnerability disclosure time, determining that the vulnerability component is an unknown vulnerability introduction and giving a second risk identification; for the vulnerability components belonging to the continuously retained dependency components, acquiring a retention duration of the vulnerability component in the historical version, when the retention duration exceeds a preset threshold, giving a third risk identification, when the retention duration does not exceed the preset threshold, giving the second risk identification; generating a risk propagation path based on the risk identifications corresponding to each of the vulnerability components and dependency relationships between the vulnerability components, and sending the risk propagation path to a visualization page.

2. The method of claim 1, wherein, The extracting a first dependency configuration file of a current version software and second dependency configuration files of at least two historical version softwares from the artifact library information, and respectively parsing the first dependency configuration file and the second dependency configuration files to generate a first SBOM list of the current version and second SBOM lists of the historical versions comprises: extracting a version list of the software project to be detected from the artifact library information; selecting a latest version as the current version and selecting a preset number of versions in a reverse chronological order as the historical versions from the version list; respectively downloading software packages of the current version and the historical versions; extracting dependency configuration files from each of the software packages, marking the dependency configuration file of the current version as a first dependency configuration file, and marking the dependency configuration files of the historical versions as second dependency configuration files; parsing component names, component version numbers and inter-component dependency relationships in the first dependency configuration file to generate a first SBOM list; parsing extracted component names, component version numbers and inter-component dependency relationships in each of the second dependency configuration files to respectively generate second SBOM lists of the corresponding historical versions.

3. The method of claim 1, wherein, The comparing the first SBOM list and the second SBOM lists to determine newly added dependency components and continuously retained dependency components in the current version comprises: extracting component names of all components in the first SBOM list to construct a current version component set; extracting component names of all components in each of the second SBOM lists, and respectively constructing a historical version component set; performing a difference set operation on the current version component set and the latest historical version component set to determine components existing only in the current version, and identifying the components existing only in the current version as newly added dependent components; performing an intersection operation on the current version component set and all historical version component sets to obtain components existing in the current version and all historical versions, and identifying the components existing in the current version and all historical versions as continuously retained dependent components.

4. The method of claim 1, wherein, The matching each component in the first SBOM list with the vulnerability intelligence library, determining a vulnerability component and extracting a corresponding vulnerability disclosure time, comprises: traversing each component in the first SBOM list to obtain a component name and a component version number of the component; querying a vulnerability record matched with the component name in the vulnerability intelligence library; extracting an affected version range from the vulnerability record to determine whether the component version number falls within the affected version range; if the component version number falls within the affected version range, determining the component corresponding to the component version number as a vulnerability component, and extracting a vulnerability disclosure time corresponding to the vulnerability component from the vulnerability record.

5. The method of claim 1, wherein, The generating a risk propagation path based on the risk identifier corresponding to each vulnerability component and the dependency relationship between each vulnerability component, and sending the risk propagation path to a visualization page, comprises: extracting dependency relationship information between each vulnerability component from the first SBOM list; constructing a dependency relationship graph according to the dependency relationship information, the dependency relationship graph comprising a component node and a dependency edge, the component node representing a vulnerability component, and the dependency edge representing a dependency relationship between components; traversing each component node in the dependency relationship graph to label a risk identifier of a corresponding vulnerability component on the component node; based on the dependency relationship graph and the second SBOM list, tracing a version evolution path of each vulnerability component from an earliest appearing historical version to a current version and a component propagation path between each vulnerability component; performing path fitting on the version evolution path and the component propagation path to obtain a risk propagation path; in the version evolution path, labeling a release time node of each historical version and the current version on a time axis, drawing a propagation connection line between each vulnerability component in different versions, and labeling a change of a component version number and a vulnerability disclosure time point on the propagation connection line; in the component propagation path, determining a dependency propagation chain between each vulnerability component according to the dependency relationship graph, and labeling a corresponding color identifier of the first risk identifier, the second risk identifier and the third risk identifier to display a corresponding propagation path; converting the risk propagation path into visual graphics data, and sending the visual graphics data to a visualization page for display.

6. The method of claim 5, wherein, The release time nodes of each historical version and the current version are marked in the version evolution path, the propagation connection lines of each vulnerability component between different versions are drawn, and the change of the component version number and the vulnerability disclosure time point on the propagation connection line are marked, including: Marking the release time nodes of each historical version and the current version in chronological order on a preset time axis; For each vulnerability component, creating a component start marker and a component end marker at the corresponding release time node position; Drawing a propagation connection line between the component start marker and the component end marker; Marking the component version number of the vulnerability component in the earliest appearing version at the start position of the propagation connection line; Marking the component version number of the vulnerability component in the current version at the end position of the propagation connection line; If the vulnerability component has a version number change in adjacent historical versions, marking the changed component version number at the corresponding release time node position; Marking the vulnerability disclosure time point of the vulnerability component on the propagation connection line, and distinguishing the vulnerability disclosure time point from the version release time node with a preset identifier.

7. The method of claim 1, wherein, After generating the risk propagation path based on the corresponding risk identifier of each vulnerability component and the dependency relationship between each vulnerability component, and sending the risk propagation path to the visualization page, the method further includes: Receiving a vulnerability component with a first risk identifier selected by a user in the visualization page, and obtaining a target component name of the selected vulnerability component; Querying a target component matching the target component name in a second SBOM list of the latest historical version; If a matching target component is queried, extracting the component version number of the target component as a rollback target version number, and generating a rollback repair suggestion, the rollback repair suggestion including the component version number of the selected vulnerability component in the current version and the rollback target version number; If no matching target component is queried, generating a repair suggestion for removing the selected vulnerability component; Superimposing the repair suggestion or the rollback repair suggestion into the risk propagation path, and marking the target version position to be executed for repair operation through a preset indication arrow.

8. A software supply chain security risk analysis detection system characterized by, The software supply chain security risk analysis and detection system includes one or more processors and a memory; the memory is coupled with the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors invoke the computer instructions to make the software supply chain security risk analysis and detection system execute the method in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions run on the software supply chain security risk analysis and detection system, the software supply chain security risk analysis and detection system executes the method in any one of claims 1-7.

10. A computer program product, characterised in that, When the computer program product runs on the software supply chain security risk analysis and detection system, the software supply chain security risk analysis and detection system executes the method in any one of claims 1-7.

Images