IPD process management method and device based on SBOM, equipment and medium

Abstract

The invention discloses an IPD process management method and device based on SBOM, equipment and a medium, and relates to the technical field of software supply chain management, and the method comprises the steps: generating an initial SBOM in an IPD demand definition stage; in an IPD development and design stage, an initial SBOM is updated by scanning a code library, a known vulnerability generation risk list is identified, and a high-risk component is intercepted by a dynamic threshold value; in the IPD test stage, a test case library is matched according to the risk list, and a quality access control is set; in an IPD release stage, deploying an application in a target environment, generating a compliance report based on the SBOM passing the access control, and binding the compliance report with a release packet for filing; synchronizing the SBOM to an operation and maintenance end; and in the IPD operation and maintenance stage, regularly scanning and updating the SBOM, and re-executing the access control check. According to the invention, deep fusion of SBOM and IPD processes is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of software supply chain management, and particularly to a method, device, equipment and medium for IPD process management based on SBOM. Background Art

[0002] In the software supply chain, the Software Bill of Materials (SBOM) is an important document that records software components, dependencies, and security information, and is of great significance for software security, compliance, and quality assurance. The Integrated Product Development (IPD) process is widely used in software development. By deeply integrating the software bill of materials into the IPD process, software quality control can be strengthened, security protection capabilities can be improved, and compliance can be ensured.

[0003] In the related technologies of software supply chain management known to the inventors, the following limitations exist: 1. Lack of full-process management: Existing tools only provide limited SBOM management functions in the development stage, and cannot cover the entire process from material entry to destruction, resulting in incomplete material information and making it difficult to trace and manage.

[0004] 2. Poor integration with the IPD process: Existing systems are difficult to deeply integrate with the IPD process and cannot meet the full-process management requirements of software from development to operation and maintenance, affecting software quality and security.

[0005] 3. Insufficient in-depth analysis: Existing tools do not analyze information such as components, vulnerabilities, and licenses in the SBOM deeply enough to provide comprehensive risk assessment and quality assurance.

[0006] 4. Disconnection in operation and maintenance monitoring: Existing operation and maintenance monitoring systems are separated from SBOM management and cannot monitor the material status in real time, affecting operation and maintenance efficiency and fault response speed.

[0007] The above limitations lead to fragmentation of software supply chain management: The data fragmentation between the development and operation and maintenance stages results in a lag in security vulnerability response. The lack of dynamic feedback of SBOM in the IPD process reduces the quality control efficiency, and shallow analysis cannot meet complex compliance requirements (such as avoiding open source license conflicts). Therefore, there is an urgent need for a system and method that can achieve full-life-cycle management of SBOM, deeply integrate into the IPD process, support multi-dimensional analysis, and be linked with operation and maintenance in real time to build a closed-loop software quality and security protection system. Summary of the Invention

[0008] The present invention provides a method, device, equipment and medium for IPD process management based on SBOM, which solves the problem of insufficient integration between software supply chain management and the IPD process.

[0009] To achieve the above object, the present application adopts the following technical solutions: In a first aspect, a method for IPD process management based on SBOM is provided, including: In the IPD requirement definition stage, a requirement document is output. Meanwhile, compliant components are preselected through a logic unit to generate an initial SBOM, and a license compliance report is output. Among them, the initial SBOM is bound to requirement items to form a requirement - SBOM mapping relationship. In the IPD development and design stage, the initial SBOM is updated by scanning the code library through an integrated SCA tool, known vulnerabilities of components in the SBOM are identified to generate a risk list, and high - risk components are intercepted according to a dynamic threshold. In the IPD testing stage, test cases in a pre - set test case library are matched according to the risk list, and quality access controls are set. A test report, a risk handling plan for those who fail to pass the access control, and an SBOM that passes the access control are generated. In the IPD release stage, the application is deployed in the target environment, a compliance report is generated based on the SBOM that passes the access control and archived by binding it to the release package. Meanwhile, the SBOM is synchronized to the operation and maintenance side. In the IPD operation and maintenance stage, vulnerabilities are scanned regularly and the SBOM is updated, patch updates or component replacements are automatically triggered, and the access control check is re - executed.

[0010] In a first possible implementation manner of the first aspect, the method further includes: Integrating an IDE plugin at the R & D side to prompt component risks in real time. Automatically associating SBOM vulnerabilities with test cases at the testing side. Performing visual monitoring and egress control at the operation and maintenance side.

[0011] In a second possible implementation manner of the first aspect, the dynamic threshold is calculated by the following formula: Threshold = μ + 2σ Threshold = μ + 2σ Where μ is the mean value of historical vulnerability CVSS scores and σ is the standard deviation.

