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

Abstract

The invention discloses a software supply chain risk detection method and system, a medium and a product, and relates to the technical field of risk detection. The method comprises the following steps: acquiring multi-source heterogeneous data of a software supply chain, and constructing the multi-source heterogeneous data into a multi-dimensional software supply chain relation graph; querying nodes and attributes associated with the target asset node based on the multi-dimensional software supply chain relation graph to extract risk features; obtaining an initial risk score of a vulnerability node associated with the target asset node from the public vulnerability library, calculating the shortest propagation path depth between the vulnerability node and the target asset node by using a graph traversal algorithm, and adjusting the initial risk score in combination with code reachability analysis to obtain a corrected technical risk feature; and calculating a comprehensive risk score based on the corrected technical risk characteristics, and executing automatic safety examination and approval, interception or manual reexamination operation. By implementing the technical scheme, the software supply chain risk can be comprehensively and accurately detected.

Description

Technical Field

[0001] This application relates to the field of risk detection, and in particular to a method, system, medium, and product for risk detection in the software supply chain. Background Technology

[0002] In today's digital age, software is increasingly used across various fields, and the software supply chain is becoming increasingly complex. The software supply chain encompasses the entire process from software development and distribution to usage, involving numerous participants and vast amounts of data. As the scale of the software supply chain continues to expand, its security issues are becoming increasingly prominent.

[0003] In the field of software supply chain risk detection, a common approach in existing technologies is to rely solely on data from public vulnerability databases. By comparing vulnerability information in the software with known vulnerabilities in public vulnerability databases, the risk of the software is assessed. This approach mainly focuses on whether vulnerabilities exist and judges the degree of risk based on the risk score given by the public vulnerability database. Another approach is to analyze based on a single type of data, such as analyzing only software asset data or personnel data, to detect potential risks in the software supply chain from a single dimension.

[0004] However, relying solely on data from public vulnerability databases fails to consider the propagation paths and actual impact of vulnerabilities within the software supply chain, leading to inaccurate risk assessments. Analyzing data based on only a single type cannot fully reflect the true risk situation in the software supply chain, as risks in the software supply chain are often the result of multiple factors working together. Summary of the Invention

[0005] This application provides a method, system, medium, and product for detecting software supply chain risks, which can comprehensively and accurately detect software supply chain risks.

[0006] The first aspect of this application provides a method for software supply chain risk detection, the method comprising the following steps: Acquire multi-source heterogeneous data from the software supply chain and construct a multi-dimensional software supply chain relationship graph from the multi-source heterogeneous data. The multi-source heterogeneous data includes software asset data, vulnerability data, personnel data, and process data. The multi-dimensional software supply chain relationship graph includes asset nodes, vulnerability nodes, personnel nodes, and process nodes. The nodes are connected by semantically related edges. The related edges include dependency edges between asset nodes to represent dependency relationships, submission edges between personnel nodes and asset nodes to represent code submission relationships, and construction edges between process nodes and asset nodes to represent construction relationships. Based on the multidimensional software supply chain relationship graph, the nodes and attributes associated with the target asset node are queried to extract risk features. The risk features include the technical risk features of the vulnerability nodes associated with the target asset node, the compliance risk features of the license nodes associated with the target asset node, and the supply chain risk features of the personnel nodes or upstream supplier nodes associated with the target asset node. The initial risk scores of the vulnerability nodes associated with the target asset node are obtained from the public vulnerability database. The shortest propagation path depth between the vulnerability node and the target asset node is calculated using a graph traversal algorithm. Combined with code reachability analysis, the initial risk scores are adjusted to obtain the corrected technical risk characteristics. A comprehensive risk score is obtained by weighting the compliance risk characteristics, supply chain risk characteristics, and modified technology risk characteristics using a preset weighted model. The comprehensive risk score then drives the review decision engine to perform automated security approval, interception, or manual review operations.

[0007] By employing the aforementioned technical solution and constructing a multi-dimensional relationship graph integrating assets, vulnerabilities, personnel, and processes, the limitations of traditional tools' data silos are overcome. This clearly presents the complete correlation path of risks throughout the entire supply chain, enabling end-to-end tracing from vulnerabilities to their introducers and the construction process. By introducing propagation path depth and code reachability analysis to dual-correct the initial risk score, the system effectively distinguishes between low-risk vulnerabilities that exist but are unreachable and high-risk, exploitable real threats, significantly reducing false alarms and resolving alert fatigue issues. Through weighted integration of risk characteristics from three dimensions—technology, compliance, and supply chain—a comprehensive and quantitative integrated risk score is derived, providing an objective and unified decision-making basis for security approvals and improving the scientific nature and automation level of risk management. Linking the integrated risk score with the review decision engine automatically triggers approval, review, or interception actions based on risk levels, achieving an automated closed loop from risk analysis to response, significantly improving the efficiency and response speed of security operations.

[0008] Optionally, the step of calculating the shortest propagation path depth between the vulnerable node and the target asset node using a graph traversal algorithm includes: Starting from the target asset node, traverse the multidimensional software supply chain relationship graph in the opposite direction of the dependency edge to extract all asset nodes that can reach the starting point, forming a reverse dependency subgraph. On the reverse dependency subgraph, a weighted shortest path search is performed, and the weights of each relation edge on the path are accumulated to determine the shortest propagation path with the smallest accumulated weight from the starting point to the first asset node to which the vulnerability node belongs. The weight value assigned to direct dependency edges is lower than the weight value assigned to indirect dependency edges. The direct dependency edge refers to the edge corresponding to the dependency relationship directly declared by the target asset node, and the indirect dependency edge refers to the edge corresponding to the dependency relationship declared by the dependency item of the target asset node. The cumulative weight value of the shortest propagation path is mapped to the depth of the shortest propagation path through a preset nonlinear mapping function. The nonlinear mapping function makes the propagation path depth increase in a decreasing trend as the cumulative weight increases.

[0009] By employing the above technical solution, and constructing a reverse dependency subgraph and calculating the weighted shortest path, the core propagation chain from the vulnerability to the target application can be accurately identified. This transforms the ambiguous dependency hierarchy into a quantifiable propagation path depth, providing an objective metric for risk analysis. By assigning different weights to direct and indirect dependencies (with lower weights for direct dependencies) and accumulating path weights during the search, the algorithm can identify paths with long topological distances but strong actual dependencies, thus more accurately assessing the actual impact of the vulnerability. Utilizing a non-linear mapping function, the propagation path depth decreases as the accumulated weight increases. This mechanism automatically attenuates the risk of deeply buried vulnerabilities with light actual dependency chain weights, effectively avoiding over-alarming of deep indirect dependencies.

[0010] Optionally, the initial risk score is adjusted based on code accessibility analysis to obtain revised technical risk characteristics, specifically including: Based on the code structure information obtained from static analysis, within the asset node range determined by the shortest propagation path, the potential call relationships between the target application execution start point located at the beginning of the shortest propagation path and the vulnerable code point located at the end of the shortest propagation path are analyzed to construct potential call chains across component boundaries. Based on the prior probability of the call type, an initial conditional execution probability is assigned to each call edge in the link. The initial conditional execution probability is used as the edge weight. Monte Carlo simulation is performed on the potential call link to calculate the path connectivity success rate from the execution start point of the target application to the vulnerable code point. The path connectivity success rate is quantified into a probabilistic reachability factor. Based on the contextual position of the vulnerability code point within its component, the probabilistic reachability factor is weighted and adjusted to obtain a final reachability correction factor. Based on the final reachability correction factor and the shortest propagation path depth, the initial risk score is comprehensively corrected to calculate the corrected technical risk characteristics.

