Project release alarm method and device, electronic equipment and program product

Abstract

The invention discloses an alarm method and device for project release, electronic equipment and a program product, relates to the field of big data and is applied to the field of financial science and technology, and the method comprises the following steps: constructing a first dependency graph according to source code information of a project at a first moment, and constructing a second dependency graph according to source code information of the project at a second moment; identifying increment change information of the project according to the nodes, the node information and the dependency relationship in the first dependency graph and the second dependency graph; determining a component change type according to the incremental change information, and determining vulnerability risk information according to the component change type and a vulnerability database; and determining compatibility risk information according to the compatibility between the components, and giving an alarm before the project is published based on the vulnerability risk information and the compatibility risk information. Through the project risk assessment method and device, the problem that the project risk assessment efficiency is low due to the fact that the project code of each version needs to be subjected to full-quantity analysis and scanning when the project release risk is assessed in the related technology is solved.

Description

Technical Field

[0001] This application relates to the field of big data and is applied to the field of financial technology. Specifically, it relates to a method, device, electronic device, and program product for issuing alarms for projects. Background Technology

[0002] In the software development field, especially in Java code, the core mechanism of automated build and dependency management tools lies in their ability to parse and manage the project dependency tree, ensuring that the correct dependency versions are used during the build process. However, as project size increases and dependency relationships become more complex, traditional dependency management and security vulnerability scanning technologies have exposed a series of problems.

[0003] In existing technologies, dependency management tools perform full dependency resolution on every build, including direct and transitive dependencies. For large projects, this is not only time-consuming and labor-intensive, but may also lead to excessive resource consumption and affect the efficiency of continuous integration (CI) and continuous deployment (CD) pipelines.

[0004] There is currently no effective solution to the problem that assessing the risks of project releases using related technologies is inefficient because it requires full parsing and scanning of the project code for each version. Summary of the Invention

[0005] The main objective of this application is to provide a project release alarm method, device, electronic device, and program product to solve the problem that the efficiency of project risk assessment is low when assessing the risk of project release due to the need to perform full parsing and scanning of the project code for each version.

[0006] To achieve the above objectives, according to one aspect of this application, a project release alerting method is provided. The method includes: constructing a first dependency graph of the project based on the project's source code information at a first time point, and constructing a second dependency graph of the project at a second time point based on the project's source code information at a second time point, wherein the second time point is later than the first time point; identifying incremental change information of the project based on the nodes, node information, and dependency relationships in the first and second dependency graphs, wherein the incremental change information includes at least: the original component and the target component; determining the component change type based on the component information of the original component and the component information of the target component, and determining vulnerability risk information based on the component change type and a vulnerability database; determining compatibility risk information based on the compatibility between components in the project, and issuing an alert before project release based on the vulnerability risk information and the compatibility risk information.

[0007] Furthermore, for the first and second dependency graphs, incremental change information of the project is identified based on the nodes, node information, and dependency relationships in the graphs. This includes: when the first set and the second set are different, generating incremental change information based on the different nodes in the first and second sets, where the first set is the set of nodes contained in the first dependency graph, and the second set is the set of nodes contained in the second dependency graph; when the first set and the second set are the same, parsing the first version number of the first node and the second version number of the second node, generating incremental change information when the first version number and the second version number are different; when the first version information and the second version information are the same, comparing the edges and edge attributes in the third and fourth sets, generating incremental change information based on different edges or different edge attributes, where the third set is the set of edges contained in the first dependency graph, and the fourth set is the set of edges contained in the second dependency graph.

[0008] Furthermore, based on the source code information of the project at the first moment, a first dependency graph of the project at the first moment is constructed, including: scanning the source code of the project at the first moment to obtain source code fingerprint information and dependency component information, and using a tree structure to represent the dependency component information to obtain a dependency tree; constructing multiple nodes based on the source code fingerprint information and dependency tree, wherein the multiple nodes include at least: repository, project, dependency component, license, vulnerability, and release date; constructing multiple edges between multiple nodes based on the dependency tree, wherein the multiple edges include at least: edges from the project to the dependency component, directed edges between different dependency components, edges from the dependency component to the license, and edges from the release date to the repository; and constructing the first dependency graph based on the multiple nodes and multiple edges.

[0009] Furthermore, before constructing the first dependency graph based on multiple nodes and multiple edges, the above method also includes: for each of the multiple nodes, determining the node's identifier information based on the node's group identifier information and the node's dependency library identifier information; standardizing the node's scope based on the standard scope; merging duplicate paths among multiple reference paths when any node in the first dependency graph has multiple reference paths; and using a dependency tree pruning algorithm to prune nodes in the first dependency graph that only function in the target scope, where the target scope represents a dependency environment unrelated to the code packaging process.

[0010] Furthermore, the component change types include at least the following: Type 1, Type 2, and Type 3. Type 1 indicates that the component itself has changed, Type 2 indicates that the scope of the component has changed, and Type 3 indicates that the relationship between the component and other components has changed. Type 1 includes at least the following subtypes: adding a component, removing a component, upgrading a version, and downgrading a version. Type 3 includes at least the following subtypes: changing the dependency path and incompatible dependency versions.

[0011] Further, vulnerability risk information is determined based on component change type and vulnerability database, including: querying the vulnerability database based on the group identifier and identifier information of the original component and the target component respectively to obtain a first query result; querying the vulnerability version set to see if there are vulnerability records in the original component and the target component respectively to obtain a second query result, wherein the vulnerability version set is a collection of component versions affected by known security vulnerabilities obtained from external channels; and determining vulnerability risk information based on component change type, according to the first query result and the second query result, wherein the vulnerability risk information includes at least: a first vulnerability list sorted by vulnerability risk level and a second vulnerability list sorted by processing priority.

[0012] Furthermore, compatibility risk information is determined based on the compatibility between components in the project, including: determining a first risk value based on the graph connectivity and cyclic path information of the second dependency graph; determining whether there are conflicts between components in the project and determining a second risk value based on the number of conflicting components; determining a third risk value based on a preset set of compatibility rules and component information in the project, wherein the set of compatibility rules is constructed based on historical code issues, developer database, component compatibility information, and framework compatibility information; determining a fourth risk value based on the business type of the business to which the component belongs in the project and the component's call chain; and determining compatibility risk information based on the first, second, third, and fourth risk values.

[0013] To achieve the above objectives, according to another aspect of this application, a project release alarm device is provided. The device includes: a construction unit, configured to construct a first dependency graph of the project at a first time based on the project's source code information at a first time, and to construct a second dependency graph of the project at a second time based on the project's source code information at a second time, wherein the second time is later than the first time; an identification unit, configured to identify incremental change information of the project based on nodes, node information, and dependency relationships in the first and second dependency graphs, wherein the incremental change information includes at least: original components and target components; a determination unit, configured to determine the component change type based on the component information of the original component and the component information of the target component, and to determine vulnerability risk information based on the component change type and a vulnerability database; and an alarm unit, configured to determine compatibility risk information based on the compatibility between components in the project, and to issue an alarm before project release based on the vulnerability risk information and the compatibility risk information.

[0014] Further, the identification unit includes: a first generation subunit, used to generate incremental change information based on different nodes in the first set and the second set when the first set and the second set are different, wherein the first set is the set of nodes contained in the first dependency graph, and the second set is the set of nodes contained in the second dependency graph; a second generation subunit, used to parse the first version number of the first node and the second version number of the second node when the first set and the second set are the same, and to generate incremental change information when the first version number and the second version number are different; and a third generation subunit, used to compare the edges and edge attributes in the third set and the fourth set when the first version information and the second version information are the same, and to generate incremental change information based on different edges or different attributes of the edges, wherein the third set is the set of edges contained in the first dependency graph, and the fourth set is the set of edges contained in the second dependency graph.