[0012] In a third possible implementation manner of the first aspect, the interception of high - risk components according to the dynamic threshold specifically includes: Periodically pulling the latest vulnerability data from NVD, calculating the mean value and standard deviation of vulnerability CVSS scores, and updating the threshold configuration. Scanning the initial SBOM in real time, triggering a high - risk component interception mechanism and providing rectification suggestions. Among them, the high - risk component interception mechanism is implemented through a risk prediction model based on machine learning, outputting a risk matrix report and marking high - risk components and their influence scopes.

[0013] In a second aspect, a device for IPD process management based on SBOM is provided, including: An initial SBOM module, which is used to output a requirements document during the IPD requirements definition phase. Meanwhile, it pre-selects compliant components through a logic unit to generate an initial SBOM and output a license compliance report. Among them, the initial SBOM is bound to the requirement items to form a requirement - SBOM mapping relationship. A dynamic update and risk interception module, which is used to update the initial SBOM by integrating SCA tools to scan the code library during the IPD development and design phases, identify known vulnerabilities of components in the SBOM to generate a risk list, and intercept high-risk components according to dynamic thresholds. A risk association and access control module, which is used to match a pre-set test case library according to the risk list during the IPD testing phase to set quality access controls, generate a test report, a risk handling plan for those failing to pass the access controls, and a SBOM for those passing the access controls. A compliance release and archiving module, which is used to deploy an application in the target environment during the IPD release phase, generate a compliance report based on the SBOM passing the access controls and archive it by binding to the release package. Meanwhile, synchronize the SBOM to the operation and maintenance side. An iteration module, which is used to regularly scan for vulnerabilities and update the SBOM during the IPD operation and maintenance phase, automatically trigger patch updates or component replacements, and re-perform access control checks.

[0014] In the first possible implementation manner of the second aspect, the device further includes a terminal multi-role collaborative interaction module, which is used for: Integrate an IDE plugin at the R & D side to prompt component risks in real time. Automatically associate SBOM vulnerabilities with test cases at the testing side. Perform visual monitoring and egress control at the operation and maintenance side.

[0015] In the second possible implementation manner of the second aspect, the dynamic threshold is calculated by the following formula: Threshold = μ + 2σ Threshold = μ + 2σ Where μ is the average value of historical vulnerability CVSS scores, and σ is the standard deviation.

[0016] In the third possible implementation manner of the second aspect, the dynamic update and risk interception module is specifically further used for: Periodically pull the latest vulnerability data from NVD, calculate the average value and standard deviation of vulnerability CVSS scores, and update the threshold configuration. Scan the initial SBOM in real time, trigger a high-risk component interception mechanism and provide rectification suggestions. Among them, the high-risk component interception mechanism is implemented through a risk prediction model based on machine learning, outputs a risk matrix report, and marks high-risk components and their impact ranges.

[0017] In a third aspect, an electronic device is provided, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, the steps of the SBOM-based IPD process management method as described in the first aspect are implemented.

[0018] In a fourth aspect, a readable storage medium is provided, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the SBOM-based IPD process management method as described in the first aspect are implemented.

[0019] The SBOM-based IPD process management method of the present invention has the following advantages: This application covers the full life cycle management from product planning to release and maintenance, integrating core links such as risk control management, SBOM generation and analysis, vulnerability detection, license compliance check, risk control, and R & D process management, ensuring the safe and efficient management of the software supply chain, solving the problems of poor integration between SBOM and IPD processes and traceability, improving the automated approval process to enhance processing efficiency, making component risks controllable, optimizing cross-departmental data collaboration, and enhancing software compliance guarantee.

[0020] The device, electronic device, and readable storage medium corresponding to the SBOM-based IPD process management method of the present invention can achieve the same technical effects. To avoid repetition, they will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a schematic flowchart of a SBOM-based IPD process management method provided by an embodiment of this application; Figure 2 It is a schematic flowchart of another SBOM-based IPD process management method provided by an embodiment of this application; Figure 3 It is a schematic flowchart of a pipeline quality access control provided by an embodiment of this application; Figure 4 It is a schematic diagram of the overall system architecture provided by an embodiment of this application; Figure 5 It is a schematic diagram of a technical architecture provided by an embodiment of this application; Figure 6 It is a schematic diagram of a deployment architecture provided by an embodiment of this application; Figure 7 It is a schematic diagram of a data architecture provided by an embodiment of this application; Figure 8 It is a schematic structural diagram of a SBOM-based IPD process management device provided by an embodiment of this application; Figure 9Schematic diagram of a structure of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0022] To further elaborate on the technical means and effects adopted by the present invention to achieve the predetermined purpose, the technical solutions in the embodiments of the present application are clearly described. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art belong to the scope of protection of the present application.

