Method and device for determining risk of software package and server

Abstract

The invention relates to the technical field of computer software development, and provides a method and device for determining the risk of a software package and a server. According to the method, the problem that privacy compliance and security vulnerability risks may be introduced due to the fact that in an actually delivered demand list, demands not in a planning demand list are not subjected to privacy compliance and security compliance analysis can be solved. The method comprises the steps of obtaining at least one code submission record associated with a software package, wherein the at least one code submission record is associated with a corresponding delivery demand; generating a delivery demand list associated with the software package according to the delivery demand; and performing delivery risk analysis on the software package according to the delivery demand list, and determining a first analysis result which is used for determining whether the software package can be published or not.

Description

Technical Field

[0001] This application relates to the technical field of computer software development, and in particular, to a method, device, and server for determining the risk of a software package. Background Art

[0002] Currently, when users use the project management capabilities provided by public cloud providers to track the project operation process of software products, they usually need to go through three stages, namely, the version start stage, the version development stage, and the version release stage of the project. To ensure the quality of the finally delivered software product, in the version release stage, it is necessary to check the software package finally delivered in the version development stage according to the planning requirement list formulated in the version start stage, and allow release only when the requirements delivered in the software package are consistent with the planning requirement list, and all inspections such as security compliance inspection and privacy compliance inspection meet the delivery permission.

[0003] However, since there may be changing requirements in the version development stage, some problems are not included in the planning requirement list of the product manager, or during the development process, due to processes such as branch merging and conflict resolution, non-code of this iteration version is accidentally merged, resulting in inconsistent delivery requirements involved in the finally delivered software package and the initial planning requirements. Among the actually delivered requirements, the requirements not in the planning requirement list may introduce privacy compliance and security vulnerability risks because they have not undergone privacy compliance and security compliance analysis. Summary of the Invention

[0004] This application provides a method, device, and server for determining the risk of a software package, which solves the problem that the delivered requirements in the prior art may introduce privacy compliance and security vulnerability risks.

[0005] To achieve the above object, this application adopts the following technical solutions:

[0006] In a first aspect, a method for determining the risk of a software package is provided, including: obtaining at least one code submission record associated with the software package, and at least one code submission record is associated with a corresponding delivery requirement; generating a delivery requirement list associated with the software package according to the delivery requirement; performing a delivery risk analysis on the software package according to the delivery requirement list to determine a first analysis result, and the first analysis result is used to determine whether the software package can be released.

[0007] In the method for determining the risk of a software package provided by the embodiments of the present application, the delivery requirement list involved in the software package is determined by backward tracing at least one code commit record involved in the software package, and then privacy, security, and other delivery risk analyses are performed based on the involved delivery requirement list to determine the first analysis result. This method can avoid the problem of introducing privacy compliance and security vulnerability risks due to the delivery requirements in the delivery requirement list not being analyzed for privacy compliance and security compliance. Among them, the first analysis result is used to determine whether the software package can be released.

[0008] In one implementation, the first analysis result is used to directly determine whether the software package can be released. Exemplarily, if the first analysis result indicates that there is a delivery risk in the software package, it is determined that the software package is not allowed to be released.

[0009] In another implementation, the first analysis result is used to assist in determining whether the software package can be released. Exemplarily, if the first analysis result indicates that there is a delivery risk in the software package, that is, the delivery requirement list includes other requirements not in the planned requirement list. For example, a new delivery requirement "push advertising information" is introduced in the delivery requirement list, but after analysis, this newly added delivery requirement does not introduce privacy compliance or security vulnerability risks. In this case, it is determined that the software package is allowed to be released.

[0010] In some embodiments, performing a delivery risk analysis on the software package according to the delivery requirement list to determine the first analysis result includes: when the delivery requirement list is inconsistent with the preset planned requirement list, determining a list of differential requirements; determining whether the delivery requirement list meets the preset conditions according to the list of differential requirements; when the delivery requirement list meets the preset conditions, performing a delivery risk analysis on the software package according to the delivery requirement list to determine the first analysis result.

[0011] In this embodiment, when the list of differential requirements formed by the delivery requirement list and the preset planned requirement list includes the requirements in the planned requirement list, it is determined that there are missing requirements in the delivery requirement list; when the list of differential requirements formed by the delivery requirement list and the preset planned requirement list does not include the requirements in the planned requirement list, it is determined that there are no missing requirements in the delivery requirement list. And when there are no missing requirements in the delivery requirement list, a delivery risk analysis is performed on the software package according to the delivery requirement list to determine the first analysis result.

[0012] In some embodiments, the preset conditions include: the delivery requirement list includes each planned requirement in the planned requirement list and N first requirements, where the N first requirements are requirements not in the planned requirement list and N≥1.

[0013] In this embodiment, the N first requirements are the requirements in the delivery requirement list that are not in the planned requirement list, that is, the newly added delivery requirements. When performing delivery risk analysis, further security compliance and privacy compliance analysis can be performed based on the N first requirements.

[0014] In some embodiments, the delivery risk analysis includes at least one of the following: determining the security compliance status of each delivery requirement among the N first requirements; determining the privacy compliance status of each delivery requirement among the N first requirements.

[0015] Among them, the security compliance status includes the legality of data collection, the security of data processing, whether compliance records are established, etc. The privacy compliance status includes identifying security compliance requirements, analyzing the compliance of requirements, analyzing the security of requirements, evaluating the difficulty of requirement implementation, etc.

[0016] In some embodiments, at least one code submission record meets the preset code submission specification, and the code submission specification includes: the code description information in the code submission record includes the requirement order number corresponding to the code, the submission description information, and the source code information.

[0017] In this embodiment, when the code submission record submitted by the R & D personnel to the code repository meets the above code submission specification, the server then traces back the associated delivery requirement list in the code submission record according to the requirement order number corresponding to the code in the code submission record, and further performs delivery risk analysis on the delivery requirement list.