[0015] Furthermore, the construction unit includes: a first construction subunit, used to scan the source code of the project at the first moment to obtain source code fingerprint information and dependent component information, and to represent the dependent component information using a tree structure to obtain a dependency tree; a second construction subunit, used to construct multiple nodes based on the source code fingerprint information and the dependency tree, wherein the multiple nodes include at least: repository, project, dependent component, license, vulnerability, and release date; a third construction subunit, used to construct multiple edges between multiple nodes based on the dependency tree, wherein the multiple edges include at least: edges from the project to the dependent component, directed edges between different dependent components, edges from the dependent component to the license, and edges from the release date to the repository; and a fourth construction subunit, used to construct a first dependency graph based on the multiple nodes and multiple edges.

[0016] Furthermore, the construction unit also includes: a first determining subunit, used to determine the identification information of each of the multiple nodes based on the node's group identification information and the node's dependency library identification information before constructing the first dependency graph based on multiple nodes and multiple edges; a processing subunit, used to standardize the scope of the nodes based on the standard scope; a merging subunit, used to merge duplicate paths among multiple reference paths when any node in the first dependency graph has multiple reference paths; and a pruning subunit, used to prune nodes in the first dependency graph that only function in the target scope using a dependency tree pruning algorithm, wherein the target scope represents a dependency environment that is independent of the code packaging process.

[0017] Furthermore, the component change types include at least the following: Type 1, Type 2, and Type 3. Type 1 indicates that the component itself has changed, Type 2 indicates that the scope of the component has changed, and Type 3 indicates that the relationship between the component and other components has changed. Type 1 includes at least the following subtypes: adding a component, removing a component, upgrading a version, and downgrading a version. Type 3 includes at least the following subtypes: changing the dependency path and incompatible dependency versions.

[0018] Further, the determining unit includes: a first query subunit, used to query the vulnerability database based on the group identifier information and identifier information of the original component, and the group identifier information and identifier information of the target component, respectively, to obtain a first query result; a second query subunit, used to query in the vulnerability version set whether there are vulnerability records in the original component and the target component, respectively, to obtain a second query result, wherein the vulnerability version set is a collection of component versions affected by known security vulnerabilities obtained from external channels; and a second determining subunit, used to determine vulnerability risk information based on the component change type, according to the first query result and the second query result, wherein the vulnerability risk information includes at least: a first vulnerability list sorted according to vulnerability risk level, and a second vulnerability list sorted according to processing priority.

[0019] Furthermore, the alarm unit includes: a third determining subunit, used to determine a first risk value based on the graph connectivity and cyclic path information of the second dependency graph; a judging subunit, used to judge whether there are conflicts between components of the project, and to determine a second risk value based on the number of conflicting components; a fourth determining subunit, used to determine a third risk value based on a preset set of compatibility rules and component information of components in the project, wherein the set of compatibility rules is constructed based on historical code issues, developer database, component compatibility information, and framework compatibility information; a fifth determining subunit, used to determine a fourth risk value based on the business type of the business to which the component belongs in the project and the call chain of the component; and a sixth determining subunit, used to determine compatibility risk information based on the first risk value, the second risk value, the third risk value, and the fourth risk value.

[0020] To achieve the above objectives, according to one aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements an alarm method for issuing any of the above-mentioned items, and when executed by a processor, implements the steps of the alarm method for issuing items in various embodiments of this application.

[0021] To achieve the above objectives, according to one aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including stored computer instructions, wherein, when the computer instructions are executed by a processor, an alarm method for issuing any of the above items is implemented.

[0022] To achieve the above objectives, according to one aspect of this application, an electronic device is provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement an alarm method issued by any of the above items.

[0023] In this embodiment, a first dependency graph of the project at a first time point is constructed based on the project's source code information at a first time point, and a second dependency graph of the project at a second time point is constructed based on the project's source code information at a second time point, wherein the second time point is later than the first time point. For the first and second dependency graphs, incremental change information of the project is identified based on the nodes, node information, and dependency relationships in the graphs, wherein the incremental change information includes at least: the original component and the target component. The component change type is determined based on the component information of the original component and the component information of the target component, and vulnerability risk information is determined based on the component change type and the vulnerability database. Compatibility risk information is determined based on the compatibility between components in the project, and an alert is issued before the project is released based on the vulnerability risk information and the compatibility risk information. This solves the technical problem that the efficiency of assessing project risk is low when assessing the risk of project release because it is necessary to perform full analysis and scanning of the project code for each version.

[0024] By constructing and comparing dependency graphs of a project at different points in time, incremental change information can be accurately captured, achieving the technical effect of efficiently identifying dependency changes. Simultaneously, by analyzing version information of more variable components, the system can determine security risks based on a vulnerability database, enabling targeted security vulnerability warnings and further achieving the technical effect of proactively preventing software security risks. Furthermore, based on compatibility assessments between project components, potential runtime compatibility risks can be accurately identified before release, achieving strict quality control of software and ensuring the stability and security of software delivery, comprehensively improving the effectiveness of risk management and software lifecycle governance. Attached Figure Description

[0025] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0026] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing an alarm method for project release, according to Embodiment 1 of this application;

[0027] Figure 2 This is a flowchart of an optional project-based alarm method provided in Embodiment 1 of this application;

[0028] Figure 3 This is a flowchart illustrating an optional incremental change identification component provided in Embodiment 1 of this application;

[0029] Figure 4 This is a schematic diagram of an optional vulnerability risk assessment process provided in Embodiment 1 of this application;

[0030] Figure 5 This is a flowchart illustrating an optional alarm mechanism provided according to Embodiment 1 of this application;

[0031] Figure 6 This is a schematic diagram of an optional process for identifying and alerting on risks in project delivery versions, provided according to Embodiment 1 of this application.

[0032] Figure 7 This is a schematic diagram of an alarm device for project release according to Embodiment 2 of this application;

[0033] Figure 8 This is a schematic diagram of an alarm electronic device for project release according to Embodiment 3 of this application. Detailed Implementation

[0034] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0035] It should be noted that the processing methods, apparatus, storage media, and electronic devices specified in this application can be used in the fintech field to reduce the risk of project release impacting business or systems before project delivery, and can also be used in any field other than fintech. The application fields of the processing methods, apparatus, storage media, and electronic devices specified in this application are not limited.

[0036] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, collected data, used data, generated data, processed data, etc.) and the data (including but not limited to data used for analysis, stored data, displayed data, collected information, used information, generated information, processed information, etc.) 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 the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken 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. For example, this system has interfaces with relevant users or organizations, providing users with corresponding operation entry points for users to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0037] Example 1

[0038] According to an embodiment of this application, a method embodiment for issuing alarms for a project is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0039] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing an alarm method for project release, according to Embodiment 1 of this application. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0040] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0041] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the project release alarm method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned project release alarm method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0042] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0043] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0044] Under the aforementioned operating environment, this application provides the following: Figure 2 The alarm method issued by the project is shown. Figure 2 This is a flowchart of an optional project-based alarm method provided in Embodiment 1 of this application.

[0045] Step S201: Construct a first dependency graph of the project at the first time point based on the source code information of the project at the first time point, and construct a second dependency graph of the project at the second time point based on the source code information of the project at the second time point, wherein the second time point is later than the first time point.

