Dynamic risk management method and device of Internet of Things software supply chain

Abstract

The invention provides a dynamic risk management method and device for an Internet of Things software supply chain, and relates to the technical field of computer security. In order to solve the problems that software bill-of-material management is dispersed and static and risk assessment is inaccurate, the method comprises the steps of automatically obtaining software bill-of-material data in response to a CI / CD pipeline event; integrating the data with the component and vulnerability data, storing the data into a structured storage library, and establishing a relationship between the data and the component and vulnerability data; calculating a quantitative risk score in combination with the environment context factor; generating a multi-level visual interface to present the risk situation; and an interactive audit workflow management vulnerability life cycle is provided to form a traceable log. According to the invention, the dynamic, accurate, visual and closed-loop management of the risk is realized, and the positioning efficiency and the traceability are improved.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a dynamic risk management method and apparatus for an Internet of Things (IoT) software supply chain. Background Technology

[0002] With the widespread adoption of IoT applications, the security of its software supply chain has become increasingly prominent. Software bill of materials (BOMs), as a key technology for managing the internal components of software and their dependencies, is crucial for ensuring the security of the software supply chain.

[0003] In existing technologies, solutions have emerged that integrate the generation and analysis of software bills of materials (BOMs) into the software development process. For example, some solutions can generate a software BOM by using automated tools to scan the codebase during the product development and design phase, identify known vulnerabilities in the components, and establish a mapping relationship between requirements, components, and vulnerabilities, thereby enabling preliminary risk assessment and tracing.

[0004] However, the existing technologies still have the following shortcomings: First, the presentation and management of risk information are relatively fragmented and static. Although a large amount of data is collected, this data often exists in the form of independent reports or lists, lacking a unified, interactive view. When it is necessary to investigate specific risks, technicians still need to manually compare and piece together information from different reports and data sources, resulting in low efficiency in risk location. Second, the risk assessment models are relatively crude. Existing risk assessments usually rely on general vulnerability scores without fully considering the specific scenarios of IoT applications, such as the network environment in which the device is located and the criticality of the business it carries. This results in the assessment results failing to accurately reflect the true threat level of vulnerabilities in a specific deployment environment, potentially leading to misjudgment of risks or mispricing. Third, the traceability of risk analysis and handling processes is insufficient, lacking a systematic recording and closed-loop management mechanism, making it difficult to meet increasingly stringent compliance audit requirements. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a dynamic risk management method and device for the Internet of Things software supply chain, which aims to solve the technical problem in the prior art that the decentralized and static software bill of materials management method makes it impossible to efficiently and accurately conduct full life cycle quantitative assessment, dynamic tracking and closed-loop management of the vulnerability risks of software components.

[0006] To address the aforementioned technical problems, this application provides a dynamic risk management method for the IoT software supply chain. The method includes: automatically acquiring software bill of materials (BOM) data for the IoT application from at least one software asset source in response to a preset trigger event detected in a continuous integration / continuous deployment pipeline associated with the IoT application; then, parsing the BOM data to obtain component data, and querying associated vulnerability information based on the component data to obtain vulnerability data; subsequently, storing the BOM data, component data, and vulnerability data in a structured data repository, and establishing dependencies or attributions among the three; and finally, based on standard vulnerability scores in the vulnerability data, and... A quantified risk score is calculated by combining at least one environmental context factor associated with the IoT application. Then, based on the risk score, component data, and vulnerability data, a user interface containing multiple hierarchical views is generated and presented to the user terminal. These hierarchical views include at least a combined overview view displaying the overall risk posture of multiple IoT applications, and an application detail view displaying details of internal components and vulnerabilities of a single IoT application. Finally, an interactive audit workflow for managing the vulnerability lifecycle is provided. This workflow receives user input on the analysis status of the vulnerability and records the history of changes to the analysis status to form a traceable audit log.

[0007] Optionally, the preset triggering event includes a code commit event or a firmware version tag creation event; the software asset source includes container images, firmware images, source code, or binary packages.

[0008] Optionally, the method further includes: after obtaining the software bill of materials data, verifying the integrity of the software bill of materials data through a hash verification algorithm.

[0009] Optionally, the structured data repository is a graph database; the establishment of dependency or attribution relationships includes: defining the IoT application, the components in the component data, and the vulnerabilities in the vulnerability data as nodes, and establishing dependency and attribution relationships between the nodes.

[0010] Optionally, the at least one environmental context factor includes at least one of the following: the business importance level of the IoT device, network reachability, attack complexity, required permissions, or user interaction.

