A system and method for sbom-based automotive software supply chain security and open source governance

Abstract

The application discloses a kind of based on SBOM's automobile software supply chain security and open source governance system and method, by identifying the bill of materials SBOM of automobile software provided by supplier, obtain the basic information of software containing multiple components, software extension information;Software basic information in SBOM is matched with trusted vulnerability library, obtain all known vulnerabilities of SBOM;According to the dependency in SBOM, the influence range of each vulnerability is analyzed, and the affected software product and vehicle model are determined;According to the software product, vehicle model, vulnerability hazard affected, determine vulnerability level;Known vulnerabilities of component and vulnerability level are bound with component in SBOM, form SBOM risk view, determine repair scheme based on risk view;From SBOM identification, vulnerability matching, risk assessment, repair scheme determination to SBOM update, cover the whole process of supply chain security management, form the closed-loop management from vulnerability discovery to repair, ensure that the problem is solved.

Description

Technical Field

[0001] This invention belongs to the field of automotive software supply chain security management, specifically involving an automotive software supply chain security and open-source governance system and method based on Software Bill of Materials (SBOM). Background Technology

[0002] With the digital transformation of the automotive industry, the importance of software in automotive products is becoming increasingly prominent, and its code volume is growing exponentially. In recent years, attacks on the software supply chain have been increasing, and software is facing serious security threats, especially in the automotive software supply chain where security incidents are frequent.

[0003] Currently, automotive software supply chain security management methods have the following shortcomings: lack of management of the entire lifecycle of software components, inability to effectively track information such as the source, version, and dependencies of components, prominent security issues of open source components, many open source components have known vulnerabilities, but due to the lack of effective management mechanisms, these vulnerabilities have not been patched in a timely manner, insufficient information sharing and collaborative work increase security risks, and make it difficult to coordinate security management among various links in the supply chain. Summary of the Invention

[0004] The technical solution adopted by the present invention to solve the above technical problems is as follows: A method for automotive software supply chain security and open-source governance based on SBOM, comprising the following steps: S1. Identify the Bill of Materials (SBOM) for automotive software provided by the supplier to obtain basic software information and extended software information containing multiple components; S2. Match the basic software information in the SBOM with the trusted vulnerability database to obtain all known vulnerabilities in the SBOM; S3. Based on the dependencies in the SBOM, analyze the scope of impact of each vulnerability and determine the affected software artifacts and vehicle models; determine the vulnerability level based on the affected software artifacts, vehicle models, and vulnerability severity. S4. Bind the known vulnerabilities and vulnerability levels of the components to the components in the SBOM to form an SBOM risk view; S5. Automatically associate vulnerable components in the SBOM with a trusted patch library via API, and determine the verified remediation plan for the vulnerability based on the SBOM risk view. S6. After fixing the components corresponding to the vulnerability according to the verified remediation plan, regenerate the SBOM.

[0005] Furthermore, the basic software information includes: author information, timestamp, component name, component version, component hash value, and unique identifier; the extended software information includes: dependency relationships, inclusion relationships, software intellectual property information, and associated vulnerability information; wherein the software intellectual property information includes: open source license copyright and open standards, and third-party authorization information.

[0006] Furthermore, step S2 also includes using the SCA tool to scan the software intellectual property information by calling its built-in SPDX public database, license text library, and policy template library to obtain the license and copyright statement.

[0007] Further, step S2 includes: The basic software information in the SBOM is matched with a trusted vulnerability database to obtain all known vulnerabilities in the SBOM, including: S201. Convert the basic software information into the CPE standard format of the universal platform; S202. Use the standardized CPE string to query the trusted vulnerability database; If the query is successful, a list of CVEs related to the CPE is returned, including a detailed description, CVSS score, and severity level information for each CVE. If the CPE match fails, for components without a standard CPE name or with custom names in the supplier's SBOM, the component's functional description, application scenario, compatible vehicle model, and development language are extracted. Based on the automotive software component knowledge base, the custom component name is semantically matched with industry standard components and mapped to the equivalent CPE component identifier. If the match is successful, the corresponding CVE and CVSS are returned. If the CPE match fails again, a feature vector is constructed for each component in the SBOM. The feature vector includes: version serial number, release date, source reliability, maintenance activity, license type, and number of dependencies, where the number of dependencies represents the number of other components that depend on the current component. Further, step S202 includes: S2021. Using labeled historical data, train an SVM classifier, where the SVM classifier kernel function is a radial basis function (RBF). S2022, the feature vector of the input node, and the risk probability score of the output node of the SVM classifier.

[0008] Further, step S3 includes: S301. Convert the SBOM into a directed graph, where each node represents a software component in the SBOM, and the edges represent the dependencies between components, with the direction from the dependent end to the dependent end; the node features include: the feature vector of the SVM, the risk probability score obtained by the SVM classifier, the known list of CVEs and CVSS scores of the component; S302. Using the trained GNN model, simulate the propagation process of vulnerability risk in the dependency graph constructed in step S301, and calculate the risk value of each node in the global context; this risk value is a dynamic risk value. S303. Sort all nodes in the graph in descending order based on their context risk values ​​output by the GNN. S304. The vulnerability score is determined based on the number of affected software artifacts, vehicle models, and the severity of the vulnerability. S305. Obtain the second vulnerability score based on the context risk value score and the first vulnerability score, and determine the vulnerability level based on the second score.