[0046] In cost-based implementation example 1, a first dependency graph reflecting the project's dependencies is constructed based on the project's source code and dependency information at a specified first time point. Subsequently, at a second time point, which is after the first time point, a second dependency graph reflecting the new state is constructed again based on the project's latest source code and dependency information. This process ensures dynamic capture of dependencies, providing baseline data for incremental code identification and risk assessment.

[0047] Specifically, the first dependency graph records the GAV coordinates (including GroupId, ArtifactId, and Version, referred to as GAV coordinates) of all dependent components in the project at the first time step, along with their dependency paths and scopes. The second dependency graph reflects the same details at the second time step. By comparing the two graphs, changes to project dependencies can be accurately identified, including added, deleted, or updated components, enabling the assessment of security vulnerabilities and compatibility risks associated with these changes.

[0048] Step S202: For the first dependency graph and the second dependency graph, identify the incremental change information of the project based on the nodes, node information and dependency relationships in the graph. The incremental change information includes at least the original component and the target component.

[0049] In cost-based implementation example 1, for the first dependency graph and the second dependency graph, by comparing the nodes, node information, and their dependencies within the graphs, changes in dependent components of the project between the two time points are identified, resulting in the aforementioned incremental change information. This identification process includes identifying the addition, removal, and version upgrade of components, where incremental change information includes, but is not limited to, the original components and their versions, as well as the corresponding target components and new versions after the changes. Through graph differential analysis, change details can be accurately obtained. This incremental identification method focuses on the points of change, effectively reducing the scope of analysis and improving the efficiency and accuracy of the evaluation.

[0050] Step S203: Determine the component change type based on the component information of the original component and the component information of the target component, and determine the vulnerability risk information based on the component change type and the vulnerability database.

[0051] In cost-based implementation example 1, the change type is determined by comparing the component information of the original component and the target component, including addition, deletion, version upgrade, or downgrade. Subsequently, for the determined change types, especially for components undergoing version upgrades or downgrades, a vulnerability database is queried to retrieve known vulnerability records related to the old and new versions of these components. The vulnerability risk information generated in this process specifically covers the security risks inherent in the changed component itself and their potential impact, providing a direct basis for subsequent risk assessment. By accurately matching the component version with the affected versions in the vulnerability database, the timeliness and relevance of the risk information are ensured.

[0052] Step S204: Determine compatibility risk information based on the compatibility between components in the project, and issue alerts based on vulnerability risk information and compatibility risk information before project release.

[0053] In cost-based implementation example 1, compatibility risk information is assessed and determined based on the compatibility status of various components within the project. The focus is on examining the impact of version changes on dependencies, including issues such as interface incompatibility and framework incompatibility. Combining the aforementioned vulnerability risk information, a comprehensive analysis of security and compatibility risks is conducted. Before the project release process, corresponding alerts are triggered based on preset risk thresholds. The alert mechanism implements hard blocking for high-risk changes, triggers soft alerts for medium-risk changes, and only records notifications for low-risk changes, ensuring effective intervention of critical risks before software delivery.

[0054] Specifically, the alerting mechanism may include the following processing methods: calculating a comprehensive risk value based on vulnerability risk information and compatibility risk information; if the comprehensive risk value falls within a first value range (e.g., (8, 10]), a hard block is implemented, i.e., the release of the project is blocked; if the comprehensive risk value falls within a second value range (e.g., (5, 8]), an alert is issued, i.e., the modified project is sent to the superior management personnel for review, and the project is released if the review is approved; if the comprehensive risk value falls within a third value range (e.g., (3, 5]), the incremental change information, vulnerability risk information, and compatibility risk information of the project are recorded in the log, and the project release continues.

[0055] Optionally, in the project release alarm method provided in Embodiment 1 of this application, for the first dependency graph and the second dependency graph, incremental change information of the project is identified based on the nodes, node information and dependency relationships in the graph, including: when the first set and the second set are different, generating incremental change information based on the different nodes in the first set and the second set, wherein the first set is the set of nodes contained in the first dependency graph and the second set is the set of nodes contained in the second dependency graph; when the first set and the second set are the same, parsing the first version number of the first node and parsing the second version number of the second node, generating incremental change information when the first version number and the second version number are different; when the first version information and the second version information are the same, comparing the edges and edge attributes in the third set and the fourth set, generating incremental change information based on different edges or different attributes of the edges, wherein the third set is the set of edges contained in the first dependency graph and the fourth set is the set of edges contained in the second dependency graph.

[0056] In this embodiment 1, the aim is to efficiently identify incremental changes to project dependent components. First, the dependency graph node sets of the project at a first time point and a second time point are compared (i.e., the first set and the second set). Set operations are used to identify newly added or removed nodes, generating incremental change information reflecting the addition and removal of components. Then, assuming the node sets are completely equal, the node version information is further compared. For components with inconsistent version numbers, their version upgrade or downgrade details are recorded to refine the incremental change information to the version level. Second, in scenarios where the version information remains consistent, the relationships and attributes of edges in the two graphs are compared in depth, including dependency paths and scopes, to identify changes in dependency relationships, such as newly added or modified dependencies, thereby improving the incremental change information to the dependency relationship level. Finally, by combining the results of the node and edge change analysis, a complete incremental change information set is constructed, covering all details of component changes, version changes, and dependency adjustments.

[0057] In one alternative embodiment, Figure 3 This is a flowchart illustrating an optional incremental change identification component provided in Embodiment 1 of this application. Figure 3 As shown, a dependency graph difference algorithm based on a three-layer comparison mechanism can be used to identify code changes. The three-layer comparison mechanism, as shown in Table 1, includes three comparison dimensions: component existence, version change, and dependency relationship change. Component existence refers to comparing the set difference operation between two versions of the graph node set to identify added or deleted components. Version change refers to comparing whether the version number has changed for components that existed in both versions through semantic parsing of version numbers. Dependency relationship change refers to comparing the dependency edge set of components through graph edge attribute structure to identify changes in the dependency source, dependency scope, and transitivity depth of the changed components.

[0058] Table 1

[0059]

[0060] Through the above steps, this embodiment achieves the technical effect of accurately locating the differences in dependent components between software delivery versions, ensuring the comprehensiveness and accuracy of change identification, reducing the resource waste caused by full analysis, improving the efficiency of risk assessment in the continuous integration and continuous deployment process, and providing a solid foundation for security review and compatibility verification before project delivery.

[0061] Optionally, in the project release alert method provided in Embodiment 1 of this application, constructing a first dependency graph of the project at the first moment based on the source code information of the project at the first moment includes: scanning the source code of the project at the first moment to obtain source code fingerprint information and dependency component information, and using a tree structure to represent the dependency component information to obtain a dependency tree; constructing multiple nodes based on the source code fingerprint information and the dependency tree, wherein the multiple nodes include at least: repository, project, dependency component, license, vulnerability, and release date; constructing multiple edges between the multiple nodes based on the dependency tree, wherein the multiple edges include at least: edges from the project to the dependency component, directed edges between different dependency components, edges from the dependency component to the license, and edges from the release date to the repository; and constructing a first dependency graph based on the multiple nodes and multiple edges.

[0062] In this first embodiment, to construct a dependency graph that accurately reflects the project's dependency structure, a deep scan of the project's source code at a specified point in time is first performed to extract source code fingerprints and detailed information about dependent components. The hierarchical relationships of these dependent components are then represented in a tree structure, forming a dependency tree. Next, based on the acquired source code fingerprints and dependency tree information, a series of nodes are constructed, covering the repository, project, dependent components, licenses, vulnerabilities, and release dates, ensuring the graph comprehensively reflects the project's key attributes. Then, according to the dependency tree structure, connections, or edges, are created between nodes. These include direct references from the project to dependent components, directed connections between components based on dependencies, associations between dependent components and their licenses, and associations between release dates and the repository. This step aims to construct the dependency network and attribute relationships within the graph. Finally, the constructed nodes and edges are integrated to form a complete first dependency graph. This graph not only displays the static structure of the project's dependencies but also includes dynamic attributes such as license type, vulnerability information, and release dates, providing a solid foundation for subsequent incremental change identification and risk assessment.