[0011] By employing the aforementioned technical solution, and constructing potential cross-component call chains and performing reachability analysis, the dimension of vulnerability risk analysis is upgraded from whether a vulnerability exists within a component to whether the vulnerable code might be triggered at runtime, significantly improving the practical relevance of risk assessment. Monte Carlo simulation is used, with the conditional execution probability of the call edge as weight, to statistically analyze the path connectivity success rate, transforming ambiguous possible calls into quantifiable probabilistic reachability factors, providing an objective and accurate data foundation for risk correction. Based on the probabilistic simulation, further weighted adjustments are made according to the specific location of the vulnerable code within the component (such as the entry point or internal function), making the final reachability correction factor closer to the real-world code execution scenario, avoiding the biases that may arise from simple path analysis. By combining the reachability correction factor with the propagation path depth, the initial, context-detached general risk score is comprehensively corrected, ultimately outputting a corrected technical risk characteristic closely integrated with the application's own characteristics and code structure, thereby accurately identifying truly high-risk vulnerabilities that require priority handling.

[0012] Optionally, the step of weighting and adjusting the probabilistic reachability factor based on the contextual position of the vulnerable code point within its component to obtain the final reachability correction factor specifically includes: From the multidimensional software supply chain relationship graph, extract the context attributes associated with the asset node to which the vulnerability code point belongs. The context attributes include the location type of the vulnerability code point in the component, the calling mode of the component in the project, and the life cycle state of the component. Based on the aforementioned context attributes, a context influence factor is calculated using a preset set of context influence rules. The final reachability correction factor is generated by combining the probabilistic reachability factor P_reachable with the contextual influence factor C using the following formula: F_final = P_reachable * (1 + k * C), where F_final represents the final reachability correction factor, P_reachable represents the probabilistic reachability factor, C represents the context influence factor, and k represents the configuration coefficient used to control the strength of context influence.

[0013] By adopting the above technical solution and introducing attributes such as the "lifecycle state" (e.g., active, deprecated) of components, the actual development and operation status is incorporated into the risk model. This allows the assessment results to reflect not only technical accessibility but also the actual maintenance status and potential risks of the component within the project. By analyzing the location type of vulnerable code (e.g., entry function, internal method) and the component's calling pattern (e.g., high-frequency calls, peripheral functions), vulnerabilities with the same accessibility probability but different actual exposure levels can be distinguished, prioritizing the marking of high-value targets that are more likely to be directly triggered. Through a pre-defined set of contextual impact rules and configurable impact strength coefficients, the risk assessment strategy can be flexibly and finely adjusted according to the security preferences of different organizations or the risk tolerance of different business scenarios, enhancing the applicability and operability of the method.

[0014] Optionally, the step of comprehensively correcting the initial risk score based on the final reachability correction factor and the shortest propagation path depth to calculate the corrected technical risk characteristics specifically includes: The depth attenuation coefficient is obtained using the following formula: F_depth = β * exp(-γ * L), where F_depth represents the depth attenuation coefficient, L represents the shortest propagation path depth, and β and γ are constants configured based on the supply chain topology complexity. The comprehensive correction factor is obtained using the following formula: F_context = 1 - (1 - F_final) * (1 - F_depth), where F_context represents the comprehensive correction factor and F_final represents the final reachability correction factor; The initial risk score is multiplied by the comprehensive correction factor to obtain the corrected technical risk score, and the corrected technical risk score is output as the corrected technical risk feature.

[0015] By employing the above technical solution, the propagation path depth is mapped to a depth decay coefficient in an exponential decay form using the formula F_depth=β*exp(-γ*L). This scientifically reflects the objective law that the actual impact of a vulnerability naturally diminishes as the dependency level deepens during its propagation within the supply chain. The formula F_context=1-(1-F_final)*(1-F_depth) is used to fuse the correction factors of the two orthogonal dimensions of code reachability and propagation depth in the compensation model logic. This ensures that low risk in either dimension is fully reflected, avoiding insufficient correction that might result from simple weighting. By multiplying the initial risk score, which is detached from context, by the comprehensive correction factor, the final corrected technical risk characteristic is no longer a general score, but a highly customized risk assessment result closely integrated with the specific application's supply chain topology and code call context.

[0016] Optionally, the method further includes: Using the vulnerability node as the risk source and the corrected technical risk score corresponding to the vulnerability node as the initial risk value, a preset independent cascade model is executed on the reverse dependency subgraph to simulate risk propagation. The probability of risk propagating along the dependency edge is determined by the type weight of the dependency edge and the probabilistic reachability factor. Collect all asset nodes whose risk values ​​exceed a preset first threshold, form an affected asset set, and calculate the overall risk exposure index of the affected asset set; Construct an extended impact subgraph, which includes all first asset nodes in the affected asset set, as well as all personnel nodes and process nodes directly connected to the first asset nodes through the submission edge or the construction edge; The extended influence subgraph is input into a preset graph neural network model to obtain the target vector representation of all nodes in the extended influence subgraph; Based on the target vector representation, the cosine similarity between the second asset node in the extended impact subgraph that is not associated with any known vulnerability and the preset high-risk asset node in the affected asset set is calculated. When the cosine similarity is higher than the preset second threshold, the second asset node is assigned a latent risk score. The implicit risk score is fused with the explicit risk score calculated based on known vulnerabilities to dynamically update the overall risk exposure index. When the implicit risk score or the updated overall risk exposure index exceeds a preset third threshold, an investigation of the second asset node or the affected asset set is triggered.

[0017] By employing the aforementioned technical solution, the dynamic propagation process of risk in the supply chain dependency network is simulated through an independent cascade model. This allows for the precise depiction of the potential impact range of individual vulnerabilities and the calculation of the overall risk exposure index, thereby quantifying the scope of risk impact and providing crucial decision-making support for emergency response. By learning the topological and attribute characteristics of the extended impact subgraph through graph neural networks, second asset nodes that are structurally similar to known high-risk nodes but have not yet been compromised can be identified and assigned implicit risk scores, enabling the proactive discovery of unknown threats and potential weaknesses. A comprehensive risk view combining explicit and implicit risks is constructed. By fusing simulated explicit risks with AI-predicted implicit risks, the overall risk exposure index is dynamically updated, ensuring that risk assessment results are no longer limited to known threats but encompass all manifest and potential risks in the current supply chain, providing an unprecedentedly comprehensive perspective.

