Software management method and device, electronic equipment, medium and program product

Abstract

The invention provides a software management method and device, electronic equipment, a medium and a program product, and can be applied to the technical field of big data and the field of financial science and technology. The method comprises the steps of obtaining target software machine account data and software construction information of an application system, identifying a target open source component used by the application system and a corresponding dependency relationship at least based on the target software machine account data and the software construction information, and obtaining a software material list; associating the software material list with external risk information, and generating a risk component list based on an association result; determining a governance target component based on the risk component list, and identifying an associated open source component having an association relationship with the governance target component based on a dependency relationship in the software material list to obtain a transformed software list; and based on the transformed software list, managing the version state of the corresponding open source component in the target software ledger data.

Description

Technical Field

[0001] This application relates to the fields of big data technology and fintech, and more specifically to a software management method, apparatus, device, medium, and program product. Background Technology

[0002] As software systems grow in scale and component-based development models become more widespread, open-source software has become a crucial foundation for building modern systems. However, it also brings with it risks such as frequent security vulnerabilities, outdated versions, changes in license rules, and maintenance disruptions. If enterprises lack systematic risk identification and planning capabilities, they are highly susceptible to unexpected events during the lifecycle, leading to production failures and supply chain risks.

[0003] Existing open-source software management systems primarily provide ledger-style records. While they can register versions, licenses, and deployment information, they remain at a static management stage, lacking real-time awareness of external ecosystem dynamics. They cannot automatically acquire community updates, risk announcements, and license change information, making it difficult to expose risks early. Furthermore, existing systems lack a risk-based proactive upgrade mechanism, only able to passively respond to security incidents, easily leading to the risk of emergency changes. Existing solutions also lack health monitoring capabilities, unable to assess project maintenance activity and supply chain sustainability. In addition, the systems lack multi-dimensional risk fusion analysis, failing to form an overall situational awareness, and unable to provide trend prediction and upgrade decision support. Summary of the Invention

[0004] In view of the above problems, this application provides software management methods, apparatus, devices, media and program products.

[0005] According to a first aspect of this application, a software management method is provided, the method comprising: acquiring target software ledger data and software construction information of an application system; identifying target open-source components used by the application system and their corresponding dependencies based at least on the target software ledger data and the software construction information, thereby obtaining a software bill of materials; associating the software bill of materials with external risk information, thereby generating a risk component list based on the association result; determining governance target components based on the risk component list, and identifying associated open-source components that are associated with the governance target components based on the dependencies in the software bill of materials, thereby obtaining a modified software list; and managing the version status of the corresponding open-source components in the target software ledger data based on the modified software list.

[0006] According to an embodiment of this application, the step of associating the software bill of materials with external risk information and generating a risk component list based on the association result includes: for the target open-source component, obtaining a multi-dimensional risk feature vector from a situational awareness information source, wherein the situational awareness information source includes at least runtime risk monitoring results, security risk intelligence, and license change information; introducing a time decay factor into the time-related features in the multi-dimensional risk feature vector to obtain a corrected risk feature vector; and associating and matching the target open-source component with the corrected risk feature vector based on the name, version number, and / or license information of the target open-source component to obtain a target risk open-source component, and generating the risk component list based on the target risk open-source component.

[0007] According to an embodiment of this application, determining the governance target component based on the risk component list includes: calculating a risk coverage index based on the risk score and usage scope of each open-source component in the risk component list, wherein the risk coverage index is used to characterize the degree of impact of the governance of a single open-source component on the overall risk reduction; and selecting a set of open-source components from the risk component list that makes the sum of the risk coverage index reach a preset target threshold, and determining the governance target component based on the set of open-source components.

[0008] According to an embodiment of this application, identifying the dependency relationship includes: parsing the dependency declarations in the software build information, extracting the direct dependencies between open-source components based on the parsing results, and obtaining a first dependency relationship set; obtaining a second dependency relationship set based on the startup configuration information and component loading information during the running process of the application system; and merging the first dependency relationship set and the second dependency relationship set to obtain the dependency relationship.

[0009] According to an embodiment of this application, the step of identifying associated open-source components that are related to the governance target component based on the dependency relationship in the software bill of materials, and obtaining a modified software list, includes: taking each governance target component as a starting point, traversing along a preset dependency direction on the dependency relationship to obtain associated open-source components and corresponding dependency paths; determining the dependency distance of the associated open-source component relative to the corresponding governance target component based on the dependency path, and counting the number of times each associated open-source component appears in multiple dependency paths; and filtering the associated open-source components based on the dependency distance and the number of occurrences, combining the filtering results with the governance target component to obtain the modified software list.

[0010] According to an embodiment of this application, the management of the version status of the corresponding open-source components in the target software ledger data based on the modified software list includes: obtaining the components to be addressed based on the modified software list, updating the version status of the components to be addressed from an available status to an observation status, collecting the corresponding application system operation results within a preset observation period; and updating the observation status to a prohibited use status in response to the application system operation results indicating that no rollback or fault records have been found; and updating the observation status to a restricted use status in response to the application system operation results indicating that rollback or fault records have been found.

[0011] According to an embodiment of this application, the method further includes: obtaining open-source components and corresponding version change information that have been included in the risk component list in multiple governance cycles based on historical governance records, and generating a historical risk sequence; and comparing the historical risk sequence with the component version evolution information in the software bill of materials to obtain potential risk components, and generating the risk component list based on the target risk open-source components and the potential risk components.

[0012] A second aspect of this application provides a software management device, comprising: a data acquisition module, configured to: acquire target software ledger data and software construction information of an application system, and identify target open-source components used by the application system and their corresponding dependencies based at least on the target software ledger data and the software construction information, thereby obtaining a software bill of materials; a risk association module, configured to: associate the software bill of materials with external risk information, and generate a risk component list based on the association results; a modified software determination module, configured to: determine target components for governance based on the risk component list, and identify associated open-source components that are associated with the target components for governance based on the dependencies in the software bill of materials, thereby obtaining a modified software list; and a software management module, configured to: manage the version status of the corresponding open-source components in the target software ledger data based on the modified software list.

[0013] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0014] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0015] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0016] According to embodiments of this application, by combining software ledger data, build information, and dependencies to construct a software bill of materials, comprehensive visualization and structured management of open-source components of the application system are achieved. By associating the software bill of materials with external risk information, open-source components affected by risks can be identified in a timely manner, forming an accurate list of risky components. Furthermore, based on the list of risky components, target components for governance are determined, and open-source components that are related to the target components for governance are identified by combining dependencies. This allows for the development of a modification list within a controllable scope, avoiding systemic risks caused by dependency omissions during the governance process. By managing the version status of the components corresponding to the modified software list, governance actions such as the replacement, upgrade, and disabling of open-source components are traceable, thereby constructing a closed-loop governance mechanism that runs through identification, assessment, governance, and verification. This not only significantly improves the accuracy of open-source software risk identification and the rationality of the governance scope but also reduces system instability caused by blind upgrades, improving the security, controllability, and maintenance efficiency of enterprise-level software systems. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 The illustrations depict application scenarios of software management methods, apparatus, devices, media, and program products according to embodiments of this application.