[0011] In a preferred embodiment, based on the method of claim 5, the step of calculating a quantified risk score specifically includes: calculating the quantified risk score based on the standard vulnerability score and according to the preset quantified value and weight corresponding to the at least one environmental context factor through a weighted formula.

[0012] Optionally, the combined overview view includes a dashboard displaying the total number of vulnerabilities in all IoT applications and a list of applications sorted by the risk score; the application detail view includes a component list view and a vulnerability audit list view.

[0013] Optionally, the analysis status input includes input for declaring the vulnerability exploitability status; when the interactive audit workflow receives a user-submitted input declaring that the application is not affected by a specific vulnerability, it generates a vulnerability exploitability exchange declaration and associates it with the software bill of materials data.

[0014] Optionally, the method further includes: parsing and converting software bill of materials data in different formats obtained from different software asset sources into a unified internal data format before storing the software bill of materials data in the structured data repository.

[0015] Another aspect of this application provides a dynamic risk management device for an IoT software supply chain, comprising: a data acquisition module, configured to automatically acquire software bill of materials (BOM) data of the IoT application from at least one software asset source in response to a preset trigger event detected in a continuous integration / continuous deployment pipeline associated with the IoT application; a data storage module, configured to parse the software BOM data to obtain component data, and query associated vulnerability information based on the component data to obtain vulnerability data, storing the software BOM data, the component data, and the vulnerability data in a structured data repository, and establishing dependency or attribution relationships among the three; and a risk calculation module, configured to calculate the risk based on a standard vulnerability score in the vulnerability data, and... A quantitative risk score is calculated by combining at least one environmental context factor associated with the IoT application; an interface generation module is used to generate and present a user interface containing multiple hierarchical views to the user terminal based on the risk score, component data, and vulnerability data. The multiple hierarchical views include at least a combined overview view for displaying the overall risk posture of multiple IoT applications, and an application detail view for displaying the internal components and vulnerability details of a single IoT application; and an audit management module is used to provide an interactive audit workflow for managing the lifecycle of the vulnerability. The audit workflow is used to receive the user's analysis status input for the vulnerability and record the history of changes to the analysis status to form a traceable audit log.

[0016] Compared with the prior art, the technical solution provided in this application has the following beneficial effects:

[0017] 1. Improved risk identification efficiency. By automating the acquisition of software bill of materials data and storing it in a structured manner in conjunction with component and vulnerability data, previously scattered information is integrated into a unified platform. This replaces time-consuming manual cross-platform and cross-document investigation work, significantly improving the efficiency of risk identification.

[0018] 2. It achieves accurate quantification and intuitive presentation of risks. By introducing a risk score calculation method that incorporates IoT environmental context factors, the risk assessment results are more closely aligned with actual application scenarios, solving the problem of inaccuracy in general scoring models. At the same time, through a multi-level visual user interface from macro to micro, abstract risk data is transformed into intuitive and quantifiable indicators, helping users accurately assess risk priorities and predict the scope of impact.

[0019] 3. Ensured the dynamism and accuracy of data management. Through integration with the continuous integration / continuous deployment pipeline, it ensured that the software bill of materials data was updated in real time as the software development process progressed, solving the problem of data disconnect between the actual operating status of equipment in traditional static management, and guaranteeing the timeliness and accuracy of risk analysis.

[0020] 4. Enhanced compliance and traceability capabilities. By providing an interactive audit workflow and recording complete audit logs, a closed-loop management and end-to-end traceability capability for vulnerabilities from discovery to handling has been built, enabling the systematic generation of compliance reports to meet industry audit requirements. Attached Figure Description

[0021] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0022] Figure 1 This is an architectural block diagram of the system according to an embodiment of the present invention;

[0023] Figure 2 This is a flowchart of a method according to an embodiment of the present invention;

[0024] Figures 3 to 6 This is a partial interface schematic diagram in one embodiment of the present invention;

[0025] Figure 7 This is a schematic diagram of data association in one embodiment of the present invention;

[0026] Figures 8 to 11 This is a partial interface diagram provided in one embodiment of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] This application provides an implementation scheme for dynamic risk management of the IoT software supply chain. This scheme achieves a closed-loop management process—from automatic data collection, structured storage, risk quantification, multi-level visualization to interactive auditing—by constructing an integrated management platform.

[0029] Please see Figure 1 This diagram illustrates the system architecture of an IoT software supply chain dynamic risk management method provided in this application embodiment. The system architecture primarily includes a management platform server, on which multiple core functional modules are deployed, and which interact with external continuous integration / continuous deployment pipelines 10 and user terminals 70. Specifically, these modules include: a data acquisition module 20, a structured data repository 30, a risk calculation engine 40, a visualization engine 50, and an interactive audit workflow module 60.