[0009] Alternatively, step S3 may include: S301. Deconstruct all software components and edges from the SBOM. Software component nodes include five types of heterogeneous nodes: vehicle basic OS nodes, vehicle control middleware nodes, safety-critical business component nodes, general open-source third-party component nodes, and vehicle entertainment non-safety-critical component nodes. Among them, safety-critical business component nodes include: autonomous driving perception, chassis control, power control, and braking and steering components. Edge types include four types: strong dependency directed edges: edges connecting safety-critical business component nodes and OS nodes or vehicle control middleware nodes; weak dependency directed edges: edges connecting entertainment components and general open-source library nodes; nested component edges, indicating that the parent software artifact contains several child components; and component version iteration related edges, indicating the association between different iteration versions of the same component. S302. Construct a heterogeneous graph G=(V, E, Tv, Te), where V represents the set of all software component nodes; E represents the set of directed edges that depend on each component; Tv={Tv1, Tv2, Tv3, Tv4, Tv5} represents 5 types of nodes; and Te={Te1, Te2, Te3, Te4} represents 4 types of edges. Each node is accompanied by an original feature vector: x i =[f SVMi RiskScore i CVEList i CVSS i ]; Where, x i This represents the original comprehensive feature vector of the i-th software component node in the SBOM dependency graph. It is composed of the SVM feature vector, SVM risk probability score, CVE vulnerability list, and CVSS hazard score, and serves as the original input to the GNN / HGNN model. f SVMiIt is the high-dimensional SVM feature vector corresponding to the i-th software component node, composed of the component version sequence number, release duration, source reliability, maintenance activity, license type, and number of dependencies, used to characterize the component's inherent attributes and basic vulnerability characteristics; RiskScore i CVEList is the static risk probability score output by the SVM classifier for the i-th component node, representing the prior probability that the component has a security vulnerability without topological dependencies; i It is a list of all CVE vulnerability IDs matched for the i-th software component, used to characterize the number of vulnerabilities, vulnerability types, and historical vulnerability richness of the component, serving as an inherent feature of the node vulnerability dimension; CVSS i It is the CVSS quantitative hazard score of the CVE vulnerability corresponding to the i-th component, which represents the static severity level of the vulnerability of a single component itself; S303, Heterogeneous Graph Feature Mapping and Type-Specific Embedding: A separate embedding layer is set for each type of node, and the adjacency weight matrix is ​​set according to the edge type; H is set. i (l) =Emb1(x i Emb2(x) i Emb3(x) i Emb4(x) i Emb5(x) i Emb represents the embedding layer, x i = the original feature vector of the i-th node, Emb i (x i ) represents the dedicated embedding layer for the i-th type of node, which is the original feature x of node i. i Perform feature transformation; where Emb i In this context, 'i' represents the node type: i=1 for the in-vehicle basic OS node, i=2 for the vehicle control middleware node, i=3 for the safety-critical business component node, i=4 for the general open-source third-party component node, and i=5 for the in-vehicle entertainment non-safety-critical component node; the adjacency convolution weight (W) for each type of edge is set. e1 W e2 W e3 W e4 ); S304 employs Heterogeneous Graph Convolutional Network (HGCN) for layer-by-layer aggregation. For target node i, neighboring nodes are grouped according to their edge types. Neighbors of the same edge type are aggregated using the same set of convolutional parameters. Aggregation results from different edge types are concatenated or weighted to obtain a new node representation. The aggregation model is as follows: h i (l+1) =σ(∑ e∈Te W e ×∑j∈Ni(e) h j (l) ); N i (e) represents all adjacent nodes connected to node i through edge type e; W e σ represents the convolution parameters specific to each edge, and σ represents the non-linear activation function. S305. In HGNN propagation, introduce the automotive industry business prior coefficient and set differentiated risk propagation gain or attenuation multiple for different types of nodes. S306. Output hierarchical heterogeneous risk value for SBOM risk rating; S3061, The final output of the model for each node: h i HGNN = Heterogeneous graph global context risk value; S3062, then merge with the original first score S1: S2 = α × h i HGNN + β× S1.

[0010] Further, step S4 includes: S401. Set the visualization attributes of each node in the directed graph, and associate the color and size of the node with the second score; S402. Associate the shape of the nodes with the type of vulnerability to form a directed graph risk heatmap.

[0011] A SBOM-based automotive software supply chain security and open-source governance system for implementing SBOM-based automotive software supply chain security and open-source governance methods, the system comprising: The SBOM identification module is used to identify the SBOM of automotive software provided by the supplier, and obtain basic software information and software extension information containing multiple components. The vulnerability identification module is used to match the basic software information in the SBOM with a trusted vulnerability database to obtain all known vulnerabilities in the SBOM. The risk assessment module is used to analyze the impact scope of each vulnerability based on the dependencies in the SBOM, determine the affected software artifacts and vehicle models, and determine the vulnerability level based on the affected software artifacts, vehicle models, and vulnerability severity. The risk visualization module is used to bind the known vulnerabilities and vulnerability levels of components to the components in the SBOM, forming a risk view of the SBOM; The vulnerability remediation module is used to automatically associate vulnerable components in the SBOM with a trusted patch library via API, and determine verified remediation solutions for the vulnerabilities based on the SBOM risk view. The SBOM update module is used to regenerate the SBOM after fixing the components corresponding to the vulnerabilities according to the verified remediation plan.

[0012] A computer-readable storage medium storing a computer program, characterized in that a processor executes the computer program to implement a SBOM-based automotive software supply chain security and open-source governance method.

[0013] A terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement an SBOM-based automotive software supply chain security and open-source governance approach.