[0018] In some embodiments, generating a delivery requirement list associated with a software package according to the delivery requirements includes: obtaining the requirement order number corresponding to the code from each code submission record; determining the delivery requirements corresponding to each requirement order number; generating a delivery requirement list associated with the software package according to the determined delivery requirements.

[0019] In some embodiments, before obtaining at least one code submission record associated with the software package, the method further includes: obtaining a preset planned requirement list; performing risk characteristic analysis on each planned requirement in the planned requirement list; when a planned requirement involves a corresponding risk among the risk characteristics, setting a corresponding label for the planned requirement, and the label is used to identify whether the planned requirement involves the corresponding risk.

[0020] In this embodiment, the risk characteristic analysis is privacy and security characteristic analysis. Optionally, it further includes characteristic analysis in aspects such as injection resilience and testing.

[0021] In some embodiments, before obtaining at least one code submission record associated with the software package, the method further includes: creating a project collaboration plan for the software package, and the project collaboration plan includes at least one of the information name, iteration name, code repository address, code repository branch, starting code submission point, and code path of the software package.

[0022] In some embodiments, the software package is built in the following manner: obtaining the code repository address and the code repository branch in the project collaboration plan; and packaging all the codes before building the software package according to the code repository address and the code repository branch to generate the software package.

[0023] In this embodiment, when building the software package, the last code commit point of the code repository and all the code description information committed before the last code commit point are packaged.

[0024] In some embodiments, obtaining at least one code commit record associated with the software package includes: determining the starting code commit point involved in the software package according to the project collaboration plan; determining the last code commit point involved in the software package according to the built software package; and obtaining at least one code commit record between the starting code commit point (excluding the starting code commit point) and the last code commit point.

[0025] In this embodiment, during the code tracing process, taking the starting code commit point in the project collaboration plan as the "starting point" and the last code commit point as the "ending point" from the built software package, querying the code commit records between the two points in the code repository, so as to obtain at least one code commit record associated with the software package.

[0026] In a second aspect, a device for determining the risk of a software package is provided. The device includes: an obtaining unit, configured to obtain at least one code commit record associated with the software package, and each of the at least one code commit records is associated with a corresponding delivery requirement; a generating unit, configured to generate a delivery requirement list associated with the software package according to the delivery requirements, and the delivery requirement list includes the delivery requirements associated with the at least one code commit record; and a determining unit, configured to perform a delivery risk analysis on the software package according to the delivery requirement list to determine a first analysis result, and the first analysis result is used to determine whether the software package can be released.

[0027] In a third aspect, a server is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for determining the risk of a software package shown in the first aspect is implemented.

[0028] In a fourth aspect, a management system is provided, including a server and at least one user device connected to the server. The server is configured to execute the method for determining the risk of a software package shown in the first aspect.

[0029] In a fifth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for determining the risk of a software package shown in the first aspect is implemented.

[0030] In a sixth aspect, a chip is provided. The chip includes a processor and a memory. A computer program is stored in the memory. When the computer program is executed by the processor, the method for determining the risk of a software package as shown in the first aspect is implemented.

[0031] It can be understood that for the beneficial effects of the above second aspect to the sixth aspect, reference can be made to the relevant descriptions in the first aspect above, and details are not repeated here. Description of the Drawings

[0032] Figure 1 It is a system architecture diagram applicable to the method for determining the risk of a software package provided by an embodiment of the present application;

[0033] Figure 2 It is a schematic diagram of each functional unit included in the server provided by an embodiment of the present application;

[0034] Figure 3 It is a schematic flowchart of the method for determining the risk of a software package provided by an embodiment of the present application;

[0035] Figure 4 It is a schematic diagram of the display interface of the user equipment side provided by an embodiment of the present application;

[0036] Figure 5 It is a schematic diagram of the project management page of the user equipment side provided by an embodiment of the present application;

[0037] Figure 6 It is a schematic diagram of the code submission record provided by an embodiment of the present application;

[0038] Figure 7 It is a schematic structural diagram of the device for determining the risk of a software package provided by an embodiment of the present application;

[0039] Figure 8 It is a schematic structural diagram of the chip provided by an embodiment of the present application. Detailed Embodiments

[0040] The technical solutions provided by the embodiments of the present application will be described below with reference to the drawings.

[0041] It should be understood that in the description of the embodiments of the present application, unless otherwise specified, " / " means "or". For example, A / B may mean A or B; herein, "and / or" is only a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may mean: A exists alone, A and B exist simultaneously, and B exists alone.

[0042] In this embodiment, the terms "first" and "second" are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more such features. In the description of this embodiment, unless otherwise specified, the meaning of "a plurality" is two or more.

[0043] Public clouds generally refer to clouds (which can also be referred to as servers or cloud servers) that can be used provided by a third-party provider (such as Huawei Cloud) for users, and users can use them via the Internet. The core attribute of public clouds is shared resource services. An enterprise directly provides services to external users through its own infrastructure, and external users access the services via the Internet. Exemplarily, users can use the project management capabilities provided by public cloud providers to track the project operation process of software products. For example, when developing an application, users can use the project management capabilities provided by public clouds to track the project operation during the entire application development process.

[0044] In some embodiments, users using public clouds to track the project operation process of software products includes at least three stages, namely, the version start stage, the version R & D stage, and the version release stage of the project.

[0045] Among them, in the version start stage, the product manager in charge of the software product will sort out the planning requirements for the software product or a certain updated version (such as version 1.0 or version 2.0) of the software product and give a list of requirements to be delivered. For example, in the version start stage of a software product for developing a chat application, the product manager in charge of the chat application will give a list of planning requirements that the chat application needs to have, such as collecting basic user information, collecting user location information, and pushing advertising information, as shown in Table 1 below.

[0046] Table 1

[0047] Serial Number Planning Requirements 1 Collect User's Basic Information 2 Collect User's Location Information 3 Push Advertising Information …… ……