[0023] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, rather than to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are usually of the same category, and the number of objects is not limited. For example, the first object can be one or multiple. In addition, "and / or" in the specification and claims means at least one of the connected objects, and the character " / " generally means that the related objects before and after are in an "or" relationship.

[0024] In the present application, the description of the method flow in the specification and the steps in the flowchart in the accompanying drawings of the present invention do not necessarily have to be strictly executed according to the step numbers. The method steps can be changed in the execution order. Moreover, some steps can be omitted, multiple steps can be combined into one step for execution, and / or one step can be decomposed into multiple steps for execution.

[0025] The following, in conjunction with the accompanying drawings and preferred embodiments, details the SBOM-based IPD process management method, apparatus, device, and medium provided by the embodiments of the present application as follows.

[0026] Currently, there are some software bill of materials management tools on the market, such as open-source Syft and commercial BlackDuck, etc. They can generate and manage SBOMs, but mainly focus on component scanning and vulnerability detection in the development stage, lacking full-process management of the bill of materials and close integration with operation and maintenance monitoring. In addition, although some large software development platforms have certain project management and R & D process management functions, they lack in-depth analysis and operation and maintenance monitoring support for SBOMs and cannot form a complete closed-loop management system from development to operation and maintenance.

[0027] In view of the limitations in the related technologies, the present application provides an end-to-end solution for software supply chain management: 1. Implement full-process management: Provide full-process management from material entry to destruction to ensure the integrity of material information, which is convenient for traceability and management.

[0028] 2. Deeply integrate the IPD process: Deeply integrate with the IPD process to form a closed-loop management system from development to operation and maintenance, improving software quality and security.

[0029] 3. Deep analysis and risk assessment: Deeply analyze information such as components, vulnerabilities, and licenses in the SBOM to provide comprehensive risk assessment and quality assurance.

[0030] 4. Deeply integrate operation and maintenance monitoring: Closely integrate SBOM management with operation and maintenance monitoring to monitor the material status in real time, improving operation and maintenance efficiency and fault response speed.

[0031] Please refer to Figure 1-2 , this embodiment of the application provides an IPD process management method based on SBOM, as Figure 1-2 shown, including: Step S1, in the IPD requirement definition stage, output a requirement document, and at the same time preselect compliant components through a logic device to generate an initial SBOM, and output a license compliance report; wherein, the initial SBOM is bound to requirement entries to form a requirement - SBOM mapping relationship.

[0032] This step is the product planning and requirement analysis stage in the IPD process. Input market requirements, regulatory requirements, technological trends, etc. into the system to clarify functional requirements and non-functional requirements (such as security, performance); preselect compliant components through a logic device (rule engine) to generate an initial SBOM; conduct a preliminary license compliance review based on the initial SBOM to check the component license types (such as MIT, GPL) and avoid high-risk licenses; then output the requirement document, the initial SBOM, and the license compliance report.

[0033] Specifically, when implementing, design a "one-key generate SBOM" function in the IPD requirement management interface, call the SCA tool (such as Black Duck) to scan the code library; generate an SBOM in a standard format (SPDX or CycloneDX), and bind it to the requirement entries to form a requirement - SBOM mapping relationship.

[0034] Step S2, in the IPD development and design stage, update the initial SBOM by integrating the SCA tool to scan the code library, identify known vulnerabilities of the components in the SBOM to generate a risk list, and intercept high-risk components according to dynamic thresholds.

[0035] In the development and design phase of the IPD process, input the requirements document and the initial SBOM, integrate the SCA tool (such as BlackDuck) to scan the code library and update the SBOM; identify known vulnerabilities (CVE) in the components, generate a risk list; apply dynamic rules in the logic engine: automatically intercept high-risk components according to the risk threshold (such as CVSS score > 7); conduct in-depth license verification to ensure that all component licenses comply with the enterprise compliance policy; output the updated SBOM, vulnerability report, and license verification results.

[0036] During specific implementation, dock with systems such as Jira and Zentaopms through OpenAPI and define the following interfaces: OST / api / sbom / sync: Sync the SBOM to the task management system; GET / api / sbom / risk / {taskId}: Obtain the SBOM risk status associated with the task; After the development submits the code, it automatically triggers the SBOM update and notifies the testing team through Webhook to achieve real-time synchronization in the development phase.

[0037] Furthermore, the dynamic threshold is calculated through the following formula: Threshold = μ + 2σ Threshold = μ + 2σ Where μ is the average CVSS score of historical vulnerabilities, and σ is the standard deviation.

[0038] Intercept high-risk components according to the dynamic threshold, specifically including: Step S21, periodically (such as daily) pull the latest vulnerability data from the NVD (National Vulnerability Database), calculate the average CVSS score (μ) and standard deviation (σ) of the vulnerabilities, and update the threshold configuration.

[0039] Step S22, scan the initial SBOM in real time, trigger the high-risk component interception mechanism and provide rectification suggestions.