[0030] The data acquisition module 20 interfaces with the external continuous integration / continuous deployment pipeline 10 to automatically acquire software bill of materials (BOM) data. The structured data repository 30 serves as the data hub of the entire system, used to uniformly store and manage software BOM data, component data, and vulnerability data, and to establish relationships between them. The risk calculation engine 40 quantifies vulnerability risks based on a pre-defined algorithm model. The visualization engine 50 generates an interactive user interface based on the data in the structured data repository 30 and the calculation results of the risk calculation engine 40, and presents it to the user terminal 70 via the network. The interactive audit workflow module 60 provides users with an interface for managing the vulnerability lifecycle. Users interact with this module through the user terminal 70, and their operation results and historical records are recorded and updated back to the structured data repository 30.

[0031] It is understandable that, in a concrete implementation, the aforementioned device can be implemented as one or more servers. For example, the data acquisition module 20, the structured data repository 30, the risk calculation engine 40, the visualization engine 50, and the interactive audit workflow module 60 can be centrally deployed on the same physical server or cloud server, or they can be distributed across multiple servers and communicate via an internal network. The user terminal 70 can be a personal computer, tablet, or any device with a browser, accessing the services provided by the visualization engine 50 via the Internet or an internal network.

[0032] The following will combine Figure 1 The system architecture shown is for Figure 2 The method and process shown will be explained in detail.

[0033] like Figure 2 As shown, the method includes the following steps:

[0034] Step S101: In response to a preset trigger event detected in the continuous integration / continuous deployment pipeline 10 associated with the IoT application, automatically obtain the software bill of materials data of the IoT application from at least one software asset source.

[0035] In this embodiment, the process is performed by the data acquisition module 20. Specifically, suppose a development team is maintaining a firmware project for a smart gateway, with its code hosted on a version control system (such as Git) and using a continuous integration platform (such as GitHub).

[0036] Actions serves as its continuous integration / continuous deployment pipeline. The platform's configuration file predefines a trigger event, which can be either "when code is committed to the main development branch" or "when a new version tag is created for the firmware."

[0037] When the developer completes the development of version V2.2 and creates a release tag named "v2.2", the preset trigger event is detected, and the continuous integration / continuous deployment pipeline 10 automatically executes the preset workflow. One step in the workflow calls the data acquisition module 20. The data acquisition module 20 further calls an open-source software bill of materials scanning tool (such as Syft) to perform a deep scan of the newly built firmware image file, which serves as the source of software assets. Syft is capable of parsing the file system in the firmware image, identifying all the software packages, library files, and their versions—i.e., component information. After the scan is complete, Syft generates a software bill of materials data file conforming to the CycloneDX standard, according to the preset configuration. This data file records in detail all the software components contained in this firmware image version V2.2 in a structured format (such as JSON or XML).

[0038] As an optional implementation, to ensure data integrity and tamper-proofing during transmission, a hash verification algorithm (e.g., Secure Hash Algorithm 256, or SHA-256) can be performed on the generated software bill of materials data file before sending it from the continuous integration / continuous deployment pipeline 10 to the management platform server to generate a unique hash value. This hash value will be sent along with the software bill of materials data file. Correspondingly, upon receiving the file and hash value, the data acquisition module 20 will recalculate the hash value of the received file content using the same hash verification algorithm and compare it with the received hash value. Only when the two hash values ​​are completely identical is the data reception confirmed to be complete and error-free, and the next step of processing proceeds. This step effectively ensures that all subsequent analysis and decisions are based on accurate and reliable data.

[0039] Step S102: Store the software bill of materials data, component data, and vulnerability data in the structured data repository 30, and establish the dependencies or attribution relationships between them.

[0040] In this embodiment, the structured data repository 30 can be implemented using a relational database (such as a MySQL database). The data acquisition module 20 passes the software bill of materials data file, which has undergone integrity verification, to a built-in parsing engine. This parsing engine is responsible for parsing the CycloneDX format data and extracting the metadata and component list.

[0041] Specifically, the parsing process is as follows: First, the parsing engine reads the metadata of the software bill of materials, such as the application name (smart gateway), application version (V2.2), and generation time. This information will be used to generate a new record and store it in the "SBOM base table" in the database. This table can be designed with the following fields: sbom_id (primary key, unique identifier), app_name (application name), app_version (application version), file_hash (file hash value), import_time (import time), etc.