[0048] After the preparatory work in the version start stage is completed, it immediately enters the version R & D stage.

[0049] In the R & D stage of this version, two actions usually need to be carried out. One is that the systems engineer (SE) conducts a fine-grained division of the requirements in the planned requirements list, breaks down each requirement into functional units to be implemented (which can also be called sub-requirements), and hands them over to specific development responsible persons for development and delivery. Among them, one planned requirement can be broken down into one or more functional units. After the development responsible persons complete the development, they submit the code corresponding to each functional unit to the code repository. And after the code submission is completed, other R & D processes such as testing are carried out for the requirements in the planned requirements list. The second is that privacy, security and other inspection specialists analyze the requirements in the planned requirements list based on design for X (DFX) items such as privacy and security for each link of the product life cycle, and output the analysis results on whether each requirement involves privacy, security and other aspects. Among them, X can represent the product life cycle or a certain link thereof, such as assembly (M - manufacturing, T - testing), processing, use, maintenance, recycling, scrapping, etc., or can represent product competitiveness or factors determining product competitiveness, such as quality, cost (C), time, etc.

[0050] Exemplarily, in the R & D stage of the version, on the one hand, the systems engineer SE conducts a fine-grained division of the requirements in the planned requirements list to obtain their respective corresponding fine-grained requirements, such as sub-requirement 1, sub-requirement 2, sub-requirement 3 and sub-requirement 4, and hands over the fine-grained requirements sub-requirement 1, sub-requirement 2, sub-requirement 3 and sub-requirement 4 to the corresponding development responsible persons A, B and C for their respective development, as specifically shown in Table 2 below.

[0051] Table 2

[0052] Serial Number Planning Requirements Fine-grained Requirements Development Responsible Person 1 Collect User's Basic Information Sub-requirement 1, Sub-requirement 2 A 2 Collect User's Location Information Sub-requirement 3 B 3 Push Advertising Information Sub-requirement 4 C …… …… …… ……

[0053] On the other hand, the inspection specialists conduct detection and analysis on each planned requirement for DFX items such as privacy and security, and output the analysis results on whether it is involved, as shown in Table 3 below.

[0054] Table 3

[0055] Serial Number Planning Requirements Whether Privacy is Involved Whether Security is Involved Analysis of Other DFX Items 1 Collect User's Basic Information Yes No 2 Collect User's Location Information Yes Yes 3 Push Advertising Information No No …… …… …… …… ……

[0056] It should be noted that when users use the project management capabilities provided by the public cloud, in order to ensure the quality of the finally delivered product, the following issues need to be concerned about during the project delivery process, but are not limited to:

[0057] (1) Whether the actual delivered requirements involved in the delivered software package are consistent with the planned requirements;

[0058] (2) Whether the user privacy involved in the delivered software package is compliant;

[0059] (3) Whether the security issues involved in the delivered software package comply with regulations.

[0060] Based on this, when the work in the version R & D stage is completed and entering the version release stage, various inspections need to be carried out on the situation of the delivered software package, specifically including: inspections of the delivery situation of requirements, privacy compliance, security compliance, etc. Only when all inspections meet the delivery permission can it be allowed to be released. After receiving the code submitted by the development team leader, the inspector combines the analysis results output by privacy and security detection specialists and other personnel to inspect items such as the delivery situation of requirements. When all inspections meet the requirements and satisfy the delivery permission, it is determined that the inspection passes and it is allowed to be released.

[0061] Currently, in the version release stage, the processes of conducting requirement inspections, privacy compliance analysis, and security compliance analysis on the delivered software package are all achieved through positive analysis based on the requirement list planned by the product manager at the beginning of the version. Exemplarily, taking the planned requirement list shown in Table 1 above as an example, when conducting processes such as requirement inspections, privacy compliance analysis, and security compliance analysis on the software package delivered in the version R & D stage, it is inspected based on each requirement involved in Table 1 above. For example, first determine the planned requirement of "collecting basic user information", whether it is delivered in the software package, and when this requirement is delivered in the software package, conduct inspections such as privacy compliance analysis and security compliance analysis on this requirement to determine whether it meets the delivery conditions; and so on, to detect whether each planned requirement in the planned requirement list meets the above delivery conditions. Then, when each planned requirement in the planned requirement list meets the delivery permission, it is determined that the inspection passes and it is allowed to be released.

[0062] However, due to the possible changing requirements during the version R & D process, some problems are not included in the planned requirement list of the product manager, or during the development process, due to processes such as branch merging and conflict resolution, non-code of this iteration version is mistakenly merged, resulting in the inconsistency between the actual delivered requirement list involved in the finally delivered software package and the initial planned requirements. Among the actual delivered requirement list, the requirements not in the planned requirement list may introduce risks of privacy compliance and security vulnerabilities because they have not undergone privacy compliance and security compliance analysis.

[0063] Therefore, the embodiment of this application provides a method for determining the risk of a software package, which can solve the problem that the requirements not in the planned requirement list in the actual delivered requirement list may introduce risks of privacy compliance and security vulnerabilities because they have not undergone privacy compliance and security compliance analysis.

[0064] Figure 1 Schematic diagram of the system applicable to the method for determining the risk of a software package provided by the embodiment of this application, see Figure 1As shown in the figure, the system includes at least one user device 100 and a server 200. Among them, users can use the services provided by the server 200 through the client or web browser of the user device 100. For example, users can use the project management capabilities required for the research and development of software products provided by the server 200 supplier through the user device 100. During the project management process of software products, tasks such as whether the requirements for software delivery are complete, whether the privacy protection strategy is appropriate, and whether the security protection is in place need to be solved. According to this part of the user's demands, the server 200 provider needs to integrate the functions of requirement management and privacy and security analysis into the project management solution.

