Software supply chain risk analysis method based on multi-source data

Abstract

The application discloses a software supply chain risk analysis method based on multi-source data, relates to the technical field of supply chain risks, and is used for solving the problem of reducing the accuracy and predictability of software supply chain security management, obtaining security repair information of software supply chain components through a code warehouse, calculating security submission density, detecting a vulnerability repair time delay to generate a repair trend, and evaluating vulnerability abnormal characteristics in combination with the security submission density; a software running period is set, the component running call frequency and the number of loaded modules are detected in the period to evaluate environment dependence characteristics, the evaluation priority level is determined in combination with the vulnerability abnormal characteristics, and it is judged whether a dependence evaluation mechanism is triggered according to the priority level; in the dependence evaluation mechanism, cycle dependence information is detected, the dependence level depth and the number of influence paths are counted to generate a risk transmission level, alarm information is output based on the level, and the accuracy and predictability of software supply chain security management are improved.

Description

Technical Field

[0001] This invention relates to the field of supply chain risk technology, and more specifically, to a software-based supply chain risk analysis method based on multi-source data. Background Technology

[0002] As the complexity of software development continues to increase, modern software systems are typically composed of a large number of components from different sources, forming a complex software supply chain. Each component may have vulnerabilities or security flaws during development, updates, and maintenance. Traditional software security management mainly relies on vulnerability database information or security testing of individual components.

[0003] The existing technology has the following shortcomings:

[0004] Currently, existing technologies lack comprehensive and dynamic monitoring capabilities and multi-source data fusion analysis capabilities for the vulnerability remediation status and operational dependency characteristics of various components in the software supply chain. This makes it impossible to accurately assess the abnormal vulnerability characteristics and environmental dependency risks of components, resulting in difficulties in timely identification of high-risk components and inability to quantify risk transmission, thus reducing the accuracy and predictability of software supply chain security management. Therefore, this paper proposes a software supply chain risk analysis method based on multi-source data.