[0040] In the above implementation logic, the support rules are stored in the database in JSON format, and the rule execution results are fed back to the operation and maintenance monitoring dashboard in real time.

[0041] Furthermore, the high-risk component interception mechanism is implemented through a risk prediction model based on machine learning, and a risk matrix report is output, marking high-risk components and their impact scope. During the implementation of the risk prediction model based on machine learning: Through feature engineering, extract 20-dimensional features such as component version, license type, and vulnerability history; including: a) Component version (the semantic version number is parsed into the major version, minor version, and revision number); b) License type (classification coding, such as MIT = 1, GPL-2.0 = 2); c) Number of historical vulnerabilities (number of CVEs in the past year); d) Code activity (Git commit frequency, number of maintainers); Community health (number of GitHub Stars, issue resolution rate); The XGBoost algorithm is used for model training, and the accuracy is ≥95%; The validation method uses 5-fold cross-validation, and the AUC is ≥0.95; Prediction output: Generate the component risk level (high / medium / low) and alternative suggestions, and provide the prediction results through the REST interface: GET / api / risk / predict / {componentId}.

[0042] In step S3, in the IPD test phase, match the pre-set test case library according to the risk list, and set quality access control; Generate a test report, a risk handling plan for those who fail to pass the access control, and an SBOM that passes the access control.

[0043] In this step, the updated SBOM and test case library are input; Special test cases are designed for high-risk components; Set quality access control (such as the vulnerability repair rate ≥95%), and if the standard is not met, an alarm will be triggered; Develop mitigation measures for unpatched vulnerabilities (such as temporary patches, component replacement); Output a test report, a risk handling plan, and an SBOM that passes the access control.

[0044] Specifically, according to the vulnerability information, automatically associate the vulnerabilities in the SBOM with the test cases: Match the test case library according to the CVE number and generate a special test plan; If the CVSS score of the vulnerability is ≥7, it is mandatory to supplement penetration test cases.

[0045] Furthermore, starting from the user-initiated pipeline, by integrating the SBOM management system, static application security system, and dynamic application security system, quality access controls are built respectively. Through the three quality defenses of the pipeline, the final project delivery is made safe and reliable. See Figure 3 .

[0046] Pipeline quality access control: Overall quality access control is carried out through the pipeline quality access control. The process is as follows: The pipeline triggers SAST / DAST scans, and the scan results are pushed to the rule engine through MQ; The rule engine combines the SBOM risk score and the test results to determine whether to allow entry into the next stage; If intercepted, automatically generate rectification suggestions (such as changing the component version) and notify the responsible person; After approval, the pipeline continues to execute, and finally a compliant SBOM report is generated.

[0047] The SBOM system provides external scanning tools or open APIs for pipeline calls, and provides information such as SBOM lists, risk information, and rectification suggestions. At the same time, the SBOM system instantiates the scanning results on the platform according to the information called by the pipeline, and finally presents them on the system from different perspective views. The quality gate calls the SAST system scanning tool to obtain the corresponding scanning report. The quality gate calls the DAST system scanning tool to obtain the corresponding scanning report. By docking with the knowledge base and empowering the IPD process platform, it can provide detailed explanations for the SBOM bill of materials it manages, and provide black and white lists and risk management capabilities for users.

[0048] Step S4, in the IPD release stage, deploy the application in the target environment, generate a compliance report based on the SBOM passing the gate and archive it bound to the release package. At the same time, synchronize the SBOM to the operation and maintenance side.

[0049] In this step, input the SBOM passing the gate and the release plan, and then conduct admission / shipment checker review: generate a compliance report based on the SBOM to ensure that all components meet the release standards. Then deploy the application in the system devices: deploy the application in the target environment (servers, containers) and synchronize the SBOM to the operation and maintenance system. Bind the final SBOM to the release package and archive it to the knowledge base, and finally output the release version, archived SBOM, and deployment logs.

[0050] Step S5, in the IPD operation and maintenance stage, regularly scan for vulnerabilities and update the SBOM, automatically trigger patch updates or component replacements, and re-perform the gate check.

[0051] In this step, input the deployed application and real-time monitoring data. Regularly scan through the SCA tool to detect newly disclosed vulnerabilities and conduct dynamic vulnerability monitoring. When high-risk vulnerabilities are found, automatically trigger the patch update component replacement process. Push risk alerts and repair suggestions through email / DingTalk. Update the SBOM and re-perform the gate check to form a closed-loop management. Output the updated SBOM, operation and maintenance report, and risk closed-loop record. Furthermore, the method further includes: Step S6, integrate an IDE plugin at the R & D end to prompt component risks in real time; automate the association of SBOM vulnerabilities with test cases at the test end; conduct visual monitoring and egress control at the operation and maintenance end.