[0042] Then, the parsing engine iterates through each component entry in the software bill of materials (SBOM), extracting component data including component name, component version, vendor, license information, and component package URL (PURL). Each piece of component information is stored as a new record in the "Component Details Table" of the database. This table can be designed with the following fields: component_id (primary key), sbom_id (foreign key, related to the SBOM base table), component_name (component name), component_version (component version), vendor (vendor), etc. The sbom_id foreign key clarifies which version of the software bill of materials each component belongs to, thus establishing the attribution relationship between components and application versions.

[0043] After storing the component data, the system needs to retrieve vulnerability data associated with these components. The data acquisition module 20, or a separate background service, iterates through newly added components in the "Component Details Table." For each component, the system uses its unique identifier (such as component name and version, or more precisely, the package URL) to query one or more public or commercial vulnerability databases, such as the National Vulnerability Database (NVD). The query result is a list of known vulnerabilities associated with that component. For each vulnerability found, the system extracts its key information, such as the vulnerability's unique ID (e.g., CVE-2021-44228), description, release date, and an important metric—the Standard Vulnerability Score (CVSS). This vulnerability information, as vulnerability data, is stored in the database's "Vulnerability Association Table." This table can be designed with fields such as: vul_id (primary key), component_id (foreign key, associated with the component details table), cve_id (vulnerability ID), description, and cvss_base_score (CVSS base score). By using the component_id foreign key, it is clear which specific component each vulnerability affects, thus establishing the attribution relationship between the vulnerability and the component.

[0044] Through the above design, the originally scattered software bill of materials, component and vulnerability information are organically integrated into the structured data repository 30, and a clear dependency and ownership chain of "application-component-vulnerability" is established through foreign key relationships.

[0045] Step S103: Calculate the quantified risk score by combining environmental context factors.

[0046] This step is performed by the risk calculation engine 40. It should be noted that relying solely on standard vulnerability scores provided by vulnerability databases (such as the base score of the Common Vulnerability Scoring System (CVSS)) is often insufficiently accurate because it does not consider the actual threat posed by vulnerabilities in specific IoT application scenarios. Therefore, this application introduces the concept of environmental context factors. In this embodiment, at least one key environmental context factor is considered: the business importance level of the IoT application.

[0047] Within the management platform, administrators can configure the business importance level for each monitored IoT application. For example, a smart gateway used for "critical infrastructure" (such as power grid control) can be rated as "high" with a high weight value, such as 1.5; while an application used for "ordinary consumer electronics" (such as a smart desk lamp) can be rated as "low" with a low weight value, such as 0.8.

[0048] The risk calculation engine 40 triggers calculation tasks periodically or when new vulnerability data is added to the database. For each vulnerability in the "Vulnerability Association Table," it first obtains its standard vulnerability score, cvss_base_score. Then, through the components associated with the vulnerability, it further associates it with the IoT application to which it belongs, thereby obtaining the weight value corresponding to the business importance level of that application. Finally, it calculates the final quantitative risk score using a multiplicative formula: Risk Score = cvss_base_score × Business Importance Weight. This scenario-adjusted risk score can more accurately reflect the actual threat level of the vulnerability to the current specific IoT application.

[0049] Step S104: Generate and render a user interface containing multiple hierarchical views.

[0050] The steps are executed by the visualization engine 50. To enable security analysts to intuitively and efficiently perceive risks and locate problems, this application designs a drill-down visualization scheme from macro to micro.

[0051] Please see Figure 3This is a user interface diagram of the combined overview view. When a user logs into the management platform, this macro view is the first thing presented, displaying the overall risk profile of all monitored IoT applications. At the top of the interface, a risk statistics summary area can be set up, prominently displaying key performance indicators such as "Total Number of Vulnerabilities," "Number of High-Risk Vulnerabilities," and "Total Number of Affected Applications" through dashboards or digital cards. Below the summary is an application list, with each row representing one IoT application. This list contains multiple columns, the key one being the risk score column, which displays the total risk score for each application calculated by the risk calculation engine (which can be the sum or maximum of all vulnerability risk scores under it). Users can click on this column to sort, thus quickly identifying the highest-risk applications. Additionally, a vulnerability distribution indicator bar can be set up, using different colored bars to visually display the distribution of high, medium, and low-risk vulnerabilities in each application.

[0052] When a security analyst finds an application (e.g., the aforementioned Smart Gateway V2.2) with an unusually high risk score in the portfolio overview view, he can click on the application entry to drill down to the next level of view.