[0063] Similarly, when constructing the second dependency graph of the project at the second time step based on the source code information of the project at the second time step, the method for constructing the first dependency graph can be used.

[0064] In one alternative embodiment, during the continuous integration phase of the project code, by associating the release branch of Git (i.e., the code branch corresponding to the production version), the complete dependency tree structure data of the project is obtained by executing a command (e.g., mvndependency:tree -Dverbose), and the source code fingerprint information, dependency component information, etc. are stored in the graph database based on the designed graph relationship structure.

[0065] The key data of the dependency tree is shown in Table 2. The key information of the dependency tree includes, but is not limited to: the root node, i.e., the coordinates of the project itself, representing the information required by the project node in the graph; the GAV coordinates of the dependency item, representing the information required by the dependency node in the graph; the dependency depth, representing the hierarchy of dependency relationships stored in the graph, for example, 1, 2, 3; the packaging type, representing the packaging type relationship data stored in the graph; and the scope, representing the scope relationship data stored in the graph.

[0066] Table 2

[0067]

[0068] Different types of nodes in the graph can be shown in Table 3. Graph nodes include, but are not limited to: Repository, indicating the name of the code repository; Project, used to record the project coordinate name and the project pom path; Dependency, used to record the GAV coordinates of dependent components; License, used to record the license agreement of the open source software; Vulnerability, used to record the Common Vulnerabilities and Exposures ID (CVE-ID, which is a unique, fixed, and globally recognized vulnerability identifier in the public vulnerability record library, used to record security vulnerabilities and exposed issues in software and hardware products), severity, and scope of impact; Release Date, used to record the release date of the code release branch.

[0069] Table 3

[0070]

[0071] Different types of key relationships (directed edges) in the graph can be shown in Table 4. Graph edges include, but are not limited to: edges pointing from a project to a dependent component, indicating that the project directly or indirectly depends on a certain component, and the relationship attributes include dependency depth and scope; edges pointing from dependent component A to dependent component B, indicating the transitive relationship between dependencies, for example, spring-core→commons-logging; edges pointing from a dependency to a license, indicating the type of license used by the dependency; edges pointing from a dependency to a vulnerability, indicating the security vulnerability that exists in the dependency; and edges pointing from a release date to a repository, indicating the repository involved in the production deployment task for the corresponding release date.

[0072] Table 4

[0073]

[0074] Through the above steps, this embodiment 1 achieves structured management of project dependencies, obtains an accurate dependency graph, and achieves the technical effect of quickly and accurately identifying dependency changes and assessing risks, providing strong support for version control and security review in the software development process.

[0075] Optionally, in the project release alerting method provided in Embodiment 1 of this application, before constructing the first dependency graph based on multiple nodes and multiple edges, the method further includes: for each of the multiple nodes, determining the node's identifier information based on the node's group identifier information and the node's dependency library identifier information; standardizing the node's scope based on the standard scope; merging duplicate paths among multiple reference paths when any node in the first dependency graph has multiple reference paths; and using a dependency tree pruning algorithm to prune nodes in the first dependency graph that only function in the target scope, wherein the target scope represents a dependency environment unrelated to the code packaging process.

[0076] In this embodiment 1, to manage the entities in the dependency graph in a refined manner and ensure the accuracy and efficiency of subsequent risk assessment, each node in the graph is first traversed, and unique identification information for each node is constructed based on its group identifier and dependency library identifier. For example, the project group ID and component ID are used as unique identifiers for components. This operation aims to enhance the accuracy of node identification and avoid duplication or confusion.

[0077] Then, the scope attributes of the nodes are standardized, mapping non-standard scopes to predefined specifications to ensure the consistency and readability of the graph, facilitating subsequent automated analysis and understanding. For example, `compile`, `runtime`, `provided`, etc., are defined as standard scopes, and the scope of each node is mapped to any one of these standard scopes.

[0078] Secondly, when there are multiple reference paths in the dependency graph, a path merging strategy is implemented to eliminate duplicate paths, optimize the graph structure, reduce redundant information, and improve the efficiency and focus of the analysis.

[0079] Finally, the dependency tree pruning algorithm is used to remove dependency nodes that only function in non-target scopes such as test or provided scopes, and to focus on retaining key dependencies in the production or runtime scopes. This further simplifies the dependency graph and concentrates resources on the most relevant dependency analysis, creating favorable conditions for incremental identification and risk assessment.

[0080] Through the above steps, the goals of optimizing the dependency graph structure and standardizing and simplifying scope dependencies have been achieved. The technical effects are reflected in improving the efficiency and pertinence of dependency analysis, reducing the complexity and resource consumption of subsequent incremental identification and risk assessment, and ensuring clearer and more timely control over changes and risks of key dependent components during software project delivery.

[0081] Optionally, in the alarm method for project release provided in Embodiment 1 of this application, the component change type includes at least: a first type, a second type, and a third type. The first type indicates that the component itself has changed, the second type indicates that the scope of the component has changed, and the third type indicates that the relationship between the component and other components has changed. The first type includes at least the following subtypes: adding a component, removing a component, upgrading a version, and downgrading a version. The third type includes at least the following subtypes: changing the dependency path and incompatible dependency versions.

[0082] In this embodiment 1, in order to systematically analyze the impact of component changes on the project dependency graph, different types of component changes are first defined and classified. The classification of component change types can be shown in Table 5, including but not limited to: component change (i.e., the first type mentioned above), component scope change (i.e., the second type mentioned above), and component structure change (i.e., the third type mentioned above). This classification system covers common change patterns in software delivery.

[0083] Then, the types of changes to the components themselves are further subdivided, clarifying the specific meanings of adding components, removing components, version upgrades, and version downgrades, and providing a basic framework for incremental identification. Component changes include, but are not limited to: adding components, indicating a component appearing for the first time in a new version; removing components, indicating a component that existed in an older version but was removed in the new version; upgrading components, indicating that the component exists but its version number changes, with the new version having a higher version number than the old version; and downgrading components, indicating that the component exists but its version number changes, with the new version having a lower version number than the old version. Component scope changes indicate changes in the scope of a component between older and newer versions.

[0084] Finally, focusing on changes in relationships between components, the study identified adjustments to dependency paths and version compatibility issues. This covers potential compatibility risks in the dependency graph caused by component upgrades or removals. Specifically, component structure changes include, but are not limited to: changes in dependency paths, indicating changes in the dependency source or dependency path depth of components; the introduction of new incompatibilities, indicating the introduction of new version-conflicting components in the new version; and the resolution of incompatibilities, indicating that version conflicts existed in the old version but have been resolved in the new version.

[0085] Table 5

[0086]

[0087] Through the aforementioned classification and identification strategies, multi-faceted analysis of incremental change information in projects was achieved, ensuring the comprehensiveness and accuracy of change identification. This enabled the rapid and accurate determination of the specific type and scope of component changes during software project delivery. This not only facilitated efficient analysis of incremental changes but also provided a structured information foundation for subsequent risk assessment, compatibility checks, and decision support, enhancing the ability to manage risks and control changes before software delivery.