[0014] The beneficial effects of this invention are as follows: 1) By using the SBOM-based automotive software supply chain security and open-source governance method of this invention, the transparency and traceability of the automotive software supply chain can be improved, helping enterprises to effectively manage software components and reduce security risks.

[0015] 2) By building and applying SBOM, enterprises can clearly understand the components and sources of software products, achieve comprehensive monitoring of the software supply chain, provide real-time security monitoring and early warning capabilities, and enable enterprises to promptly discover security issues in software components and take corresponding measures.

[0016] 3) This invention uses an SVM classifier and a GNN model, combined with historical data and graph structure information, to improve the accuracy of risk assessment. The GNN model can simulate the propagation of vulnerability risks in the dependency graph, calculate dynamic risk values, and reflect the real-time risk status of components. By periodically regenerating the SBOM, the timeliness and accuracy of supply chain information are ensured.

[0017] 4) From SBOM identification, vulnerability matching, risk assessment, and remediation solution determination to SBOM updates, the entire supply chain security management process is covered. This forms a closed-loop management system from vulnerability discovery to remediation, ensuring that problems are thoroughly resolved. Through this systematic, automated, and dynamic management approach, the security and open-source governance efficiency of the automotive software supply chain are significantly improved, effectively addressing the increasingly complex software supply chain security challenges.

[0018] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above description and other objects, features and advantages of the present invention more obvious and understandable, preferred embodiments are provided and described in detail below. Attached Figure Description

[0019] 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 invention. Furthermore, the same reference numerals denote the same parts throughout the drawings.

[0020] Figure 1 This is a structural diagram of an SBOM-based automotive software supply chain security and open-source governance system. Detailed Implementation

[0021] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0022] In the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," "fixing," etc., should be interpreted broadly. For example, they can refer to a connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0023] Example 1 A method for automotive software supply chain security and open-source governance based on SBOM, comprising the following steps: S1. Identify the Bill of Materials (SBOM) for automotive software provided by the supplier to obtain basic software information and extended software information containing multiple components. The basic software information includes: author information, timestamp, component name, component version, component hash value, and unique identifier. The extended software information includes: dependency relationships, inclusion relationships, software intellectual property information, and associated vulnerability information. Among them, the software intellectual property information includes: open source license copyright and open standards, and third-party authorization information. S2. Match the basic software information in the SBOM with the trusted vulnerability database to obtain all known vulnerabilities in the SBOM; use the SCA tool to scan the software intellectual property information by calling its built-in SPDX public database, license text library, and policy template library to obtain the license and copyright statement. This involves matching the basic software information in the SBOM with a trusted vulnerability database to obtain all known vulnerabilities in the SBOM, including: S201. Convert the basic software information into the CPE standard format of the universal platform; S202. Using the standardized CPE string, query a trusted vulnerability database. If the query is successful, a list of CVEs related to the CPE is returned, including a detailed description, CVSS score, and severity level information for each CVE. If the CPE match fails, for components without a standard CPE name or with custom names in the supplier's SBOM, the component's functional description, application scenario, compatible vehicle model, and development language are extracted. Based on the automotive software component knowledge base, the custom component name is semantically matched with industry standard components and mapped to an equivalent CPE component identifier. If the match is successful, the corresponding CVE and CVSS are returned. If the CPE match fails again, a feature vector is constructed for each component in the SBOM. The feature vector includes: version serial number, release date, source reliability, maintenance activity, license type, and number of dependencies, where the number of dependencies represents the number of other components that depend on the current component.

[0024] The reliability of the source includes official releases and third-party releases.

[0025] Maintaining activity includes the number of code commits made within a year.

[0026] S2021. Using labeled historical data, i.e., identifying known vulnerabilities in which components, train an SVM classifier. The kernel function of the SVM classifier is the radial basis function (RBF). S2022: Input its feature vector, and the SVM classifier outputs a risk probability score; A high risk probability score means that the component should be prioritized for review even if there is no CVE match yet. For components with matched CVEs, the SVM score can be used as an additional dimension for risk prioritization; for example, a poorly maintained component with a questionable origin may have a high overall risk even with only one medium-risk CVE. This vulnerability identification and risk assessment method, which combines CPE standard matching and SVM classifiers, is not only comprehensive and accurate but also has strong prioritization capabilities, scalability, practicality, and adaptability, effectively supporting security management and open-source governance in the automotive software supply chain.

[0027] This method is applicable to various types of software components, whether open-source or third-party, and can perform risk analysis through CPE matching and feature vector evaluation. Furthermore, by adjusting the training data and feature weights of the SVM classifier, it can adapt to different security needs and risk preferences, meeting the security management requirements of different organizations. Using labeled historical data to train the SVM classifier enables the model to learn the relationship between component features and vulnerability risk.

[0028] S3. Based on the dependencies in the SBOM, analyze the scope of impact of each vulnerability and determine the affected software artifacts and vehicle models; determine the vulnerability level based on the affected software artifacts, vehicle models, and vulnerability severity. S301. Convert the SBOM into a directed graph, where each node represents a software component in the SBOM, and the edges represent the dependencies between components, with the direction from the dependent end to the dependent end; the node features include: the feature vector of the SVM, the risk probability score obtained by the SVM classifier, the known list of CVEs and CVSS scores of the component; S302. Using the trained GNN model, simulate the propagation process of vulnerability risk in the dependency graph constructed in step S301, and calculate the risk value of each node in the global context; this risk value is a dynamic risk value. S303. Sort all nodes in the graph in descending order based on their context risk values ​​output by the GNN. S304. The vulnerability score is determined based on the number of affected software artifacts, vehicle models, and the severity of the vulnerability. S305. Obtain the second vulnerability score based on the context risk value score and the first vulnerability score, and determine the vulnerability level based on the second score.