[0065] Among them, the users faced by the user device 100 can be enterprise users or individual users. Individual users refer to users with small usage volumes who can directly register and authenticate with their personal identities. For example, individual webmasters. Enterprise users refer to users in various industries, such as e-commerce, Internet finance, online education, etc. Enterprise users can apply information technology infrastructure, management, business, etc. based on the Internet and connect to social resources, share services and capabilities through the Internet and cloud computing means.

[0066] Figure 2 Exemplarily shown are the various functional units included in the server provided by the embodiments of the present application. It should be understood that Figure 2 The various functional units included in the shown server 200 are only an example, and the server 200 may have more or fewer functional units than Figure 2 shown in this, and no specific limitations are made in this embodiment.

[0067] See Figure 2 As shown in the figure, the server 200 may include: a code repository 201, a project management module 202, a requirement management module 203, and a continuous integration (CI) build module 204. Among them, the code repository 201 is used to host business code, record code submission information, code merge rules configuration, etc. The project management module 202 is part of software engineering management, used to be responsible for project iteration cycle management, etc., and check the delivery status of versions, etc. The requirement management module 203 is used to manage the requirements to be delivered during the project iteration cycle, including DFX feature analysis such as privacy and security for the requirements. The CI build module 204 is used to be responsible for code packaging and building, and will record information such as source code, component dependencies, software package names, etc. during the building process.

[0068] In some embodiments, the code repository 201 includes a commit rule configuration unit 2011, a commit record unit 2012, and a branch tag management unit 2013. Among them, the commit rule configuration unit 2011 is used to support the configuration of commit rules and detect the normativity of commit information when code is committed; the commit record unit 2012 is used to record the code description information (also known as code commit information) when code is committed; the branch tag management unit 2013 is used to manage the code repository branches and the tag points of the branches.

[0069] The project management module 202 includes a version traceability unit 2021, an access control release unit 2022, and a version release unit 2023. Among them, the version traceability unit 2021 is used to trace back the requirements for the code in the finally delivered software package in reverse and determine whether the delivered requirements are consistent with the expectations; the access control release unit 2022 is used for centralized inspection of whether the version meets the release conditions, including the results of version traceability; the version release unit 2023 is used to implement the delivery and online release of the software iterative version when the release access control requirements are met.

[0070] The requirements management module 203 includes a requirements management unit 2031 and a requirements analysis unit 2032. Among them, the requirements management unit 2031 is used to manage the life cycle of product requirements; the requirements analysis unit 2032 is used to analyze the privacy, security labels, etc. of product requirements.

[0071] The CI build module 204 includes a pipeline management unit 2041. The CI build module 204 is a functional module for business compilation, build, and packaging. During the business build process, it will record the branch of the current code repository 201 and the last code commit point (commit-id).

[0072] Figure 3 It is a schematic flowchart of a method for determining the risk of a software package provided by an embodiment of the present application. This method is applied to a server, and a user can access the server through a user device to execute the method provided in this embodiment. Refer to Figure 3 As shown, this method includes the following steps S301 to S303.

[0073] S301, the server obtains at least one code commit record associated with the software package, and the at least one code commit record is associated with corresponding delivery requirements.

[0074] Among them, the software package can be generated by packaging the code-related information involved in a certain update and iteration version (such as version 1.0 or version 2.0) of the software product, or can be generated by packaging the code-related information associated with the entire development cycle of the software product. The embodiments of the present application do not limit this.

[0075] It should be noted that in this embodiment, at least one code commit record associated in the software package is generated by the server according to the code commit information uploaded to the corresponding code repository on the server through at least one user device after the development person in charge completes the development work of the code corresponding to each different sub-requirement during the project R & D stage.

[0076] In this embodiment, the code commit records corresponding to each code commit point meet the preset code commit specification. Exemplarily, the code commit specification may be: the code commit information in the code commit record includes the requirement order number corresponding to the code, the commit description information, and the source code information.

[0077] S302. The server generates a delivery requirement list associated with the software package according to the delivery requirements.

[0078] In some embodiments, based on the fact that the code commit record includes the requirement order number corresponding to the code, the commit description information, and the source code information, when generating the delivery requirement list, the server first obtains the requirement order number corresponding to the code from each code commit record, then determines the delivery requirement corresponding to each requirement order number according to the respective requirement order numbers, and finally generates the delivery requirement list involved in the software package according to the determined respective delivery requirements.

[0079] S303. The server performs a delivery risk analysis on the software package according to the delivery requirement list to determine a first analysis result, and this first analysis result is used to determine whether the software package can be released.

[0080] Among them, the delivery risk analysis includes privacy compliance situation analysis, security compliance situation analysis, etc., and is used to identify the delivery risks existing in each requirement involved in the delivery requirement list.

[0081] In some embodiments, the server first obtains the delivery requirement list, and then performs a delivery risk analysis on each delivery requirement involved in the delivery requirement list to determine the first analysis result. That is to say, this first analysis result is determined by the server after analyzing each delivery requirement involved in the delivery requirement list. Exemplarily, the delivery requirement list involves delivery requirement 1, delivery requirement 2, and delivery requirement 3. After the server performs a delivery risk analysis on delivery requirement 1, delivery requirement 2, and delivery requirement 3 respectively, it is determined that the privacy and security issues in delivery requirement 1 and delivery requirement 2 are both compliant; while the privacy and security issues in delivery requirement 3 are non-compliant. At this time, the first analysis result determined by the server is that there is no delivery risk for delivery requirement 1 and delivery requirement 2, while there is a delivery risk for delivery requirement 3. Enterprise users or individual users can determine whether the software package can be released according to this first analysis result when obtaining this first analysis result.

[0082] It should be noted that when the server determines that there are delivery risks for some of the delivery requirements in the delivery requirements list, in actual applications, such delivery risks may not affect the normal use of the software product or there may be no violations of usage rules such as infringement of users' personal privacy data. Enterprise users or individual users may also allow the normal release of the software package product. Specifically, it can be considered according to the actual situation of the users themselves, and this embodiment does not limit it.