[0053] Please see Figure 4 Figure 5 This is a user interface diagram of the application details view. This micro-view is used to display the internal components and vulnerability details of a single IoT application, and typically contains two switchable subviews or tabs: the component inventory view and the vulnerability audit view. The component inventory view lists detailed information on all software components that make up the Smart Gateway V2.2, including component name, version, vendor, license type, etc., providing a basis for software asset management and compliance checks.

[0054] Users can switch to the vulnerability audit view. This view displays a list of all vulnerabilities associated with all components of the application. Each row in the list represents a vulnerability, including the vulnerability ID, CVSS score, adjusted quantified risk score, affected component name and version, etc. In particular, this view includes a crucial column: vulnerability analysis status. This column shows the current status of each vulnerability, such as "Pending Analysis," "Under Analysis," "Confirmed," "Not a Real Threat," or "Unaffected." This status provides clear guidance for team collaboration and progress tracking.

[0055] Step S105: Manage the vulnerability lifecycle through an interactive audit workflow.

[0056] When an analyst locates a high-risk vulnerability that needs to be addressed in the application details view, he can click on the vulnerability entry to enter an interface specifically for handling that vulnerability.

[0057] Please see Figure 6 This is a user interface diagram of the interactive audit workflow. Provided by the interactive audit workflow module 60, this interface is used for in-depth analysis, decision-making, and tracking of individual vulnerabilities to form a closed-loop management system. The left or upper part of the interface can be a vulnerability description area, displaying detailed technical information about the vulnerability obtained from the vulnerability database, including its working principle, the range of affected software versions, known attack methods, etc., providing analysts with the technical intelligence needed for decision-making.

[0058] The core of the interface is an analysis status input form. After in-depth analysis (e.g., checking whether the application code actually calls the vulnerable library), analysts can submit their analysis conclusions in this form. The form can include a dropdown menu for users to select the vulnerability's analysis status, such as updating to "Unaffected." Simultaneously, a text box must be provided requiring users to fill in detailed reasons for their judgment, such as "Code review confirmed that the vulnerability exists in an uncalled library function, and the related functionality is not enabled in the code."

[0059] As a preferred implementation, this workflow can integrate a Vulnerability Exploitability Exchange (VEX) mechanism. When a user submits an "unaffected" analysis status, the interactive audit workflow module 60 can automatically generate a structured VEX statement based on the user's input. This VEX statement clearly records which application version (Smart Gateway V2.2) is "unaffected" for which specific vulnerability, and the reasoning behind it. This VEX statement will be stored and associated with the corresponding software bill of materials data. In this way, in future automated scans or report generation, the system can automatically identify and ignore this clarified vulnerability, thereby avoiding duplicate alerts and analysis work.

[0060] In addition, another important part of this interface is the audit trail log 52. Whenever a user makes any change to the analysis status of the vulnerability (e.g., from "Pending Analysis" to "Analyzing," and then to "Unaffected"), the system automatically records this operation. Audit trail log 52 clearly displays the operator, operation time, pre-change status, post-change status, and reason for submission for each change in a timeline format. These records constitute a full lifecycle audit log for the vulnerability from discovery to final resolution, possessing non-repudiation and traceability, and greatly satisfying the requirements of compliance auditing.

[0061] Through the close coordination of the above five steps, this embodiment constructs a dynamic, closed-loop IoT software supply chain risk management system, which significantly improves the efficiency, accuracy and traceability of risk management.

[0062] This embodiment is a variant of step S102 in the aforementioned related embodiments, designed to demonstrate another more efficient implementation of the structured data repository 30, which is particularly suitable for handling IoT systems with deep and complex dependencies. In this embodiment, the relational database (such as MySQL) used in the aforementioned related embodiments is replaced with a graph database (such as Neo4j).

[0063] When adopting a graph database, the data storage model also changes from a two-dimensional table to a graph structure of nodes and relationships. See also... Figure 7 This is a schematic diagram of data association based on a graph database in this embodiment. The system defines different types of entities as nodes with different labels. For example, an IoT application is modeled as an application node 701; each software component contained in the application is modeled as a component node 702; and each vulnerability associated with a component is modeled as a vulnerability node 703.

[0064] Dependencies or affiliations between entities are modeled as directed edges (relationships) between nodes. For example, if an application "Smart Home Hub" contains a component "log4j-core", an edge will be created in the graph database from the application node 701 representing "Smart Home Hub" to the component node 702 representing "log4j-core". This edge can be defined as a HAS_COMPONENT relation 711, indicating a "containment" relationship. If the component "log4j-core" itself depends on another base component "commons-logging", a relation of type "DEPENDS_ON" can be established between the two component nodes. Furthermore, if the component "log4j-core" has a vulnerability "CVE-2021-44228", an edge will be created from the component node 702 representing "log4j-core" to the vulnerability node 703 representing the vulnerability. This edge can be defined as a HAS_VULNERABILITY relation 712, indicating a "vulnerability exists" relationship.