[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a software supply chain risk analysis method based on multi-source data. By employing multi-source data fusion analysis technology, combined with component vulnerability repair trends, runtime call characteristics, and dependency structure assessment, the method dynamically generates component risk levels and outputs graded alarms to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a software supply chain risk analysis method based on multi-source data, comprising the following steps:

[0008] Step S1: Inspect the components of the software supply chain, obtain security fix information for each component through the code repository, calculate the security commit density of the component based on the security fix information, and detect the vulnerability fix latency of each component;

[0009] Step S2: Generate vulnerability remediation trends for each component based on vulnerability remediation latency, assess the vulnerability anomaly characteristics of each component in conjunction with security submission density, set the software runtime cycle, and detect the runtime call frequency and number of loaded modules for each component within the software runtime cycle.

[0010] Step S3: Evaluate the environmental dependency characteristics of each component based on the overall running call frequency and the number of loaded modules, set the evaluation priority level of each component in combination with the vulnerability anomaly characteristics, and determine whether to trigger the dependency evaluation mechanism based on the evaluation priority level.

[0011] Step S4: In the dependency evaluation mechanism, detect the circular dependency information of the component, determine whether to count the dependency depth and number of impact paths of the component based on the circular dependency information and generate a risk transmission level, and output different alarm information based on the risk transmission level.

[0012] In a preferred embodiment, in step S1, the software supply chain refers to the multi-level interconnected system formed between various components, development tools, dependency libraries, operating environments, and participating organizations involved in the entire process of software product development, construction, testing, deployment, and use.

[0013] The software supply chain components are inspected, and security fix information for each component is obtained by accessing the corresponding code repositories.

[0014] Security remediation information includes the security remediation submission record, submission time, vulnerability number, and vulnerability discovery time.

[0015] In a preferred embodiment, in step S1, the total number of security remediation submission records for all vulnerabilities of the component within a preset time interval is divided by the length of the time interval to obtain the security submission density.

[0016] For each security fix submission record in the component, the time of the vulnerability's first discovery and the time of the vulnerability fix submission are recorded, and the difference between the two is taken as the vulnerability fix delay.

[0017] In a preferred embodiment, in step S2, the vulnerability repair delay of each component within a preset time interval is arranged in chronological order, and the difference between two consecutive vulnerability repair delays is calculated as the repair change amount.

[0018] Calculate the average of all patch changes as the vulnerability patching trend;

[0019] By performing a linear combination calculation on security submission density and vulnerability remediation trends, the abnormal vulnerability characteristics of each component are obtained: ;

[0020] in, The abnormal characteristics of the component's vulnerability To ensure safe submission density, As a trend in vulnerability remediation, The index value of the component. and These are the preset weighting coefficients.

[0021] In a preferred embodiment, in step S2, a software running period is set to define a time interval in which the software is in a predetermined normal running state for observing the running behavior of each component;

[0022] The ratio of the number of times the component is called by other components in the software running period to the length of the running period is taken as the running call frequency;

[0023] The total number of modules actually loaded by the component at runtime in the software running period is taken as the loaded module quantity.

[0024] In a preferred embodiment, in step S3, the product of the running call frequency and the loaded module quantity after standardization is taken as the environmental dependency feature of the component;

[0025] The environmental dependency feature and the vulnerability anomaly feature are combined to evaluate the evaluation priority level of the component by a fuzzy inference method;

[0026] The environmental dependency feature and the vulnerability anomaly feature are defined as input variables, and the evaluation priority level is defined as an output variable, which is divided into a potential level, an alert level, and a warning level;

[0027] A set of fuzzy rules is formulated to describe the influence of different input variables on the output variable;

[0028] Fuzzy inference is performed according to the fuzzy rules to obtain the evaluation priority level of each component;

[0029] When the evaluation priority level of the component is the warning level, the dependency evaluation mechanism is triggered;

[0030] Conversely, the dependency evaluation mechanism is not triggered.

[0031] In a preferred embodiment, in step S4, in the dependency evaluation mechanism, for the component with the evaluation priority level of the warning level, the cyclic dependency information of the component is obtained from the version control repository, including the number of cyclic paths;

[0032] The number of cyclic paths is compared with a preset cyclic path threshold to determine whether to count the dependency level depth and the number of impact paths of the component:

[0033] If the number of cyclic paths is greater than the preset cyclic path threshold, the dependency level depth and the number of impact paths of the component are counted;

[0034] Conversely, the dependency level depth and the number of impact paths of the component are not counted, and the risk transmission level of the component is determined as a low level transmission.

[0035] In a preferred embodiment, in step S4, when the number of cyclic paths is greater than a preset cyclic path threshold, the dependency structure of the component is traversed to obtain the dependency level depth of the component;

[0036] The number of influence paths of the component is obtained by traversing the call reference relationship of the component upwards.

[0037] The dependency level depth and the number of influence paths are respectively standardized to generate a dependency level depth coefficient and a number of influence path coefficient.

[0038] The conduction parameter is calculated based on the dependency level depth coefficient and the number of influence path coefficient using a weighting method, and the risk conduction index is further calculated based on the conduction parameter.

[0039] In a preferred embodiment, in step S4, the risk conduction index is compared with a preset risk conduction threshold to generate the risk conduction level of the component and the alarm information:

[0040] If the risk conduction index is greater than the preset risk conduction threshold, it is judged that the risk conduction level of the component is high-level conduction and high-risk alarm information is generated.

[0041] Conversely, it is judged that the risk conduction level is low-level conduction and monitoring prompt information is generated.

[0042] Technical effects and advantages of the present application:

[0043] The present application obtains the security repair information of each component of the software supply chain through the code repository and calculates the security submission density of the component, detects the vulnerability repair time delay of each component to generate the vulnerability repair trend of each component, evaluates the vulnerability abnormal characteristics of each component in combination with the security submission density, sets the software running period, detects the running call frequency and the number of loaded modules of each component within the software running period to evaluate the environmental dependency characteristics of each component, sets the evaluation priority level of each component in combination with the vulnerability abnormal characteristics, judges whether to trigger the dependency evaluation mechanism according to the evaluation priority level, detects the cyclic dependency information of the component in the dependency evaluation mechanism to judge whether to count the dependency level depth and the number of influence paths of the component and generate the risk conduction level, outputs different alarm information based on the risk conduction level, and through the fusion analysis of multiple source data, identifies high-risk components in advance and generates graded alarms, thereby improving the accuracy and predictability of software supply chain security management. BRIEF DESCRIPTION OF DRAWINGS

[0044] Fig. 1 The implementation flowchart of the software supply chain risk analysis method based on multiple source data of the present application.

[0045] Fig. 2 The step schematic diagram of the software supply chain risk analysis method based on multiple source data of the present application. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0047] The present application obtains security repair information of each component of a software supply chain through a code repository, calculates security submission density of the component, detects vulnerability repair time delay of each component to generate vulnerability repair trend of each component, evaluates vulnerability abnormal features of each component in combination with the security submission density, sets a software running period, detects running call frequency and loaded module quantity of each component in the software running period to evaluate environment dependency features of each component, sets evaluation priority level of each component in combination with the vulnerability abnormal features, judges whether to trigger a dependency evaluation mechanism according to the evaluation priority level, detects cyclic dependency information of the component in the dependency evaluation mechanism to judge whether to count dependency level depth and influence path quantity of the component and generate a risk transmission level, outputs different alarm information based on the risk transmission level, and identifies high-risk components in advance and generates graded alarms through fusion analysis of multi-source data.

