A method and system for predicting zero-day vulnerabilities of an open-source operating system

Abstract

The application discloses a prediction method and system for open source operating system zero-day vulnerabilities, and relates to the technical field of system security. The application constructs a software dependency topology graph, calculates the endogenous basic risk probability of a software package and the propagation weight of a dependent edge, uniformly incorporates the node self-risk and the dependent propagation risk into a probability graph model for iterative propagation calculation to obtain a global risk distribution. The application can not only quantify the propagation influence range of vulnerabilities in the dependency relationship, but also comprehensively evaluate the joint action of the self-risk of the software package and the dependent propagation risk, identify software packages without historical vulnerability records but with high propagation risks, thereby improving the accuracy of zero-day vulnerability prediction and the risk warning capability, and reducing the false positive rate and risk mismatch problems caused by traditional static evaluation. The application also discloses a prediction system for open source operating system zero-day vulnerabilities, which comprises an operating system layer, a resource layer and an application function layer.

Description

Technical Field

[0001] This application relates to the field of system security technology, and in particular to a method and system for predicting zero-day vulnerabilities in open-source operating systems. Background Technology

[0002] The rise of the modern open-source software supply chain has profoundly reshaped the software building paradigm, reducing development costs and significantly improving delivery efficiency. However, this high degree of reuse has also brought systemic coupling risks: millions of software packages are interwoven into a vast topological network through intricate dependencies, making it easy for even minor defects in a single component to trigger a global chain reaction (such as the Heartbleed event). Against this backdrop, software package risk assessment has become a standard practice for ensuring the security of the software supply chain.

[0003] In existing technologies, mainstream practices generally employ static scanning techniques based on known vulnerability databases (CVE / NVD). These methods primarily determine risk by matching component fingerprints in the Software Bill of Materials (SBOM) and combining them with general vulnerability scoring systems or static heuristics such as OpenSSFScorecard. Although such technologies have the advantages of low implementation threshold and intuitive results, they have gradually revealed the following limitations when facing the large-scale, dynamically evolving modern dependency ecosystem: 1. Survivorship Bias and Baseline Ratio Fallacy: Existing methods rely too heavily on historical vulnerability disclosure data, which fails to effectively identify components that are poorly maintained, lack CVEs, but are extremely vulnerable.

[0004] 2. Lack of topology propagation and blast radius modeling: Traditional checklist scanning only focuses on vulnerable components but ignores the reachability differences of dependency edges. It cannot quantify the conditional probability of risk propagation along dependency paths, resulting in the inability to distinguish between "direct core dependencies" and "deep unused transitive dependencies", which in turn causes serious false positives and risk mismatches.

[0005] 3. Static retrospectiveness and lag: Existing assessments are mostly static snapshots, which can only respond to disclosed vulnerabilities after the fact (Retrospective Patching). They lack the ability to model the dynamic evolution of dependencies during continuous integration / continuous deployment (CI / CD) and cannot provide forward-looking risk warnings before vulnerabilities occur. Summary of the Invention

[0006] This application provides a method and system for predicting zero-day vulnerabilities in open-source operating systems to solve the aforementioned technical problems.

[0007] Firstly, this application provides a method for predicting zero-day vulnerabilities in open-source operating systems, including: Step S100: Construct a software dependency topology graph, including constructing a directed dependency topology graph containing nodes and edges. , where nodes Represents software packages, edges This represents a dependency reference relationship; Step S200: Calculate the intrinsic basic risk probability of the node and dynamically assign propagation weights to each edge; Step S300: Input the endogenous basic risk probability and propagation weight into the probabilistic graphical model, and use an iterative algorithm to perform network-wide risk propagation calculation on the dependency topology graph to obtain a stable global risk distribution; Step S400: Based on the global risk distribution, classify the software packages into different risk levels.

[0008] Preferably, step S100 includes: Step S110: Obtain external data, including vulnerability databases, maintenance behavior data, and metadata; Step S120: Parse the target package and extract its dependencies; Step S130: Recursively resolve the sub-dependencies of the dependencies and construct a directed dependency topology graph. .

[0009] Preferred, node i Endogenous basic risk probability As shown in the following formula: ; ; in, Represents reliability weight. Indicates the score for direct evidence. Indicates the score for indirect evidence. Represents a node The highest CVSS value among historical CVE outbreaks.