[0018] Optionally, the step of calculating a comprehensive risk score by weighting the compliance risk characteristics, the supply chain risk characteristics, and the modified technical risk characteristics using a preset weighted model, and then driving the review decision engine to perform automated security approval, interception, or manual review operations based on the comprehensive risk score, specifically includes: The modified technical risk characteristics, compliance risk characteristics, and supply chain risk characteristics are all mapped to a preset scaling range using a min-max standardization method. The mapped modified technical risk characteristics, compliance risk characteristics and supply chain risk characteristics are assigned corresponding weight coefficients, and the specific values ​​of the weight coefficients are dynamically determined by the business type or security strategy to which the target asset node belongs. The comprehensive risk score is calculated using a linear weighted summation formula. The comprehensive risk score is matched with a set of preset decision thresholds. If the comprehensive risk score is lower than the fourth threshold, a security approval action is triggered. If the comprehensive risk score is between the fourth and fifth thresholds, a manual review process is triggered. If the comprehensive risk score is higher than the fifth threshold, an interception and alarm action is triggered.

[0019] By employing the aforementioned technical solution and utilizing a minimum-maximum standardization method, the risk characteristics of technology, compliance, and supply chain—three different natures and scales—are uniformly mapped to a pre-defined scaling range. This solves the problem of directly comparing and integrating multi-source heterogeneous risk data, laying a data foundation for comprehensive decision-making. By dynamically allocating weight coefficients based on the business type or security strategy of the target asset node, the risk assessment strategy is no longer rigid and uniform but can flexibly adapt to the different security requirements of different business lines (such as the core payment system and internal back-end systems), achieving refined and scenario-based risk management. Through a linear weighted summation formula, the risk scores of the three dimensions are integrated into a single, authoritative comprehensive risk score, eliminating the ambiguity or contradictions that may arise from multi-dimensional assessments and providing a clear and unambiguous source of instructions for subsequent automated processing.

[0020] In a second aspect, embodiments of this application provide a computer system including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the steps of the method described in any possible implementation of the first aspect.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the method described in any possible implementation of the first aspect.

[0022] Fourthly, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the method described in any possible implementation of the first aspect.

[0023] It is understood that the computer system provided in the second aspect, the storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the method provided in this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By constructing a unified graph containing multiple semantic relationship edges (dependency, commit, build) from four originally scattered heterogeneous data categories—software assets, vulnerabilities, personnel, and processes—data silos are broken down. This enables the system to answer questions that traditional tools cannot, thereby achieving end-to-end risk tracing. 2. By calculating the shortest propagation path depth and combining it with code reachability analysis, the initial general vulnerability score is revised, shifting the risk assessment standard from whether a component has a vulnerability to whether the vulnerability is actually exploitable in a specific application environment. This directly solves the problem of excessive alerts and high false positives caused by traditional tools ignoring code call context, making the risk assessment results closer to actual threats; 3. By integrating risk characteristics from three dimensions—technology, compliance, and supply chain—through a weighted model, the technical effect is to generate a comprehensive and quantitative integrated risk score. This score is no longer based solely on a technical perspective, but comprehensively considers non-technical factors such as license conflicts and supplier reputation, providing decision-makers with a unified and more authoritative basis for judgment and avoiding decision-making errors caused by one-sided assessments. 4. By linking the comprehensive risk score with the review decision engine and automatically triggering approval, review, or interception actions based on the score threshold, an automated closed loop of the security review process is achieved. This significantly reduces the need for manual intervention, greatly improves the efficiency and response speed of software supply chain security management, and enables large-scale, high-frequency software delivery to be carried out under controlled security conditions. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a method for detecting software supply chain risks in an embodiment of this application; Figure 2 This is a schematic diagram of the architecture of the chain graph detection tool in the embodiments of this application; Figure 3 This is a schematic diagram of the multidimensional software supply chain relationship map in the embodiments of this application; Figure 4 This is a schematic diagram of the weighted model data flow and calculation process in the embodiments of this application; Figure 5 This is a schematic diagram of an exemplary hardware structure of a computer system in an embodiment of this application. Detailed Implementation

[0026] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0028] The following is combined Figure 1 The method of the embodiments of this application will be described below.

[0029] Figure 1 This is a flowchart illustrating a method for software supply chain risk detection in an embodiment of this application. Figure 1 As shown, the method includes the following steps: S101. Obtain multi-source heterogeneous data of the software supply chain and construct a multi-dimensional software supply chain relationship graph from the multi-source heterogeneous data. The multi-source heterogeneous data includes software asset data, vulnerability data, personnel data, and process data. The multi-dimensional software supply chain relationship graph includes asset nodes, vulnerability nodes, personnel nodes, and process nodes. The nodes are connected by semantically related edges. The related edges include dependency edges between asset nodes to represent dependency relationships, submission edges between personnel nodes and asset nodes to represent code submission relationships, and construction edges between process nodes and asset nodes to represent construction relationships. S102. Based on the multidimensional software supply chain relationship graph, query the nodes and attributes associated with the target asset node to extract risk features. The risk features include the technical risk features of the vulnerability nodes associated with the target asset node, the compliance risk features of the license nodes associated with the target asset node, and the supply chain risk features of the personnel nodes or upstream supplier nodes associated with the target asset node. S103. Obtain the initial risk score of the vulnerability node associated with the target asset node from the public vulnerability database, calculate the shortest propagation path depth between the vulnerability node and the target asset node using a graph traversal algorithm, and adjust the initial risk score in combination with code reachability analysis to obtain the corrected technical risk characteristics. S104. A comprehensive risk score is obtained by weighting the compliance risk characteristics, the supply chain risk characteristics, and the modified technical risk characteristics using a preset weighted model, and the review decision engine is driven to perform automated security approval, interception, or manual review operations based on the comprehensive risk score.

[0030] Multi-source heterogeneous data includes software asset data, vulnerability data, personnel data, and process data. Software asset data primarily comes from parsing software bills of materials, such as package.json and pom.xml. This embodiment uses PURL (Package URL) as a globally unique identifier for all asset nodes, ensuring the uniqueness and accuracy of assets. Vulnerability data is obtained by periodically calling the APIs (Application Programming Interfaces) of multiple authoritative vulnerability databases (such as NVD, CNVD, and CNNVD) through a collector, and then integrated, deduplicated, and standardized to form a large and timely updated vulnerability intelligence source. Personnel data comes from code repository commit logs (such as Git records) to identify developers. Process data comes from CI / CD pipeline build logs to record fingerprint information such as build environment and time. Node types include asset nodes, vulnerability nodes, personnel nodes, and process nodes. Technical risk feature extraction: All vulnerability nodes associated with the target asset are queried, and their original attributes, such as Initial Risk Score (CVSS) and description, are extracted. Compliance risk feature extraction: Through graph queries, identify all license nodes associated with the target asset node through connections, and extract the compatibility_risk attribute of these license nodes. Supply chain risk feature extraction: Through graph queries, identify personnel nodes associated with the target asset through connection relationships, and extract their trust_score. Simultaneously, identify upstream supplier organization nodes and extract their risk_rating.