[0029] The specific process includes: Furthermore, the feature vector of node i is x. i ,but: x i =[f SVMi RiskScore i CVEList i CVSS i ] Where: f SVMi This is the feature vector of the SVM classifier. RiskScore i This is the risk probability score obtained by the SVM classifier. CVEList i This is a list of known CVEs for this component. CVSS i This is the CVSS score of this component.

[0030] Furthermore, if the output of the GNN model is hi, then: hi=GNN(x i ,G) Where: hi is the global context risk value of node i. G is the dependency graph.

[0031] The sorted node sequence is N sorted Then: N sorted =sort(h1,h2,…,h n ) Where n is the number of nodes in the graph.

[0032] Furthermore, if the vulnerability's first score is S1, then: S1=w1×AffectedArtifacts+w2×VehicleModels+w3×Severity in: w1, w2, and w3 are weighting coefficients.

[0033] Here, AffectedArtifacts represents the number of affected software artifacts. VehicleModels represents the number of affected vehicle models. Severity represents the severity of the vulnerability, such as the CVSS score. All of the above parameters are normalized.

[0034] Furthermore, if the vulnerability's second score is S2, then: S2=α×hi+β×S1 in: α and β are weighting coefficients, where α = 0.9 and β = 0.1. hi is the context risk value output by the GNN model. S1 is the first score of the vulnerability. That is, the second score is an optimization based on the first score. Optionally, the relationship between static and dynamic evaluation can also be measured based on actual needs.

[0035] Furthermore, GNN models include message-passing neural networks, graph convolutional networks, and graph attention networks; Downgrade Case: A vulnerability with a CVSS score of 8.0 (high risk) may be downgraded in priority if it exists in a deprecated deep library without network access. The GNN model will give it a lower overall risk score, such as 3.5, because it is at the "end" of the graph and has a low neighbor risk aggregation value.

[0036] Upgrade Case: A vulnerability with a CVSS score of 5.0 (medium risk) exists in a basic component that is directly relied upon by many core business services (i.e., the node has a high in-degree in the graph and is on the critical path). The GNN model will give it a higher comprehensive risk score, such as 8.5, due to its wide risk impact, thus raising its priority to the highest level (P0) and requiring immediate fix.

[0037] By following the steps and formulas described above, the vulnerability risks in a SBOM can be systematically assessed and prioritized, ensuring that high-risk vulnerabilities are addressed first. This method combines global context analysis using graph neural networks (GNNs) with traditional vulnerability scoring methods, improving the accuracy and efficiency of vulnerability management.

[0038] By combining CVSS scores, remediation feasibility, and impact scope to determine the priority of remediation strategies, the comprehensiveness and effectiveness of remediation efforts can be ensured. This multi-dimensional evaluation method considers not only the severity of the vulnerability but also the feasibility of remediation and its impact on business operations, enabling security teams to manage vulnerability remediation work more efficiently and ensuring system security and stability.

[0039] Alternatively, step S3 includes: S301. Deconstruct all software components and edges from the SBOM. Software component nodes include five types of heterogeneous nodes: vehicle basic OS nodes, vehicle control middleware nodes, safety-critical business component nodes, general open-source third-party component nodes, and vehicle entertainment non-safety-critical component nodes. Among them, safety-critical business component nodes include: autonomous driving perception, chassis control, power control, and braking and steering components. Edge types include four types: strong dependency directed edges: edges connecting safety-critical business component nodes and OS nodes or vehicle control middleware nodes; weak dependency directed edges: edges connecting entertainment components and general open-source library nodes; nested component edges, indicating that the parent software artifact contains several child components; and component version iteration related edges, indicating the association between different iteration versions of the same component. S302. Construct a heterogeneous graph G=(V, E, Tv, Te), where V represents the set of all software component nodes; E represents the set of directed edges that depend on each component; Tv={Tv1, Tv2, Tv3, Tv4, Tv5} represents 5 types of nodes; and Te={Te1, Te2, Te3, Te4} represents 4 types of edges. Each node is accompanied by an original feature vector: x i =[f SVMi RiskScore i CVEList i CVSS i ]; Where, x i This represents the original comprehensive feature vector of the i-th software component node in the SBOM dependency graph. It is composed of the SVM feature vector, SVM risk probability score, CVE vulnerability list, and CVSS hazard score, and serves as the original input to the GNN / HGNN model. f SVMi It is the high-dimensional SVM feature vector corresponding to the i-th software component node, composed of the component version sequence number, release duration, source reliability, maintenance activity, license type, and number of dependencies, used to characterize the component's inherent attributes and basic vulnerability characteristics; RiskScore iCVEList is the static risk probability score output by the SVM classifier for the i-th component node, representing the prior probability that the component has a security vulnerability without topological dependencies; i It is a list of all CVE vulnerability IDs matched for the i-th software component, used to characterize the number of vulnerabilities, vulnerability types, and historical vulnerability richness of the component, serving as an inherent feature of the node vulnerability dimension; CVSS i It is the CVSS quantitative hazard score of the CVE vulnerability corresponding to the i-th component, which represents the static severity level of the vulnerability of a single component itself; S303, Heterogeneous Graph Feature Mapping and Type-Specific Embedding: A separate embedding layer is set for each type of node, and the adjacency weight matrix is ​​set according to the edge type; H is set. i (l) =Emb1(x i Emb2(x) i Emb3(x) i Emb4(x) i Emb5(x) i Emb represents the embedding layer, x i = the original feature vector of the i-th node, Emb i (x i ) represents the dedicated embedding layer for the i-th type of node, which is the original feature x of node i. i Perform feature transformation; where Emb i In this context, 'i' represents the node type: i=1 for the in-vehicle basic OS node, i=2 for the vehicle control middleware node, i=3 for the safety-critical business component node, i=4 for the general open-source third-party component node, and i=5 for the in-vehicle entertainment non-safety-critical component node; the adjacency convolution weight (W) for each type of edge is set. e1 W e2 W e3 W e4 ); S304 employs Heterogeneous Graph Convolutional Network (HGCN) for layer-by-layer aggregation. For target node i, neighboring nodes are grouped according to their edge types. Neighbors of the same edge type are aggregated using the same set of convolutional parameters. Aggregation results from different edge types are concatenated or weighted to obtain a new node representation. The aggregation model is as follows: h i (l+1) =σ(∑ e∈Te W e ×∑ j∈Ni(e) h j (l) ); N i (e) represents all adjacent nodes connected to node i through edge type e; W eσ represents the convolution parameters specific to each edge, and σ represents the non-linear activation function. S305. In HGNN propagation, introduce the automotive industry business prior coefficient and set differentiated risk propagation gain or attenuation multiple for different types of nodes. Safety-critical component nodes: Risk propagation gain × 1.5; OS / underlying middleware nodes: Upward propagation gain × 1.3; General open-source components: Propagation coefficient × 1.0; Entertainment-related non-critical components: Propagation attenuation × 0.6; S306. Output hierarchical heterogeneous risk value for SBOM risk rating; S3061, The final output of the model for each node: h i HGNN = Heterogeneous graph global context risk value; S3062, then merge with the original first score S1: S2 = α × h i HGNN + β× S1.