[0019] Figure 2 A flowchart illustrating a software management method according to an embodiment of this application is shown schematically;

[0020] Figure 3 A flowchart illustrating a method for obtaining a modified software inventory according to some exemplary embodiments of this application is shown schematically;

[0021] Figure 4 This illustration schematically depicts an overall process diagram of open-source software management according to some exemplary embodiments of this application;

[0022] Figure 5 This schematically illustrates a structural block diagram of a software management device according to an embodiment of the present application; and

[0023] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a software management method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] First, the technical terms used in this article are explained and clarified as follows.

[0029] Target software ledger data: This is used to represent the information records of open source components maintained by the organization during the software management process, such as component identification, historical usage, application system to which it belongs, version records, etc., to support the standardized identification and usage statistics of components.

[0030] Software Bill of Materials: This is a list of components generated based on the target software ledger data and the software build information of the application system. It includes information such as the identifiers, version information, and dependencies of open-source components, and is used to characterize the open-source software composition of the application system.

[0031] External risk information: This refers to risk warning data related to the use of open-source components that comes from external or independent information sources.

[0032] Risk Components List: This refers to a group of open-source components that are at risk or require special attention, obtained after correlating the software bill of materials with external risk information.

[0033] Governance target components: refers to open-source components that are selected from the list of risky components and require priority governance.

[0034] Modification Software List: This refers to the set of all open-source components that are directly or indirectly related to the governance target component and may need to be adjusted synchronously during the governance process, based on dependency analysis after the governance target component has been identified. It includes the governance target component and related open-source components.

[0035] Version status: This describes the usage strategy and governance phase of open-source components within an organization, including the status of continued use, the status of needing observation, the status of restricted use, and the status of discontinued use. It is used to guide the usage specifications of components at different stages.

[0036] Historical risk sequence: This is used to record the inclusion of open source components in the risk component list during multiple governance cycles, as well as related version change information. It is also used to reflect the changes in risk characteristics of components during long-term evolution, providing a basis for identifying potential risk components.

[0037] Potential risk components: These are components identified by comparing historical risk sequences with version evolution information in the current software bill of materials. Although they are not directly reflected in the current external risk information, they still require attention based on historical trends.

[0038] Multidimensional risk feature vector: used to represent a set of risk attributes extracted and structured from external risk information, such as component maintenance status, update frequency, community activity, license change records, supply chain stability prompts and other dimensions.

[0039] Situational awareness information sources: These refer to external or internal platforms that provide risk situational information for components, including runtime risk monitoring systems, supply chain risk monitoring platforms, license change monitoring systems, etc., which support the formation of external risk information.

[0040] Time decay factor: This parameter represents the weighting adjustment applied to risk information with time attributes, giving more weight to recent risk events in the analysis than earlier events. The time decay factor can be flexibly set based on the event's occurrence time, update cycle, or institutional strategy to improve the timeliness of risk assessment.

[0041] Component fingerprinting technology: refers to a technical method that uniquely identifies components based on their name characteristics, version rules, source path, binary characteristics, or other identifying information, in order to solve the problem of inconsistent naming methods for components from different sources or in different build environments.

[0042] Class loading trace: A record of the order in which components or modules are loaded by the class loader during the runtime of an application system, used to identify dynamic dependencies.

[0043] With the continuous expansion of software system scale and the popularization of modular and component-based development models, open-source software has become an indispensable and crucial foundational resource in the construction of modern software systems. The introduction of numerous mature open-source components, frameworks, and tools has significantly improved software development efficiency and drastically reduced development costs. However, while the open-source ecosystem brings convenience to enterprises, it also increasingly exposes a series of risks, including frequent security vulnerabilities, outdated and unupdated versions, complex and changing license rules, and interruptions in the maintenance of critical components. If enterprises cannot effectively and systematically identify and plan for the risks associated with the open-source software they use, they are highly susceptible to unexpected events during the software lifecycle, leading to production failures, compliance risks, and even supply chain disruptions.

[0044] In existing technologies, the industry typically uses open-source software management systems to manage open-source components in a ledger-like manner, recording software usage within an enterprise. For example, the system registers basic information such as software name, version number, license type, deployment location, and dependencies, and conducts regular audits to ensure that the registered information matches actual operation. Such systems help enterprises establish basic asset awareness and, to some extent, improve the compliance management process for open-source components.

[0045] However, research has found that existing open-source software management solutions generally remain at the stage of static management and passive response, making it difficult for enterprises to achieve refined and forward-looking risk governance in the complex and ever-changing open-source ecosystem. Specifically, existing technologies have the following main shortcomings.

[0046] First, existing systems generally employ a static recording model, lacking the ability to perceive the dynamics of the external ecosystem in real time. Information such as software version updates, maintainer activities, security risk announcements, and license rule changes in the open-source community are crucial for enterprises to formulate upgrade and risk management strategies. However, existing solutions lack an automated mechanism for collecting and analyzing external information, failing to incorporate these dynamic factors into management processes. Enterprises can only rely on manual searches or fragmented information from third parties for judgment, preventing potential security and maintenance risks from being exposed in advance.

[0047] Secondly, existing technology version planning capabilities are significantly lagging. Most systems only record the current version status without building a proactive upgrade strategy based on risk. When the maintenance activity of open-source components declines, the speed of risk remediation slows down, or there is a risk of supply chain disruption, the system cannot make timely trend analysis and early warnings. Enterprises often can only passively carry out emergency upgrades after a serious security incident, which not only disrupts the existing R&D and operation rhythm, but may also lead to new functional failures, compatibility issues, or performance degradation due to hasty changes, placing an additional burden on system stability.

[0048] Secondly, existing solutions lack the ability to continuously monitor the health of open-source projects, and relying solely on static ledgers makes it difficult to determine the long-term sustainability of project maintenance. For example, indicators such as the number of maintainers in the open-source community, code update frequency, issue response speed, and version iteration cycle can reflect different states of a project, such as continuous maintenance, slow decline, or impending discontinuation. However, existing systems have not established a health indicator system, nor have they linked health to the enterprise's own use cases, making it difficult to identify in a timely manner whether critical dependencies are experiencing maintenance stagnation or potential supply chain risks.

[0049] Finally, existing technologies cannot achieve enterprise-level overall situational awareness. The open-source ecosystem is highly uncertain; security incidents may erupt in clusters, and legal compliance risks may arise due to license changes. Existing ledger systems lack multi-dimensional risk fusion analysis capabilities, failing to form a unified risk view from multiple perspectives such as version risk, risk risk, license risk, health risk, and supply chain risk, and even less capable of predictive analysis and upgrade recommendations based on risk trends.