[0048] Embodiment 1, as shown in the following table, a software supply chain risk analysis method based on multi-source data includes the following steps: Figs. 1-2

[0049] Step S1: detecting components of a software supply chain, obtaining security repair information of each component through a code repository, calculating security submission density of the component according to the security repair information, and detecting vulnerability repair time delay of each component.

[0050] Step S2: generating vulnerability repair trend of each component according to the vulnerability repair time delay, evaluating vulnerability abnormal features of each component in combination with the security submission density, setting a software running period, and detecting running call frequency and loaded module quantity of each component in the software running period.

[0051] Step S3: evaluating environment dependency features of each component by comprehensively evaluating the running call frequency and the loaded module quantity, setting evaluation priority level of each component in combination with the vulnerability abnormal features, and judging whether to trigger a dependency evaluation mechanism according to the evaluation priority level.

[0052] Step S4: in the dependency evaluation mechanism, detecting cyclic dependency information of the component, judging whether to count dependency level depth and influence path quantity of the component and generating a risk transmission level according to the cyclic dependency information, and outputting different alarm information based on the risk transmission level.

[0053] The specific implementation is as follows:​

[0054] In step S1, the software supply chain refers to a multi-level association system formed between various components, development tools, dependent libraries, running environments and participating organizations in the whole process of software products from development, construction, testing, deployment to use. The software supply chain realizes the generation and propagation of software products through links such as source code repository, third-party open source components, construction platform and package management system, and each component has dependency transmission and risk spread.

[0055] Each component in the software supply chain is detected, and each component in the software supply chain is taken as an analysis object. The security repair information of each component is obtained by accessing the corresponding code repository. The security repair information includes the security repair submission record, submission time, vulnerability number and vulnerability discovery time of the vulnerability, and is used to reflect the historical behavior and repair ability of the component in the security maintenance aspect.

[0056] It should be noted that the code repository is a basic software development repository for centralized storage, management and maintenance of software source code and version information. Based on the distributed version control system, all code files, modification history, branch structure and submission records of the software project in the development process are recorded to ensure the traceability and integrity of the code evolution process.

[0057] The security submission density of the component is calculated based on the security repair information. The total number of security repair submission records of all vulnerabilities of the component in a preset time interval is divided by the length of the time interval to obtain the number of security repair submissions completed by the component in a unit time, which is taken as the security submission density, reflecting the security update activity level of the component.

[0058] At the same time, the vulnerability repair time delay of each component is detected. The vulnerability repair time delay is the time interval from the first discovery of the vulnerability of the component to the repair submission to solve the vulnerability. Specifically, for each security repair submission record corresponding to a vulnerability in the component, the first discovery time of the vulnerability and the vulnerability repair submission time are recorded. The difference between the two is the repair time delay of the vulnerability, which is used to reflect the timeliness and repair efficiency of the component in response to the vulnerability.

[0059] In step S2, the vulnerability repair trend of each component is generated according to the vulnerability repair time delay. Specifically, the vulnerability repair time delay of each component in a preset time interval is subjected to time series analysis. The vulnerability repair time delay is arranged in time sequence, and the difference between the two consecutive vulnerability repair time delays is calculated as the repair change amount.