[0031] Calculating the shortest propagation path depth (first level of correction): Starting from the target application node, traverse the graph in the reverse direction of the dependency edges (BFS algorithm) to construct an inverse dependency subgraph. Calculate the shortest path to the vulnerable component node on the inverse dependency subgraph. Different weights can be assigned to direct and indirect dependencies, and a non-linear mapping function is used to map the path length to a depth decay coefficient. This allows for reasonable attenuation of deep, indirect dependency risks. Code reachability analysis (second level of correction): Based on the function call graph generated by static code analysis, analyze whether there is an actual call chain from the target application to the vulnerable function on the component sequence determined by the shortest propagation path. Through Monte Carlo simulation, the success rate of path connectivity is statistically analyzed to obtain a probabilistic reachability factor. Further, a contextual influence factor (based on the location of the vulnerable code, component call pattern, and lifecycle state) is introduced to weight and adjust the probabilistic reachability factor, resulting in a final reachability correction factor. This considers the actual usage scenarios of the code in the project. The two correction factors are merged and multiplied by the initial risk score to obtain the corrected technical risk characteristics. The three indicators—modified technical risk characteristics, compliance risk characteristics, and supply chain risk characteristics—are standardized to a unified range (e.g., 0-10). Then, based on the business type or security strategy of the target asset, dynamic weights are assigned to each indicator, and a comprehensive risk score is obtained through weighted calculation. Operation: The comprehensive risk score is matched against a preset decision threshold, and based on the matching result, a decision is made on whether to proceed with security approval, interception, or manual review.

[0032] Figure 2 This is a schematic diagram of the architecture of the chain graph detection tool in this application embodiment. This application embodiment executes the above method steps using the chain graph detection tool, such as... Figure 2As shown, the chain graph detection tool includes a data acquisition layer, an application service layer, and a core graph engine layer. External intelligence collector: Periodically calls the application programming interface of external vulnerability databases to provide the system with the latest vulnerability intelligence. Internal asset scanner: Scans source code repositories or binary files, parses dependency lists (such as package.json), identifies all software components, and generates a unique PURL identifier for each component. Process / environment log collector: Collects build logs, extracts build environment fingerprints (such as Docker image hashes, toolchain versions), build times, etc., to form process data. Risk visualization dashboard: Provides users with a graphical interface that can display: a panoramic view of the software supply chain, multi-dimensional risk scores and details of assets, and end-to-end tracing paths of vulnerabilities. Review decision / API interface: Provides a programmable interface to empower risk assessment capabilities to other systems (such as CI / CD platforms and operation and maintenance management systems). Automated response module: This is the execution unit of the review decision engine. It automatically executes defined decision actions based on comprehensive risk scores and preset thresholds. Graph Model Converter: Transforms and writes the raw, heterogeneous data reported by the data acquisition layer into a graph database according to predefined node types and relationship edges. Graph Database (SCG): The software supply chain relationship graph, the data hub of the entire system, stores all nodes and relationships created by the graph model converter, providing real-time query and traversal capabilities for upper-level analysis. Deep Relationship Analysis Engine: Calls the graph database, executes graph traversal algorithms to calculate the shortest propagation path depth; utilizes call graph information obtained from static analysis to perform code reachability analysis (such as Monte Carlo simulation) on the graph. Risk Quantification and Review Module: Queries and extracts compliance risk features and supply chain risk features from the graph database; calculates a comprehensive risk score.

[0033] Figure 3 This is a schematic diagram of the multidimensional software supply chain relationship graph in the embodiments of this application, such as... Figure 3As shown, the multidimensional software supply chain relationship graph includes multiple nodes and multiple relationship edges. Asset (Software Asset Node): This is the target being monitored, typically an application or a core software component; in this example, it's an application version 2.1.0. Component (Component Node): This is a third-party library or component that the target software asset depends on; in this example, it's log4j library version 1.2.3. Vulnerability (Vulnerability Node): Represents a known security vulnerability; in this example, it's the Log4Shell vulnerability (CVE-2021-44228). Person (Personnel Node): Represents a software developer or contributor; in this example, it's a developer named Alice. Process (Build Process Node): Represents a software build process, recording the pipeline ID (build-567) and status (Success) of this build. License (License Node): Represents the open-source license followed by the software component; in this example, it's the low-risk Apache-2.0 license. DEPENDS_ON (Dependency Edge): Connects Asset and Component, indicating that "the software asset depends on the log4j component." HAS_VULNERABILITY (Vulnerability Exists): Connects Component and Vulnerability, indicating that "the log4j component has a CVE-2021-44228 vulnerability." COMMITTED (Committed Edge): Connects Person and Asset, indicating that "developer Alice committed code to this software asset." This is the core of this invention for personnel tracing; when a high-risk vulnerability is found in a component, the system can quickly locate the person responsible for potentially introducing the component by following this edge. TRIGGERED_BY (Triggered by...): Connects Process and Person, indicating that "this build was triggered by Alice." BUILT (Build Edge): Connects Process and Asset, indicating that "this version of the software asset was generated by the build-567 build process." This is the core for implementing process auditing and environment fingerprint verification; if problems are subsequently found in this version of the software, the specific build environment can be traced for reproduction and investigation. USES (Usage Edge): Connects Component and License, indicating that "the log4j component uses the Apache-2.0 license." This edge is used for compliance risk feature extraction; the system can traverse it to check for license conflict risks.

[0034] Optionally, the step of calculating the shortest propagation path depth between the vulnerable node and the target asset node using a graph traversal algorithm includes: Starting from the target asset node, traverse the multidimensional software supply chain relationship graph in the opposite direction of the dependency edge to extract all asset nodes that can reach the starting point, forming a reverse dependency subgraph. On the reverse dependency subgraph, a weighted shortest path search is performed, and the weights of each relation edge on the path are accumulated to determine the shortest propagation path with the smallest accumulated weight from the starting point to the first asset node to which the vulnerability node belongs. The weight value assigned to direct dependency edges is lower than the weight value assigned to indirect dependency edges. The direct dependency edge refers to the edge corresponding to the dependency relationship directly declared by the target asset node, and the indirect dependency edge refers to the edge corresponding to the dependency relationship declared by the dependency item of the target asset node. The cumulative weight value of the shortest propagation path is mapped to the depth of the shortest propagation path through a preset nonlinear mapping function. The nonlinear mapping function makes the propagation path depth increase in a decreasing trend as the cumulative weight increases.

[0035] Starting with the target asset node to be evaluated (e.g., an application named Frontend-App), traverse the global graph backwards along the dependency edges (typically using Breadth-First Search (BFS) or a similar algorithm). Identify all components (directly or indirectly) that Frontend-App depends on, forming a reverse dependency tree, or reverse dependency subgraph, with Frontend-App as the root node. Within this subgraph, vulnerable component nodes (i.e., the first asset node, such as a vulnerable utils-library) can be found. Direct dependency edges: These are edges corresponding to dependencies directly declared by the target asset node in its dependency declaration file (e.g., package.json), such as Frontend-App → react-library. They are assigned lower weights, e.g., a weight of 1. Direct dependencies typically imply tighter coupling and a higher likelihood of being called, hence the low weight. Indirect dependency edges: These are edges corresponding to the declared dependencies of the target asset node. For example, react-library→utils-library (while Frontend-App directly depends on react-library). These edges are assigned higher weights, such as 3. Indirect dependencies are further apart, looserly coupled, and have a relatively lower probability of being actually called, hence the higher weight. On the inverse dependency subgraph, Dijkstra's algorithm is used to find the path with the minimum cumulative weight from the starting point (Frontend-App) to the vulnerability node (utils-library). Cumulative weight = the sum of the weights of all dependency edges on the path. For example, suppose there are two paths from Frontend-App to the vulnerability component utils-library: Path A (direct + indirect): Frontend-App -- (weight 1, direct) → A -- (weight 3, indirect) → utils-library. Cumulative weight = 1 + 3 = 4. Path B (fully indirect): Frontend-App -- (weight 3, indirect) → B -- (weight 3, indirect) → C -- (weight 3, indirect) → utils-library. Cumulative weight = 3 + 3 + 3 = 9. The algorithm selects path A with a smaller cumulative weight as the shortest propagation path because it represents a path with stronger overall dependency strength. Non-linear mapping function: A function such as L = a / log(b + W) is used (where W is the cumulative weight, L is the shortest propagation path depth, and a and b are adjustable parameters). This function is designed so that the propagation path depth L increases in a decreasing trend with the increase of the cumulative weight W. This means that the larger W is, the slower the growth rate of L, and it may even tend to an upper limit or start to decrease. The final L is not a simple hop count, but a comprehensive depth index that integrates topological distance and dependency strength.This L value will be used as a key factor in the subsequent risk correction formula to reduce the initial risk score more realistically. It ensures that even if a vulnerability is close in hop count, its final corrected risk will be significantly reduced if its path is full of high-weight indirect dependencies.