[0050] Based on this, embodiments of this application provide a software management method, the method comprising: acquiring target software ledger data and application system software construction information; identifying target open-source components used by the application system and their corresponding dependencies based at least on the target software ledger data and the software construction information, thereby obtaining a software bill of materials; associating the software bill of materials with external risk information, and generating a risk component list based on the association result; determining governance target components based on the risk component list, and identifying associated open-source components that are associated with the governance target components based on the dependencies in the software bill of materials, thereby obtaining a modified software list; and managing the version status of the corresponding open-source components in the target software ledger data based on the modified software list. According to embodiments of this application, by combining software ledger data, build information, and dependencies to construct a software bill of materials, comprehensive visualization and structured management of open-source components of the application system are achieved. By associating the software bill of materials with external risk information, open-source components affected by risks can be identified in a timely manner, forming an accurate list of risky components. Furthermore, based on the list of risky components, target components for governance are determined, and open-source components that are related to the target components for governance are identified by combining dependencies. This allows for the development of a modification list within a controllable scope, avoiding systemic risks caused by dependency omissions during the governance process. By managing the version status of the components corresponding to the modified software list, governance actions such as the replacement, upgrade, and disabling of open-source components are traceable, thereby constructing a closed-loop governance mechanism that runs through identification, assessment, governance, and verification. This not only significantly improves the accuracy of open-source software risk identification and the rationality of the governance scope but also reduces system instability caused by blind upgrades, improving the security, controllability, and maintenance efficiency of enterprise-level software systems.

[0051] It should be noted that the software management methods, apparatus, devices, media, and program products defined in this application can be used in the fields of big data technology and fintech, and can also be used in a variety of other fields besides big data technology and fintech. The application fields of the software management methods, apparatus, devices, media, and program products provided in the embodiments of this application are not limited.

[0052] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0053] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all offer users corresponding operation entry points, allowing them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process proceeds to expert decision-making. Here, "expert decision-making" refers to the decision-making activities of personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0054] Figure 1 The illustrations depict application scenarios of software management methods, apparatus, devices, media, and program products according to embodiments of this application.

[0055] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0056] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0057] In the embodiments of this application, the first terminal device 101 can be an example of the first device, and the second terminal device 102 and / or the third terminal device 103 can be an example of at least one second device. The first device and the second device can communicate collaboratively through an internal client mechanism to implement the data distribution and rendering logic described in the software management method.

[0058] In some embodiments, the first device and at least one second device may be different display modules, windows or screens on the same computing terminal (such as a host), or multiple physical devices that work together through a network, such as different client instances deployed on a desktop computer, tablet terminal or mobile device respectively.

[0059] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smart mobile terminals, tablet computers, laptop computers, and desktop computers.

[0060] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0061] It should be noted that the software management method provided in this application embodiment can generally be executed by server 105. Correspondingly, the software management device provided in this application embodiment can generally be located in server 105. The software management method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the software management device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0062] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0063] The following will be based on Figure 1 The described scene, through Figures 2-4 The software management method of the disclosed embodiments will be described in detail.

[0064] Figure 2 A flowchart illustrating a software management method according to an embodiment of this application is shown schematically.

[0065] like Figure 2 As shown, the software management method 200 of this embodiment includes operations S210 to S240.

[0066] In operation S210, target software ledger data and application system software construction information are obtained. At least based on the target software ledger data and software construction information, the target open source components used by the application system and their corresponding dependencies are identified, and a software bill of materials is obtained.

[0067] In the embodiments of this application, the software bill of materials for the application system can be generated by jointly parsing the target software ledger data and the software build information. The target software ledger data can be continuously maintained by the organization during long-term software management, recording the reference relationships, component identifiers, version information, usage scenarios, and corresponding basic metadata of each open-source component in different application systems. The software build information of the application system can come from build scripts, dependency configuration files, build artifact lists, resource description files, etc., and is used to describe the open-source components and configuration relationships that the application system depends on during compilation, packaging, and deployment.

[0068] In some embodiments, the software build information of an application system includes not only static configuration content but also intermediate results generated during the build process, such as the parsed dependency tree structure, component resolution logs, and feature switches enabled during the build process. By structuring the intermediate build artifacts, implicit dependencies that are difficult to discover through traditional static parsing can be identified. For example, when version wildcards are used in the dependency configuration file, the specific version ultimately parsed by the build platform should be considered the actual dependency of the application system. Furthermore, when an application system depends on a certain aggregate component, this aggregate component may be broken down into multiple basic components during the build phase. This type of decomposition during the build phase can also be included in the software bill of materials to ensure the completeness and accuracy of dependency identification.

[0069] In embodiments of this application, the system can also extract direct dependencies between components from software build information, including call relationships, resource loading relationships, protocol declaration relationships, and runtime environment declaration relationships. After parsing direct dependencies, the system can further construct a multi-level dependency structure to reflect the hierarchical position and interrelationships of open-source components within the application system. For complex application systems, dependencies may be represented as tree-like, network-like, or graph structures containing circular dependencies. The system can use algorithms such as graph traversal, hierarchical analysis, and dependency folding to normalize these complex dependency structures, enabling them to be efficiently utilized by subsequent analysis modules.

[0070] In some embodiments, to improve the comprehensiveness of dependency identification, the system can supplement static analysis results by incorporating component loading information from the runtime phase. Component loading information from the runtime phase can originate from the application system startup process, component loading trajectories recorded during runtime, dynamic parsing results of configuration files, and component activation processes triggered by plug-in mechanisms. Some open-source components are not explicitly declared during the build phase but are dynamically selected or enabled at runtime based on the context; these include components loaded through reflection, policy matching, or runtime environment negotiation mechanisms.

[0071] In the embodiments of this application, the target software ledger data can provide a unified component identification standard, enabling software build information from different build environments, business lines, or development teams to be processed in a standardized manner within the same framework. The ledger data can record a component's globally unique identifier, historical usage records, component source information, compliance attributes, scope of use, and sharing relationships with other application systems. When identifying open-source components, the system can utilize the ledger data to standardize component names, component paths, version representations, etc. For example, when different application systems use the same component but employ different naming methods or directory structures, the ledger data can serve as a lookup table to uniformly identify them as the same component, thereby avoiding issues of duplicate statistics or fragmented representation.

[0072] In the embodiments of this application, the system can also set various parsing strategies for the software bill of materials generation process to adapt to application systems of different sizes and types. For example, for application systems adopting modular or plug-in architectures, the system can identify the assembly relationship between components by parsing module description files and plug-in lists; for application systems adopting microservice architectures, the system can identify cross-service dependency links from service-level build lists and deployment information; for application systems adopting hybrid technology stacks (such as situations where scripting language components and compiled components coexist), the system can identify multi-source dependencies by combining static parsing and runtime trajectory collection.

[0073] In operation S220, the software bill of materials is linked with external risk information, and a risk component list is generated based on the linkage result.

[0074] In the embodiments of this application, the system can perform correlation analysis between the open-source components in the generated software bill of materials and external risk information to identify the set of components that may pose risks in the current application system. External risk information can originate from various channels, including risk announcements published by industry security communities, update notices from component maintenance teams, license adjustment notifications, component stability assessment results, trends in component ecosystem activity, and supply chain disruption warnings. Upon receiving external risk information, the system can first standardize the risk information, structuring and parsing the risk events according to fields such as component identifier, version information, license attributes, release time, and risk level to establish a matching basis that can be aligned with the component records in the software bill of materials.