[0088] Optionally, in the project release alarm method provided in Embodiment 1 of this application, determining vulnerability risk information based on component change type and vulnerability database includes: querying the vulnerability database based on the group identifier information and identifier information of the original component and the group identifier information and identifier information of the target component respectively to obtain a first query result; querying the vulnerability version set to determine whether there are vulnerability records in the original component and the target component respectively to obtain a second query result, wherein the vulnerability version set is a set of component versions affected by known security vulnerabilities obtained from external channels; determining vulnerability risk information based on component change type, according to the first query result and the second query result, wherein the vulnerability risk information includes at least: a first vulnerability list sorted according to vulnerability risk level, and a second vulnerability list sorted according to processing priority.

[0089] In this embodiment 1, to assess the security vulnerability risks arising from changes to software delivery components, firstly, based on the component's group identification information and identification information, a precise query is performed on the components before and after the change (the original component and the target component) in a pre-maintained vulnerability database, generating a first query result to determine the security baseline of the two component versions. Then, for the specific version of the changed component, a second query is performed into a vulnerability version set to obtain a second query result. This set summarizes component versions historically affected by security vulnerabilities, aiming to finely verify the security history of changed component versions. Secondly, the results from the two queries are combined, and based on the component change type (such as component updates, scope changes, or changes in inter-component relationships), the security vulnerability risks are classified and assessed. Finally, based on the vulnerability risk level and processing priority, a first and second vulnerability list are compiled and ranked to form a clear vulnerability risk report, i.e., the aforementioned vulnerability risk information.

[0090] In one alternative embodiment, Figure 4 This is a schematic diagram of an optional vulnerability risk assessment process provided in Embodiment 1 of this application. Figure 4 As shown, first, the list of changed components is determined based on the incremental change information of the project, including but not limited to: component identifier (i.e., Group Id and Artifact Id), the version of the component before the change (i.e., the old version), the version of the component after the change (i.e., the new version), the component change type, the component dependency depth, and the component dependency source.

[0091] Then, a security vulnerability risk assessment engine is used for processing. The security vulnerability risk assessment engine can include the following processing rules. First, for the project group ID, component ID (i.e., component identifier, which can be represented as G:A), and target version (New Version) of the newly added component, query the public vulnerability database for all vulnerability records that match the project group ID and component ID, and whose affected range (affected_versions) includes the target version, and report all known vulnerabilities introduced by the newly added component.

[0092] Second, for upgraded components, first address vulnerabilities in the target version, treating them similarly to adding a new component, and check if the target version is within the affected scope. For older versions, pay extra attention to whether the older version is within the affected version range and whether the new version has already patched the vulnerabilities. The report should include any vulnerabilities introduced by the target version after the upgrade, as well as a list of vulnerabilities that have been patched after the upgrade.

[0093] Third, for downgraded components, handle them the same as newly added components, checking whether the target version is within the affected range. The key is to assess whether any reintroduced vulnerabilities exist.

[0094] Third, regarding vulnerability risk assessment, it's not enough to just generate a vulnerability list; the actual risk of each vulnerability in the list must also be evaluated. This requires comprehensive consideration of the basic score from a general vulnerability scoring system, known exploit intelligence, and environmental factors. These environmental factors include dependency scope types, actual call path analysis, dependency depth, and reference breadth.

[0095] Finally, a vulnerability risk report (i.e., a security risk assessment report) is generated based on the structured risk assessment report format. The vulnerability risk report may include the content shown in Table 6, including but not limited to: an overview, indicating the version comparison of the assessment, assessment time, vulnerability database snapshot version, and overall risk statistics found (by change type and risk level); newly added components, listing each component, version number, propagation path, component source, and details of included vulnerabilities; upgraded components, listing changes to the component, upgrades from lower to higher versions, propagation path, component source, and details of included vulnerabilities; deleted components; downgraded components, listing changes to the component, downgrades from higher to lower versions, propagation path, component source, and details of included vulnerabilities; a risk summary and priority ranking, which can sort all identified vulnerabilities by final risk level, highlighting vulnerabilities with high exploitability and re-introduction, and providing a priority list of remediation recommendations.

[0096] Table 6

[0097]

[0098] In addition, the impact factor of the change can be calculated based on the dependency depth (transitive dependency level) and breadth (number of affected components) of the changed components, and the risk level can be determined by combining the role of the component in the project (core component / peripheral component).

[0099] Through the above steps, the technical effect of accurately identifying and quantifying the security risks of component changes is achieved, ensuring the pertinence and operability of risk assessment, providing detailed data support for the pre-delivery security review of software, and thus improving the security and efficiency of the entire development process.

[0100] Optionally, in the project release alarm method provided in Embodiment 1 of this application, determining compatibility risk information based on the compatibility between components in the project includes: determining a first risk value based on the graph connectivity and cyclic path information of the second dependency graph; determining whether there is a conflict between the components of the project and determining a second risk value based on the number of conflicting components; determining a third risk value based on a preset set of compatibility rules and the component information of the components in the project, wherein the set of compatibility rules is constructed based on historical code issues, developer database, component compatibility information, and framework compatibility information; determining a fourth risk value based on the business type of the business to which the components belong in the project and the call chain of the components; and determining compatibility risk information based on the first risk value, the second risk value, the third risk value, and the fourth risk value.

[0101] In this embodiment 1, to quantify the compatibility risks of a software project, the connectivity and circular dependency information of the second dependency graph corresponding to the project changes are first analyzed to calculate a first risk value representing the circular dependency risk in the project. Then, by checking whether the project component versions are consistent, version conflicts between components are determined, and a second risk value is assessed based on the number of conflicting components. Next, a compatibility rule set is constructed using a historical code issue database, a developer experience base, and component-framework compatibility rules. The component information in the project is matched against this set to derive a third risk value, aiming to reveal potential interface incompatibility and framework conflict issues. Finally, combining the business type of the project components and a deep analysis of the component call chain, a fourth risk value is determined for the components on the critical business path. This assessment considers the degree of impact of the components on the core business.

[0102] In one alternative embodiment, to determine the compatibility risk information of a project, firstly, a compatibility rule base can be built. For implicit incompatibility risks in the project, compatibility rules are derived from compatibility reports of historical issues in open-source projects, developer community experience libraries, and internal community experience summaries, with a focus on application programming interface (API) incompatibility issues and framework incompatibility issues, and risk weight values ​​are set. Secondly, for explicit incompatibility issues in the project, these are already stored in the built graph and can be queried.

[0103] Then, a multi-dimensional risk quantification model involving multiple risk dimensions is established, and compatibility risk information is quantified based on the model output results. The multi-dimensional risk quantification model can be shown in Table 7, where multiple risk dimensions include, but are not limited to: assessing structural risk through graph connectivity analysis and outputting a circular dependency risk index (i.e., the first risk value mentioned above, with a value range of [0, 100]); assessing version incompatibility risk based on inconsistent component version numbers and outputting the number of incompatible components (i.e., the second risk value mentioned above); assessing compatibility risk value based on mismatch between interface definition and implementation version, coexistence of multiple similar framework implementations, etc., and outputting a compatibility risk weight value (i.e., the third risk value mentioned above, with a value range of [1, 10]); and assessing the business criticality of components through manual annotation and call chain tracing, and outputting a business impact coefficient (i.e., the fourth risk value mentioned above, with a value range of [1, 5]).

[0104] Table 7

[0105]

[0106] Finally, provide suggestions on handling strategies for identified compatibility risk information. For example, if a conflict of components with high business impact or a high risk factor is detected, provide a priority strategy for conflict handling, provide version rollback path analysis, and suggest a list of alternative components (based on similarity matching).