[0083] In some embodiments, when the delivery requirements list is inconsistent with the preset planned requirements list, the server first determines the list of differential requirements; then determines whether the delivery requirements list meets the preset conditions according to the list of differential requirements. Among them, the preset conditions include: the delivery requirements list includes each planned requirement in the planned requirements list and N first requirements, where the N first requirements are requirements not in the planned requirements list and N≥1. Exemplarily, if the preset planned requirements list, delivery requirements list 1, delivery requirements list 2, and delivery requirements list 3 are as shown in Table 4 below, it can be seen from the content shown in Table 4 that each delivery requirement involved in delivery requirements list 1 corresponds to the planned requirements in the planned requirements list. In this case, the delivery requirements list is consistent with the planned requirements list; each delivery requirement involved in delivery requirements list 2 has a corresponding planned requirement in the planned requirements list. In this case, although the delivery requirements list is inconsistent with the planned requirements list (delivery requirements list 2 also includes 1 first requirement, i.e., delivery requirement 5), there is no omission of planned requirements in the delivery requirements list. At this time, the delivery requirements list meets the preset conditions; while in delivery requirements list 3, there is no corresponding delivery requirement for planned requirement 3. In this case, the delivery requirements list is inconsistent with the planned requirements list, and there is an omission of planned requirements in the delivery requirements list. At this time, the delivery requirements list does not meet the preset conditions.

[0084] Table 4

[0085] Serial Number List of Planning Requirements List of Delivery Requirements 1 List of Delivery Requirements 2 List of Delivery Requirements 3 1 Planning Requirement 1 Delivery Requirement 1 Delivery Requirement 1 Delivery Requirement 1 2 Planning Requirement 2 Delivery Requirement 2 Delivery Requirement 2 Delivery Requirement 2 3 Planning Requirement 3 Delivery Requirement 3 Delivery Requirement 3 / 4 Planning Requirement 4 Delivery Requirement 4 Delivery Requirement 4 Delivery Requirement 4 5 / / Delivery Requirement 5 /

[0086] In one implementation of this embodiment, the server compares the delivery requirement list with a preset planned requirement list to determine the list of differential requirements formed by the two. It should be noted that, as shown in Table 4 above, the differential requirements in the list of differential requirements may come from the planned requirement list (the list of differential requirements obtained by comparing the planned requirement list with Delivery Requirement List 3), or may come from the delivery requirement list (the list of differential requirements obtained by comparing the planned requirement list with Delivery Requirement List 2). When the list of differential requirements includes differential requirements from the planned requirement list, it indicates that there are omissions in the planned requirements in the delivery requirement list, that is, there is no corresponding delivery item in the delivery requirement list for a certain planned requirement in the planned requirement list; when the list of differential requirements includes differential requirements from the delivery requirement list, it indicates that there are no omissions in the planned requirements in the delivery requirement list, that is, there is a corresponding delivery item in the delivery requirement list for each planned requirement in the planned requirement list, and the delivery requirement list may also include additional other delivery requirements.

[0087] In this embodiment, when the server determines the first analysis result, it includes determining the security compliance status of each delivery requirement among the N first requirements; and determining the privacy compliance status of each delivery requirement among the N first requirements. Among them, the security compliance analysis refers to analyzing and evaluating the security and compliance of software requirements during the software development process. This helps to ensure that the software meets both functional requirements and security and compliance requirements, reduces the security risks faced by the software system, and improves software quality. For example, the legality of data collection, the security of data processing, and whether compliance records are established, etc. The privacy compliance analysis includes performing a compliance analysis on the enterprise's data processing activities to ensure that the enterprise complies with relevant privacy laws and policies during the process of collecting, storing, processing, and transmitting personal data. For example, identifying security compliance requirements, analyzing the compliance of requirements, analyzing the security of requirements, and evaluating the implementation difficulty of requirements, etc.

[0088] In the method for determining the risk of a software package provided in this embodiment, the server determines the delivery requirement list involved in the software package by means of reverse tracing of the code submission records involved in the software package. Then, based on the involved delivery requirement list, privacy, security and other delivery risk analyses are carried out to determine the first analysis result, which is used to determine the release status of the software package. At the same time, it can also judge whether there are problems such as omissions in the delivery requirements. Compared with the traditional method of performing forward analysis with the planned requirement list to determine the analysis result, the method provided in this embodiment can avoid the problem that the software package to be released may introduce privacy compliance and security vulnerability risks.

[0089] The following combines Figure 1 the system shown and Figure 2The various functional units included in the server shown will exemplarily illustrate the method for determining software package risks provided in the embodiments of the present application based on three different stages during the project operation process. This method involves that enterprise user A needs to develop a software product x-app, and enterprise user A uses the project management capabilities provided by the public cloud to track the project operation process of the first iterative delivery of the software product x-app. Among them, the planning requirements to be delivered in the first iteration are functions with three features: "collecting user location", "user authentication", and "pushing activity information". The next iteration will deliver the function of "purchasing (renewing) VIP membership". Delivery requirements that are not within the scope of this iteration are requirements that have been accidentally merged in and are not allowed to be released.

[0090] (I) Version starting stage

[0091] In this embodiment, the version starting stage includes three stages: configuring code submission specifications in the code repository, creating a project collaboration plan, and analyzing risk features such as requirement privacy and security.

[0092] (a) The server configures code submission specifications in the code repository according to user operations.

[0093] Among them, the code submission specification can also be called a code submission access control, which is used to indicate the submission rules for the code description information submitted to the code repository.

[0094] When a developer submits code description information to the code repository of the server through a user device, if the code description information meets the preset code submission specifications, it is allowed to be submitted to the code repository; if the code description information does not meet the preset code submission specifications, it is not allowed to be submitted to the code repository.