[0075] In some embodiments, the system can perform preliminary matching between components in the software bill of materials and external risk information based on key fields such as component name, version number, and license information. When the component identifier recorded in the risk information differs in naming convention or alias from the record in the bill of materials, normalization can be performed using component fingerprinting technology, unified identifiers recorded in the ledger, component source records, etc., to ensure matching accuracy. For cases where version number formats are inconsistent or range descriptions exist, the system can expand the matching according to component version rules, for example, converting the version range expression into a set of specific versions, so that the actual version in the bill of materials can be accurately matched.

[0076] In some embodiments, the system can consider the changing trends of the component ecosystem in correlation analysis to identify potential risk factors. For example, when a component has not been updated for a long time, the activity of the maintenance team has significantly decreased, or its usage rate in the open-source ecosystem continues to decline, the system can incorporate these trend analysis results into external risk information and, in conjunction with the software bill of materials, determine whether the component is an object requiring close attention. As another example, when a component is simultaneously flagged for potential stability issues or is largely abandoned across multiple industries, the system can consider it a potentially risky component and mark it in the risk component list.

[0077] In the embodiments of this application, the system can introduce statistical analysis or pattern recognition methods to deeply correlate external risk information. For example, when multiple risk information sources issue risk warnings for different versions and usage scenarios of a component, the system can perform cross-analysis based on the component dependency chain and deployment scenario recorded in the bill of materials to identify the key position of the component in the application system, thereby determining the potential impact of the risk on the system. As another example, when a risk event involves a change in the license attributes of a component, the system can further analyze its propagation impact in the dependency chain, identify other components that may be affected by license incompatibility, and form an extended risk component set.

[0078] In the embodiments of this application, the system can also integrate risk information from different sources by weighting it to generate a comprehensive risk score. The system can set different weights based on factors such as the authority, coverage, and historical accuracy of the risk source, and obtain a comprehensive risk assessment value for each open-source component through weighted calculation.

[0079] In some embodiments, the system can correlate external risk information with the version evolution sequence in the software bill of materials to determine whether a component is in a period of concentrated risk in its current version. For example, when a component has recently released frequent patch versions or its upstream dependent components are undergoing significant changes, the system can combine version evolution history and risk information to determine whether the component is in an unstable cycle and include it in the list of risky components. Furthermore, the system can also combine historical governance records to predict potential future risk trends for components and incorporate these trends into the supplementary evaluation criteria for the list of risky components.

[0080] In operation S230, the target components for governance are determined based on the risk component list, and related open-source components that are associated with the target components for governance are identified based on the dependencies in the software bill of materials, thus obtaining a list of software to be modified.

[0081] In embodiments of this application, the system can determine priority governance target components based on a risk component list. The risk component list can include risk warnings from multiple sources, including component update frequency, maintenance team activity, license rule changes, changes in community usage trends, long-term lack of updates, and supply chain instability signals. The system can comprehensively assess the risk level of each component based on these risk warnings to identify components that have a significant impact on the application system or require urgent governance. Based on this, the system can select some components as governance target components according to the organization's governance strategy, such as regular governance cycles, prioritizing high-risk components, or prioritizing components with a wide impact.

[0082] In some embodiments, the system can combine the risk assessment scores recorded in the risk component list with the scope of component usage across multiple application systems to determine the target governance components. Components referenced by multiple critical application systems typically have higher governance priority because the stability and controllability of these components have a significant impact on overall business operations. The system can calculate the component's impact weight in the overall environment based on the degree of component sharing, the business importance of the application system, and the component's position in the technical architecture, and then superimpose this weight with the risk level to generate a comprehensive governance priority. Components with higher comprehensive governance priority can be selected as target governance components, thereby enabling governance resources to focus on components with greater global impact.

[0083] In the embodiments of this application, after determining the target component for governance, the system can further identify open-source components that are related to the target component based on the dependencies in the software bill of materials, thereby obtaining a list of modified software. Dependencies can be reflected in reference relationships, hierarchical structures, loading orders, and functional coupling relationships between components. The system can start from the target component and traverse the dependency graph along a preset direction to identify related components that directly or indirectly depend on the target component or provide underlying support to it.

[0084] In some embodiments, the system can introduce the concept of dependency depth during dependency analysis to distinguish the relationship between the target component and dependent components at different levels. When the target component is located high in the dependency chain, its downstream components may need to be adjusted synchronously to ensure compatibility. The system can calculate the hierarchical distance between related components and the target component, and decide whether to include related components at a certain level in the scope of modification based on the organization's pre-defined governance strategy. For example, the organization can set a strategy to govern only one or two layers of dependencies, or it can set a strategy to comprehensively govern all levels of components, so as to flexibly control the balance between modification costs and governance scope in different governance cycles.

[0085] In the embodiments of this application, the system can consider the type and strength of dependencies when identifying related components. Some components have strong coupling dependencies, and their governance operations may directly affect the integrity of system functionality; while some components are only weak dependencies, such as being loaded only under specific conditions or being passively dependent. The system can distinguish the necessity of governing related components based on the dependency type and call frequency. When generating the modified software inventory, the system can choose to include all strongly dependent components in the governance scope, while selectively including weakly dependent components, or manually confirming them according to the actual situation.

[0086] In some embodiments, the system can also adjust the scope of the transformation based on the actual operation of the application system. For example, if a related component has a very low call frequency during the runtime phase or does not participate in the core business process, it can be excluded from the transformation scope to reduce governance costs. Conversely, related components that have a high call frequency during the runtime phase and have a significant impact on system functionality should be included in the transformation list, even if their dependency level is deep.

[0087] In the embodiments of this application, the system can further incorporate historical governance records to optimize the generation method of the modified software inventory. Historical records may include compatibility issues, fine-tuning scope, and dependent components requiring additional confirmation that occurred during past governance processes. The system can utilize this historical experience to refer to previous governance paths when generating the modified software inventory, thereby avoiding the recurrence of the same problems. For example, if a component has triggered a large-scale chain of changes during previous version switches, the system can proactively alert governance personnel that the component may have broader implicit dependencies, thus expanding the scope of this governance effort and preventing the omission of critical dependent components.

[0088] In some embodiments, the software refactoring manifest may include not only the components that need to be updated or replaced, but also supplementary information such as the dependency paths of each component, sources of risk, governance priorities, involved business modules, and expected maintenance windows. This extended information helps governance personnel to better understand the complexity of the refactoring scope and assists in developing a more refined governance plan. For example, by explicitly showing the dependency edges and hierarchical relationships between components, the governance team can identify potential impact areas during the refactoring process and develop appropriate testing strategies.

[0089] When operating S240, based on the list of modified software, the version status of the corresponding open-source components in the target software ledger data is managed.

[0090] In the embodiments of this application, the system can uniformly manage the version status of corresponding open-source components in the target software ledger data based on the modified software list, to ensure that the governance results can be implemented and maintained at the system level. The modified software list typically includes open-source components that need to be adjusted, replaced, or deactivated in this round of governance. The system can update the version records of these components in the ledger according to the list content. The version status can be used to indicate the usage recommendations and restrictions of the component within the organization, including different levels such as continueable use, need for observation, restricted use, and discontinued use.