[0065] Once the software bill of materials data for a batch is acquired and parsed by the data acquisition module 20, the system no longer inserts it into multiple two-dimensional tables, but converts it into the aforementioned graph data model and stores it in the graph database.

[0066] The significant advantages of using a graph database as a structured data repository 30 lie in the improved query efficiency and analytical capabilities. For example, when a critical new vulnerability is discovered, the security team's primary concern is: "Which of our applications will ultimately be affected by this vulnerability?" In the relational database model of the aforementioned embodiments, answering this question requires executing multiple join queries across three tables; when the dependency chain is long (e.g., application A -> component B -> component C -> ... -> component N -> vulnerability X), the query becomes extremely complex and inefficient. However, in a graph database, this problem can be solved with a very concise and efficient graph query statement. For example, using Neo4j's Cypher query language, the following query can be executed: MATCH(app:Application)-[*]->(c:Component)-[:HAS_VULNERABILITY]->(v:Vulner ability{id:'CVE-2021-44228'})RETURNapp.name. The meaning of this query is: "Find all application nodes (app) that can be reached by a path of arbitrary length and type (-[*]->) and ultimately a component node (c), which in turn contains a vulnerability with the ID 'CVE-2021-44228'; return the names of these applications." The underlying engine of the graph database has been highly optimized for this type of path traversal query, and can return results in milliseconds or seconds even in cases with very deep dependencies and very large networks.

[0067] Therefore, by employing a graph database as a structured data repository, this embodiment greatly improves the efficiency of risk transmission analysis and impact tracing in complex software supply chains, providing stronger technical support for solving the problems of information fragmentation and weak traceability.

[0068] This embodiment is a refinement and enhancement of step S103 in the aforementioned related embodiments, aiming to demonstrate a more refined and scenario-based risk quantification model to further improve the accuracy of risk assessment. In this embodiment, the risk calculation engine 40 comprehensively considers multiple IoT-specific environmental context factors when calculating the quantified risk score.

[0069] As described in the aforementioned embodiments, while using only standard vulnerability scoring and a single business importance factor is effective, there is still room for optimization. In this embodiment, the risk calculation engine 40 has been upgraded to support richer environmental context factors. These factors are all configurable, and when an administrator enters or manages an IoT application, they need to set the corresponding environmental attributes for it in the management platform. These factors and their quantified values ​​may include, but are not limited to:

[0070] Network reachability: Describes the network path required for an attacker to reach the target device. For example, if the device is directly exposed to the public internet and can be accessed by anyone, its quantification value is the highest, which can be set to 1.0; if the device is located in an isolated internal network protected by a firewall and the external network needs to be compromised first, its quantification value is lower, which can be set to 0.5; if the device is completely physically isolated and can only be attacked through physical contact (such as inserting a USB device), its quantification value is the lowest, which can be set to 0.1.

[0071] Attack complexity: This is a metric used in general vulnerability scoring systems, which is emphasized and applied in this application as part of the environmental context. It describes how easy or difficult it is to exploit a vulnerability. "Low" complexity means the exploit can be repeated without requiring special timing or conditions; "high" complexity means the attacker needs to overcome additional obstacles (such as obtaining specific information). These can be mapped to different modifiers.

[0072] Required Permissions: Describes the level of privileges an attacker needs to exploit the vulnerability. Vulnerabilities that require no privileges pose the greatest threat; those requiring ordinary user privileges are next; and those requiring administrator privileges pose the least threat.

[0073] User Interaction: Describes whether exploiting the vulnerability requires the participation of a legitimate user. "None" indicates the vulnerability can be exploited remotely and automatically without any user intervention; "Required" indicates that a user must perform some action (such as clicking a malicious link).

[0074] Please see Figure 8 , Figure 9 , Figure 10 and Figure 11 This allows risk management administrators to configure the aforementioned environmental context factors. For example, the interface can include a series of attack vector selectors and impact metric selectors. By selecting these options, the system backend can convert these selections into corresponding quantitative values. The CVSSv3 scoring dashboard can display the scores calculated based on these selections in real time.

[0075] In this embodiment, the final quantified risk score is calculated using a configurable weighted formula. The general form of this formula can be expressed as:

[0076]