[0060] The average value of all repair change amounts is calculated as the vulnerability repair trend, reflecting the change direction and speed of the repair time delay of the component with time. The positive value indicates that the repair delay gradually increases, and the negative value indicates that the repair delay gradually decreases.

[0061] The linear combination of the security submission density and the vulnerability repair trend is calculated to obtain the vulnerability anomaly feature of each component, and the expression is as follows:

[0062] ;

[0063] wherein, is the vulnerability anomaly feature of the component, is the security submission density, is the vulnerability repair trend, is the index value of the component, and are weight coefficients.

[0064] The vulnerability anomaly feature reflects whether the component has abnormal fluctuations in the security repair behavior, and the higher the value, the higher the vulnerability repair density of the component but the longer the repair time, and the greater the abnormality; the lower the value, the lower the vulnerability repair density of the component and the shorter the repair time, that is, the repair is sparse but efficient, and the lower the abnormality.

[0065] It should be noted that the weight coefficients α and β are used to quantitatively adjust the relative influence of the security submission density and the vulnerability repair trend in the calculation of the vulnerability anomaly feature, and are quantified based on historical component security data and statistical analysis: collect the security submission density and vulnerability repair time of all components in the target software supply chain within a fixed time interval, calculate the standard deviation of each index to reflect the fluctuation amplitude, and set α and β as the normalized ratio of the fluctuation amplitude of each index, ensuring that α+β=1.

[0066] The software running period is set to define the time interval for observing the running behavior of each component when the software is in a predetermined normal running state, and the software running period is determined according to the software running plan or operation and maintenance period;

[0067] During the software running period, the running call frequency and the number of loaded modules of each component are detected:

[0068] The running call frequency refers to the ratio of the number of times a component is called by other components to the length of the running period within the software running period, which quantifies the activity and dependency of the component in the running environment;

[0069] Specifically, during the software running period, each component call event is recorded and counted through the call running log, and the total number of component calls is divided by the length of the software running period to obtain the call frequency per unit time as the running call frequency.

[0070] The number of loaded modules is the total number of modules actually loaded by the component during the software running period, which reflects the functional complexity and dependency range of the component in the running environment;

[0071] Specifically, the loading log of the module management system is invoked to record and count the modules loaded each time by the component, and the repeatedly loaded modules are removed to obtain the number of loaded modules of the component in the entire running cycle.

[0072] It should be noted that the running log refers to a data file or database record generated during the running of the software, recording the execution and event information of the component, including component call events, execution time, caller and callee identification, call parameters, return status and other information; the module management system refers to a management platform or tool for managing the registration, loading, unloading and dependency relationship of software components and their internal modules; the loading log refers to a log file or data record generated by the module management system during the running of the software component, recording the loading of the component, including the actual loading information of each component during running, including module identification, version number, loading time and loading sequence.

[0073] In step S3, the running call frequency and the number of loaded modules are standardized respectively to generate a running call frequency coefficient and a number of loaded modules coefficient;

[0074] The product of the running call frequency coefficient and the number of loaded modules coefficient is taken as the environmental dependency feature of the component;

[0075] The environmental dependency feature reflects the degree of dependency and call of the component in the running environment; the greater the running call frequency coefficient, the more frequently the component is called in the running cycle, and the greater the environmental dependency feature; the greater the number of loaded modules coefficient, the more sub-modules associated or loaded by the component during running, and the wider the environmental influence range in the supply chain, the greater the environmental dependency feature.

[0076] It should be explained that the standardization processing method includes but is not limited to standard linear transformation based on interval scaling, Z-Score standardization method based on statistics or normalization method based on nonlinear mapping function, and the application method of standardization processing is not described here.

[0077] The comprehensive environmental dependency feature and vulnerability anomaly feature are used to evaluate the evaluation priority level of the component by fuzzy reasoning method;

[0078] The environmental dependency feature and the vulnerability anomaly feature are defined as input variables, which are divided into different fuzzy sets, for example, the environmental dependency feature is divided into low dependency, medium dependency and high dependency, and the vulnerability anomaly feature is divided into slight anomaly, medium anomaly and severe anomaly;