[0091] In some embodiments, the system can establish a full-link record mechanism for governance versions when managing version status. After governance operations are completed, open-source components in the software inventory can be assigned a new version identifier. The system will record information about this new version in the ledger, including its source, release date, reason for change, and associated governance task identifier. For example, when a component is assessed as a high-risk version, the system can mark it as deprecated and its replacement version as recommended for use.

[0092] In the embodiments of this application, the system can batch process components according to the modified software list, enabling version management operations to be executed automatically and maintain consistency. When a component is simultaneously depended on by multiple application systems, the system can uniformly update the version status of the component according to the modified software list and push relevant prompts to these application systems. For example, when a component is marked as restricted, the system can prompt each team that depends on the component to complete the replacement or upgrade operation within the appropriate maintenance window.

[0093] In some embodiments, the system can incorporate historical governance data for auxiliary evaluation during version status management. For example, if a component has been rolled back due to compatibility issues in past governance, the system can set the component's version status to a state requiring observation in the current governance cycle and monitor its stability performance during a specific observation period. If no operational issues are detected during the observation period, the version can be updated to a recommended usage state; however, if significant anomalies occur during the observation period, the version status can be further adjusted to a restricted or discontinued usage state.

[0094] In the embodiments of this application, version status management can also be implemented in conjunction with the organization's internal software release strategy. For example, for systems requiring high stability and controllability, version status management can adopt a progressive strategy, first marking new versions as needing observation, and then gradually upgrading their status based on operational status. Conversely, for some rapidly iterating systems, version status updates can be more direct, such as using a rapid replacement strategy to ensure the continuous use of the version most suitable for the system.

[0095] In some embodiments, the system can generate version status adjustment suggestions based on the software modification manifest, including alternative versions, recommended usage instructions, compatibility considerations, and dependency change analysis. These suggestions can be pushed to relevant teams through the system interface, automatic notifications, or reports, helping developers and operations personnel quickly understand the reasons behind version status changes and reducing the cognitive cost of version switching. For example, when a component is marked as deprecated, the system can automatically list alternative components or updated versions and provide compatibility information to facilitate overall adjustments by the team.

[0096] In the embodiments of this application, the system can trigger a series of auxiliary processes while updating the version status to ensure that the governance results can be implemented at each system level. For example, the system can automatically check whether there are still components in the current application system that have been marked as stopped or restricted from use. If so, the system will prompt the developers to make corrections. The system can also add a version verification step to the build process to automatically prevent unauthorized versions from entering the production environment.

[0097] In some embodiments, version status management can support customized policies to accommodate the governance flexibility needs of different business lines within large organizations. For example, for certain business-critical application systems, stricter status thresholds can be set, allowing components to unconditionally enter a restricted use state when assessed as having a high risk; while for experimental or internal tool systems, version status policies can be more lenient to allow for quick trials of new versions or exploratory features.

[0098] In the embodiments of this application, the version status records ultimately generated by the system can be used for subsequent governance assessments and trend analysis. For example, the system can statistically analyze indicators such as the number of version status changes for each component, the frequency of component updates during the governance cycle, and the stability performance of the system after governance, providing quantitative basis for the organization's governance decisions. If a certain type of component consistently exhibits a high transformation cost or a trend of frequent changes across multiple governance cycles, the system can prompt the organization to adjust its dependency strategy, or even consider replacing the component source or optimizing the architecture, in order to fundamentally reduce governance costs.

[0099] According to embodiments of this application, by jointly analyzing the target software ledger data and the software construction information of the application system, the system can comprehensively and accurately identify the open-source components actually used by the application system and their dependencies, and generate a structured software bill of materials, providing a reliable data foundation for subsequent governance. By correlating the software bill of materials with external risk information, the system can promptly identify components that are unstable or have potential compliance and supply chain risks, forming a list of risky components that can be used for governance decisions, thereby significantly improving the timeliness and accuracy of risk identification. On this basis, by comprehensively considering the risk attributes and dependency structure of the components, the system can determine the governance target components that need to be addressed, and further identify the associated open-source components, forming a list of modified software with reasonable coverage and sufficient impact analysis, enabling the governance process to balance comprehensiveness and cost controllability.

[0100] The software management method of this application will be specifically described below by way of preferred embodiments.

[0101] In the embodiments of this application, after generating the software bill of materials, the system can perform correlation analysis between the target open-source components recorded therein and risk information from external sources to form a more targeted list of risky components. External risk information can be continuously provided by multiple situational awareness information sources, including at least risk monitoring results generated during the application system's operation, publicly available component risk intelligence within the industry, update and adjustment notices issued by component maintainers, and information related to changes in component license terms. The system can structure and organize the above-mentioned multi-source information, transforming it into a multi-dimensional risk feature vector that can be used for feature analysis, so that each risk dimension can be quantified and aligned, facilitating subsequent correlation processing.

[0102] In some embodiments, for risk information with time attributes in situational awareness information sources, the system can introduce a time decay factor to the relevant features, giving higher weight to recent risk events in the analysis process, while gradually weakening the impact of earlier events. For example, when a component experiences a significant decrease in activity, a slower pace of community maintenance, or multiple adjustments to relevant license rules within a short period, the system can enhance the influence of this type of information on the overall risk assessment through the time decay mechanism.

[0103] In the embodiments of this application, the system can perform association matching with the time-corrected risk feature vector based on the name, version number, license type, and recording method of the target open-source component in the bill of materials. Since different information sources may use different naming or version representation methods, the system can perform unified identification processing on the target open-source component based on ledger data and component fingerprint technology to ensure matching accuracy. After unifying the identification, the system can retrieve the feature records corresponding to the target open-source component in the multi-dimensional risk vector and mark the successfully matched component as the target risk open-source component.

[0104] According to the embodiments of this application, it is possible to highlight high-risk components that are still exposed in the near future, avoid misjudgments caused by historical but fixed issues, and improve the accuracy and practical value of risk identification.

[0105] In the embodiments of this application, after obtaining the risk component list, the system can determine the key governance target components to be addressed in this round of governance based on the multi-dimensional risk attributes contained in the list. The risk component list can record the risk level, frequency of occurrence, usage scenarios, distribution in different application systems, and scope of dependencies for each open-source component. The system can generate a risk score for each component based on these attributes to quantify the potential impact of the component on the overall environment. Simultaneously, the system can also combine the software bill of materials to statistically analyze the usage scope of components in multiple application systems, including whether the component is depended upon by critical business modules, whether it is reused as a basic component in multiple systems, and the criticality of the component in the dependency structure.

[0106] In some embodiments, the system can calculate a risk coverage index based on risk scores and usage scope. This risk coverage index can be used to measure the extent to which governing individual components can reduce the potential risks of the overall system. For example, a component with a high risk score and widely used by multiple application systems may have a significantly higher risk coverage index than a component used only in a local module. The system can set different calculation rules according to the organization's governance strategy, such as assigning higher weights to components with high dependency depth or increasing the influence coefficient of components in critical business links.