[0107] Through the above steps, risks across four dimensions—structure, version, compatibility, and business criticality—were comprehensively analyzed, ultimately generating compatibility risk information. The technical benefits lie in the ability to comprehensively and systematically identify and quantify potential compatibility risks during software project delivery, providing the development team with a basis for decision-making. This helps prevent and reduce runtime failures in the early stages, ensuring the stability and security of software delivery.

[0108] Optionally, in cost embodiment 1, Figure 5 This is a flowchart illustrating an optional alarm mechanism provided according to Embodiment 1 of this application. Figure 5As shown, firstly, a comprehensive scan of project dependencies and corresponding risks is conducted to identify any potential security vulnerabilities or compatibility issues. Then, based on pre-defined risk thresholds, different risk levels—high, medium, and low—are categorized, a crucial step in determining subsequent action paths. Secondly, appropriate procedures are initiated based on the risk level; urgent risks may trigger immediate remediation actions, while low risks may simply be recorded and continuously monitored. Finally, to ensure the effectiveness and completeness of risk handling, the development team must report the remedial measures taken to the system. The system then automatically verifies whether the measures have thoroughly resolved the risk, forming a complete closed loop from risk identification to resolution, ensuring the continuous security and stability of the software project. Through this process, dynamic monitoring and efficient management of risks in software delivery components are achieved, improving the project's risk response capabilities and delivery quality.

[0109] Figure 6 This is a schematic diagram of an optional process for identifying and issuing alerts regarding risks in project delivery versions, provided according to Embodiment 1 of this application. Figure 6 As shown, it includes the following steps:

[0110] First, the continuous integration pipeline triggers the scanning process of this invention by providing customized component support within the continuous integration pipeline.

[0111] Second, source code scanning and identification: by scanning and identifying the target source code, source code fingerprint information and dependent component information are collected.

[0112] Third, generate a project dependency graph (e.g., the first dependency graph and the second dependency graph mentioned above), construct the project dependency network based on the scanning results, and visualize the dependencies of each component.

[0113] Fourth, by comparing with historical versions, comparative analysis can identify incrementally changed components and accurately pinpoint the scope of changed components.

[0114] Fifth, conduct risk assessments, including: 1) Security vulnerability risk assessment: provide vulnerability assessment reports for the changed components; 2) Compatibility impact risk assessment: analyze the version incompatibility issues of the changed components and their potential impact on system compatibility.

[0115] Sixth, a unified risk view is provided to present the comprehensive risk analysis results of incremental change components in version delivery in a visual manner, and to provide an intuitive risk assessment report.

[0116] Seventh, for projects involving high risks, trigger alarms upon delivery, such as blocking, auditing, or logging.

[0117] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0118] In summary, the project release alerting method provided in this application constructs a first dependency graph of the project based on the source code information of the project at a first time, and constructs a second dependency graph of the project at a second time based on the source code information of the project at a second time, wherein the second time is later than the first time. For the first and second dependency graphs, incremental change information of the project is identified based on the nodes, node information, and dependency relationships in the graphs. The incremental change information includes at least: the original component and the target component. The component change type is determined based on the component information of the original component and the component information of the target component, and vulnerability risk information is determined based on the component change type and the vulnerability database. Compatibility risk information is determined based on the compatibility between components in the project, and an alert is issued before project release based on the vulnerability risk information and the compatibility risk information. This solves the problem in related technologies where assessing the risk of project release is inefficient due to the need for full parsing and scanning of the project code for each version.

[0119] By constructing and comparing dependency graphs of a project at different points in time, incremental change information can be accurately captured, achieving the technical effect of efficiently identifying dependency changes. Simultaneously, by analyzing version information of more variable components, the system can determine security risks based on a vulnerability database, enabling targeted security vulnerability warnings and further achieving the technical effect of proactively preventing software security risks. Furthermore, based on compatibility assessments between project components, potential runtime compatibility risks can be accurately identified before release, achieving strict quality control of software and ensuring the stability and security of software delivery, comprehensively improving the effectiveness of risk management and software lifecycle governance.

[0120] Example 2

[0121] This application also provides an alarm device for project release. It should be noted that the alarm device for project release in this application can be used to execute the alarm method for project release provided in this application. The alarm device for project release provided in this application is described below.

[0122] According to an embodiment of this application, an apparatus for implementing the alarm method for issuing the above-described project is also provided. Figure 7 This is a schematic diagram of an alarm device for project release according to Embodiment 2 of this application. For example... Figure 7 As shown, the device includes:

[0123] Specifically, the construction unit 701 is used to construct a first dependency graph of the project at the first time based on the source code information of the project at the first time, and to construct a second dependency graph of the project at the second time based on the source code information of the project at the second time, wherein the second time is later than the first time.

[0124] The identification unit 702 is used to identify incremental change information of the project based on the nodes, node information and dependency relationships in the first dependency graph and the second dependency graph. The incremental change information includes at least the original component and the target component.

[0125] The determination unit 703 is used to determine the component change type based on the component information of the original component and the component information of the target component, and to determine the vulnerability risk information based on the component change type and the vulnerability database.

[0126] Alarm unit 704 is used to determine compatibility risk information based on the compatibility between components in the project, and to issue alarms before the project is released based on vulnerability risk information and compatibility risk information.

[0127] The project release alarm device provided in this application embodiment constructs a first dependency graph of the project at a first time based on the source code information of the project at a first time, and constructs a second dependency graph of the project at a second time based on the source code information of the project at a second time, wherein the second time is later than the first time; the identification unit 702 identifies incremental change information of the project based on the nodes, node information and dependency relationships in the first dependency graph and the second dependency graph, wherein the incremental change information includes at least: original components and target components; the determination unit 703 determines the component change type based on the component information of the original component and the component information of the target component, and determines the vulnerability risk information based on the component change type and the vulnerability database; the alarm unit 704 determines the compatibility risk information based on the compatibility between components in the project, and issues an alarm before the project release based on the vulnerability risk information and the compatibility risk information. This solves the problem in related technologies where assessing the risk of project release is inefficient because a full analysis and scan of the project code for each version is required.

[0128] By constructing and comparing dependency graphs of a project at different points in time, incremental change information can be accurately captured, achieving the technical effect of efficiently identifying dependency changes. Simultaneously, by analyzing version information of more variable components, the system can determine security risks based on a vulnerability database, enabling targeted security vulnerability warnings and further achieving the technical effect of proactively preventing software security risks. Furthermore, based on compatibility assessments between project components, potential runtime compatibility risks can be accurately identified before release, achieving strict quality control of software and ensuring the stability and security of software delivery, comprehensively improving the effectiveness of risk management and software lifecycle governance.

[0129] Optionally, in the project release alarm device provided in Embodiment 2 of this application, the identification unit 702 includes: a first generation subunit, used to generate incremental change information based on different nodes in the first set and the second set when the first set and the second set are different, wherein the first set is a set of nodes contained in the first dependency graph and the second set is a set of nodes contained in the second dependency graph; a second generation subunit, used to parse the first version number of the first node and the second version number of the second node when the first set and the second set are the same, and generate incremental change information when the first version number and the second version number are different; a third generation subunit, used to compare the edges and edge attributes in the third set and the fourth set when the first version information and the second version information are the same, and generate incremental change information based on different edges or different attributes of the edges, wherein the third set is a set of edges contained in the first dependency graph and the fourth set is a set of edges contained in the second dependency graph.