[0010] Preferably, the direct evidence score is as follows: ; in, Indicates the power-law amplification parameter. This indicates a non-zero small baseline.

[0011] Preferably, the indirect evidence score is as follows: ； in, This represents the overall OpenSSF Scorecard score. This indicates the available coverage of the Scorecard check item. This represents the minimum usefulness retention factor.

[0012] Preferably, in step S200, dynamically assigning propagation weights to each edge includes: Retrieve the package version constraints, dependency types, and optional dependency identifiers corresponding to the dependency edges; Determine the version constraint correction factor based on the version constraints; Determine the dependency type correction factor based on the dependency type; Determine the optional dependency correction factor based on the optional dependency identifier; The base probability is combined with the version constraint correction coefficient, dependency type correction coefficient and optional dependency correction coefficient to obtain the propagation weight of the corresponding dependency edge. The propagation weight of each dependency edge is then used to construct a risk propagation matrix.

[0013] Preferred propagation weight As shown in the following formula: ； in, Represents the base probability. This represents the version constraint correction factor. This represents the dependency type correction factor. Indicates optional dependency correction coefficient, This indicates the upper limit of the propagation weight.

[0014] Preferably, step S300 includes: Step S310: Input the endogenous basic risk probability of each node as the initial risk value of the node into the probabilistic graphical model, and input the risk propagation matrix constructed based on the propagation weight into the probabilistic graphical model; Step S320: Update the risk value of each node according to the preset iteration rules based on the probabilistic graphical model. The probabilistic graphical model is configured as a Markov network model. Step S330: When the change in global risk probability obtained from two consecutive iterations is lower than a preset convergence threshold, stop the iteration to obtain a stable global risk distribution, as shown in the following formula: ; in, Represents a node i The probability of endogenous basic risks, Represents a node i In the t+1 Risk probability after round of iteration Represents a node i The set of all upstream dependent nodes, Indicates propagation weight, Indicates upstream dependency j In the t The current risk probability in the round of iteration.

[0015] Preferably, step S400 further includes determining whether the risk source of the software package is component-specific risk or dependency propagation risk based on the difference between the risk probability corresponding to the software package in the global risk distribution and the endogenous basic risk probability.

[0016] Secondly, this application provides a prediction system for zero-day vulnerabilities in open-source operating systems, comprising: Operating system layer; The resource layer runs on top of the operating system layer and includes a numerical computation and graph algorithm library, a vulnerability database, an OpenSSF Scorecard database, an evidence fusion algorithm library, and an NPM package registry. The application function layer, running on the resource layer, includes a topology construction module, an endogenous risk calculation module, a propagation matrix generation module, an iterative convergence engine module, and a hierarchical early warning module. The topology construction module interacts with the endogenous risk calculation module and the propagation matrix generation module. The endogenous risk calculation module and the propagation matrix generation module are connected to the iterative convergence engine module. The iterative convergence engine module is connected to the hierarchical early warning module to complete risk propagation calculation and risk early warning. The prediction method and system of this application have at least the following beneficial effects: (1) The prediction method of this application constructs a software dependency topology graph and calculates the intrinsic basic risk probability of the software package and the propagation weight of the dependency edge. It integrates the node's own risk and the dependency propagation risk into the probabilistic graph model for iterative propagation calculation to obtain the global risk distribution. It realizes dynamic modeling of the risk propagation process in the software supply chain. Compared with the existing technology that only performs static scanning based on historical vulnerability databases, this application can not only quantify the propagation impact range of vulnerabilities in dependency relationships, but also comprehensively evaluate the combined effect of the software package's own risk and the dependency propagation risk, identify software packages with no historical vulnerability records but with high propagation risk, thereby improving the accuracy of zero-day vulnerability prediction and risk warning capability, and reducing the false alarm rate and risk mismatch problem caused by traditional static assessment.

[0017] (2) This application breaks through the limitations of the basic ratio fallacy: This application no longer relies solely on "whether there are historical CVEs" to judge security, but instead identifies those components that are "extremely dangerous but currently have no CVEs" by integrating maintenance behavior data and historical data, effectively filling the gap in zero-day vulnerability prediction.