[0107] In the embodiments of this application, after calculating the risk coverage index of each component, the system can select a group of components from the list of risk components whose sum of coverage indices reaches a preset target threshold as the governance target component set. This preset target threshold can be flexibly set by the organization based on the governance cycle, team resources, system complexity, or risk tolerance. For example, in certain governance cycles, the organization may prefer to cover more risk sources, so the preset threshold can be set relatively high; while under resource constraints, a lower threshold can be selected, allowing the governance focus to concentrate on the most representative high-risk components.

[0108] In some embodiments, the system may introduce constraints when selecting the set of governance target components to ensure a more reasonable governance scope. For example, the system may limit the number of selected components to no more than a certain upper limit to avoid an overly large governance task; it may also require the inclusion of certain key components to ensure that fundamental risks are addressed first; and it may group components according to their relationships to make the governance task more coherent and executable. Under these constraints, the system ultimately determines the set of governance target components based on the principle that the cumulative risk coverage index reaches a threshold.

[0109] In the embodiments of this application, the above-described method enables the governance process to have a clear priority order and quantifiable selection criteria, avoiding the subjectivity and omissions that are prone to occur in traditional manual judgment methods. By comprehensively considering the degree of risk and the scope of system impact, the embodiments of this application can improve the overall system's stability and long-term maintainability under the condition that the governance cost is relatively controllable.

[0110] In the embodiments of this application, in order to accurately identify the dependencies between various open-source components in the application system, the system can parse the software build information to obtain the dependencies explicitly declared during the build phase. The software build information may include dependency configuration files, build scripts, component manifests, resource description files, and intermediate data generated by the build tools. This information can record the direct reference relationships between open-source components in a structured or semi-structured form. The system can parse each dependency declaration line by line, extracting the component name, version identifier, scope, and reference relationships, and construct a first dependency set accordingly to reflect the dependency structure that can be explicitly identified during the build phase.

[0111] In some embodiments, to improve the comprehensiveness of dependency identification, in addition to parsing build information, the system can also identify dynamic dependencies that are difficult to fully cover during the build phase by combining the actual operation process of the application system. The application system's startup configuration may include component loading order, environment variables, plugin enablement items, dynamic extension points, etc., which directly affect the component's runtime behavior. The system can construct a second set of dependencies based on the startup configuration file and component loading information collected during the runtime phase, such as runtime scan records, class loading traces, and runtime dependency resolution events.

[0112] In the embodiments of this application, the system can fuse a first dependency set and a second dependency set to obtain a more complete and accurate dependency model. During the fusion process, the system can merge duplicate dependencies, perform consistency correction on conflicting dependency entries, and classify and label dependencies according to their source, usage stage, and loading characteristics. The fused dependency structure can be represented as a graph or hierarchical structure for subsequent governance target analysis, impact scope identification, and transformation scope generation. By combining static analysis with dynamic acquisition, the embodiments of this application can improve the coverage and accuracy of dependency identification, enabling subsequent governance operations to make decisions based on the true dependency structure.

[0113] In the embodiments of this application, when there are multiple open-source component relationships in the application system, the impact range of the governance target component on the overall system can be accurately identified based on the following methods, thereby obtaining a comprehensive, clearly defined, and cost-controllable list of modified software under complex dependency structures.

[0114] Figure 3 A flowchart illustrating a method for obtaining a list of modified software according to some exemplary embodiments of this application is shown schematically.

[0115] like Figure 3 As shown, the method for obtaining the list of modified software includes operations S310 to S330.

[0116] When operating S310, each governance target component is taken as the starting point, and the dependencies are traversed along the preset dependency direction to obtain the associated open source components and their corresponding dependency paths.

[0117] In the embodiments of this application, the system can use the governance target component as the starting point for traversal and perform depth-first or breadth-first traversal on the dependency graph along a preset dependency direction. The preset direction can include traversal from the target component towards its downstream dependent components, or traversal from the target component towards its upstream basic components, or bidirectional traversal depending on different governance strategies. During the traversal, the system can record each dependency path and collect all associated open-source components appearing in the path. In this way, the system can identify components that have direct or indirect dependencies with the governance target component, achieving cross-level and cross-module dependency scope capture.

[0118] When operating S320, based on the dependency path, determine the dependency distance of the associated open source component relative to the corresponding governance target component, and count the number of times each associated open source component appears in multiple dependency paths.

[0119] Specifically, the system can determine the dependency distance of each related open-source component based on the number of hops or the length of the dependency chain between each related component and the governance target component, reflecting the tightness of its coupling with the governance target component. Simultaneously, for related components appearing in multiple dependency paths, the system can count their occurrences to identify core components that are shared by multiple functional modules and are of high importance within the system.

[0120] When operating S330, related open-source components are filtered based on dependency distance and frequency of occurrence. The filtered results are combined with the governance target components to obtain a list of software to be modified.

[0121] For example, the system can prioritize including components with shorter dependency distances in the governance scope based on preset threshold rules, or it can consider critical components that occur frequently as non-negligible governance targets. Furthermore, the system can employ flexible screening logic based on different institutional governance strategies, such as using a tiered grouping strategy, setting weighting coefficients, or employing a comprehensive scoring model.

[0122] In the embodiments of this application, after obtaining the list of modified software, the system can dynamically manage the version status of the corresponding open-source components in the target software ledger data to ensure that the governance results can be verified in a real environment and form a traceable lifecycle record. Specifically, the system can first extract the set of components that need to be governed from the list of modified software and adjust the version status of these components from the original available state to the observation state. The observation state is used to indicate that the component is in a transition phase and its usage risk needs to be assessed through actual operation performance within a certain period. The system can automatically collect the operation results of relevant application systems within a preset observation period, including whether the function is normal, whether abnormal termination occurs, whether rollback behavior occurs, and compatibility changes caused by component upgrades, thereby forming a practical basis for judging the version status.

[0123] In some embodiments, the operational results during the observation period can be obtained in various ways, such as monitoring application system operation logs, version rollback records, automated inspection results, dependency verification records during the build process, and system operational status analysis. The system can normalize these multi-source information to form monitoring results that can be used to judge component stability. By obtaining feedback information in the actual operating environment, the system can avoid the errors caused by making version status judgments based solely on static analysis, making component status assessments more consistent with real business scenarios.

[0124] In the embodiments of this application, after the observation period ends, the system can decide whether to adjust the version status of the component based on the running results. When no rollback records, running anomalies, or incompatibility are found during the observation period, it indicates that the component has achieved stability in the existing environment. At this time, the system can further update its version status from the observation state to the prohibited use state. The prohibited use state is used to indicate that the version of the component has been included in the governance scope and processed, and should not be introduced again in subsequent development and deployment processes, thereby ensuring that the governance work has a lasting effect.

[0125] In some embodiments, when component-related rollback records or operational failures occur during the observation period, the system can update the version status from the observation state to the restricted use state. The restricted use state does not completely prohibit the use of the component, but rather reminds the relevant teams that the component has not met the requirements for complete stability under the current governance conditions, and needs to be used with caution in specific scenarios, and may require further verification, supplementary governance measures, or selection of alternative versions.