[0040] h i HGNN The node global context dynamic risk value output by the HGNN model represents the component's comprehensive risk transmission capability and global hazard level in the heterogeneous dependency topology of SBOM; By using the aforementioned HGNN (Heterogeneous Graph Neural Network), heterogeneous graph data containing multiple types of nodes and relationships can be modeled. By setting independent embedding layers for different types of nodes and configuring exclusive convolutional weights for different types of dependency edges, differentiated feature aggregation and risk propagation can be achieved, adapting to the complex dependency structure of multi-level and multi-role software components in automotive SBOM.

[0041] Heterogeneous graph global context risk value h i HGNN This is a normalized comprehensive risk metric output for the i-th software component node after multi-layer feature aggregation and risk propagation simulation of the heterogeneous network of the vehicle SBOM software dependency using a heterogeneous graph neural network (HGNN). This value integrates the component's inherent characteristics (SVM feature vector, vulnerability probability, CVE vulnerability list, CVSS hazard score), node type attributes, the strength of heterogeneous dependency edges, and the risk transmission effect under the overall network dependency topology. It characterizes the dynamic real risk level of the component from a global network context perspective, with values ​​normalized to the [0,1] range. A larger value indicates a stronger global security risk and propagation impact of the component in the automotive software supply chain. By replacing the original ordinary GNN output with heterogeneous GNN output, we can achieve the following: distinguish component types, distinguish the strength of dependencies, automatically amplify the risks of core components and automatically converge non-core components, and make the vulnerability impact range assessment more consistent with the actual architecture of the whole vehicle domain / ECU.

[0042] S4. Bind the known vulnerabilities and vulnerability levels of the components to the components in the SBOM to form an SBOM risk view; S401. Set the visualization attributes of each node in the directed graph, and associate the color and size of the node with the second score; S402. Associate the shape of the nodes with the type of vulnerability to form a directed graph risk heatmap.

[0043] In the heat map, Node colors: Red nodes are high-risk core nodes that require immediate attention. Green nodes are relatively safe.

[0044] Node size: The larger the node, the higher the risk, which is very prominent in the graph.

[0045] Node placement: With a hierarchical layout, the nodes at the top of the diagram typically represent the final application, while the bottom represents the underlying libraries. The path of risk (in red) propagating upwards from the bottom is readily apparent.

[0046] Cluster structure: Tightly connected components form a cluster. If an entire cluster turns red, it indicates that the functional module has a systemic risk.

[0047] The shape of a node in a heatmap indicates the type of vulnerability. If a component has multiple vulnerabilities, the node is set to a circle.

[0048] S5. Automatically associate vulnerable components in the SBOM with a trusted patch library via API, and determine the verified remediation plan for the vulnerability based on the SBOM risk view. S501. Set the standard structured fields for patch schemes in the trusted patch library; S502. Based on the security level of the node vulnerability in the SBOM risk view, and in descending order of risk, call the API of the trusted patch library. For each CVE identified on the node, the patch library returns all recorded remediation solutions for that CVE. The vulnerability management platform binds the CVE details and remediation solution list to the corresponding component in the SBOM.

[0049] S6. After fixing the components corresponding to the vulnerability according to the verified remediation plan, regenerate the SBOM.

[0050] The repair of the components corresponding to the vulnerabilities, based on the verified remediation plan, includes: S601, the vulnerability management platform automatically creates and dispatches vulnerability remediation work orders through its integration API with ITSM systems such as Jira or ServiceNow; For vulnerabilities on the nodes corresponding to each component, based on the vulnerability type and according to the set priority of the remediation strategy, The repair strategy includes: Strategy 1: Prioritize vulnerabilities based on severity, such as those with extremely high CVSS scores.