[0095] In some embodiments, the server sets the code submission specifications in the following manner based on the user's operations on the user device side. After the user device responds to the user's sequential clicks on the selection controls of "code repository address - settings - submission rule settings" on the corresponding client or web interface of the public cloud, the display interface 401 as shown is displayed on the user device side. Figure 4 The display interface 401 includes display contents such as rule name, branch rule, and submission rule (commit rule). Among them, each display content corresponds to an input box or content option for that display content. For example, an input box for entering the rule name is displayed under the display content of the rule name; a content option for selecting the corresponding code repository branch is displayed under the display content of the branch rule; under the display content of the submission rule, the submission information associated with the submission rule and the corresponding input box, the submitter and the corresponding input box, and the submitter's email address and the corresponding input box are displayed, etc. It should be noted that the display interface 401 may include more or fewer display contents, which can be specifically configured according to actual usage requirements, and this embodiment does not make any restrictions.

[0096] The server determines the code submission specification based on the input information in the input boxes associated with each display content by the user, and / or the option information determined by the user's selection operation on the content options.

[0097] Exemplarily, if the user enters the regular expression of "\[TicketNo:\].[a-zA-z0-9]{1,}\W\[Description:\][\s\S]*\W\[Binary\WSource:\].*" in the input box corresponding to the submission information under the display content associated with the submission rule, the code description information submitted to the code repository must conform to the constraint format of the above regular expression to be incorporated. That is, the code submission rule requires that the code description information submitted must include the following three parts:

[0098] [TicketNo:]: The requirement order number composed of letters and numbers;

[0099] [Description:]: The requirement description information;

[0100] [Binary Source:]: The binary source code information.

[0101] (b) The server creates a project collaboration plan according to the user operation.

[0102] In some embodiments, the server responds to the user's operation on the user device side, creates a project collaboration plan in the project management page, and determines the relevant information of the current iteration version. Exemplarily, the relevant content of the project collaboration plan includes but is not limited to that shown in Table 5 below. The server creates a project collaboration plan according to the user's input of various contents such as the code repository branch and the starting point information in the corresponding input box or content option in the project management page. See Figure 5 as shown in.

[0103] Table 5

[0104] Information Name Information Value Iteration Name App0001 Code Repository Address https: / / codehub.com / A / x-app.git Development Branch master Release Branch master Starting Code Commit Point aeb05354123dd Code Path / service / x-app

[0105] Among them, "associated code repository" refers to the code repository used by the project. "Development branch" refers to the branch in the code repository used for development. "Release branch" refers to the branch used to store the released code, that is, the code of this branch is used for the final delivery build and packaging. "Starting Tag": refers to the latest commit point in the code repository at the start of the project. "Code path": refers to the location of the root directory of the project in the code repository.

[0106] (c) The server performs risk characteristic analysis such as privacy and security on the requirement planning list.

[0107] In this embodiment, the planning requirements to be delivered in the first iteration of the software product x-app developed by enterprise user A are: "Collect user location", "User authentication", and "Push activity information". Among them, each planning requirement has a corresponding requirement order number. Exemplarily, as shown in Table 6 below, the requirement order number corresponding to planning requirement 1 is AR00000001, and the requirement description is "Collect user location"; the requirement order number corresponding to planning requirement 2 is AR00000002, and the requirement description is "User authentication"; the requirement order number corresponding to planning requirement 3 is AR00000003, and the requirement description is "Information push".

[0108] Table 6

[0109] Requirement Order Number Requirement Description AR00000001 Collect User Location AR00000002 User Authentication AR00000003 Information Push

[0110] The user uploads the list of planning requirements to be delivered in the first iteration of the software product x-app to the requirement management module of the server in the format corresponding to the requirement description according to the above requirement order numbers through the user device. The requirement management module analyzes each planning requirement and tags each planning requirement to distinguish whether the planning requirement involves features such as privacy and security. Specifically, see Table 7 below.

[0111] Table 7

[0112] Requirement Order Number Requirement Description Whether User Privacy is Involved Whether There is a Security Risk Analysis of Other DFX Items AR00000001 Collect User Location Yes No AR00000002 User Authentication Yes Yes AR00000003 Information Push No No

[0113] In this embodiment, the DFX feature analysis is mainly the privacy and security feature analysis. Optionally, it also includes feature analysis in aspects such as injection resilience and testing. This embodiment does not limit this.

[0114] The above is the three processes that the server needs to execute according to the user operation in the initial stage of the version, namely, configuring the code submission specification in the code repository, creating a project collaboration plan, and analyzing risk features such as requirement privacy and security. It should be noted that when the server executes these three processes according to the user operation, there is no sequence, and they can be processed in parallel.

[0115] (2) Version R & D stage

[0116] In the version R & D stage, the technical architect SE makes a fine-grained division of each requirement in the planning requirement list to obtain their corresponding fine-grained requirements, such as sub-requirement 1, sub-requirement 2, sub-requirement 3, and sub-requirement 4, and hands over the fine-grained requirements sub-requirement 1, sub-requirement 2, sub-requirement 3, and sub-requirement 4 to the corresponding development responsible persons A, B, and C for their respective developments. Specifically, see Table 8 below.

[0117] Table 8

[0118] Requirement Order Number Requirement Description Fine-grained Requirements Development Responsible Person AR00000001 Collect User Location Sub-requirement 1 A AR00000002 User Authentication Sub-requirement 2, Sub-requirement 3 B AR00000003 Information Push Sub-requirement 4 C

[0119] In the initial stage of the version, during the process of creating a project collaboration plan, the configuration of the development branch used for code development in the code repository has been completed. Therefore, developers A, B, and C are responsible for developing the code required for the planned requirements they are in charge of at the development branch position of the configured code repository.

[0120] After developers A, B, and C complete the code development required for the planned requirements they are responsible for in the development branch of the code repository, they need to submit the code description information corresponding to the code to the code repository according to the code submission specifications. At this time, the code repository will automatically record the code description information submitted by the developers and generate a code submission record.