[0036] Optionally, the initial risk score is adjusted based on code accessibility analysis to obtain revised technical risk characteristics, specifically including: Based on the code structure information obtained from static analysis, within the asset node range determined by the shortest propagation path, the potential call relationships between the target application execution start point located at the beginning of the shortest propagation path and the vulnerable code point located at the end of the shortest propagation path are analyzed to construct potential call chains across component boundaries. Based on the prior probability of the call type, an initial conditional execution probability is assigned to each call edge in the link. The initial conditional execution probability is used as the edge weight. Monte Carlo simulation is performed on the potential call link to calculate the path connectivity success rate from the execution start point of the target application to the vulnerable code point. The path connectivity success rate is quantified into a probabilistic reachability factor. Based on the contextual position of the vulnerability code point within its component, the probabilistic reachability factor is weighted and adjusted to obtain a final reachability correction factor. Based on the final reachability correction factor and the shortest propagation path depth, the initial risk score is comprehensively corrected to calculate the corrected technical risk characteristics.

[0037] Based on the function call graph generated after pre-analyzing the codebase using static code analysis tools (such as Soot and CodeQL), this graph describes the call relationships between functions and methods, limiting the analysis scope to the sequence of asset nodes determined by the shortest propagation path. For example, if the path is App→Lib-A→Vuln-Lib, the analysis scope is limited to these three components. Start point: The execution point of the target application at the beginning of the propagation path, usually the program's main entry function (such as the main method) or an API interface providing services externally. End point: The vulnerable code point at the end of the propagation path, i.e., the specific function, method, or code segment containing the vulnerability (such as the unsafeDeserialize function in Vuln-Lib). The call graph analyzes all possible function call sequences from the start point to the end point. Since multiple components (libraries) are involved, this requires tracing across component boundaries to identify call chains such as App calling method A of Lib-A, and method A internally calling the vulnerable function of Vuln-Lib. Each call edge (i.e., a function call) in the call graph is not guaranteed to occur during actual execution; it may be located in conditional branches (such as if / else), loops, or exception handling. The system assigns an initial conditional execution probability as an edge weight to each call edge based on the prior probability of the call type. For example: unconditional direct call, probability = 1.0; in simple conditional judgments, probability = 0.7; in complex conditions or rare error handling branches, probability = 0.2. Numerous (e.g., 10,000) random simulations are performed on the constructed potential call chains. In each simulation, starting from the beginning, whenever a call edge is encountered, a random sample is taken based on its initial conditional execution probability to determine whether the call occurs in this simulation. Finally, the number of simulations that successfully traverse from the starting point to the endpoint is counted. The probabilistic reachability factor P_reachable = number of successful simulations / total number of simulations. This factor is a value between 0 and 1, comprehensively reflecting the impact of various execution conditions on all potential paths, quantifying the overall probability of the vulnerability being triggered. The closer P_reachable is to 1, the higher the probability that the vulnerability will be triggered at runtime. The probabilistic reachability factor is primarily based on control flow, but the actual threat of a vulnerability is also closely related to its code context. The probabilistic reachability factor is weighted according to the contextual location of the vulnerable code point. For example, if the vulnerable function is a core API or public entry point of a component, its threat is amplified (multiplied by a coefficient >1); if the vulnerable function is located in a deprecated module or an internal private method, its threat is attenuated (multiplied by a coefficient <1). After contextual weighting, the final reachability correction factor is obtained. A vulnerability's original risk score must be double-attenuated based on its true threat level within the specific software supply chain context.The process of comprehensively revising the initial risk score involves synergistically combining the corrective effects of the two dimensions mentioned above to jointly influence the initial risk score. The logic is that a vulnerability is only considered a high-risk vulnerability requiring immediate attention when it is both accessible in the code and close to the supply chain. Conversely, any decrease in risk in either dimension (unreachable code or excessively deep dependency layers) will significantly reduce the final revised risk score.

[0038] Optionally, the step of weighting and adjusting the probabilistic reachability factor based on the contextual position of the vulnerable code point within its component to obtain the final reachability correction factor specifically includes: From the multidimensional software supply chain relationship graph, extract the context attributes associated with the asset node to which the vulnerability code point belongs. The context attributes include the location type of the vulnerability code point in the component, the calling mode of the component in the project, and the life cycle state of the component. Based on the aforementioned context attributes, a context influence factor is calculated using a preset set of context influence rules. The final reachability correction factor is generated by combining the probabilistic reachability factor P_reachable with the contextual influence factor C using the following formula: F_final = P_reachable * (1 + k * C), where F_final represents the final reachability correction factor, P_reachable represents the probabilistic reachability factor, C represents the context influence factor, and k represents the configuration coefficient used to control the strength of context influence.

[0039] Vulnerable code location type: This refers to the degree to which the vulnerable function is exposed within its component. For example, public APIs / entry points, such as exported functions or externally exposed interfaces, are easily called and pose the greatest threat; internal private methods, used only within the component and inaccessible externally, pose a smaller threat; deprecated code segments, marked with @Deprecated or known to be no longer used, pose an extremely low threat. Component calling pattern: This refers to the frequency and scope of calls made to the component by other modules within the overall project. For example, high-frequency calls to core components mean frequent calls from multiple core modules, resulting in a wide impact if an issue occurs; low-frequency calls to peripheral components mean occasional calls from non-core functions, limiting the impact; no calls mean the component has been introduced but not actually used, as static analysis reveals. Component lifecycle status: This refers to the component's maintenance and activity status. For example, active maintenance means continuous updates from the community or vendor, resulting in rapid security responses; discontinued maintenance means no one maintains it, and new vulnerabilities cannot be fixed, posing a high risk; experimental features are unstable and may be disabled by default, with relatively controllable risks. The preset context impact rule set is a configurable set of rules, typically in the form of "IF-THEN" logic. For example, if the position type is "public API" and the lifecycle state is "stopped maintenance," then THENC = +0.8 (high-risk gain); if the call mode is "not called" or the position type is "deprecated code," then THENC = -0.9 (high-risk decay); if the call mode is "high-frequency core," then THENC = +0.5; if the lifecycle state is "active maintenance," then THENC = -0.2 (risk slightly decays due to strong repair capabilities). The system iterates through all relevant rules, evaluates each attribute, and finally aggregates the numerical results output by these rules into a comprehensive context impact factor C through weighting or extreme value taking. C is a signed number, typically in the range [-1, +1]. A positive value indicates that the context amplifies the risk, while a negative value indicates that the context weakens the risk. The probabilistic technical analysis results (P_reachable) are mathematically synthesized with the contextual business impact (C). P_reachable is the foundation, representing the probability of the vulnerability being executed under ideal conditions; C is the contextual impact factor, determining the direction and magnitude of adjustments; k is a configurable coefficient set by the system administrator or security policy to control the strength of the contextual impact. For example, under strict security policies, k=1.0 can be set to maximize the contextual impact; in environments that place more emphasis on technical metrics, k=0.3 can be set to reduce the contextual impact.When C > 0 (risk amplification), the multiplier > 1, thus correcting F_final upwards, making the final risk higher than the pure probability estimate; when C < 0 (risk decay), the multiplier < 1, thus correcting F_final downwards, making the final risk lower than the pure probability estimate; when C = 0 (no effect), the multiplier = 1, and F_final equals P_reachable.