[0051] Strategy 2: Focus on the feasibility of vulnerability remediation, for example, prioritize "verified" "version upgrade" solutions. In version upgrades, the officially recommended solution is usually the most thorough and secure.

[0052] Strategy 3: Focus on the scope of impact, for example, through dependency analysis, prioritize vulnerabilities that affect core business operations.

[0053] If the vulnerability is an injection vulnerability, then strategy 3 takes precedence; If the vulnerability is an authentication and authorization flaw, then strategy 2 takes precedence.

[0054] Understandably, for injection vulnerabilities: if the vulnerability is an injection vulnerability, such as SQL injection or command injection, then strategy 3 prioritizes the scope of impact. This is because injection vulnerabilities can usually directly affect core business data and system stability, and their potential impact is very broad. For authentication and authorization flaws: if the vulnerability is an authentication and authorization flaw, such as weak passwords or privilege escalation, then strategy 2 prioritizes the feasibility of remediation. This is because these vulnerabilities can usually be completely fixed through version upgrades, and version upgrade solutions have been officially verified, effectively resolving these issues while reducing the risk of introducing new problems.

[0055] S602. Fix the vulnerability according to the verified repair plan in the work order, and verify it after repair; If the verification passes, the pipeline script automatically closes the corresponding remediation work order in the ITSM system and marks the vulnerability status as "remediated" in the vulnerability management platform; if the CI / CD pipeline fails automatically, it will notify that the remediation was invalid; it will then search for a remediation solution and execute the remediation until a remediation solution is found or the preset number of attempts is reached.

[0056] S603. Regenerate the SBOM according to the preset number of vulnerabilities to be repaired, and replace the old SBOM as the benchmark for subsequent processes.

[0057] The process design in step S6 ensures the efficiency and reliability of vulnerability remediation through automation, multi-dimensional priority assessment, verification and feedback mechanisms, and regular updates to the SBOM, thereby improving the overall security of the supply chain.

[0058] Furthermore, the supplier's Bill of Materials (SBOM) for automotive software is stored on the cloud blockchain to generate the first record. The client downloads the SBOM to its local machine for analysis, and whenever the SBOM is updated, it uploads the updated SBOM to the cloud blockchain to generate the second record.

[0059] The entire closed loop of "supplier → cloud blockchain → local terminal → back to cloud blockchain" has traceability, verifiability, auditability, and rollback capability, meeting the stringent requirements of modern automotive software supply chain security governance.

[0060] Example 2 A SBOM-based automotive software supply chain security and open-source governance system for implementing SBOM-based automotive software supply chain security and open-source governance methods, the system comprising: The SBOM identification module is used to identify the SBOM of automotive software provided by the supplier, and obtain basic software information and software extension information containing multiple components. The vulnerability identification module is used to match the basic software information in the SBOM with a trusted vulnerability database to obtain all known vulnerabilities in the SBOM. The risk assessment module is used to analyze the impact scope of each vulnerability based on the dependencies in the SBOM, determine the affected software artifacts and vehicle models, and determine the vulnerability level based on the affected software artifacts, vehicle models, and vulnerability severity. The risk visualization module is used to bind the known vulnerabilities and vulnerability levels of components to the components in the SBOM, forming a risk view of the SBOM; The vulnerability remediation module is used to automatically associate vulnerable components in the SBOM with a trusted patch library via API, and determine verified remediation solutions for the vulnerabilities based on the SBOM risk view. The SBOM update module is used to regenerate the SBOM after fixing the components corresponding to the vulnerabilities according to the verified remediation plan.

[0061] A SBOM-based automotive software supply chain security and open-source governance system, including cloud, local, communication channels, and distributed storage systems; In the cloud, a permissioned blockchain network (Fabric or Quorum) is jointly maintained by automakers, Tier 1 suppliers, and third-party security companies. Each node is deployed in its own private cloud or trusted cloud host, and nodes communicate with each other via TLS.

[0062] On the local end, the SBOM-Workstation software package is installed on OEM R&D centers, diagnostic computers, or fleet management servers, and includes an offline vulnerability database, a license compliance check engine, and a blockchain SDK.

[0063] Transport channel: HTTPS, two-way TLS, Hardware Security Module (HSM) signature; The distributed storage system uses IPFS / Filecoin to store large files, with only the CID and metadata stored on the blockchain.

[0064] Example 3 A computer-readable storage medium storing a computer program, characterized in that a processor executes the computer program to implement a SBOM-based automotive software supply chain security and open-source governance method.

[0065] Example 4 A terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement an SBOM-based automotive software supply chain security and open-source governance approach.

[0066] Example 5 A heterogeneous vulnerability analysis method for automotive software SBOM based on HGNN includes the following steps: Sa301: Parse the automotive SBOM (Bill of Materials) submitted by the supplier, extract all software component entities and their dependencies, and build the basic topology. Sa302. Each software component in the SBOM is categorized and labeled into five preset heterogeneous nodes: vehicle basic OS node, vehicle control middleware node, safety-critical business component node, general open source third-party component node, and vehicle entertainment non-safety-critical component node. Sa303. Semantically classify and label the dependency relationships between components, distinguishing four types of heterogeneous directed edges: strong dependency edges, weak dependency edges, nested containment edges, and version-related edges, and assign corresponding risk propagation attributes. Sa304. Based on the annotated heterogeneous nodes and edges, construct the SBOM software-dependent heterogeneous graph and generate the heterogeneous graph adjacency table and the original feature matrix of the nodes. Sa305: Construct independent and dedicated embedding layers according to the five types of nodes, and configure dedicated convolutional weight parameters for the four types of heterogeneous dependent edges to complete the heterogeneous parameter initialization of the HGNN model; Sa306 employs Heterogeneous Graph Convolutional (HGCN) to perform multi-layer neighborhood feature aggregation and message passing, grouping and aggregating neighbor node features by edge type to realize the propagation and deduction of differentiated vulnerability risks in dependent topologies; Sa307 outputs the heterogeneous graph global context risk value of each component node by training the converged HGNN model, replacing the single risk assessment result of the traditional homogeneous GNN. Sa308: The global context risk value of the heterogeneous graph is weighted and fused with the first vulnerability score to obtain the second vulnerability score. The vulnerability level is determined based on the second score, and an SBOM risk heatmap is generated to support the subsequent priority ranking of vulnerability remediation and governance decisions.