[0052] Specifically: IDE plugin at the R & D end (such as VS Code extension): a) Real-time scan code dependencies and mark high-risk components (highlighted in red); b) The right-click menu supports one-click component replacement (call Maven / Gradle commands).

[0053] Automated Association Vulnerabilities in the Test End: a) The test platform parses the SBOM and automatically generates penetration test cases (such as Burp Suite scripts); b) The test results are written back to the SBOM system to update the component risk status.

[0054] The operation and maintenance end monitors the component status through a visual dashboard and supports one-click triggering of the release process.

[0055] Visual Dashboard: a) Displays the component health status (marked with green / yellow / red); b) Supports one-click triggering of the release process and generates compliance reports (in PDF / Excel format).

[0056] In the specific implementation process, in terms of system architecture design, this application fully considers the openness, scalability, and independence among various modules and service interfaces. The system can be quickly expanded and horizontally scaled without affecting or interrupting the original business service capabilities. The integration of third-party systems is considered at the design level, and third-party systems can be seamlessly and quickly connected to provide various channels, various forms of service presentation, and application capabilities for our system.

[0057] Core Module Interaction Logic: SBOM Collection Engine: Integrates SCA tools (such as Black Duck), supports automated scanning of code libraries, container images, and binary files; generates SBOMs in standard formats (SPDX, CycloneDX), and parses component dependency relationships and license information; Intelligent Rule Engine: Dynamic Threshold Algorithm: Calculates the mean and standard deviation based on historical vulnerability data and sets the CVSS scoring threshold (e.g., threshold = mean + 2σ); Supports custom rules (such as automatic interception of blacklisted components and license compliance checks); Cross-Departmental Collaboration Platform: Connects to the IPD system (Jira, ZenTao) through RESTful APIs to achieve real-time synchronization of requirements, tasks, and defect status; After the R & D submits a component, it automatically triggers the association of test cases and the configuration of operation and maintenance monitoring; Risk Prediction Model: Feature Engineering: Extracts 20-dimensional features such as component version, license type, vulnerability history, and code activity; Model Training: Adopts the XGBoost algorithm, with the accuracy rate of the training set ≥ 95% and the recall rate ≥ 90%; Output Results: Generates a risk level (high / medium / low) and a recommended list of alternative components.

[0058] The system adopts the currently open standard, open source, mature and very popular spring cloud microservice architecture. The overall architecture of the system is as Figure 4 shown: The system is divided into four layers from the technical architecture level, namely: system presentation layer, load balancing layer, business application layer, and data access layer.

[0059] System presentation layer: It mainly includes the front-end web page, third-party docking system, global style, page layout, etc.

[0060] Load balancing layer: When mainly in distributed deployment, it conducts unified routing control, and the servers are deployed in a load balancing cluster. All microservices in the application layer perform load balancing control through the api gateway.

[0061] Business application layer: Decouple the business application logic, make the common modules into common services, and conduct unified authentication and unified management, such as: single sign-on, unified authentication, unified logging, unified configuration, unified caching, etc. The functional modules are microservicized. For example, relatively independent modules such as WEB automation and interface automation are deployed as a separate service to provide interface service capabilities for the front end; the calls between each microservice are provided through service governance to avoid mesh-like mutual calls between microservices.

[0062] Data access layer: It mainly adopts database technology, in-memory database technology, and file data processing technology to provide data access and persistence services.

[0063] From the technical framework level, the system sets up common reusable modules at the architecture level such as service registration, service discovery, fuse, monitoring and inspection, security control, exception handling, and log handling.

[0064] From the business architecture level, the system achieves business decoupling. According to business needs, it splits WEB automation services, interface automation services, mobile automation services, performance testing services, task scheduling services, error handling services, asynchronous message services, etc. Each service is decomposed into separate microservices to meet the requirements of distributed microservice deployment.

[0065] Developed based on the distributed microservice Spring Cloud framework, with separation between the front and back ends, and using RESUFul API calls. The overall architecture has 7 layers: load balancing layer, service gateway layer, service discovery / registration center, business microservice layer, data caching layer, data access layer, and data storage layer. As Figure 5 , the detailed design description of the technical architecture is as follows: Implement unified authentication and authorization using OAuth2.0; Use the Ribbon component to achieve load balancing for calls between microservices; Implement the circuit breaker mechanism using Hystix to achieve automatic service degradation; The configuration center manages the configurations of all microservice applications, separating applications from configurations, making microservices stateless, and allowing services to automatically scale according to business traffic; Distributed service tracking system to achieve service monitoring and tracking; Use MQ to implement asynchronous service requests and queues, such as: the continuous integration pipeline asynchronously calls the test service platform, and the same application integrates the queue mechanism, etc.; The data cache layer is implemented using Redis Cluster to reduce the database access pressure and ensure high service availability; Adopt appropriate storage methods for different data, such as: business data is stored in MySQL, and logs are stored in MongoDB, etc.;