[0040] Optionally, the step of comprehensively correcting the initial risk score based on the final reachability correction factor and the shortest propagation path depth to calculate the corrected technical risk characteristics specifically includes: The depth attenuation coefficient is obtained using the following formula: F_depth = β * exp(-γ * L), where F_depth represents the depth attenuation coefficient, L represents the shortest propagation path depth, and β and γ are constants configured based on the supply chain topology complexity. The comprehensive correction factor is obtained using the following formula: F_context = 1 - (1 - F_final) * (1 - F_depth), where F_context represents the comprehensive correction factor and F_final represents the final reachability correction factor; The initial risk score is multiplied by the comprehensive correction factor to obtain the corrected technical risk score, and the corrected technical risk score is output as the corrected technical risk feature.

[0041] β is a scaling factor, typically set to 1. It can be used to adjust the baseline level of the entire decay curve. γ is a decay rate constant that controls the rate at which risk decays with increasing depth L. In a system with complex dependencies and numerous components (high complexity), γ can be set larger to allow the risk of deep dependencies to decay more quickly, avoiding over-alarming of massive indirect dependencies. F_depth = β * exp(-γ * L) is an exponential decay model that simulates the objective law that the influence of risk decreases sharply as the path depth increases when it propagates in the dependency chain. When L is small (e.g., L = 1, direct dependency): the value of exp(-γ * L) is close to 1, so F_depth is also close to β (the maximum value). This indicates that the risk decay for direct dependencies is small because their impact is the most direct. When L increases (indirect dependency): the value of exp(-γ * L) rapidly approaches 0, causing F_depth to decrease sharply as well. This means that the risk of deep indirect dependencies is significantly decayed.

[0042] The formula F_context = 1 - (1 - F_final) * (1 - F_depth) is not a simple weighted average, but rather based on probabilistic compensation logic. It treats F_final (risk attenuation due to code unreachability) and F_depth (risk attenuation due to depth propagation) as two independent events that may jointly lead to a reduction in risk. (1 - F_final) represents the remaining risk that code unreachability failed to correct. (1 - F_depth) represents the remaining risk that depth propagation failed to attenuate. The product of the two, (1 - F_final) * (1 - F_depth), represents the most stubborn remaining risk that could not be eliminated even after considering code reachability and propagation depth. Subtracting this product from 1 yields the comprehensive correction factor F_context, which represents the proportion of risk retained after double correction. This formula ensures that the two correction factors work synergistically; if either F_final or F_depth is small (i.e., either dimension indicates low risk), the value of F_context will be significantly reduced. For example, a vulnerability, even with high code reachability (F_final=0.9), if it lies in a very deep dependency layer (F_depth=0.1), then the comprehensive correction factor F_context=1-(1-0.9)*(1-0.1)=1-0.1*0.9=0.91, indicating that the risk is significantly attenuated by deep propagation. A vulnerability, even with a short propagation path (F_depth=0.9), if the code is completely unreachable (F_final=0.1), then F_context=1-(1-0.1)*(1-0.9)=1-0.9*0.1=0.91, indicating that the risk is significantly attenuated by code unreachability. Only when a vulnerability is both reachable (high F_final) and close (high F_depth) will F_context be high. The initial general vulnerability score (CVSS), after adjustment by the comprehensive correction factor representing the real-world context, is ultimately transformed into the corrected technical risk characteristic R_Tech. This R_Tech is no longer the theoretical highest possible risk, but rather the real and imminent level of risk that the vulnerability presents after being closely integrated with the supply chain structure and code implementation of a specific application.

[0043] Optionally, the method further includes: Using the vulnerability node as the risk source and the corrected technical risk score corresponding to the vulnerability node as the initial risk value, a preset independent cascade model is executed on the reverse dependency subgraph to simulate risk propagation. The probability of risk propagating along the dependency edge is determined by the type weight of the dependency edge and the probabilistic reachability factor. Collect all asset nodes whose risk values ​​exceed a preset first threshold, form an affected asset set, and calculate the overall risk exposure index of the affected asset set; Construct an extended impact subgraph, which includes all first asset nodes in the affected asset set, as well as all personnel nodes and process nodes directly connected to the first asset nodes through the submission edge or the construction edge; The extended influence subgraph is input into a preset graph neural network model to obtain the target vector representation of all nodes in the extended influence subgraph; Based on the target vector representation, the cosine similarity between the second asset node in the extended impact subgraph that is not associated with any known vulnerability and the preset high-risk asset node in the affected asset set is calculated. When the cosine similarity is higher than the preset second threshold, the second asset node is assigned a latent risk score. The implicit risk score is fused with the explicit risk score calculated based on known vulnerabilities to dynamically update the overall risk exposure index. When the implicit risk score or the updated overall risk exposure index exceeds a preset third threshold, an investigation of the second asset node or the affected asset set is triggered.