[0077] Or a weighted summation form:

[0078] RiskScore = S base ×(w1×F1+w2×F2+…+w n ×F n )

[0079] Among them, S base It is a standard vulnerability score obtained from a vulnerability database (such as the CVSS baseline score), F i w is the quantified value of the i-th environmental context factor (such as network reachability, business importance, etc.). i The weight of the i-th factor represents its importance in the overall risk assessment, and the sum of all weights can be set to 1. These weight values ​​can be preset and adjusted by security experts based on the company's risk preferences.

[0080] To better understand the technical solution of this application, a specific working process example is given below: Assume a "production line controller" application deployed in a factory's isolated intranet, with a business importance level of "extremely high" (weight 1.8, quantification value 1.0) and network reachability of "internal network" (quantification value 0.5). A high-risk vulnerability is discovered in one of its components, with a CVSS base score of 9.8. However, exploiting this vulnerability requires the attacker to also be on the same intranet. The risk calculation engine 40, during calculation, obtains these preset environmental context factors and substitutes them into the formula. A simplified calculation might be: Risk Score = 9.8 × (0.7 × 1.0 [Business Importance] + 0.3 × 0.5 [Network Reachability]) = 9.8 × 0.85 = 8.33. In contrast, another application directly exposed to the public network with a business importance of "low" might have a higher risk score even when facing the same vulnerability. In this way, this embodiment achieves scenario-based and refined assessment of vulnerability risks, avoiding a "one-size-fits-all" scoring method for the same vulnerability in all environments. This allows security teams to more accurately identify vulnerabilities that truly pose a high threat in the current specific environment, thereby focusing limited remediation resources and efforts on the most critical areas and significantly improving the return on investment in risk management. This embodiment aims to demonstrate the universality and flexibility of the method proposed in this application, which does not rely on a specific continuous integration / continuous deployment platform or a specific triggering event. This embodiment will vary the implementation of step S101 to illustrate its flexible integration into different development and operations toolchains. In the above related embodiments, integration with the GitHub Actions platform is described. As another example, in this embodiment, another widely used automation server in the industry—Jenkins—will be used as the continuous integration / continuous deployment pipeline 10. A development team uses Jenkins to automate the build and deployment process of one of its IoT cloud services, which is packaged into a container image. In Jenkins, the team creates a pipeline task. The preset triggering event for this task is configured to "when the project is successfully built and the container image is deployed to the test environment". This means that the software bill of materials scan is only triggered after the code is compiled, tested, packaged as an image, and successfully run on the test server. This ensures that the assets being scanned are verified, upcoming release versions.

[0081] One post-build stage of this Jenkins pipeline script is specifically designed to perform a software bill of materials (BOM) scan. In this stage, the pipeline invokes another popular scanning tool—Trivy. Trivy is configured to scan container images that have just been built and pushed to the internal image repository. Unlike the Syft tool in the related embodiments above, Trivy can be configured to output a software BOM report in SPDX (Software Package Data Exchange) format, another mainstream software BOM standard in the industry.

[0082] After the scan is complete, the Jenkins pipeline will execute a script step. This script is executed via an HTTP...

[0083] A POST request is sent to the API interface of the management platform, which provides the generated SPDX format software bill of materials report file.

[0084] The parsing engine of the data acquisition module 20 is capable of processing various software bill of materials formats. In this embodiment, when it receives data in SPDX format, it calls the corresponding parser to extract its content. To achieve unified data management and analysis, regardless of whether the original format is CycloneDX or SPDX, the parsing engine converts it into a unified, standardized internal data model before performing subsequent storage, association, and analysis operations. This "format normalization" process ensures that the diversity of upstream data acquisition tools and formats does not affect the stability of downstream risk analysis and visualization modules, thereby enhancing the compatibility and scalability of the entire system.

[0085] The workflow can be summarized as follows: After the development team completes a feature iteration, they manually or automatically trigger a build task on Jenkins via code commit. The Jenkins server pulls the latest code, executes compilation and unit tests, then packages the application into a container image and pushes it to the container runtime in the test environment. Once Jenkins confirms successful deployment, the pipeline automatically enters the post-build stage. In this stage, the script calls Trivy to begin scanning the newly deployed image. After the scan is complete, the generated SPDX format software bill of materials report is sent to the management platform's API endpoint via a curl command or a similar HTTP client tool. The management platform's data acquisition module 20 receives and processes the report, and subsequent processes are similar to those described in the aforementioned embodiments.