[0066] In terms of the deployment architecture, the deployment architecture is as follows Figure 6 , to meet the requirements of high service availability, high concurrency, and avoid single point of failure problems, it is deployed in a distributed cluster architecture and delivered in a docker containerized manner. Implement load balancing and dual-machine hot standby through nginx + keepalived, and deploy the service registry center SpringCloud Eureka and Config Server in a cluster. The database has one master and multiple slaves, with read-write separation, and semi-synchronous replication is used for synchronization between the master and slaves. The Redis cluster is deployed. To better protect data from loss, AOF persistence is adopted, and cold backup is in the RDB mode.

[0067] In terms of the data architecture, such as Figure 7 , the data architecture of this system is divided into four layers: Data application layer: The data application layer is the top layer directly facing users and business scenarios. It mainly includes various software application programs, reporting tools, and data analysis and visualization platforms developed to meet specific business goals. These application programs obtain the required data by calling the data services in the lower layer and present the data to users in an intuitive and easy-to-understand form.

[0068] Data Service Layer: The data service layer is located between the data application layer and the data storage layer, acting as a bridge and intermediary. It encapsulates the access logic to the data in the data storage layer and provides functions such as data acquisition, data update, and data query to the outside in the form of service interfaces. These data services can be implemented based on different technical architectures, such as Web services in the Service-Oriented Architecture (SOA) or RESTful-style APIs. The design of the data service layer enables the data application layer to avoid directly dealing with complex data storage structures, reducing the coupling degree of the system and improving data security and manageability.

[0069] Data Storage Layer: The data storage layer is the basic layer of the data architecture, responsible for the persistent storage of data. It covers a variety of different types of data storage media and database management systems to adapt to data with different structures, scales, and characteristics. Relational databases such as MySQL and Oracle are suitable for storing highly structured data that requires frequent complex transaction processing and precise queries, such as enterprise financial data and employee information; non-relational databases such as MongoDB and Redis are good at handling semi-structured or unstructured data, such as a large number of log files, social media data, and cache data. In addition, it may also include data warehouses (such as Hive-based data warehouses) for storing and managing massive historical data to support enterprise-level data analysis and decision-making support.

[0070] Data Synchronization Layer: The data synchronization layer is mainly responsible for ensuring data consistency and timeliness between different storage systems and different data nodes. In a complex enterprise data environment, data may be distributed across multiple systems. The data synchronization layer uses a series of data synchronization technologies and tools to achieve data transmission, conversion, and integration.

[0071] In addition, the platform of this application can be guaranteed to be deployed on domestic servers and domestic operating systems, support CPUs such as Feiteng, Kunpeng, and Haiguang, and support server operating systems such as Kirin, Tongxin, and OpenEuler.

[0072] This application covers the full life cycle management from product planning to release and maintenance, integrating core links such as risk control management, SBOM (Software Bill of Materials) generation and analysis, vulnerability detection, license compliance check, risk control, and R & D process management to ensure the security and efficient management of the software supply chain and solve the problems of poor integration and traceability between SBOM and IPD processes. The advantages of this application are illustrated as follows with data: 1. Efficiency improvement: The automated approval process shortens the processing time to 1 hour; Through automated SBOM scanning and rule engines, the manual review workload is reduced by 80%; The cross - departmental data synchronization mechanism shortens the demand response time from 48 hours to 1 hour.

[0073] 2. Risk controllable: The dynamic threshold adjustment increases the interception rate of high - risk components to 95%; The accuracy rate of the dynamic rule engine for intercepting high - risk components increases to 95%; The false - alarm rate of the machine - learning model for predicting vulnerabilities is less than 5%; 3. Collaborative optimization: The real - time cross - departmental data synchronization reduces the communication cost by 70%; The RESTful API enables real - time synchronization of R & D, testing, and operation and maintenance data, reducing the communication cost by 70%; The unified dashboard displays the full - process status, reducing the frequency of cross - departmental meetings.

[0074] 4. Compliance guarantee: It supports one - key generation of an SBOM report compliant with ISO / IEC 5230.

[0075] One - key generation of an SBOM report compliant with ISO / IEC 5230, with an audit passing rate of 100%; Built - in multi - country license templates (such as GDPR, CCPA), supporting automated compliance checks.