[0044] An independent cascading model is run on the inverse dependency subgraph (i.e., the subgraph rooted at the target application and containing all dependent components). Risk propagates along dependency edges; propagation is not guaranteed, and its success probability is dynamically determined by the type weights and probabilistic reachability factors of the dependency edges. Dependency edge type weights: As mentioned earlier, direct dependency edges have low weights (high propagation probability), while indirect dependency edges have high weights (low propagation probability). Probabilistic reachability factor: This factor is not only used to adjust risk values ​​but is also reused here as a regulator of propagation probability. If the code call relationship between two components is close (high reachability factor), the risk is more likely to propagate between them. After multiple rounds of simulation, each asset node accumulates a risk value. Nodes include the first asset node, all personnel nodes directly connected to these assets (via connection edges), and all process nodes (via construction edges). First asset node: All assets whose risk values ​​exceed the first threshold after simulation constitute the affected asset set. The extended impact subgraph automatically associates technical risks with responsible parties and the construction environment, providing direct action targets for subsequent review and handling. The extended impact subgraph is input into a pre-trained graph neural network model (GNN). GNNs learn a low-dimensional target vector representation for each node by aggregating information from nodes and edges in the graph over multiple layers. This target vector representation encodes the node's structural role, attribute features, and relationships with its neighbors in the graph. It identifies second asset nodes in the graph that are not associated with any known vulnerabilities (i.e., components not currently identified by the scan). It calculates the cosine similarity between the vector representations of the second asset node and known high-risk asset nodes in the affected asset set. If two nodes are very close in the vector space (cosine similarity above a second threshold), it means they are highly similar in terms of code structure, dependency patterns, developers, and build environment. Therefore, this second asset node is likely to have similar, undiscovered vulnerabilities or design flaws (i.e., latent risks). Second asset nodes with cosine similarity above a preset second threshold are assigned a latent risk score. The latent risk score is then fused with an explicit risk score derived from simulation to dynamically update the overall risk exposure index of the entire affected asset set. The system's risk assessment is no longer static but evolves in real-time with the prediction results. A seemingly localized vulnerability can significantly increase the overall risk level of the system if it is surrounded by a large number of similar high-latent-risk components. The system automatically triggers a review when any of the following conditions are met: a node's latent risk score is excessively high (indicating a new, high-risk point requiring verification), or the overall risk exposure index after merging and updating is excessively high (indicating systemic risk to the entire subsystem). For high-risk secondary asset nodes, a dedicated security scan or code audit is triggered. For high-risk sets of affected assets, a comprehensive review of the associated developers and build processes is triggered.

[0045] 7. Optionally, the step of calculating a comprehensive risk score by weighting the compliance risk characteristics, the supply chain risk characteristics, and the modified technical risk characteristics using a preset weighted model, and then driving the review decision engine to perform automated security approval, interception, or manual review operations based on the comprehensive risk score, specifically includes: The modified technical risk characteristics, compliance risk characteristics, and supply chain risk characteristics are all mapped to a preset scaling range using a min-max standardization method. The mapped modified technical risk characteristics, compliance risk characteristics and supply chain risk characteristics are assigned corresponding weight coefficients, and the specific values ​​of the weight coefficients are dynamically determined by the business type or security strategy to which the target asset node belongs. The comprehensive risk score is calculated using a linear weighted summation formula. The comprehensive risk score is matched with a set of preset decision thresholds. If the comprehensive risk score is lower than the fourth threshold, a security approval action is triggered. If the comprehensive risk score is between the fourth and fifth thresholds, a manual review process is triggered. If the comprehensive risk score is higher than the fifth threshold, an interception and alarm action is triggered.

[0046] The three risk characteristic values ​​are uniformly mapped to a preset scale range (e.g., 0 to 10) using a min-max standardization method. The calculation formula is: X_norm = (X - X_min) / (X_max - X_min) * (scale_max - scale_min) + scale_min. X is the original value (e.g., R_Tech, compliance risk characteristic R_Comp, supply chain risk characteristic R_SC). X_min and X_max are the theoretical minimum and maximum values ​​for this type of risk characteristic, respectively, while scale_max and scale_min are the maximum and minimum values ​​of the target range (e.g., 10 and 0). For example, mapping R_Tech=7.5 (technical risk), R_Comp=85 (compliance risk on a percentage scale), and R_SC=0.3 (supply chain risk probability value) to a 0-10 scale might yield R_Tech_norm=7.5, R_Comp_norm=8.5, and R_SC_norm=3.0. This ensures that risk values ​​of different natures and origins can be measured on the same scale, laying a fair foundation for subsequent weighted fusion. Figure 4 This is a schematic diagram of the weighted model data flow and calculation process in the embodiments of this application, as shown below. Figure 4As shown, the three standardized risk characteristics are assigned corresponding weight coefficients: W_Tech (technical risk weight), W_Comp (compliance risk weight), and W_SC (supply chain risk weight), which satisfy W_Tech + W_Comp + W_SC = 1. The specific values ​​of the weights are not fixed but dynamically determined by the business type or security strategy of the target asset node. Example 1: Core payment business application. Strategy: Stability and compliance are prioritized. Weight allocation: W_Tech = 0.5 (technical vulnerabilities are still important), W_Comp = 0.4 (high license compliance requirements), W_SC = 0.1. Example 2: Internal data processing tools. Strategy: Data security and supply chain trustworthiness are prioritized. Weight allocation: W_Tech = 0.4, W_Comp = 0.3, W_SC = 0.3 (more focus on the reliability of data component sources). Example 3: Rapidly iterating front-end prototype. Strategy: Speed ​​is prioritized, tolerating some risk. Weight allocation: W_Tech = 0.7 (only focusing on the most critical technical vulnerabilities), W_Comp = 0.2, W_SC = 0.1. This allows for close integration of risk assessment results with business objectives. The same vulnerability may generate different comprehensive risk levels in different applications, making decision-making more targeted. A final comprehensive risk score is calculated using a linear weighted summation formula. The calculated comprehensive risk score R_Final is then matched against a set of preset decision thresholds. The fourth threshold is for low-risk applications. The fifth threshold is for high-risk applications. Automated action triggering: If R_Final < the fourth threshold, a security approval action is triggered. If the risk is acceptable, the system automatically approves the use of the component or the release of the version, without disrupting the development or deployment process, ensuring development efficiency. If the fourth threshold <= R_Final <= the fifth threshold, a manual review process is triggered. If there is a medium risk, the system automatically generates a work order and pushes the assessment report to a security engineer for manual review. This balances automation and expert wisdom, handling cases in gray areas. If R_Final > the fifth threshold, an interception and alert action is triggered. If the risk is unacceptable, the system automatically fails the build in the CI / CD pipeline, preventing the integration or release of versions containing high risks, and immediately sends alerts to relevant personnel via email, SMS, etc.

[0047] The above describes a method for detecting software supply chain risks in the embodiments of this application. The following describes the computer system in the embodiments of this application in detail with reference to the above method for detecting software supply chain risks.

[0048] Please see Figure 5 This is a schematic diagram of an exemplary hardware structure of a computer system in an embodiment of this application.

[0049] In some embodiments, the computer system 500 includes a computer device, which may be a terminal device. The computer device includes a processor 501, a memory 502, a sensor module 503, a communication module 504, an input device 505, and an output device 506 connected via a system bus. The processor 501 of the computer device provides computing and control capabilities. The memory 502 of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database is used to store data.

[0050] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0051] In some embodiments of this application, a computer-readable storage medium is provided, including instructions that, when executed on a computer system 500, cause the computer system 500 to perform a software supply chain risk detection method according to an embodiment of this application.

[0052] In some embodiments of this application, a computer program product is also provided, which, when run on a computer system 500, causes the computer system 500 to execute a software supply chain risk detection method according to an embodiment of this application.