[0086] This embodiment demonstrates an integration scheme (Jenkins + post-build triggering + Trivy + container image + SPDX format) that differs from the aforementioned related embodiments, powerfully proving the core idea of ​​this application's method—"automatically acquiring SBOM data in response to CI / CD events"—has good universality. It can flexibly adapt to existing and diverse development and operation toolchains and processes within enterprises. Whether based on code commit events or post-build events, whether scanning firmware images or container images, and whether processing CycloneDX or SPDX formats, it can seamlessly integrate to achieve automated software bill of materials data collection and dynamic updates. The above descriptions are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A dynamic risk management method for an IoT software supply chain, characterized in that, Includes the following steps: In response to a pre-triggered event detected in the continuous integration / continuous deployment pipeline associated with an IoT application, automatically obtain the software bill of materials data for the IoT application from at least one software asset source; The software bill of materials data is parsed to obtain component data, and the associated vulnerability information is queried based on the component data to obtain vulnerability data; The software bill of materials data, the component data, and the vulnerability data are stored in a structured data repository, and dependency or attribution relationships are established among the three. A quantified risk score is calculated based on the standard vulnerability score in the vulnerability data and combined with at least one environmental context factor associated with the IoT application. Based on the risk score, component data, and vulnerability data, a user interface containing multiple layers of views is generated and presented to the user terminal. The multiple layers of views include at least: a combined overview view for displaying the overall risk situation of multiple IoT applications, and an application detail view for displaying the internal components and vulnerability details of a single IoT application. An interactive audit workflow is provided for managing the lifecycle of the vulnerability; the audit workflow is used to receive user input on the analysis status of the vulnerability and record the history of changes to the analysis status to form a traceable audit log.

2. The method according to claim 1, characterized in that, The preset trigger events include code commit events or firmware version tag creation events; the software asset sources include container images, firmware images, source code, or binary packages.

3. The method according to claim 1, characterized in that, The method further includes: After obtaining the software bill of materials data, the integrity of the software bill of materials data is verified by a hash check algorithm.

4. The method according to claim 1, characterized in that, The structured data repository is a graph database; The establishment of dependency or attribution relationships includes: defining the IoT application, the components in the component data, and the vulnerabilities in the vulnerability data as nodes, and establishing dependency and attribution relationships between the nodes.

5. The method according to claim 1, characterized in that, The at least one environmental context factor includes at least one of the following: the business importance level of the IoT device, network reachability, attack complexity, required permissions, or user interaction.

6. The method according to claim 5, characterized in that, The calculation yields a quantified risk score, which includes: Based on the standard vulnerability score, and according to the preset quantification value and weight corresponding to the at least one environmental context factor, the quantified risk score is calculated by a weighted formula.

7. The method according to claim 1, characterized in that, The combined overview view includes a dashboard displaying the total number of vulnerabilities for all IoT applications and a list of applications sorted by the risk score; The application details view includes a component inventory view and a vulnerability audit list view.

8. The method according to claim 1, characterized in that, The analysis status inputs include inputs used to declare the exploitability status of the vulnerability; When the interactive audit workflow receives a user-submitted statement declaring that the application is not affected by a specific vulnerability, it generates a vulnerability exploitability exchange statement and associates it with the software bill of materials data.

9. The method according to claim 1, characterized in that, The method further includes: Before storing the software bill of materials data in the structured data repository, software bill of materials data in different formats obtained from different software asset sources are parsed and converted into a unified internal data format.

10. A dynamic risk management device for an Internet of Things (IoT) software supply chain, characterized in that, include: The data acquisition module is used to automatically acquire the software bill of materials data of the IoT application from at least one software asset source in response to a preset trigger event detected in the continuous integration / continuous deployment pipeline associated with the IoT application. The data storage module is used to parse the software bill of materials data to obtain component data, and to query associated vulnerability information based on the component data to obtain vulnerability data; The software bill of materials data, the component data, and the vulnerability data are stored in a structured data repository, and dependency or attribution relationships are established among the three. The risk calculation module is used to calculate a quantitative risk score based on the standard vulnerability score in the vulnerability data and in combination with at least one environmental context factor associated with the IoT application. The interface generation module is used to generate and present a user interface containing multiple layers of views to the user terminal based on the risk score, component data and vulnerability data. The multiple layers of views include at least: a combined overview view for displaying the overall risk status of multiple IoT applications, and an application detail view for displaying the internal components and vulnerability details of a single IoT application. The audit management module provides an interactive audit workflow for managing the lifecycle of the vulnerability. The audit workflow receives user input on the analysis status of the vulnerability and records the history of changes to the analysis status to form a traceable audit log.

Images