[0018] (3) This application achieves precise risk quantification at the topology level: Unlike traditional static inventory scanning, this application introduces trajectory-conditional propagation weights and probabilistic graphical models (Markov propagation mechanism), which can accurately quantify the "explosion radius", distinguish the actual threat differences between direct dependence and deep propagation dependence, and significantly reduce the false alarm rate.

[0019] (4) This application provides an interpretable risk attribution: By calculating the difference between the risk probability corresponding to the software package and the intrinsic basic risk probability, this application can clearly define whether the high risk of a package is due to its own code quality or the poor upstream and downstream environment, providing clear remediation guidance for security personnel (fixing code or changing dependencies). Attached Figure Description

[0020] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart of Embodiment 1 of this application; Figure 2 This is a flowchart of Embodiment 2 of this application; Figure 3 This is a framework diagram of the early warning system according to Embodiment 3 of this application; Figure 4 yes Figure 3 Technical architecture diagram of the application functional layer. Detailed Implementation

[0021] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0022] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0023] Example 1: like Figure 1 As shown, this embodiment discloses a method for predicting zero-day vulnerabilities in an open-source operating system, including steps S100 to S400.

[0024] Step S100: Construct a software dependency topology graph Collect metadata from the software ecosystem, parse dependencies between packages, and construct a directed dependency topology graph containing nodes and edges. , where nodes Represents software packages, edges This represents a dependency reference relationship.

[0025] Step S200: Calculate the intrinsic basic risk probability of the node and dynamically allocate propagation weights to each edge. Calculating the intrinsic basic risk probability and allocating propagation weights can be two sequential sub-steps or two parallel sub-steps; both are optional in this embodiment. For ease of description of the technical solution of this embodiment, it is assumed below that the intrinsic basic risk probability is calculated first, and then propagation weights are dynamically allocated to each edge.

[0026] I. Endogenous Basic Risk Probability of Computation Nodes For each package node Collect its historical vulnerability severity data (CVSS) and maintenance behavior data (OpenSSF metrics), nodes Endogenous basic risk probability It represents the probability that a vulnerability exists when it is not affected by dependency propagation. It is obtained by fusing a reliability-weighted index of direct evidence (CVSS score of historical CVE) and indirect evidence (OpenSSF Scorecard).

[0027] Direct evidence score : ; in, Represents a node The highest CVSS (Common Vulnerability Scoring System) score for historically occurring CVEs is generally between 0 and 10. It's important to note that NVD includes the CVSS score for CVEs (CVSS provides a method for scoring vulnerabilities based on their primary characteristics, reflecting their severity). Although the CVSS score is a vector, the output is a numerical value from 0 to 10, which can be directly queried within NVD. This represents the power-law amplification parameter, used to highlight critical vulnerabilities, and can be taken as 1.2 to 1.4. This represents a non-zero small baseline, set to 0.05, used to combat the baseline ratio fallacy.

[0028] Indirect evidence score : ； in, This represents the OpenSSF Scorecard overall score (the lower the score, the higher the risk). This indicates the available coverage of the Scorecard check item. Indicates the minimum usefulness retention factor, preferred. =0.67.

[0029] In this embodiment, when calculating the direct evidence score, an exponential mapping is performed on the historical vulnerability CVSS scores to establish a non-linear correspondence between the vulnerability severity and the direct evidence score. This highlights the impact of high-risk vulnerabilities on software package risks. At the same time, by assigning a non-zero baseline value to software packages without historical CVE records, the direct evidence score is prevented from degenerating to zero. This ensures that all software packages have basic risk representation capabilities and can continuously participate in risk calculations during subsequent evidence fusion and risk propagation processes. This improves the ability to predict unknown vulnerabilities and zero-day vulnerabilities and reduces the risk of missed detections due to missing historical vulnerability data.

[0030] In this embodiment, when calculating the indirect evidence score, the OpenSSF Scorecard comprehensive score is introduced to quantify the software package maintenance behavior, and the following is utilized: The function is modified to allow the indirect evidence score to be adaptively adjusted according to the completeness of the maintenance information. At the same time, by setting a minimum usefulness retention coefficient, the basic maintenance risk contribution is guaranteed even when the coverage is low, avoiding the distortion of risk assessment results due to missing maintenance data. This enhances the stability and continuity of indirect evidence, improves the reliability of subsequent evidence fusion results, and makes up for the deficiency that it is difficult to discover potentially high-risk software packages by relying solely on historical vulnerability data.