[0079] The evaluation priority level is defined as an output variable, which is divided into potential level, alert level and warning level;

[0080] A set of fuzzy rules is formulated to describe the influence of different input variables on the output variable. The definition of the rules can be based on professional knowledge or obtained through data analysis and experiments, for example,

[0081] If the environment dependency feature is high dependency and the vulnerability anomaly feature is severe anomaly, it is judged that the evaluation priority level of the component is the pre-warning level.

[0082] If the environment dependency feature is medium dependency and the vulnerability anomaly feature is medium anomaly, it is judged that the evaluation priority level of the component is the alert level.

[0083] If the environment dependency feature is low dependency and the vulnerability anomaly feature is slight anomaly, it is judged that the evaluation priority level of the component is the potential level.

[0084] According to the fuzzy reasoning of the above fuzzy rules, the evaluation priority level of each component is obtained. When the evaluation priority level of the component is the pre-warning level, the dependency evaluation mechanism is triggered; when the evaluation priority level is the potential level, the state is continuously monitored and recorded; when the evaluation priority level is the alert level, the component is marked, and the sampling frequency and anomaly detection accuracy are improved in the subsequent running period.

[0085] It needs to be explained that the fuzzy reasoning method is a multi-dimensional feature comprehensive judgment method based on fuzzy set theory; the division of fuzzy set can be adjusted according to actual situation, actually, the environment dependency feature and the vulnerability anomaly feature can be divided into three or more sets, for example, the environment dependency feature set is divided into four sets of low dependency, medium dependency, higher dependency and high dependency, so as to realize more accurate evaluation priority level determination in different scenarios.

[0086] This step realizes the hierarchical screening mechanism of risk detection, avoids the calculation burden caused by full complex analysis of all components, and through the establishment of trigger threshold based on risk intensity, the system can pay more attention to the key components that may cause chain reaction, and improve the detection efficiency and response speed.

[0087] In step S4, in the dependency evaluation mechanism, for the component with the evaluation priority level of the pre-warning level, the cyclic dependency information of the component is obtained from the version control warehouse, the cyclic dependency information is the direct dependency relationship set formed in the version control record of the component, including the number of cyclic paths;

[0088] Among them, the number of cyclic paths refers to the total number of closed paths starting from the component in the version control record and finally returning to itself, reflecting the complexity and risk of the component being cyclically referenced;

[0089] Compare the number of cyclic paths with the preset cyclic path threshold to determine whether to count the dependency level depth and the number of influence paths of the component:

[0090] If the number of cyclic paths is greater than the preset cyclic path threshold, the dependency level of the component and the number of influence paths are counted.

[0091] On the contrary, the dependency level of the component and the number of influence paths are not counted, and the risk transmission level of the component is determined as a low level.

[0092] When the number of cyclic paths is greater than the preset cyclic path threshold, the dependency structure of the component is traversed to obtain the dependency level of the component. The dependency level refers to the maximum number of layers from the layer where the component is located to the bottom layer. The deeper the dependency level, the longer the path of the vulnerability or abnormal state of the component along the chain.

[0093] By traversing the call reference relationship of the component upwards, the number of influence paths of the component is obtained. The number of influence paths refers to the total number of reachable paths formed by tracing the upper components of the referenced component from the current component. The greater the number of influence paths, the wider the influence range of the component in the supply chain.

[0094] Wherein, the upward traversal refers to starting from the dependent component, finding the upper components that depend on the component level by level, and performing path statistics.

[0095] The dependency level and the number of influence paths are standardized to generate the dependency level coefficient and the number of influence paths coefficient.

[0096] Based on the dependency level coefficient and the number of influence paths coefficient, the transmission parameter is calculated by using the weighting method: , wherein, is the dependency level coefficient, is the number of influence paths coefficient, and is the preset weighting coefficient, is the transmission parameter.

[0097] Further based on the transmission parameter, the risk transmission index is calculated: , wherein, is the preset adjustment factor, is the risk transmission index.

[0098] It should be explained that the preset weighting coefficient can be set according to the importance proportion of different system structures and dependency characteristics. For example, when the component has a greater impact on the overall architecture stability, the preset weighting coefficient corresponding to the dependency level coefficient can be set to a higher value. The preset adjustment factor can be set according to the sensitivity requirement of the risk assessment scene. For example, in a software system with complex supply chain, the preset adjustment factor can be set to a higher value.