[0130] Optionally, in the project release alarm device provided in Embodiment 2 of this application, the aforementioned construction unit 701 includes: a first construction subunit, used to scan the source code of the project at a first moment to obtain source code fingerprint information and dependent component information, and to characterize the dependent component information using a tree structure to obtain a dependency tree; a second construction subunit, used to construct multiple nodes based on the source code fingerprint information and the dependency tree, wherein the multiple nodes include at least: version repository, project, dependent component, license, vulnerability, and release date; a third construction subunit, used to construct multiple edges between multiple nodes based on the dependency tree, wherein the multiple edges include at least: edges from the project to the dependent component, directed edges between different dependent components, edges from the dependent component to the license, and edges from the release date to the version repository; and a fourth construction subunit, used to construct a first dependency graph based on the multiple nodes and multiple edges.

[0131] Optionally, in the project release alarm device provided in Embodiment 2 of this application, the aforementioned construction unit 701 further includes: a first determining subunit, used to determine the identification information of each of the multiple nodes based on the node's group identification information and the node's dependency library identification information before constructing the first dependency graph based on multiple nodes and multiple edges; a processing subunit, used to standardize the scope of the nodes based on the standard scope; a merging subunit, used to merge duplicate paths among the multiple reference paths when any node in the first dependency graph has multiple reference paths; and a pruning subunit, used to prune nodes in the first dependency graph that only function in the target scope using a dependency tree pruning algorithm, wherein the target scope represents a dependency environment that is unrelated to the code packaging process.

[0132] Optionally, in the alarm device for project release provided in Embodiment 2 of this application, the above-mentioned component change types include at least: a first type, a second type, and a third type. The first type indicates that the component itself has changed, the second type indicates that the scope of the component has changed, and the third type indicates that the relationship between the component and other components has changed. The first type includes at least the following subtypes: adding a component, removing a component, upgrading a version, and downgrading a version. The third type includes at least the following subtypes: changing the dependency path and the dependency version being incompatible.

[0133] Optionally, in the project release alarm device provided in Embodiment 2 of this application, the aforementioned determining unit 703 includes: a first query subunit, used to query the vulnerability database based on the group identification information and identification information of the original component and the group identification information and identification information of the target component respectively, to obtain a first query result; a second query subunit, used to query in the vulnerability version set whether the original component and the target component have vulnerability records respectively, to obtain a second query result, wherein the vulnerability version set is a set of component versions affected by known security vulnerabilities obtained from external channels; and a second determining subunit, used to determine vulnerability risk information based on the component change type, according to the first query result and the second query result, wherein the vulnerability risk information includes at least: a first vulnerability list sorted according to vulnerability risk level, and a second vulnerability list sorted according to processing priority.

[0134] Optionally, in the project release alarm device provided in Embodiment 2 of this application, the alarm unit 704 includes: a third determining subunit, used to determine a first risk value based on the graph connectivity and cyclic path information of the second dependency graph; a judging subunit, used to judge whether there is a conflict between the components of the project, and to determine a second risk value based on the number of conflicting components; a fourth determining subunit, used to determine a third risk value based on a preset compatibility rule set and the component information of the components in the project, wherein the compatibility rule set is constructed based on historical code issues, developer database, component compatibility information, and framework compatibility information; a fifth determining subunit, used to determine a fourth risk value based on the business type of the business to which the components belong in the project and the call chain of the components; and a sixth determining subunit, used to determine compatibility risk information based on the first risk value, the second risk value, the third risk value, and the fourth risk value.

[0135] It should be noted that the aforementioned construction unit 701, identification unit 702, determination unit 703, and alarm unit 704 correspond to steps S201 to S204 in Embodiment 1. The two modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the aforementioned modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The aforementioned modules can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0136] Example 3

[0137] Embodiments of this application may provide an electronic device. Figure 8 This is a schematic diagram of an alarm electronic device issued according to Embodiment 3 of this application. Figure 8 As shown, the electronic device may include: one or more ( Figure 8 (Only one is shown) processor 802, memory 804, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0138] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0139] The processor can access information and applications stored in memory via a transmission device to perform the following steps: constructing a first dependency graph of the project based on the source code information of the project at a first time point, and constructing a second dependency graph of the project at a second time point based on the source code information of the project at a second time point, wherein the second time point is later than the first time point; identifying incremental change information of the project based on the nodes, node information, and dependencies in the first and second dependency graphs, wherein the incremental change information includes at least: the original component and the target component; determining the component change type based on the component information of the original component and the component information of the target component, and determining vulnerability risk information based on the component change type and the vulnerability database; determining compatibility risk information based on the compatibility between components in the project, and issuing warnings before project release based on the vulnerability risk information and compatibility risk information.

[0140] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: For a first dependency graph and a second dependency graph, identify incremental change information for items based on nodes, node information, and dependencies in the graphs, including: if the first set and the second set are different, generate incremental change information based on different nodes in the first set and the second set, wherein the first set is the set of nodes contained in the first dependency graph, and the second set is the set of nodes contained in the second dependency graph; if the first set and the second set are the same, parse the first version number of the first node, parse the second version number of the second node, and generate incremental change information if the first version number and the second version number are different; if the first version information and the second version information are the same, compare the edges and edge attributes in the third set and the fourth set, and generate incremental change information based on different edges or different edge attributes, wherein the third set is the set of edges contained in the first dependency graph, and the fourth set is the set of edges contained in the second dependency graph.

[0141] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: constructing a first dependency graph of the project at a first moment based on the project's source code information at a first moment, including: scanning the source code of the project at the first moment to obtain source code fingerprint information and dependency component information, and representing the dependency component information using a tree structure to obtain a dependency tree; constructing multiple nodes based on the source code fingerprint information and the dependency tree, wherein the multiple nodes include at least: repository, project, dependency component, license, vulnerability, and release date; constructing multiple edges between the multiple nodes based on the dependency tree, wherein the multiple edges include at least: edges from the project to the dependency component, directed edges between different dependency components, edges from the dependency component to the license, and edges from the release date to the repository; and constructing the first dependency graph based on the multiple nodes and multiple edges.

[0142] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: Before constructing a first dependency graph based on multiple nodes and multiple edges, the above method further includes: for each of the multiple nodes, determining the node's identifier information based on the node's group identifier information and the node's dependency library identifier information; standardizing the node's scope based on standard scopes; merging duplicate paths among multiple reference paths when any node in the first dependency graph has multiple reference paths; and pruning nodes in the first dependency graph that only function in the target scope using a dependency tree pruning algorithm, wherein the target scope represents a dependency environment unrelated to the code packaging process.

[0143] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: The component change type includes at least the following: Type 1, Type 2, and Type 3. Type 1 indicates that the component itself has changed, Type 2 indicates that the scope of the component has changed, and Type 3 indicates that the relationship between the component and other components has changed. Type 1 includes at least the following subtypes: adding a component, removing a component, upgrading a version, and downgrading a version. Type 3 includes at least the following subtypes: changing the dependency path and incompatible dependency versions.

[0144] The processor can access information and applications stored in memory via a transmission device to perform the following steps: determining vulnerability risk information based on component change type and vulnerability database, including: querying the vulnerability database based on the group identifier and identifier information of the original component and the target component respectively, to obtain a first query result; querying the vulnerability version set to determine whether there are vulnerability records in the original component and the target component respectively, to obtain a second query result, wherein the vulnerability version set is a collection of component versions affected by known security vulnerabilities obtained from external channels; determining vulnerability risk information based on component change type, according to the first query result and the second query result, wherein the vulnerability risk information includes at least: a first vulnerability list sorted by vulnerability risk level, and a second vulnerability list sorted by processing priority.