[0031] After calculating the direct evidence score and the indirect evidence score, the direct historical evidence and the indirect maintenance evidence are fused to generate a fused threat confidence score, which is then transformed into an exponential mapping function. Endogenous risk probability within the interval .

[0032] ; ; in, Represents a node Endogenous basic risk probability , Preferred Take 2.0, Indicates the reliability weight.

[0033] In this embodiment, a reliability-weighted + exponential fusion mechanism is adopted. This completely eliminates the basic ratio fallacy of "no CVE means security" while unifying the severity of historical vulnerabilities and open-source maintenance behavior into a strictly bounded probability space. It also naturally reserves an upper limit space for topology propagation, thereby significantly improving the hit rate of future unknown vulnerabilities with extremely low false positives.

[0034] Furthermore, this embodiment constructs a reliability-weighted fusion model of direct evidence scores and indirect evidence scores, enabling risk evidence from different sources to adaptively participate in risk calculation based on its credibility, avoiding risk assessment bias caused by single historical vulnerability data or single maintenance behavior data. It also utilizes an exponential mapping function to establish a nonlinear mapping relationship between fused evidence and endogenous basic risk probability, enabling the fusion result to be converted into a continuous and bounded risk probability, while maintaining responsiveness to changes in fused evidence.

[0035] Furthermore, this embodiment dynamically adjusts the reliability of direct evidence based on whether the software package has historical CVE records. This allows the credibility of direct evidence to adaptively change with the completeness of historical vulnerability information. When historical CVE records exist, the impact of historical vulnerability information on intrinsic risk assessment is increased, enabling known vulnerabilities to fully reflect their risk contribution. When historical CVE records are absent, the impact of default direct evidence values ​​on risk calculation is reduced, avoiding bias in risk assessment results due to missing historical vulnerability data. Simultaneously, by setting a global sensitivity parameter, a non-linear probability mapping is applied to the fused evidence strength. This ensures that the intrinsic base risk probability maintains good distinguishability for high-risk software packages while preventing premature saturation or excessively slow growth, providing stable input for subsequent dependency propagation calculations. The reliability weights and global sensitivity parameters in this embodiment can be adjusted according to different software ecosystems and engineering application requirements.

[0036] 2. Dynamically assign propagation weights to each edge to construct a trajectory-conditional risk propagation matrix. Based on the attributes of the dependent edges (such as semantic version range, dependency depth, and API call coverage), propagation weights are dynamically assigned to each edge. This weight represents the probability of a vulnerability successfully propagating from an upstream package to a downstream package. Specifically, it involves: first, obtaining the package version constraints, dependency types, and optional dependency identifiers corresponding to the dependency edges; then, determining the corresponding correction coefficients; next, combining the base probability and the correction coefficients to calculate the propagation weight of the corresponding dependency edge; and finally, constructing a trajectory-conditional risk propagation matrix. As shown in the following formula: ； This represents the base probability, which is the expected value of a Beta(2,5) distribution. It reflects that most dependencies only expose a portion of the APIs. The default value is 0.3. It should be noted that most projects only use a small portion of the APIs in the dependency package. In addition, the two parameters of the beta distribution have a strong engineering background. When it equals 2, it can be understood as observing 2 successful propagation attempts, and when it equals 5, it means observing 5 failed propagation attempts. The selection of this parameter comes from the analysis of the dependency graph of the NPM platform.

[0037] This represents the version constraint adjustment factor. The version constraint adjustment factor is determined based on the openness of the package version constraints. The stricter the version constraints, the larger the version constraint adjustment factor; the looser the version constraints, the smaller the version constraint adjustment factor, reflecting the probability of automatic upgrade to the vulnerability-fixed version. For example: Precise version = 1.2, ~= 0.9, >= / = 0.85, ^= 0.8, * / x / latest = 0.6, default = 0.8; Table 1 below shows the corresponding values ​​of the version constraint correction coefficients.

[0038] This represents the dependency type correction factor. Dependency types include runtime dependencies, bundled dependencies, peer dependencies, development dependencies, and optional dependencies. Different dependency types correspond to different dependency type correction factors to characterize the reachability of vulnerability propagation under different dependency relationships. Specifically: runtime (runtime dependency) = 1.0, bundled (bundled dependency) = 0.9, peer (peer dependency) = 0.8, dev (development dependency) = 0.5, optional (optional dependency) = 0.3, default = 0.8; This represents the optional dependency correction coefficient. If the dependency is optional, then... If the value is 0.3, then... Take 1.0.