[0067] The beneficial effects of this invention are as follows: 1) By using the SBOM-based automotive software supply chain security and open-source governance method of this invention, the transparency and traceability of the automotive software supply chain can be improved, helping enterprises to effectively manage software components and reduce security risks.

[0068] 2) By building and applying SBOM, enterprises can clearly understand the components and sources of software products, achieve comprehensive monitoring of the software supply chain, provide real-time security monitoring and early warning capabilities, and enable enterprises to promptly discover security issues in software components and take corresponding measures.

[0069] 3) This invention uses an SVM classifier and a GNN model, combined with historical data and graph structure information, to improve the accuracy of risk assessment. The GNN model can simulate the propagation of vulnerability risks in the dependency graph, calculate dynamic risk values, and reflect the real risk status of components in real time. By periodically regenerating the SBOM, the timeliness and accuracy of supply chain information are ensured. Through the use of the HGNN model, dangerous vehicle control components and ordinary open-source components are effectively distinguished, the strength of dependency links is automatically differentiated, and risk propagation is more in line with the automotive electronic architecture, adapting to the layered SBOM risk assessment of the vehicle layer → domain layer → ECU layer → component layer.

[0070] 4) From SBOM identification, vulnerability matching, risk assessment, and remediation solution determination to SBOM updates, the entire supply chain security management process is covered. This forms a closed-loop management system from vulnerability discovery to remediation, ensuring that problems are resolved. Through this systematic, automated, and dynamic management approach, the security and open-source governance efficiency of the automotive software supply chain are significantly improved, effectively addressing the increasingly complex software supply chain security challenges.

[0071] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automotive software supply chain security and open-source governance based on SBOM, characterized in that, The method includes the following steps: S1. Identify the Bill of Materials (SBOM) for automotive software provided by the supplier to obtain basic software information and extended software information containing multiple components; S2. Match the basic software information in the SBOM with the trusted vulnerability database to obtain all known vulnerabilities in the SBOM, including converting the basic software information into the CPE standard format for the general platform. S3. Based on the dependencies in the SBOM, analyze the scope of impact of each vulnerability and determine the affected software artifacts and vehicle models; determine the vulnerability level based on the affected software artifacts, vehicle models, and vulnerability severity. S4. Bind the known vulnerabilities and vulnerability levels of the components to the components in the SBOM to form an SBOM risk view; S5. Automatically associate vulnerable components in the SBOM with a trusted patch library via API, and determine the verified remediation plan for the vulnerability based on the SBOM risk view. S6. After fixing the components corresponding to the vulnerabilities according to the verified remediation plan, regenerate the SBOM; Step S3 includes: S301. Deconstruct all software components and edges from the SBOM. Software component nodes include five types of heterogeneous nodes: vehicle basic OS nodes, vehicle control middleware nodes, safety-critical business component nodes, general open-source third-party component nodes, and vehicle entertainment non-safety-critical component nodes. Among them, safety-critical business component nodes include: autonomous driving perception, chassis control, power control, and braking and steering components. Edge types include four types: strong dependency directed edges: edges connecting safety-critical business component nodes and OS nodes or vehicle control middleware nodes; weak dependency directed edges: edges connecting entertainment components and general open-source library nodes; nested component edges, indicating that the parent software artifact contains several child components; and component version iteration related edges, indicating the association between different iteration versions of the same component. S302. Construct a heterogeneous graph G=(V, E, Tv, Te), where V represents the set of all software component nodes; E represents the set of directed edges that depend on each component; Tv={Tv1, Tv2, Tv3, Tv4, Tv5} represents 5 types of nodes; and Te={Te1, Te2, Te3, Te4} represents 4 types of edges. Each node is accompanied by an original feature vector: x i =[f SVMi RiskScore i CVEList i CVSS i ]; Where, x i This represents the original comprehensive feature vector of the i-th software component node in the SBOM dependency graph. It is composed of the SVM feature vector, SVM risk probability score, CVE vulnerability list, and CVSS hazard score, and serves as the original input to the HGNN model. f SVMi It is the high-dimensional SVM feature vector corresponding to the i-th software component node, composed of the component version sequence number, release duration, source reliability, maintenance activity, license type, and number of dependencies, used to characterize the component's inherent attributes and basic vulnerability characteristics; RiskScore i CVEList is the static risk probability score output by the SVM classifier for the i-th component node, representing the prior probability that the component has a security vulnerability without topological dependencies; i It is a list of all CVE vulnerability IDs matched for the i-th software component, used to characterize the number of vulnerabilities, vulnerability types, and historical vulnerability richness of the component, serving as an inherent feature of the node vulnerability dimension; CVSS i It is the CVSS quantitative hazard score of the CVE vulnerability corresponding to the i-th component, which represents the static severity level of the vulnerability of a single component itself; S303, Heterogeneous Graph Feature Mapping and Type-Specific Embedding: A separate embedding layer is set for each type of node, and the adjacency weight matrix is ​​set according to the edge type; H is set. i (l) =Emb1(x i Emb2(x) i Emb3(x) i Emb4(x) i Emb5(x) i Emb represents the embedding layer, x i = the original feature vector of the i-th node, Emb i (x i ) represents the dedicated embedding layer for the i-th type of node, which is the original feature x of node i. i Perform feature transformation; where Emb i In this context, 'i' represents the node type: i=1 for the in-vehicle basic OS node, i=2 for the vehicle control middleware node, i=3 for the safety-critical business component node, i=4 for the general open-source third-party component node, and i=5 for the in-vehicle entertainment non-safety-critical component node; the adjacency convolution weight (W) for each type of edge is set. e1 W e2 W e3 W e4 ); S304 employs Heterogeneous Graph Convolutional Network (HGCN) for layer-by-layer aggregation. For target node i, neighboring nodes are grouped according to their edge types. Neighbors of the same edge type are aggregated using the same set of convolutional parameters. Aggregation results from different edge types are concatenated or weighted to obtain a new node representation. The aggregation model is as follows: h i (l+1) =σ(∑ e∈Te W e ×∑ j∈Ni(e) h j (l) ); N i (e) represents all adjacent nodes connected to node i through edge type e; W e σ represents the convolution parameters specific to each edge, and σ represents the non-linear activation function. S305. In HGNN propagation, introduce the automotive industry business prior coefficient and set differentiated risk propagation gain or attenuation multiple for different types of nodes. Among them, the automotive industry business prior coefficient is introduced, and different risk propagation gain or attenuation multiples are set for different types of nodes, including: setting different risk propagation gain or attenuation multiples for safety-critical component nodes, underlying middleware nodes, general open source components, and entertainment non-critical components. S306. Output hierarchical heterogeneous risk value for SBOM risk rating; S3061, The final output of the model for each node: h i HGNN = Heterogeneous graph global context risk value; S3062, then merge with the original first score S1: S2 = α × h i HGNN + β× S1; If the vulnerability's first score is S1, then: S1=w1×AffectedArtifacts+w2×VehicleModels+w3×Severity Where w1, w2, and w3 are weighting coefficients; AffectedArtifacts is the number of affected software artifacts; VehicleModels is the number of affected vehicle models; and Severity is the CVSS score.