[0121] Exemplarily, refer to Figure 6 As shown in, the code description information submitted by developer A is as follows:

[0122] [TicketNo:]AR00000001

[0123] [Description:] Submit code for collecting user location

[0124] [Binary Source:]NA

[0125] The code description information submitted by developer B is as follows:

[0126] [TicketNo:]AR00000002

[0127] [Description:] Add code for user authentication function

[0128] [Binary Source:]NA

[0129] The code description information submitted by developer C is as follows:

[0130] [TicketNo:]AR00000003

[0131] [Description:] Submit code for pushing activity information

[0132] [Binary Source:]NA

[0133] When the server incorporates the code into the code repository according to the code description information submitted by the developers in charge, due to factors such as improper resolution of code conflicts, lax manual control, or code submission errors, there may be a situation of incorrect code incorporation. Exemplarily, when the server incorporates the code, while incorporating the code submitted by developers A, B, and C, it also incorrectly incorporates the code submitted by D. For example, the code description information submitted by D is as follows:

[0134] [Ticket No:]AR00000004

[0135] [Description:]Submit the code for the function of purchasing (renewing) VIP membership

[0136] [Binary Source:]NA

[0137] (3) Version release stage

[0138] In this embodiment, the version release stage includes five core steps: software package construction, code traceability, delivery requirement extraction, requirement differentiation analysis, and releasability assessment.

[0139] (a) Software package construction

[0140] In some embodiments, the CI construction module in the server constructs the full amount of code at the code repository branch location according to the code repository address and the code repository branch location in the project collaboration plan created in the initial version stage, that is, packages the last code commit point of the code repository and all the code description information submitted before the last code commit point. Exemplarily, as shown in Table 5, the server constructs a software package based on the master branch of the code repository at https: / / codehub.com / A / x-app.git. The last code commit point of the code repository is "af621dfc549e". The server packages the last code commit point "af621dfc549e" in the code repository and all the code description information submitted before the last code commit point "af621dfc549e" according to the code repository address and the code repository branch to construct a software package. After the CI construction module completes the construction of the software package, it submits the software package to the project management module.

[0141] (b) Code traceability

[0142] In some embodiments, the project management module in the server queries the starting code commit point when the version plan is created from the project collaboration plan, and determines the last code commit point from the constructed software package; then queries the code commit records between the starting code commit point (excluding) and the last code commit point (including) from the code repository. Exemplarily, in combination with Figure 6As shown in the figure, the server queries the starting code submission point as "aeb05354123dd" from the project collaboration plan, determines the last code submission point as "af621dfc549e" from the built software package. There are a total of 4 code submission records between the starting code submission point and the last code submission point in the code repository, and their corresponding commit-ids are "767873a864d", "ce703806aa5a", "209c1487d3b", and "af621dfc549e".

[0143] (c) Delivery requirement extraction

[0144] After the project management module in the server obtains the code submission records, based on the code submission specifications configured in the initial stage of the version, each code submission record includes the requirement order number corresponding to the code. Therefore, the server can extract the requirement order numbers associated with each code submission record from the 4 code submission records, namely "AR00000001", "AR00000002", "AR00000003", and "AR00000004".

[0145] (d) Requirement differentiation analysis

[0146] The project management module in the server generates a delivery requirement list based on the requirement order numbers extracted in the delivery requirement extraction step, and compares it with the requirement order numbers in the planned requirement list to generate a list of differential requirements, as shown in Table 9 below.

[0147] Table 9

[0148] List of Planning Requirements List of Delivery Requirements AR00000001 AR00000001 AR00000002 AR00000002 AR00000003 AR00000003 AR00000004

[0149] After comparison, the project management module in the server determines that all the planned requirements in the preset planned requirements have been delivered, but "AR00000004" is a newly introduced requirement that is not within the scope of this iteration. In this case, although the delivered requirement list is inconsistent with the planned requirement list (the delivered requirement list also includes AR00000004), that is, the delivered requirement list introduces a new first requirement that is not in the planned requirement list, the delivered requirement list meets the preset conditions. The project management module in the server performs delivery risk analysis such as privacy compliance analysis and security compliance analysis on the software package based on the newly added first requirement in the delivered requirement list, and determines the first analysis result. The first analysis result indicates that "AR00000004" introduces new privacy and security issues. The user can analyze and determine whether to release the software package for this iteration based on the first analysis result. The product manager views the requirement plan according to the requirement order number "AR00000004" and determines that the requirement of "AR00000004" is to "purchase (renew) VIP membership", which belongs to the content to be delivered in the next iteration. The product manager, privacy specialist, and security specialist finally determine that since "AR00000004" introduces new privacy and security issues and belongs to the content to be delivered in the next iteration, the product owner judges that the impact is significant and the "not allowed to release" process needs to be followed for rectification.

[0150] In this embodiment, the server reversely derives the delivered requirement list involved in the software package from the code submission record, and compares the delivered requirement list with the preset planned requirement list to evaluate the integrity of requirement delivery and judge issues such as whether requirements are omitted or multiple requirements are incorporated. Through the reverse derivation method, the delivery risk characteristics analysis such as privacy and security is re-analyzed to improve the accuracy of the analysis, so as to determine the release situation of the software package.

[0151] In summary, the method for determining the risk of a software package provided by the embodiments of the present application records the latest code submission point of the code and configures the code submission specification when the project is started. Before release, the code submission record during the R & D process is traced back reversely to obtain the requirement list involved in the code. Then, it is compared with the planned requirement list preset at the beginning of the version to obtain the differences between the delivered requirements and the planned requirements, assisting the product owner to re-analyze the requirement delivery integrity, privacy protection strategy, security protection, etc., and improving the accuracy.

[0152] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0153] The embodiments of the present application also provide a device for determining the risk of a software package. See Figure 7As shown, the device includes an acquisition unit 701, a generation unit 702, and a determination unit 703.