[0039] This indicates the upper limit of the propagation weight; in this embodiment, it is preferred. We set it to 0.95 to prevent degradation of determinism.

[0040] In this embodiment, a propagation weight calculation model composed of basic probability, version constraint correction, dependency type correction, and optional dependency correction is constructed. This model transforms the static connection relationships in the traditional dependency graph into dynamic probability weights that reflect the actual propagation capability of vulnerabilities. It can automatically adjust the propagation intensity according to the different attributes of the dependency edges, reflecting both the high propagation risk caused by strict version locking and the weakening effect of relaxed version constraints, development dependencies, and optional dependencies on propagation capability. This significantly improves the realism and discriminativeness of dependency edge risk modeling. At the same time, the propagation weight upper limit constraint prevents the propagation probability from being infinitely amplified, ensuring that the subsequent risk propagation model has good numerical stability and iterative convergence characteristics, thereby improving the accuracy and reliability of vulnerability propagation simulation and zero-day vulnerability prediction results in large-scale software dependency networks.

[0041] Step S300: Perform time-series dynamic risk iteration convergence. The inherent basic risk probability and propagation weights are input into the probabilistic graphical model. In this embodiment, the preferred probabilistic graphical model includes a Markov network model. A fixed-point iterative algorithm is used to calculate the risk propagation across the entire network on the dependency graph. In each iteration, the total risk value of the node is updated according to the inherent risk of the node and the propagation weights of the incoming edges, until the change in the overall network risk probability is reached. = Below the preset convergence threshold This allows for a stable global risk distribution.

[0042] Specifically, it includes the following sub-steps: Step S310: Input the endogenous basic risk probability of each node as the initial risk value of the node into the Markov network model, and also input the risk propagation matrix constructed by the propagation weights corresponding to each dependent edge into the Markov network model. Step S320: Update the risk value of each node according to the preset iteration rules; Step S330: When the change in global risk probability obtained from two consecutive iterations is lower than a preset convergence threshold, stop the iteration to obtain a stable global risk distribution, as shown in the following formula: ; in, Represents a node i The probability of endogenous basic risks, Represents a node i In the t+1 Risk probability after round of iteration Represents a node i The set of all upstream dependent nodes, Indicates propagation weight, Indicates upstream dependency j In the t The current risk probability in the round of iteration.

[0043] The iterative formula in this embodiment uses a Markov update rule, taking endogenous risk as the baseline and dependency propagation as the increment, and fuses multi-source inputs in a probabilistic union manner. This ensures numerical stability while accurately quantifying the probability of transitive vulnerabilities being exposed in the supply chain. Furthermore, this embodiment boasts extremely high computational efficiency and scalability: based on an iterative convergence algorithm, it can complete full risk recalculation within minutes on large-scale dependency graphs containing millions of nodes, meeting the stringent real-time requirements of CI / CD pipelines.

[0044] Step S400: Zero-day vulnerability risk assessment and early warning Based on the converged global risk distribution, the software package is divided into different risk levels. Target components that still pose a high risk of propagation even without historical CVE records are identified, and warning information is output. The classification rules are as follows: Grade A: Low risk, top 25% of scores, representing software packages with extremely low endogeneous risk and weak dependence on propagation paths; Grade B: Low to medium risk, score 25%–50%, characterized by no obvious high-risk signals, but with some exposure to the software package; Grade C: Medium to high risk, with a score of 50%–75%, indicating a software package with high endogenous risk or located in a critical transmission path; Grade D: High risk, score above 75%, indicating a high-risk vulnerability with strong propagation capabilities, and located in the core topology of the software package.

[0045] This classification method ensures that each layer is statistically comparable, avoiding hierarchical imbalance caused by the long tail of risk distribution. In practice, the classification parameters and methods can be dynamically determined according to the evolution of software package risks to adapt to different practical needs of the development environment.

[0046] Example 2: like Figure 2 As shown, the difference between this second embodiment and the first embodiment is that step S400 in this second embodiment further includes risk attribution, that is, determining whether the risk source of the software package is component-specific risk or dependency propagation risk based on the difference between the risk probability corresponding to the software package in the global risk distribution and the endogenous basic risk probability. Specifically, determining the risk source is performed after the risk level classification step, and involves first calculating the residual. , This represents the risk probability after node convergence, and then it is attributed based on the residuals.