[0145] The processor can access information and applications stored in memory via a transmission device to perform the following steps: determining compatibility risk information based on the compatibility between components in the project, including: determining a first risk value based on the graph connectivity and cyclic path information of the second dependency graph; determining whether there are conflicts between components in the project and determining a second risk value based on the number of conflicting components; determining a third risk value based on a preset set of compatibility rules and component information in the project, wherein the set of compatibility rules is constructed based on historical code issues, a developer database, component compatibility information, and framework compatibility information; determining a fourth risk value based on the business type of the business to which the component belongs and the component's call chain; and determining compatibility risk information based on the first, second, third, and fourth risk values.

[0146] This application provides a method for issuing alerts for project releases. It constructs a first dependency graph of the project based on its source code information at a first time point, and a second dependency graph based on its source code information at a second time point, where the second time point is later than the first time point. For both the first and second dependency graphs, incremental change information of the project is identified based on nodes, node information, and dependencies within the graphs. This incremental change information includes at least the original component and the target component. The component change type is determined based on the component information of the original component and the target component, and vulnerability risk information is determined based on the component change type and a vulnerability database. Compatibility risk information is determined based on the compatibility between components in the project, and an alert is issued before the project release based on the vulnerability risk information and the compatibility risk information. This method solves the technical problem of low efficiency in assessing project risk due to the need for full parsing and scanning of each version of the project code.

[0147] By constructing and comparing dependency graphs of a project at different points in time, incremental change information can be accurately captured, achieving the technical effect of efficiently identifying dependency changes. Simultaneously, by analyzing version information of more variable components, the system can determine security risks based on a vulnerability database, enabling targeted security vulnerability warnings and further achieving the technical effect of proactively preventing software security risks. Furthermore, based on compatibility assessments between project components, potential runtime compatibility risks can be accurately identified before release, achieving strict quality control of software and ensuring the stability and security of software delivery, comprehensively improving the effectiveness of risk management and software lifecycle governance.

[0148] Those skilled in the art will understand that Figure 8 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 8 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 8 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 8 The different configurations shown.

[0149] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0150] Example 4

[0151] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the alarm method for project publishing provided in Embodiment 1.

[0152] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0153] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing alarm method steps published by a project.

[0154] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0155] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0157] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0158] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0159] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0160] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A project release alerting method, characterized by, The method comprises the following steps: constructing a first dependency graph of the project at a first time according to source code information of the project at the first time, and constructing a second dependency graph of the project at a second time according to source code information of the project at the second time, wherein the second time is later than the first time; identifying incremental change information of the project according to nodes, node information and dependency relationships in the first dependency graph and the second dependency graph, wherein the incremental change information at least includes original components and target components; determining a component change type according to component information of the original components and component information of the target components, and determining vulnerability risk information according to the component change type and a vulnerability database; determining compatibility risk information according to compatibility between components in the project, and performing warning before release of the project based on the vulnerability risk information and the compatibility risk information.

2. The method of claim 1, wherein, The method for identifying incremental change information of the project according to nodes, node information and dependency relationships in the first dependency graph and the second dependency graph comprises the following steps: in the case that the first set and the second set are different, generating the incremental change information according to different nodes in the first set and the second set, wherein the first set is a set of nodes contained in the first dependency graph, and the second set is a set of nodes contained in the second dependency graph; in the case that the first set and the second set are the same, parsing a first version number of a first node, parsing a second version number of a second node, and in the case that the first version number and the second version number are different, generating the incremental change information; in the case that the first version number and the second version number are the same, comparing edges and attributes of edges in a third set and a fourth set, and generating the incremental change information according to different edges or different attributes of edges, wherein the third set is a set of edges contained in the first dependency graph, and the fourth set is a set of edges contained in the second dependency graph.

3. The method of claim 1, wherein, The method for constructing a first dependency graph of the project at a first time according to source code information of the project at the first time comprises the following steps: scanning source code of the project at the first time to obtain source code fingerprint information and dependency component information, and representing the dependency component information in a tree structure to obtain a dependency tree; constructing a plurality of nodes according to the source code fingerprint information and the dependency tree, wherein the plurality of nodes at least include version libraries, projects, dependency components, licenses, vulnerabilities and release dates; constructing a plurality of edges between the plurality of nodes according to the dependency tree, wherein the plurality of edges at least include edges from projects to dependency components, directed edges between different dependency components, edges from dependency components to licenses and edges from release dates to version libraries; constructing the first dependency graph according to the plurality of nodes and the plurality of edges.

4. The method of claim 3, wherein, Before constructing the first dependency graph according to the plurality of nodes and the plurality of edges, the method further comprises the following steps: for each node in the plurality of nodes, determining identification information of the node according to group identification information of the node and dependency library identification information of the node. standardize a scope of the node based on a standard scope; in a case where there are multiple reference paths in any node in the first dependency graph, merging repeated paths in the multiple reference paths; using a dependency tree pruning algorithm, pruning nodes in the first dependency graph that only function in a target scope, wherein the target scope represents a dependency environment irrelevant to a code packaging process.

5. The method of claim 1, wherein, The component change type at least includes: first type, second type, third type, the first type represents that the component itself changes, the second type represents that the scope of the component changes, and the third type represents that the relationship between the component and other components changes, the first type at least includes the following subtypes: new component, remove component, version upgrade, version downgrade, the third type at least includes the following subtypes: change dependency path, dependency version incompatible.

6. The method of claim 1, wherein, According to the component change type and the vulnerability database, the vulnerability risk information is determined, including: According to the group identification information and the identification information of the original component and the group identification information and the identification information of the target component, query in the vulnerability database respectively, and obtain the first query result; In the vulnerability version set, query whether the original component and the target component exist vulnerability record respectively, obtain the second query result, wherein the vulnerability version set is a set of component versions affected by known security vulnerabilities obtained from external channels; Based on the component change type, the first query result and the second query result are determined, wherein the vulnerability risk information at least includes: the first vulnerability list sorted based on vulnerability risk level, and the second vulnerability list sorted based on processing priority.

7. The method of claim 1, wherein, According to the compatibility between components in the project, the compatibility risk information is determined, including: Determine a first risk value according to the graph connectivity and the cycle path information of the second dependency graph; Determine a second risk value according to whether there is a conflict between the components of the project, and according to the number of conflict components; Determine a third risk value according to a preset compatibility rule set and component information of components in the project, wherein the compatibility rule set is constructed according to historical code problems, developer database, component compatibility information and framework compatibility information; Determine a fourth risk value according to the business type of the business to which the component in the project belongs and the calling link of the component; Determine the compatibility risk information according to the first risk value, the second risk value, the third risk value and the fourth risk value.

8. An alarm device for a project release, characterized by including: The construction unit is used for constructing the first dependency graph of the project at the first moment according to the source code information of the project at the first moment, and constructing the second dependency graph of the project at the second moment according to the source code information of the project at the second moment, wherein the second moment is later than the first moment; An identifying unit is configured to identify incremental change information of the project according to nodes, node information and dependency relationships in the first dependency graph and the second dependency graph, wherein the incremental change information at least includes a source component and a target component; A determining unit is configured to determine a component change type according to component information of the source component and component information of the target component, and determine vulnerability risk information according to the component change type and a vulnerability database; An alarming unit is configured to determine compatibility risk information according to compatibility between components in the project, and perform alarming before the project is released based on the vulnerability risk information and the compatibility risk information.

9. An electronic device, comprising: The method comprises the following steps: A memory is configured to store an executable program; A processor is configured to run the program, wherein the program is configured to perform the method for alarming of the project release according to any one of claims 1 to 7 when the program is run.

10. A computer program product comprising computer instructions, characterized in that, The computer instructions are configured to perform the steps of the method for alarming of the project release according to any one of claims 1 to 7 when the computer instructions are executed by the processor.

Images