[0099] Based on the comparison between the risk transmission index and the preset risk transmission threshold, the risk transmission level of the component is generated.

[0100] If the risk transmission index is greater than the preset risk transmission threshold, the risk transmission level of the component is determined to be high-level transmission.

[0101] Conversely, if the risk transmission level is low, then the risk transmission level is determined to be low.

[0102] Output different alarm messages based on the risk transmission level:

[0103] When the risk transmission level is high, a high-risk alarm message is generated;

[0104] When the risk transmission level is low, a monitoring alert message is generated;

[0105] High-risk alerts are used to indicate that a component may cause multi-level risk propagation, requiring component repair or replacement; monitoring alerts are used to remind users to maintain periodic monitoring and version updates, without requiring emergency handling.

[0106] It should be noted that a version control repository is a code management repository used to store and manage the source code and dependency information of software components. It can be used to track the reference relationships between components and extract circular dependency information. The preset circular path threshold can be set according to the complexity of the overall dependency structure of the components and the scale of the project. For example, when there are many components and the dependency hierarchy is deep, a higher circular path threshold can be set. The preset risk transmission threshold can be set according to security requirements and risk tolerance. For example, for ordinary systems with relatively low security requirements or stable operating environments, the preset risk transmission threshold is set to a higher value to reduce the frequency of high-risk alarm information.

[0107] This step will rely on the combination of topological information and risk propagation characteristics to achieve a layer-by-layer mapping from structural complexity to risk transmission capability, enabling proactive early warning and refined hierarchical control of software supply chain risks under multi-source data conditions.

[0108] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0109] Also, the use of "including," "comprising," or "having" and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless otherwise specified, "or" means "and / or." Unless otherwise noted, the use of the positive is meant to encompass the negative, e.g., the use of "a" is meant to encompass "not a," the use of "at least one" is meant to encompass "zero or more," etc.

[0110] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of "at least one." In this document, the term "or" as used herein is used to mean "and / or," i.e., "A or B" means "A or B or both." Throughout this document, the term "comprising" or "comprises" means "including, but not limited to" or "containing, but not limited to," and the like. The term "consisting essentially of" means "including, but not limited to, integers which do not materially affect the essential characteristics of the subject matter." The term "consisting of" means "including, but not limited to," such that the only integers which can be present are those specifically named. As used herein, unless otherwise clear from context, the term "about" means ±10% of the value of that which follows, for example, about 90% means in the range of 81-99%, unless otherwise stated.

[0111] The various embodiments described in this specification are intended to cover all modifications and alternatives of the subject matter as falling within the scope of the disclosure. As used herein the expression "and / or" when used in a list of two or more items, that at least one of the identified list items is present in the combination, and it is not intended to mean that a combination of one of the items capable of being expressed from the combination.

[0112] It will be apparent to those skilled in the art that various modifications and variations can be made to the specific embodiments described herein without departing from the spirit or scope of the application. Thus, it is intended that the application covers the modifications and variations of this application provided they come within the scope of the appended claims and their equivalents.

Claims

1. A software supply chain risk analysis method based on multi-source data, characterized by: Includes the following steps: Step S1: Inspect the components of the software supply chain, obtain security fix information for each component through the code repository, calculate the security commit density of the component based on the security fix information, and detect the vulnerability fix latency of each component; Step S2: Generate vulnerability remediation trends for each component based on vulnerability remediation latency, assess the vulnerability anomaly characteristics of each component in conjunction with security submission density, set the software runtime cycle, and detect the runtime call frequency and number of loaded modules for each component within the software runtime cycle. Step S3: Evaluate the environmental dependency characteristics of each component based on the overall running call frequency and the number of loaded modules, set the evaluation priority level of each component in combination with the vulnerability anomaly characteristics, and determine whether to trigger the dependency evaluation mechanism based on the evaluation priority level. Step S4: In the dependency evaluation mechanism, detect the circular dependency information of the components, determine whether to count the dependency depth and number of impact paths of the components based on the circular dependency information and generate a risk transmission level, and output different alarm information based on the risk transmission level. In step S4, in the dependency evaluation mechanism, for components with an evaluation priority level of warning, the circular dependency information of the components, including the number of circular paths, is obtained through the version control repository. The number of loop paths is compared with a preset loop path threshold to determine whether to count the dependency depth and number of impact paths of the component: If the number of loop paths exceeds the preset loop path threshold, the dependency depth of the component and the number of impact paths will be counted. Conversely, without considering the depth of the component's dependency hierarchy and the number of impact paths, the risk propagation level of the component is judged to be low-level propagation.