[0076] See Figure 8 , corresponding to the above - mentioned embodiment of the IPD process management method based on SBOM, the embodiment of the present application provides an IPD process management device based on SBOM, including: The initial SBOM module 1001 is used to output a requirements document during the IPD requirements definition stage, and at the same time pre - select compliant components through a logic unit to generate an initial SBOM and output a license compliance report; among them, the initial SBOM is bound to requirement entries to form a requirement - SBOM mapping relationship; The dynamic update and risk interception module 1002 is used to update the initial SBOM by integrating SCA tools to scan the code library during the IPD development and design stages, identify known vulnerabilities of components in the SBOM to generate a risk list, and intercept high - risk components according to dynamic thresholds; The risk association and access control module 1003 is used to match the pre - set test case library according to the risk list during the IPD testing stage, set quality access controls; generate a test report, a risk handling plan for those who fail to pass the access control, and an SBOM for those who pass the access control; The compliance release and archiving module 1004 is used to deploy the application in the target environment during the IPD release stage, generate a compliance report based on the SBOM that has passed the access control and archive it by binding it to the release package; at the same time, synchronize the SBOM to the operation and maintenance side; The iterative module 1005 is used to regularly scan for vulnerabilities and update the SBOM during the IPD operation and maintenance phase, automatically trigger patch updates or component replacements, and re - execute access control checks.

[0077] Furthermore, the device further includes a terminal multi - role collaborative interaction module for: Integrating an IDE plugin at the R & D end to real - time prompt component risks; Automatically associating SBOM vulnerabilities with test cases at the test end; Performing visual monitoring and egress control at the operation and maintenance end.

[0078] Furthermore, the dynamic threshold is calculated by the following formula: Threshold = μ + 2σ Threshold = μ + 2σ where μ is the mean value of the historical vulnerability CVSS score and σ is the standard deviation.

[0079] Furthermore, the dynamic update and risk interception module 1002 is specifically further used for: Periodically pulling the latest vulnerability data from NVD, calculating the mean value and standard deviation of the vulnerability CVSS score, and updating the threshold configuration; Scanning the initial SBOM in real - time, triggering a high - risk component interception mechanism and providing rectification suggestions; Among them, the high - risk component interception mechanism is implemented through a risk prediction model based on machine learning, outputting a risk matrix report and marking high - risk components and their impact ranges.

[0080] The above - mentioned IPD process management device based on SBOM implements the steps and processes of the above - mentioned IPD process management method embodiment based on SBOM, and can achieve the same technical effects. To avoid repetition, it will not be elaborated here.

[0081] See Figure 9 , corresponding to the above - mentioned IPD process management method embodiment based on SBOM, an embodiment of the present application provides an electronic device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps and processes of the above - mentioned IPD process management method embodiment based on SBOM, and can achieve the same technical effects. To avoid repetition, it will not be elaborated here.

[0082] The memory 1009 can be used to store software programs and various data. The memory 1009 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data. Among them, the first storage area may store an operating system, application programs or instructions required for at least one function (such as a sound playback function, an image playback function, etc.). In addition, the memory 1009 may include a volatile memory or a non-volatile memory, or the memory 1009 may include both a volatile memory and a non-volatile memory. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDR SDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synchlink dynamic random access memory (SLDRAM), and a direct rambus random access memory (DRRAM). The memory 1009 in the embodiments of the present application includes, but is not limited to, these and any other suitable types of memories.

[0083] The processor 1010 may include one or more processing units; optionally, the processor 1010 integrates an application processor and a modem processor. Among them, the application processor mainly processes operations related to the operating system, user interface, and application programs, etc., and the modem processor mainly processes wireless communication signals, such as a baseband processor. It can be understood that the above-mentioned modem processor may not be integrated into the processor 1010 either.

[0084] Corresponding to the embodiments of the above SBOM-based IPD process management method, the embodiments of the present application also provide a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps and processes of the embodiments of the above SBOM-based IPD process management method are implemented, and the same technical effects can be achieved. To avoid repetition, it will not be elaborated here.

[0085] Among them, the processor is the processor in the electronic device described in the embodiments of the present application above. The readable storage medium includes computer-readable storage media, such as computer read-only memory ROM, random access memory RAM, magnetic disks, or optical discs, etc.

[0086] It should be noted that in this article, the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article or device including that element. In addition, it should be pointed out that the methods and devices in the embodiments of the present application are not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in a reverse order according to the functions involved. For example, the described methods may be performed in an order different from that described, and various steps may also be added, omitted, or combined. Additionally, the features described with reference to certain examples may be combined in other examples.