2. The SBOM-based automotive software supply chain security and open-source governance method according to claim 1, characterized in that, The basic software information includes: author information, timestamp, component name, component version, component hash value, and unique identifier; the extended software information includes: dependency relationships, inclusion relationships, software intellectual property information, and associated vulnerability information; among which, the software intellectual property information includes: open source license copyright and open standards, and third-party authorization information.

3. The SBOM-based automotive software supply chain security and open-source governance method according to claim 1, characterized in that, Step S2 also includes using the SCA tool to scan the software intellectual property information by calling its built-in SPDX public database, license text library, and policy template library to obtain the license and copyright statement.

4. The SBOM-based automotive software supply chain security and open-source governance method according to claim 1, characterized in that, Step S2 includes: The basic software information in the SBOM is matched with a trusted vulnerability database to obtain all known vulnerabilities in the SBOM, including: S202. Use the standardized CPE string to query the trusted vulnerability database; If the query is successful, a list of CVEs related to the CPE is returned, including a detailed description, CVSS score, and severity level information for each CVE. If the CPE match fails, for components without a standard CPE name or with custom names in the supplier's SBOM, the component's functional description, application scenario, compatible vehicle model, and development language are extracted. Based on the automotive software component knowledge base, the custom component name is semantically matched with industry standard components and mapped to an equivalent CPE component identifier. If the match is successful, the corresponding CVE and CVSS are returned. If the CPE match fails again, a feature vector is constructed for each component in the SBOM. The feature vector includes: version serial number, release date, source reliability, maintenance activity, license type, and number of dependencies, where the number of dependencies represents the number of other components that depend on the current component.

5. The SBOM-based automotive software supply chain security and open-source governance method according to claim 4, characterized in that, Step S202 includes: S2021. Using labeled historical data, train an SVM classifier, where the SVM classifier kernel function is a radial basis function (RBF). S2022, the feature vector of the input node, and the risk probability score of the output node of the SVM classifier.

6. A SBOM-based automotive software supply chain security and open-source governance system for performing the method as described in any one of claims 1-5, the system comprising: The SBOM identification module is used to identify the SBOM of automotive software provided by the supplier, and obtain basic software information and software extension information containing multiple components. The vulnerability identification module is used to match the basic software information in the SBOM with a trusted vulnerability database to obtain all known vulnerabilities in the SBOM. The risk assessment module is used to analyze the impact scope of each vulnerability based on the dependencies in the SBOM, determine the affected software artifacts and vehicle models, and determine the vulnerability level based on the affected software artifacts, vehicle models, and vulnerability severity. The risk visualization module is used to bind the known vulnerabilities and vulnerability levels of components to the components in the SBOM, forming a risk view of the SBOM; The vulnerability remediation module is used to automatically associate vulnerable components in the SBOM with a trusted patch library via API, and determine verified remediation solutions for the vulnerabilities based on the SBOM risk view. The SBOM update module is used to regenerate the SBOM after fixing the components corresponding to the vulnerabilities according to the verified remediation plan.

7. A computer-readable storage medium storing a computer program, characterized in that, The processor executes the computer program to implement the method as described in any one of claims 1-5.

8. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method as described in any one of claims 1-5.

Images