[0126] In the embodiments of this application, the aforementioned version status management mechanism can be deeply integrated with the organization's overall governance process, component usage specifications, and continuous monitoring capabilities. When a component's status changes, the system can automatically push notifications to relevant teams and perform status verification during the build and deployment process, preventing non-compliant components from re-entering the system at the source.

[0127] Through the embodiments of this application, the provided version status management method can form a closed-loop control in each stage before, during, and after governance, making the introduction, observation, decision-making, and exit of component versions a systematic process. This mechanism ensures the stability of governance effects while reducing potential system risks caused by unclear component status judgments, thereby improving the controllability and continuous governance capabilities of the overall software supply ecosystem.

[0128] In the embodiments of this application, to ensure that governance operations triggered by the modified software inventory can proceed smoothly within the organization, the system can track and record the execution process of governance tasks through an open-source software management system. Once the version status management process updates the status of the component to be governed to the observation status, the system can automatically generate the corresponding governance task entry and assign it to the application system team maintaining that component. The governance task entry may include the component identifier, recommended alternative version, observation period duration, expected governance completion time, and relevant dependency information, so that the relevant teams can clearly understand the scope and objectives of this round of governance.

[0129] In some embodiments, the open-source software management system can periodically collect data on the execution status of governance tasks, including whether each application system has completed component replacement, submitted operational verification reports, and whether any exception handling procedures have been triggered during the observation period. The system can obtain governance progress information through various methods such as pipeline callback construction, reporting from the operations and maintenance platform, and data entry by governance personnel, forming a real-time status record of the tasks. Based on this information, the system can automatically calculate indicators such as governance completion rate, risk elimination rate, and observation period stability to evaluate the governance effectiveness.

[0130] In the embodiments of this application, to further enhance the comprehensiveness and foresight of risk identification, the system can also analyze the long-term change trends of open-source components using historical governance records, thereby discovering potential risk components that may not have been directly identified in the current governance cycle. Specifically, the system can extract open-source components included in the risk identification scope in each cycle based on the risk component list generated in multiple governance cycles, and generate a historical risk sequence by combining information such as their handling methods in the current governance, version replacement results, dependency impact scope, and the occurrence time of related events. The historical risk sequence can reflect the changes in risk characteristics of different components in different time periods, providing a basis for identifying components with recurring or continuously evolving risks.

[0131] Furthermore, the historical risk sequence can be enriched by incorporating version change information of components from historical governance records. For example, when a component frequently appears on the risk component list across multiple governance cycles, or when its version remains unstable across multiple cycles, its long-term risk characteristics can be reflected through the historical risk sequence. For components exhibiting significant version evolution fluctuations, such as the release of multiple important versions within a short period or a marked adjustment to the version strategy, the system can use such changes as key attributes in the historical risk sequence to increase their weight in potential risk assessments.

[0132] In embodiments of this application, the system can compare historical risk sequences with component version evolution information in the current software bill of materials to identify potentially risky components that have historically exhibited high-risk characteristics, while the corresponding versions in the current bill of materials may still be within the evolution-sensitive range. This comparison process may include time-series analysis of component version numbers, anomaly detection of version change cycles, and judgment of component maintenance activity trends. For example, a component may be included in the risk list multiple times during historical governance cycles due to unstable maintenance schedules, license adjustments, or dependency changes.

[0133] After identifying potential risk components, these components can be merged with target risk open-source components obtained through external situational awareness analysis. By combining real-time risk information with long-term evolving risk information, the system can generate a more comprehensive list of risk components. This list reflects both the current external risk situation and the structural risks accumulated during component evolution. This effectively avoids potential risk omissions that might occur if relying solely on real-time risk information, and also allows for the early identification of components with continuously rising risk trends, providing institutions with a more comprehensive basis for governance decisions.

[0134] Figure 4 The illustration shows a schematic diagram of the overall process of open source software management according to some exemplary embodiments of this application.

[0135] like Figure 4 As shown, this process can be completed collaboratively by software composition analysis tools (SCA analysis tools), situational awareness platforms, open source software management systems, open source software dependency analysis tools, and open source software user departments to achieve dynamic governance of the entire lifecycle of open source software within the organization.

[0136] In the embodiments of this application, a software composition analysis tool first scans the code repositories of each open-source software user department to identify the open-source components actually referenced in the application system, generating an open-source software list containing component names, version attributes, and dependencies. Subsequently, the situational awareness platform can obtain external situational awareness information based on this open-source software list, including supply chain risks, changes in component maintenance status, license adjustment information, etc., and form a situational awareness risk software list based on the analysis results.

[0137] Open-source software management systems can initiate open-source software version planning and governance processes based on a situational awareness risk software list, automatically generating a governance software list and issuing governance tasks. Open-source software dependency analysis tools can analyze the application system's dependency structure based on the governance software list, identifying open-source components with direct or indirect relationships to the target governance components, and forming a list of software to be modified. This dependency analysis process ensures that governance strategies cover all affected components, avoiding overlooking potential problems caused by dependency coupling.

[0138] The open-source software management system can update the version status of components in the open-source software consolidation ledger based on the list of software to be addressed. For example, it can update versions requiring governance to an observation status, a recommended alternative version, a restricted usage status, or a prohibited usage status, and push notifications of version status changes to the relevant open-source software user departments. These departments can then adjust system configurations, implement code modifications, or switch versions based on these version status changes to complete the remediation tasks within the governance cycle.

[0139] Through the aforementioned collaborative process, the system can form a complete governance closed loop, from open-source component identification, risk perception, governance task generation, dependency analysis to version status adjustment. This governance process not only improves the transparency and controllability of open-source component management, but also continuously optimizes governance strategies based on actual operational conditions, enabling organizations to maintain stability, compliance, and sustainable evolution capabilities in a complex open-source ecosystem.

[0140] Corresponding to the above-described software management method, embodiments of this application also provide a software management device.

[0141] Figure 5 A schematic block diagram of a software management device according to an embodiment of this application is shown.

[0142] like Figure 5 As shown, the software management device 500 in this embodiment includes a data acquisition module 510, a risk association module 520, a modified software determination module 530, and a software management module 540.

[0143] The data acquisition module 510 can be used to acquire target software ledger data and application system software construction information, and at least based on the target software ledger data and software construction information, identify the target open-source components used by the application system and their corresponding dependencies, and obtain a software bill of materials. In one embodiment, the data acquisition module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0144] The risk association module 520 can be used to associate the software bill of materials with external risk information and generate a list of risk components based on the association results. In one embodiment, the risk association module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0145] The modified software determination module 530 can be used to determine the governance target components based on the risk component list, and to identify related open-source components that are associated with the governance target components based on the dependencies in the software bill of materials, thereby obtaining a modified software list. In one embodiment, the modified software determination module 530 can be used to perform the operation S230 described above, which will not be repeated here.