[0087] Through the description of the above embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc), and includes several instructions to enable a terminal (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present application.

[0088] It can be understood that the embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Those skilled in the art know that without departing from the spirit and scope of the present invention, these features and embodiments can be variously changed or equivalently replaced. Additionally, those of ordinary skill in the art, under the inspiration or teaching of the present application, can modify these features and embodiments to adapt to specific situations and materials without departing from the spirit and scope of the present invention. Therefore, the present invention is not limited by the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of the present application belong to the scope protected by the present invention.

Claims

1. An IPD process management method based on SBOM, characterized in that, Including: In the IPD requirement definition stage, a requirement document is output. Meanwhile, compliant components are preselected through a logic device to generate an initial SBOM, and a license compliance report is output. Among them, the initial SBOM is bound to requirement items to form a requirement-SBOM mapping relationship. In the IPD development and design stage, the initial SBOM is updated by scanning the code library through an integrated SCA tool, known vulnerabilities of components in the SBOM are identified to generate a risk list, and high-risk components are intercepted according to a dynamic threshold. In the IPD testing stage, the pre-set test case library is matched according to the risk list to set quality access controls; a test report, a risk handling plan for failing to pass the access control, and an SBOM passing the access control are generated. In the IPD release stage, the application is deployed in the target environment, a compliance report is generated based on the SBOM passing the access control and archived by binding to the release package; meanwhile, the SBOM is synchronized to the operation and maintenance side. In the IPD operation and maintenance stage, vulnerabilities are scanned regularly and the SBOM is updated, patch updates or component replacements are automatically triggered, and the access control check is re-executed.

2. The SBOM-based IPD process management method according to claim 1, wherein, The method further includes: Integrating an IDE plugin at the R & D side to prompt component risks in real time. Automatically associating SBOM vulnerabilities with test cases at the testing side. Performing visual monitoring and egress control at the operation and maintenance side.

3. The IPD process management method based on SBOM according to claim 1, characterized in that The dynamic threshold is calculated by the following formula: Threshold = μ + 2σ Threshold = μ + 2σ Where μ is the mean value of historical vulnerability CVSS scores and σ is the standard deviation.

4. The IPD process management method based on SBOM according to claim 1, characterized in that Intercepting high-risk components according to the dynamic threshold specifically includes: Periodically pulling the latest vulnerability data from NVD, calculating the mean value and standard deviation of vulnerability CVSS scores, and updating the threshold configuration. Scanning the initial SBOM in real time, triggering a high-risk component interception mechanism and providing rectification suggestions. Among them, the high-risk component interception mechanism is implemented through a risk prediction model based on machine learning, outputting a risk matrix report and marking high-risk components and their influence ranges.

5. The IPD process management device based on SBOM is characterized in that, Including: An initial SBOM module, used to output a requirement document in the IPD requirement definition stage. Meanwhile, compliant components are preselected through a logic device to generate an initial SBOM, and a license compliance report is output. Among them, the initial SBOM is bound to requirement items to form a requirement-SBOM mapping relationship. A dynamic update and risk interception module, used to update the initial SBOM by scanning the code library through an integrated SCA tool in the IPD development and design stage, identify known vulnerabilities of components in the SBOM to generate a risk list, and intercept high-risk components according to a dynamic threshold. A risk association and access control module, used to match the pre-set test case library according to the risk list to set quality access controls in the IPD testing stage; generate a test report, a risk handling plan for failing to pass the access control, and an SBOM passing the access control. A compliance release and archiving module, used to deploy the application in the target environment in the IPD release stage, generate a compliance report based on the SBOM passing the access control and archive it by binding to the release package; meanwhile, synchronize the SBOM to the operation and maintenance side. An iterative module, used in the IPD operation and maintenance stage, to regularly scan for vulnerabilities and update the SBOM, automatically trigger patch updates or component replacements, and re - execute access control checks.

6. The SBOM - based IPD process management device according to claim 5, wherein the device further includes a terminal multi - role collaborative interaction module, which is used for: integrating an IDE plugin at the R & D end to real - time prompt component risks; automatically associating SBOM vulnerabilities with test cases at the testing end; performing visual monitoring and exit control at the operation and maintenance end.

7. The SBOM - based IPD process management device according to claim 5, wherein the dynamic threshold is calculated by the following formula: Threshold = μ + 2σ Threshold = μ + 2σ where μ is the mean value of the historical vulnerability CVSS score and σ is the standard deviation.

8. The SBOM - based IPD process management device according to claim 5, wherein the dynamic update and risk interception module is specifically further used for: periodically pulling the latest vulnerability data from NVD, calculating the mean value and standard deviation of the vulnerability CVSS score, and updating the threshold configuration; scanning the initial SBOM in real - time, triggering a high - risk component interception mechanism and providing rectification suggestions; wherein the high - risk component interception mechanism is implemented through a risk prediction model based on machine learning, outputting a risk matrix report, and marking high - risk components and their impact scope.

9. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the SBOM - based IPD process management method according to any one of claims 1 to 4.

10. A readable storage medium, characterized in that, A program or instruction is stored on the readable storage medium. When the program or instruction is executed by the processor, it implements the steps of the SBOM - based IPD process management method according to any one of claims 1 to 4.

Images