[0053] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0054] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0055] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for detecting risks in the software supply chain, characterized in that, include: Acquire multi-source heterogeneous data from the software supply chain and construct a multi-dimensional software supply chain relationship graph from the multi-source heterogeneous data. The multi-source heterogeneous data includes software asset data, vulnerability data, personnel data, and process data. The multi-dimensional software supply chain relationship graph includes asset nodes, vulnerability nodes, personnel nodes, and process nodes. The nodes are connected by semantically related edges. The related edges include dependency edges between asset nodes to represent dependency relationships, submission edges between personnel nodes and asset nodes to represent code submission relationships, and construction edges between process nodes and asset nodes to represent construction relationships. Based on the multidimensional software supply chain relationship graph, the nodes and attributes associated with the target asset node are queried to extract risk features. The risk features include the technical risk features of the vulnerability nodes associated with the target asset node, the compliance risk features of the license nodes associated with the target asset node, and the supply chain risk features of the personnel nodes or upstream supplier nodes associated with the target asset node. The initial risk scores of the vulnerability nodes associated with the target asset node are obtained from the public vulnerability database. The shortest propagation path depth between the vulnerability node and the target asset node is calculated using a graph traversal algorithm. Combined with code reachability analysis, the initial risk scores are adjusted to obtain the corrected technical risk characteristics. A comprehensive risk score is obtained by weighting the compliance risk characteristics, supply chain risk characteristics, and modified technology risk characteristics using a preset weighted model. The comprehensive risk score then drives the review decision engine to perform automated security approval, interception, or manual review operations.

2. The method for software supply chain risk detection according to claim 1, characterized in that, The calculation of the shortest propagation path depth between the vulnerable node and the target asset node using a graph traversal algorithm includes: Starting from the target asset node, traverse the multidimensional software supply chain relationship graph in the opposite direction of the dependency edge to extract all asset nodes that can reach the starting point, forming a reverse dependency subgraph. On the reverse dependency subgraph, a weighted shortest path search is performed, and the weights of each relation edge on the path are accumulated to determine the shortest propagation path with the smallest accumulated weight from the starting point to the first asset node to which the vulnerability node belongs. The weight value assigned to direct dependency edges is lower than the weight value assigned to indirect dependency edges. The direct dependency edge refers to the edge corresponding to the dependency relationship directly declared by the target asset node, and the indirect dependency edge refers to the edge corresponding to the dependency relationship declared by the dependency item of the target asset node. The cumulative weight value of the shortest propagation path is mapped to the depth of the shortest propagation path through a preset nonlinear mapping function. The nonlinear mapping function makes the propagation path depth increase in a decreasing trend as the cumulative weight increases.

3. The method for software supply chain risk detection according to claim 2, characterized in that, The initial risk score is adjusted based on the code accessibility analysis to obtain the revised technical risk characteristics, specifically including: Based on the code structure information obtained from static analysis, within the asset node range determined by the shortest propagation path, the potential call relationships between the target application execution start point located at the beginning of the shortest propagation path and the vulnerable code point located at the end of the shortest propagation path are analyzed to construct potential call chains across component boundaries. Based on the prior probability of the call type, an initial conditional execution probability is assigned to each call edge in the link. The initial conditional execution probability is used as the edge weight. Monte Carlo simulation is performed on the potential call link to calculate the path connectivity success rate from the execution start point of the target application to the vulnerable code point. The path connectivity success rate is quantified into a probabilistic reachability factor. Based on the contextual position of the vulnerability code point within its component, the probabilistic reachability factor is weighted and adjusted to obtain a final reachability correction factor. Based on the final reachability correction factor and the shortest propagation path depth, the initial risk score is comprehensively corrected to calculate the corrected technical risk characteristics.

4. The method for software supply chain risk detection according to claim 3, characterized in that, The step of weighting and adjusting the probabilistic reachability factor based on the contextual position of the vulnerable code point within its component to obtain the final reachability correction factor specifically includes: From the multidimensional software supply chain relationship graph, extract the context attributes associated with the asset node to which the vulnerability code point belongs. The context attributes include the location type of the vulnerability code point in the component, the calling mode of the component in the project, and the life cycle state of the component. Based on the aforementioned context attributes, a context influence factor is calculated using a preset set of context influence rules. The final reachability correction factor is generated by combining the probabilistic reachability factor P_reachable with the contextual influence factor C using the following formula: F_final = P_reachable * (1 + k * C), where F_final represents the final reachability correction factor, P_reachable represents the probabilistic reachability factor, C represents the context influence factor, and k represents the configuration coefficient used to control the strength of context influence.

5. The method for software supply chain risk detection according to claim 4, characterized in that, The initial risk score is comprehensively corrected based on the final reachability correction factor and the shortest propagation path depth to calculate the corrected technical risk characteristics, specifically including: The depth attenuation coefficient is obtained using the following formula: F_depth = β * exp(-γ * L), where F_depth represents the depth attenuation coefficient, L represents the shortest propagation path depth, and β and γ are constants configured based on the supply chain topology complexity. The comprehensive correction factor is obtained using the following formula: F_context = 1 - (1 - F_final) * (1 - F_depth), where F_context represents the comprehensive correction factor and F_final represents the final reachability correction factor; The initial risk score is multiplied by the comprehensive correction factor to obtain the corrected technical risk score, and the corrected technical risk score is output as the corrected technical risk feature.

6. The method for software supply chain risk detection according to claim 5, characterized in that, The method further includes: Using the vulnerability node as the risk source and the corrected technical risk score corresponding to the vulnerability node as the initial risk value, a preset independent cascade model is executed on the reverse dependency subgraph to simulate risk propagation. The probability of risk propagating along the dependency edge is determined by the type weight of the dependency edge and the probabilistic reachability factor. Collect all asset nodes whose risk values ​​exceed a preset first threshold, form an affected asset set, and calculate the overall risk exposure index of the affected asset set; Construct an extended impact subgraph, which includes all first asset nodes in the affected asset set, as well as all personnel nodes and process nodes directly connected to the first asset nodes through the submission edge or the construction edge; The extended influence subgraph is input into a preset graph neural network model to obtain the target vector representation of all nodes in the extended influence subgraph; Based on the target vector representation, the cosine similarity between the second asset node in the extended impact subgraph that is not associated with any known vulnerability and the preset high-risk asset node in the affected asset set is calculated. When the cosine similarity is higher than the preset second threshold, the second asset node is assigned a latent risk score. The implicit risk score is fused with the explicit risk score calculated based on known vulnerabilities to dynamically update the overall risk exposure index. When the implicit risk score or the updated overall risk exposure index exceeds a preset third threshold, an investigation of the second asset node or the affected asset set is triggered.

7. The method according to claim 1, characterized in that, The process involves using a preset weighted model to calculate a comprehensive risk score by weighting the compliance risk characteristics, supply chain risk characteristics, and modified technology risk characteristics. This comprehensive risk score then drives the review decision engine to perform automated security approval, blocking, or manual review operations. Specifically, this includes: The modified technical risk characteristics, compliance risk characteristics, and supply chain risk characteristics are all mapped to a preset scaling range using a min-max standardization method. The mapped modified technical risk characteristics, compliance risk characteristics and supply chain risk characteristics are assigned corresponding weight coefficients, and the specific values ​​of the weight coefficients are dynamically determined by the business type or security strategy to which the target asset node belongs. The comprehensive risk score is calculated using a linear weighted summation formula. The comprehensive risk score is matched with a set of preset decision thresholds. If the comprehensive risk score is lower than the fourth threshold, a security approval action is triggered. If the comprehensive risk score is between the fourth and fifth thresholds, a manual review process is triggered. If the comprehensive risk score is higher than the fifth threshold, an interception and alarm action is triggered.

8. A computer system comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1-7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1-7.

Images