[0047] like ( To determine the threshold (which can be dynamically adjusted based on the experimental environment), it indicates that the high risk mainly originates from upstream dependencies, prompting developers to prioritize upgrading or replacing upstream dependencies rather than modifying their own software code.

[0048] Example 3: like Figure 3 and Figure 4 As shown, this embodiment discloses a prediction system for zero-day vulnerabilities in an open-source operating system. The prediction system is used to implement the prediction method in Embodiment 1 or Embodiment 2. The prediction system includes an operating system layer, a resource layer, and an application function layer.

[0049] The resource layer runs on top of the operating system layer and includes a numerical computation and graph algorithm library, a vulnerability database, an OpenSSF Scorecard database, an evidence fusion algorithm library, and an NPM package registry.

[0050] The application function layer runs on the resource layer and includes a topology construction module, an endogenous risk calculation module, a propagation matrix generation module, an iterative convergence engine module, and a hierarchical early warning module.

[0051] The topology construction module, used to execute step S100, is responsible for parsing software ecosystem metadata and constructing a directed dependency graph containing nodes and edges. This provides the basic topology structure for risk propagation. Specifically, it first calls the NPM package registry resource to obtain the target package and its dependency information, and then combines numerical computation and graph algorithm libraries to complete dependency resolution and graph structure construction, generating a directed dependency topology graph containing package nodes and dependency edges. The software dependency graph output by the topology construction module serves as the basic data for subsequent propagation analysis and risk calculation, and is simultaneously passed to the endogenous risk calculation module, the propagation matrix generation module, and the iterative convergence engine. More preferably, the topology construction module includes a dependency resolution submodule and a graph construction submodule.

[0052] The intrinsic risk calculation module is used to perform the intrinsic basic risk probability calculation in step S200. It integrates historical vulnerability severity and maintenance behavior data, eliminates conflicts through evidence theory, and generates the inherent risk probability of components unaffected by survivor bias. Specifically, after obtaining the package node information output by the topology construction module, the intrinsic risk calculation module calls the NVD / OSV vulnerability database to obtain historical vulnerability data for each package, calls the OpenSSF Scorecard database to obtain maintenance behavior data, and calls the evidence fusion algorithm library to complete multi-source evidence fusion calculation, generating the intrinsic risk probability corresponding to each package, thus completing the intrinsic basic risk probability calculation in step S200. The intrinsic risk calculation module sends the calculated node intrinsic risk as a node attribute to the iterative convergence engine. Further preferably, the intrinsic risk calculation module includes a data acquisition submodule and an evidence fusion submodule.

[0053] The propagation matrix generation module is used to dynamically allocate propagation weights to each edge and construct the propagation matrix in step S200. It dynamically allocates edge weights based on semantic version range and dependency depth, quantifying the actual reachability and propagation attenuation characteristics of vulnerabilities in the runtime environment. Specifically, the propagation matrix generation module receives the dependency edge information output by the topology construction module, calculates the propagation weights of each dependency edge based on attributes such as dependency version constraints, dependency type, and optional dependency flags, forms a risk propagation matrix, and completes the allocation of propagation weights and construction of the risk propagation matrix in step S200. The propagation matrix generation module calls numerical computation and graph algorithm libraries to complete the propagation weight calculation and sends the generated propagation matrix to the iterative convergence engine.

[0054] The iterative convergence engine module is used to execute step S300. Based on the Markov network, it performs a fixed-point iterative algorithm to quickly calculate the steady-state risk distribution of the entire network on a large-scale dependency graph, ensuring the convergence and timeliness of the calculation results. Specifically, it simultaneously receives the software dependency topology graph provided by the topology construction module, the node intrinsic risk probability provided by the intrinsic risk calculation module, and the propagation matrix provided by the propagation matrix generation module. It calls the numerical calculation and graph algorithm library to execute the fixed-point iterative algorithm based on the Markov network, and performs multiple rounds of propagation and update of the risks in the entire dependency network until the preset convergence condition is met, and obtains the stable global risk distribution of each software package. This module outputs the global risk probability and the risk propagation results of each node.

[0055] The graded early warning module executes step S400, mapping the converged risk values ​​to discrete levels. It distinguishes between code defects and supply chain contagion risks through residual analysis, outputting visualized decision-making early warning information. Specifically, it receives the global risk distribution output by the iterative convergence engine, classifies software package risk levels according to preset risk grading rules, and performs risk attribution analysis based on the difference between node-endogenous risk and converged risk. This identifies software packages with high propagation risk but no historical vulnerability records, generating zero-day vulnerability early warning information. Further preferably, the graded early warning module includes a risk grading submodule and a risk attribution factor module.

[0056] The entire early warning system in this embodiment adopts a pipelined collaborative working method. The topology construction module provides a unified data foundation for subsequent modules. The intrinsic risk calculation module and the propagation matrix generation module establish risk models from the node dimension and the edge dimension, respectively. The two modules can be calculated independently and in parallel or sequentially, and their calculation results are used as inputs to the iterative convergence engine. The iterative convergence engine is responsible for integrating node risks and edge propagation capabilities to complete the network-wide risk propagation calculation. The hierarchical early warning module uses the global risk distribution obtained from the final convergence to complete risk ranking, risk attribution, and early warning output. The early warning system in this embodiment can form a complete zero-day vulnerability prediction process, including data collection, topology construction, node risk assessment, edge propagation modeling, network-wide risk propagation, and risk early warning.

[0057] The following is a calculation example based on the early warning system: This computational example selects the NPM (Node Package Manager) ecosystem as the implementation object and Express.js (a widely used web server framework) as the target evaluation package. The process is as follows.

[0058] I. Implementation of the Topology Building Module (1) Dependency resolution submodule: It retrieves metadata from the NPM official registry. For the target package Express.js, the module parses its package.json file and extracts its dependencies (this is just an example and does not represent real dependency information). { "accepts":"~1.3.8", "body-parser":"^1.20.2" } (2) Graph construction submodule: recursively parse the sub-dependencies of these dependencies to construct a directed acyclic graph (DAG) containing about 50 nodes, where Express is the core node and its downstream is connected to multiple business application nodes that directly depend on it.

[0059] II. Implementation of the Endogenous Risk Calculation Module (1) Data collection submodule: For the key node accepts in the figure, the intrinsic risk calculation module performs the following operations: query the OSV vulnerability database and find that accepts has no CVE records in the past 3 years; query the OpenSSF Scorecard and find that its maintenance activity is good, but it lacks fuzzing configuration.

[0060] (2) Evidence fusion submodule: The module fuses “no CVE (low risk)” and “no fuzzing (high risk)” as two evidence sources. The module determines that although the package has no historical vulnerabilities, it still has a medium intrinsic risk due to the lack of automated security testing.

[0061] (3) Output: Probability of intrinsic risk in the generated accepts package III. Implementation of the Propagation Matrix Generation Module For the edge Express->accepts, the propagation matrix generation module analyzes its SemVer range to ~1.3.8: Due to the use of the tilde (~), which allows patch version updates, the module determines that its propagation determinism is high and assigns it a high base weight. Considering that accepts is the core library for HTTP request processing, the module determines that its API call coverage is extremely high. Taking both factors into account, the module assigns a propagation weight to the edge that generates this edge. This means that if Accepts is compromised, there is an 85% chance that Express will be affected.

[0062] IV. Implementation of the Iterative Convergence Engine The iterative convergence engine loads the above topology, intrinsic risk, and propagation matrix, and uses a Markov network to iteratively calculate the final risk value for each software package. After approximately 20 iterations, the risk value of all nodes in the entire graph changed by less than [a certain amount]. The engine confirmed that the overall network risk has reached a steady state.

[0063] V. Implementation of the Tiered Early Warning Module The hierarchical early warning module reads the converged results and sorts, classifies, and attributes the software packages in the entire database.

[0064] (1) Risk Classification Submodule: The module marks the top 5% of packages as Grade D (high risk). Although accepts has no CVE, it is still classified as high risk due to its core topology location and lack of testing.

[0065] (2) Risk attribution module: The module calculates the residuals. ΔP, like This indicates that the high risk in Express mainly stems from its upstream dependency (accepts), suggesting that developers prioritize upgrading the accepts package rather than modifying the Express code.

[0066] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for predicting zero-day vulnerabilities in open-source operating systems, characterized in that, include: Step S100: Construct a software dependency topology graph, including constructing a directed dependency topology graph containing nodes and edges. , where nodes Represents software packages, edges This represents a dependency reference relationship; Step S200: Calculate the intrinsic basic risk probability of the node and dynamically assign propagation weights to each edge; Step S300: Input the endogenous basic risk probability and propagation weight into the probabilistic graphical model, and use an iterative algorithm to perform network-wide risk propagation calculation on the dependency topology graph to obtain a stable global risk distribution; Step S400: Based on the global risk distribution, classify the software packages into different risk levels.

2. The prediction method according to claim 1, characterized in that, Step S100 includes: Step S110: Obtain external data, including vulnerability databases, maintenance behavior data, and metadata; Step S120: Parse the target package and extract its dependencies; Step S130: Recursively resolve the sub-dependencies of the dependencies and construct a directed dependency topology graph. .

3. The prediction method according to claim 1 or 2, characterized in that, node i Endogenous basic risk probability As shown in the following formula: ； ； in, Represents reliability weight, Indicates the score for direct evidence. Indicates the score for indirect evidence. Represents a node The highest CVSS value among historical CVE outbreaks.

4. The prediction method according to claim 3, characterized in that, The direct evidence score is shown in the following formula: ； in, Indicates the power-law amplification parameter. This indicates a non-zero small baseline.

5. The prediction method according to claim 4, characterized in that, The indirect evidence score is shown in the following formula: ； in, This represents the overall OpenSSF Scorecard score. This indicates the available coverage of the Scorecard check item. This represents the minimum usefulness retention factor.

6. The prediction method according to claim 1, characterized in that, In step S200, dynamically assigning propagation weights to each edge includes: Retrieve the package version constraints, dependency types, and optional dependency identifiers corresponding to the dependency edges; Determine the version constraint correction factor based on the version constraints; Determine the dependency type correction factor based on the dependency type; Determine the optional dependency correction factor based on the optional dependency identifier; The base probability is combined with the version constraint correction coefficient, dependency type correction coefficient and optional dependency correction coefficient to obtain the propagation weight of the corresponding dependency edge. The propagation weight of each dependency edge is then used to construct a risk propagation matrix.

7. The prediction method according to claim 6, characterized in that, Propagation weight As shown in the following formula: ； in, Represents the base probability. This represents the version constraint correction factor. This represents the dependency type correction factor. Indicates optional dependency correction coefficients. This indicates the upper limit of the propagation weight.

8. The prediction method according to claim 1, characterized in that, Step S300 includes: Step S310: Input the endogenous basic risk probability of each node as the initial risk value of the node into the probabilistic graphical model, and input the risk propagation matrix constructed based on the propagation weight into the probabilistic graphical model; Step S320: Update the risk value of each node according to the preset iteration rules based on the probabilistic graphical model. The probabilistic graphical model is configured as a Markov network model. Step S330: When the change in global risk probability obtained from two consecutive iterations is lower than a preset convergence threshold, stop the iteration to obtain a stable global risk distribution, as shown in the following formula: ； in, Represents a node i The probability of endogenous basic risks, Represents a node i In the t+1 Risk probability after round of iteration Represents a node i The set of all upstream dependent nodes, Indicates propagation weight, Indicates upstream dependency j In the t The current risk probability in the round of iteration.

9. The prediction method according to claim 8, characterized in that, Step S400 further includes determining whether the risk source of the software package is component-specific risk or dependency propagation risk based on the difference between the risk probability corresponding to the software package in the global risk distribution and the endogenous basic risk probability.

10. A prediction system for zero-day vulnerabilities in an open-source operating system, characterized in that, include: Operating system layer; The resource layer runs on top of the operating system layer and includes a numerical computation and graph algorithm library, a vulnerability database, an OpenSSF Scorecard database, an evidence fusion algorithm library, and an NPM package registry. The application function layer, which runs on the resource layer, includes a topology construction module, an endogenous risk calculation module, a propagation matrix generation module, an iterative convergence engine module, and a hierarchical early warning module. The topology construction module interacts with the endogenous risk calculation module and the propagation matrix generation module, respectively. The endogenous risk calculation module and the propagation matrix generation module are connected to the iterative convergence engine module, respectively; the iterative convergence engine module is connected to the hierarchical early warning module to complete risk propagation calculation and risk early warning.

Images