2. The software supply chain risk analysis method based on multi-source data according to claim 1, characterized in that: In step S1, the software supply chain refers to the multi-layered interconnected system of various components, development tools, dependency libraries, operating environments, and participating organizations involved in the entire process of software product development, construction, testing, deployment, and use. The software supply chain components are inspected, and security fix information for each component is obtained by accessing the corresponding code repositories. Security remediation information includes the security remediation submission record, submission time, vulnerability number, and vulnerability discovery time.

3. The software supply chain risk analysis method based on multi-source data according to claim 2, characterized in that: In step S1, the security submission density is obtained by dividing the total number of security fix submission records for all vulnerabilities of the component within the preset time interval by the length of the time interval. For each security fix submission record in the component, the time of the vulnerability's first discovery and the time of the vulnerability fix submission are recorded, and the difference between the two is taken as the vulnerability fix delay.

4. The software supply chain risk analysis method based on multi-source data according to claim 1, characterized in that: In step S2, the vulnerability repair delay of each component within the preset time interval is arranged in chronological order, and the difference between two consecutive vulnerability repair delays is calculated as the repair change amount. Calculate the average of all patch changes as the vulnerability patching trend; By performing a linear combination calculation on security submission density and vulnerability remediation trends, the abnormal vulnerability characteristics of each component are obtained: ; in, The abnormal characteristics of the component's vulnerability To ensure safe submission density, As a trend in vulnerability remediation, The index value of the component. and These are the preset weighting coefficients.

5. The software supply chain risk analysis method based on multi-source data according to claim 1, characterized in that: In step S2, the software running cycle is set to define the time interval for observing the running behavior of each component when the software is in a predetermined normal running state; The ratio of the number of times a component is called by other components during the software runtime to the runtime length is used as the runtime call frequency. The total number of modules actually loaded by the component during the software runtime cycle will be used as the number of loaded modules.

6. The software supply chain risk analysis method based on multi-source data according to claim 1, characterized in that: In step S3, the product of the running call frequency and the number of loaded modules after standardization is used as the environment dependency feature of the component. The evaluation priority of components is assessed by combining environmental dependency characteristics and vulnerability anomaly characteristics using fuzzy reasoning methods. Environmental dependency characteristics and vulnerability anomaly characteristics are defined as input variables, and evaluation priority level is defined as output variable, which are divided into potential level, alert level and warning level. Develop a set of fuzzy rules to describe the impact of different input variables on the output variable; Fuzzy reasoning is performed based on fuzzy rules to obtain the evaluation priority level of each component; When the evaluation priority of a component is at the warning level, the dependency evaluation mechanism is triggered. Conversely, the dependency evaluation mechanism will not be triggered.

7. The software supply chain risk analysis method based on multi-source data according to claim 1, characterized in that: In step S4, when the number of loop paths exceeds a preset loop path threshold, the dependency structure of the component is traversed to obtain the dependency hierarchy depth of the component. The number of impact paths of a component is obtained by traversing the component's call reference relationship up the way. After standardizing the dependency hierarchy depth and the number of influence paths respectively, dependency hierarchy depth coefficient and influence path number coefficient are generated. Based on the dependency hierarchy depth coefficient and the number of influence paths coefficient, a weighted method is used to calculate the transmission parameters, and then the risk transmission index is calculated based on the transmission parameters.

8. The software supply chain risk analysis method based on multi-source data according to claim 7, characterized in that: In step S4, the risk transmission index is compared with a preset risk transmission threshold to generate the component's risk transmission level and alarm information. If the risk transmission index is greater than the preset risk transmission threshold, the risk transmission level of the component is determined to be high-level and a high-risk alarm message is generated. Conversely, if the risk transmission level is low, a monitoring alert will be generated.

Images