[0146] The software management module 540 can be used to manage the version status of corresponding open-source components in the target software ledger data based on the list of modified software. In one embodiment, the software management module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0147] According to an embodiment of this application, the data acquisition module 510 can also be used to parse the dependency declarations in the software build information, extract the direct dependencies between open-source components based on the parsing results, and obtain a first dependency set; obtain a second dependency set based on the application system's startup configuration information and component loading information during operation; and merge the first dependency set and the second dependency set to obtain the dependencies.

[0148] According to an embodiment of this application, the risk association module 520 can also be used to obtain a multi-dimensional risk feature vector from a situational awareness information source for the target open-source component. The situational awareness information source includes at least runtime risk monitoring results, security risk intelligence, and license change information. A time decay factor is introduced into the time-related features in the multi-dimensional risk feature vector to obtain a corrected risk feature vector. Based on the name, version number, and / or license information of the target open-source component, the target open-source component and the corrected risk feature vector are associated and matched to obtain the target risk open-source component. The risk component list is generated based on the target risk open-source component.

[0149] According to an embodiment of this application, the risk association module 520 can also be used to obtain, based on historical governance records, open-source components included in the risk component list and corresponding version change information within multiple governance cycles, and generate a historical risk sequence; and compare the historical risk sequence with the component version evolution information in the software bill of materials to obtain potential risk components, and generate a risk component list based on the target risk open-source components and potential risk components.

[0150] According to an embodiment of this application, the modified software determination module 530 can also be used to calculate a risk coverage index based on the risk score and usage scope of each open source component in the risk component list. The risk coverage index is used to characterize the degree of impact of the governance of a single open source component on the overall risk reduction. It can also select a set of open source components from the risk component list that makes the sum of the risk coverage index reach a preset target threshold, and determine the governance target component based on the set of open source components.

[0151] According to an embodiment of this application, the modified software determination module 530 can also be used to take each governance target component as a starting point, traverse along a preset dependency direction in terms of dependency relationship, obtain associated open source components and corresponding dependency paths; determine the dependency distance of the associated open source component relative to the corresponding governance target component based on the dependency path, and count the number of times each associated open source component appears in multiple dependency paths; and filter the associated open source components based on the dependency distance and the number of occurrences, combine the filtering results with the governance target components, and obtain a list of modified software.

[0152] According to an embodiment of this application, the software management module 540 can also be used to obtain components to be governed based on the list of modified software, update the version status of the components to be governed from the available status to the observation status, collect the corresponding application system operation results within a preset observation period; and update the observation status to the prohibited use status in response to the application system operation results showing that no rollback record or fault record has appeared; and update the observation status to the restricted use status in response to the application system operation results showing that a rollback record or fault record has appeared.

[0153] According to embodiments of this application, any multiple modules among the data acquisition module 510, risk association module 520, modification software determination module 530, and software management module 540 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the data acquisition module 510, risk association module 520, modification software determination module 530, and software management module 540 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, at least one of the data acquisition module 510, risk association module 520, modified software determination module 530, and software management module 540 can be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0154] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a software management method according to an embodiment of this application.

[0155] like Figure 6As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0156] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0157] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0158] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0159] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0160] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the software management method provided in the embodiments of this application.

[0161] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0162] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0163] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0164] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0165] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0166] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0167] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A software management method, characterized in that, The method includes: Obtain target software ledger data and application system software construction information, and at least based on the target software ledger data and the software construction information, identify the target open source components used by the application system and their corresponding dependencies, and obtain a software bill of materials; The software bill of materials is correlated with external risk information, and a risk component list is generated based on the correlation results; Based on the risk component list, target components for governance are determined, and related open-source components that are associated with the target components are identified based on the dependencies in the software bill of materials, thereby obtaining a list of software to be modified; and Based on the aforementioned list of modified software, the version status of the corresponding open-source components in the target software ledger data is managed.

2. The method according to claim 1, characterized in that, The step of associating the software bill of materials with external risk information and generating a risk component list based on the association result includes: For the target open-source component, a multi-dimensional risk feature vector is obtained from a situational awareness information source, which includes at least runtime risk monitoring results, security risk intelligence, and license change information. A time decay factor is introduced into the time-related features of the multidimensional risk feature vector to obtain a corrected risk feature vector; and Based on the name, version number, and / or license information of the target open-source component, the target open-source component and the corrected risk feature vector are associated and matched to obtain the target risk open-source component, and the risk component list is generated based on the target risk open-source component.

3. The method according to claim 1, characterized in that, The determination of governance target components based on the risk component list includes: Based on the risk scores and usage scope of each open-source component in the risk component list, a risk coverage index is calculated. This risk coverage index characterizes the impact of the governance of a single open-source component on the overall risk reduction. Select a set of open-source components from the risk component list that make the sum of the risk coverage indicators reach a preset target threshold, and determine the governance target component based on the set of open-source components.

4. The method according to claim 1, characterized in that, Identifying the dependencies corresponding to the target open-source component includes: Parse the dependency declarations in the software build information, extract the direct dependencies between open-source components based on the parsing results, and obtain the first dependency set; Based on the application system's startup configuration information and component loading information during operation, a second dependency set is obtained; and The first dependency set and the second dependency set are merged to obtain the dependency relationship.

5. The method according to claim 1, characterized in that, The process of identifying associated open-source components that are related to the governance target component based on the dependencies in the software bill of materials, and obtaining a list of modified software, includes: Starting from each governance target component, the system traverses along the preset dependency direction along the dependency relationship to obtain the associated open source components and their corresponding dependency paths. Based on the dependency path, determine the dependency distance of the associated open source component relative to the corresponding governance target component, and count the number of times each associated open source component appears in multiple dependency paths; as well as The associated open-source components are filtered based on the dependency distance and the frequency of occurrence. The filtering results are combined with the governance target components to obtain the list of modified software.

6. The method according to claim 1, characterized in that, The management of the version status of corresponding open-source components in the target software ledger data based on the modified software list includes: Based on the list of modified software, obtain the components to be addressed, update the version status of the components to be addressed from the available status to the observation status, and collect the corresponding application system operation results within a preset observation period. as well as If the application system operation results indicate that no rollback or fault record has been found, the observation status is updated to a prohibited use status; if the application system operation results indicate that a rollback or fault record has been found, the observation status is updated to a restricted use status.

7. The method according to claim 2, characterized in that, The method further includes: Based on historical governance records, obtain the open-source components and corresponding version change information that were included in the risk component list in multiple governance cycles, and generate a historical risk sequence. as well as By comparing the historical risk sequence with the component version evolution information in the software bill of materials, potential risk components can be obtained; The risk component list is generated based on the target risk open-source component and the potential risk component.

8. A software management device, characterized in that, The device includes: The data acquisition module is used to: acquire target software ledger data and application system software construction information, identify the target open source components used by the application system and their corresponding dependencies based at least on the target software ledger data and the software construction information, and obtain a software bill of materials; The risk association module is used to: associate the software bill of materials with external risk information, and generate a list of risk components based on the association results; The software modification determination module is used to: determine the target components for governance based on the risk component list, and identify related open-source components that are associated with the target components for governance based on the dependencies in the software bill of materials, thereby obtaining a software modification list; and The software management module is used to manage the version status of the corresponding open-source components in the target software ledger data based on the modified software list.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images