[0154] Among them, the acquisition unit 701 is used to acquire at least one code submission record associated with the software package, and each of the at least one code submission record is associated with a corresponding delivery requirement.

[0155] The generation unit 702 is used to generate a delivery requirement list associated with the software package according to the delivery requirements, and the delivery requirement list includes the delivery requirements associated with at least one code submission record.

[0156] The determination unit 703 is used to perform a delivery risk analysis on the software package according to the delivery requirement list to determine a first analysis result, and the first analysis result is used to determine whether the software package can be released.

[0157] An embodiment of the present application also provides a server, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to execute the method for determining the risk of a software package shown in each of the above embodiments.

[0158] An embodiment of the present application also provides a chip. Refer to Figure 8 As shown, the chip includes a processor and a memory. A computer program is stored in the memory, and when the computer program is executed by the processor, the method for determining the risk of a software package in each of the above embodiments is implemented.

[0159] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the method for determining the risk of a software package provided in each of the above embodiments is implemented.

[0160] An embodiment of the present application also provides a computer program product, which includes a computer program. When the computer program is run on a user device, the user device is enabled to implement the method for determining the risk of a software package provided in each of the above embodiments.

[0161] It should be understood that the processor mentioned in the embodiments of the present application may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0162] It should also be understood that the memory mentioned in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0163] In the embodiments provided in the present application, the division of each framework or module is only a logical function division. In actual implementation, there may be other division methods. For example, multiple frameworks or modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0164] In addition, in each embodiment of the present application, each functional module can be integrated into a processing module, or each module can exist physically alone, or two or more modules can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module.

[0165] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments, and will not be described herein again.

[0166] The reference to "one embodiment" or "some embodiments" in the description of the present application means that a specific feature, structure, or characteristic described in conjunction with the embodiment is included in one or more embodiments of the present application. Thus, the statements "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different parts of this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized in another way.

[0167] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of each embodiment of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for determining the risk of a software package, characterized in that, Including: Obtain at least one code commit record associated with the software package, and each of the at least one code commit records is associated with a corresponding delivery requirement; Generate a delivery requirement list associated with the software package according to the delivery requirement; Perform delivery risk analysis on the software package according to the delivery requirement list to determine a first analysis result, and the first analysis result is used to determine whether the software package can be released.

2. The method according to claim 1, wherein The performing delivery risk analysis on the software package according to the delivery requirement list to determine a first analysis result includes: When the delivery requirement list is inconsistent with a preset planned requirement list, determine a differential requirement list; Determine whether the delivery requirement list meets a preset condition according to the differential requirement list; When the delivery requirement list meets the preset condition, perform delivery risk analysis on the software package according to the delivery requirement list to determine the first analysis result.

3. The method according to claim 2, characterized in that The preset condition includes: The delivery requirement list includes each planned requirement in the planned requirement list and N first requirements, where the N first requirements are requirements not in the planned requirement list and N≥1.

4. The method according to claim 3, wherein The delivery risk analysis includes at least one of the following: Determine the security compliance of each delivery requirement among the N first requirements; Determine the privacy compliance of each delivery requirement among the N first requirements.

5. The method according to any one of claims 1 to 4, characterized in that, Each of the at least one code commit records meets a preset code commit specification, and the code commit specification includes: The code description information in the code commit record includes the requirement order number corresponding to the code, the submission description information, and the source code information.

6. The method according to claim 5, wherein The generating a delivery requirement list associated with the software package according to the delivery requirement includes: Obtain the requirement order number corresponding to the code from each of the code commit records; Determine the delivery requirement corresponding to each requirement order number; Generate a delivery requirement list associated with the software package according to the determined delivery requirements.

7. The method according to any one of claims 1 to 6, characterized in that Before obtaining at least one code commit record associated with the software package, the method further includes: Obtain a preset planned requirement list; Perform risk characteristic analysis on each planned requirement in the planned requirement list; When the planned requirement involves the corresponding risk in the risk characteristics, set a corresponding label for the planned requirement, and the label is used to identify whether the planned requirement involves the corresponding risk.

8. The method according to any one of claims 1 to 7, characterized in that Before obtaining at least one code commit record associated with the software package, the method further includes: Create a project collaboration plan for the software package, and the project collaboration plan includes at least one of the information name, iteration name, code repository address, code repository branch, starting code commit point, and code path of the software package.

9. The method according to claim 8, wherein The software package is constructed in the following manner: Obtain the code repository address and the code repository branch in the project collaboration plan; According to the code repository address and the code repository branch, package the full amount of code before constructing the software package to generate the software package.

10. The method according to claim 9, wherein The obtaining at least one code commit record associated with the software package includes: Determine the starting code commit point involved in the software package according to the project collaboration plan; Determine the last code commit point involved in the software package according to the constructed software package; Obtain at least one code commit record between the starting code commit point, excluding the starting code commit point, and the last code commit point.

11. A device for determining the risk of a software package, characterized in that, Including: An obtaining unit, configured to obtain at least one code commit record associated with the software package, and the at least one code commit record is associated with a corresponding delivery requirement; A generating unit, configured to generate a delivery requirement list associated with the software package according to the delivery requirement, and the delivery requirement list includes the delivery requirements associated with the at least one code commit record; A determining unit, configured to perform a delivery risk analysis on the software package according to the delivery requirement list, and determine a first analysis result, where the first analysis result is used to determine whether the software package can be released.

12. A server, characterized in that, Including a memory, a processor, and a computer program stored in the memory and executable on the processor, where when the processor executes the computer program, the method described in any one of claims 1 to 10 is implemented.

13. A management system, characterized in that, Including a server and at least one user device connected to the server, where the server is configured to execute the method described in any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of claims 1 to 10 is implemented.

15. A chip, characterized in that, The chip includes a processor and a memory, and a computer program is stored in the memory, and when the computer program is executed by the processor, the method described in any one of claims 1 to 10 is implemented.

Images