Method and apparatus for managing application code, and device and medium

Abstract

Provided are a method and apparatus for managing application code, and a device and a medium. In one method, a calling relationship of at least one code element in application code is determined; a data flow processed by the application code is obtained, wherein the data flow comprises at least one data item processed by the at least one code element; a risk path associated with the application code is determined, wherein the risk path indicates a calling path of a code element that causes a potential risk in an application; and the potential risk in the application code is determined on the basis of the calling relationship, the data flow, and the risk path. By applying some implementations of the present disclosure, the application code can be automatically analyzed and the calling relationship of the corresponding code element and the data flow processed by the application can be obtained. Further, the risk path can be used to specify an association between the code and the potential risk, thereby determining the potential risk in the code.

Description

Methods, apparatus, devices, and media for managing application code. Technical Field

[0001] Implementations of this disclosure generally relate to computer technology, and in particular to methods, apparatus, devices, and computer-readable storage media for managing application code. Background Technology

[0002] With the development of computer technology, various programming languages ​​can be used to write application code and implement applications with different functions. During the coding process, developers may introduce various risks. To ensure that the application achieves its intended functionality, it is necessary to examine the application code to identify potential risks. However, for different applications, experienced developers are required to perform the risk inspection process to identify and eliminate risks in the code of each application. This results in significant manpower and time costs. Therefore, there is a need for a more general and effective way to manage application code and identify risks within it. Summary of the Invention

[0003] In a first aspect of this disclosure, a method for managing application code is provided. In this method, call relationships of at least one code element in the application's code are determined. A data flow processed by the application's code is obtained, the data flow including at least one data item processed by the at least one code element. A risk path associated with the application's code is determined, the risk path indicating a call path of a code element that causes a potential risk in the application. Based on the call relationships, the data flow, and the risk path, potential risks in the application's code are determined.

[0004] In a second aspect of this disclosure, an apparatus for managing the code of an application is provided. The apparatus includes: a relationship determination module configured to determine call relationships of at least one code element in the application's code; an acquisition module configured to acquire a data stream processed by the application's code, the data stream including at least one data item processed by the at least one code element; a path determination module configured to determine risk paths associated with the application's code, the risk paths indicating call paths of code elements that cause potential risks in the application; and a risk determination module configured to determine potential risks in the application's code based on call relationships, data streams, and risk paths.

[0005] In a third aspect of this disclosure, an electronic device is provided. The electronic device includes: at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to a first aspect of this disclosure when executed by the at least one processor.

[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method according to a first aspect of this disclosure.

[0007] In a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method according to a first aspect of this disclosure.

[0008] It should be understood that the content described in this content section is not intended to limit the key or essential features of the implementation of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] In the following detailed description, the above and other features, advantages, and aspects of various implementations of this disclosure will become more apparent, taken in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0010] Figure 1 shows a block diagram of an application environment according to one implementation of the present disclosure;

[0011] Figure 2 shows a block diagram of code for managing an application according to some implementations of this disclosure;

[0012] Figure 3 shows a block diagram for determining the calling relationships between various code elements in the code according to some implementations of this disclosure;

[0013] Figure 4 shows a block diagram illustrating the mapping between code features and risks based on some implementations of this disclosure;

[0014] Figure 5 shows a block diagram for determining risks in code according to some implementations of this disclosure;

[0015] Figure 6 shows a flowchart of a method for managing application code according to some implementations of this disclosure;

[0016] Figure 7 shows a block diagram of an apparatus for managing application code according to some implementations of this disclosure; and

[0017] Figure 8 shows a block diagram of a device capable of implementing various implementations of the present disclosure. Detailed Implementation

[0018] Implementations of this disclosure will now be described in more detail with reference to the accompanying drawings. While some implementations of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the implementations set forth herein. Rather, these implementations are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and implementations of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0019] In the description of the implementation methods disclosed herein, the term "comprising" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one implementation" or "the implementation" should be understood as "at least one implementation". The term "some implementations" should be understood as "at least some implementations". Other explicit and implicit definitions may also be included below. As used herein, the term "model" can represent the relationships between various data. For example, the aforementioned relationships can be obtained based on various currently known and / or future-developed technical solutions.

[0020] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0021] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure through appropriate means in accordance with relevant laws and regulations, and user authorization should be obtained.

[0022] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0023] As an optional but non-restrictive implementation, in response to a user's active request, a prompt message can be sent to the user, for example, via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose whether to "agree" or "disagree" to provide personal information to the electronic device.

[0024] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0025] The term "in response to" as used herein refers to a state in which a corresponding event occurs or a condition is satisfied. It will be understood that the timing of subsequent actions performed in response to such event or condition is not necessarily strongly correlated with the time when the event occurs or the condition is met. For example, in some cases, subsequent actions may be performed immediately upon the occurrence of the event or the fulfillment of the condition; while in others, they may be performed some time after the occurrence of the event or the fulfillment of the condition.

[0026] Example Environment

[0027] With the development of computer technology, various programming languages ​​can be used to write application code and implement applications with different functions. During the code writing process, various risks may be introduced. Referring to Figure 1, which describes an application environment according to some implementations of this disclosure, Figure 1 shows a block diagram 100 of an application environment according to one implementation of this disclosure. As shown in Figure 1, the code 120 of application 110 can be written using various programming languages. Code 120 may include multiple code elements, and code elements may include one or more static code elements 130 and / or one or more dynamic code elements 132.

[0028] During development, to ensure clean code and minimize modifications, different business functions within an application may use the same code. Some business functions can be dynamically abstracted into configurations, which can be passed in from outside the application during execution to achieve code reuse. However, this dynamic approach can lead to significant data security risks. Theoretically, various variable data and multiple variable logical functions can be transmitted and executed within the same data processing channel. For example, during data processing, the data source, data processor, and data destination may not meet data security requirements, resulting in data security risks. For instance, a call to code element 132 might lead to risk 140.

[0029] To ensure an application functions as intended, its code needs to be examined to identify potential risks. However, for different applications, highly experienced developers are required to perform the risk review process to identify and eliminate risks in the code for each application. This results in significant manpower and time costs. Therefore, there is a need for a more general and effective way to manage application code and identify risks within it.

[0030] Overview of code management

[0031] To at least partially address the shortcomings of the prior art, a method for managing application code is proposed according to one implementation of this disclosure. Referring to Figure 2, which describes an overview of one implementation of this disclosure, Figure 2 shows a block diagram 200 for managing application code according to some implementations of this disclosure. As shown in Figure 2, a method for managing application code is provided. Specifically, the call relationships 210 of at least one code element 130, ..., and 132 in the application code 120 can be determined. Here, code elements can represent various programming elements in the code. Code elements can be determined at different granularities; for example, code elements can include, but are not limited to, functions, procedures, code segments, statements, etc.

[0032] A data stream 220 processed by the application's code can be acquired. This data stream 220 may include at least one data item processed by at least one code element. Here, a data stream refers to data items passed between functional units defined by various code elements within the application during its execution. For example, in a media application, data items may include data items related to objects in the media application (e.g., users), video-related data items, and other data items used to support data transmission within the media application, etc. Risk paths associated with the application's code can be determined. Risk path 230 indicates the call path of code elements that cause potential risks 240 in the application. Furthermore, potential risks 240 in the application's code 120 can be determined based on call relationships 210, data stream 220, and risk path 230.

[0033] Using some implementations of this disclosure, application code can be automatically analyzed to obtain the call relationships of corresponding code elements and the data flow processed by the application. Furthermore, risk paths can be used to specify the association between code and potential risks, thereby identifying potential risks in the code. In this way, it is not necessary to perform a dedicated risk analysis process for each application; instead, potential risks in the code of different applications can be identified in a more general manner.

[0034] Detailed process of code management

[0035] Having described an overview of some implementations of this disclosure, further details regarding methods for managing application code will be described below. According to some implementations of this disclosure, the calling relationships of at least one code element in the application's code can be determined. See Figure 3 for further details, which illustrates a block diagram 300 for determining the calling relationships between various code elements according to some implementations of this disclosure. As shown in Figure 3, code 120 may include multiple code elements. Taking only functions as examples of code elements, code 120 may include functions 310, 320, 330, ..., and 340. Function 310 may call functions 320, ..., and 340, and function 320 may further call function 330.

[0036] It should be understood that code 120 in Figure 3 is merely illustrative. Code 120 may include a single file, or alternatively and / or additionally, code 120 may include multiple files located in different locations, in which case code 120 can be stored in a distributed manner. When code 120 includes multiple files, the calling relationships can further indicate the location of each code element within its respective file.

[0037] According to some implementations of this disclosure, a data stream 220 processed by the application's code can be acquired. The data stream 220 includes at least one data item processed by at least one code element. It should be understood that since the application's code may include dynamic statements, and the actual content of these dynamic statements can only be determined during application runtime, the data stream here includes data items actually processed by various code elements within the application during application runtime. Specifically, during the acquisition of the data stream, the application's code can be compiled to generate an intermediate representation (IR).

[0038] Here, intermediate representation refers to an intermediate representation obtained from source code in a compiler or interpreter. This intermediate representation is a format between the source code and the final machine code; it is closer to machine code but also platform-independent. Intermediate representation allows the compiler to perform optimizations and transformations at different stages without needing to redesign these stages for each source language or target platform. Furthermore, this intermediate representation can be run to determine the data items processed by individual code elements. Tagned input data can be provided to the running application; during application execution, the tagged input data can be tracked to obtain the data flow.

[0039] Specifically, taint data analysis can be used to determine data flow. Tainted data typically refers to external input data received by an application, which can be stored as temporary data or in files. When the application needs to use this data, it generally accesses and processes the data through functions or system calls. In taint data analysis, input data from external sources is marked as tainted data. Taint data analysis can be performed during application runtime, tracing the flow of tainted data within the application. By tracing the flow of tainted data, the propagation path of data within the application can be discovered, thereby identifying potential security risks. Using some implementations of this disclosure, by acquiring the data flow processed by the application in real time during runtime, it is possible to detect in real time whether there are security risks in data processed by dynamic statements.

[0040] According to some implementations of this disclosure, risk paths associated with application code can be identified, indicating call paths of code elements that may cause potential risks in the application. Specifically, it can be determined whether the code includes predetermined risk characteristics, which can represent features in the code that may cause potential risks. For example, risk characteristics may include dynamic statements, and dynamic statements may include dynamic query statements or dynamic scripts. Here, dynamic query statements may, for example, include Dynamic Structured Query Language (SQL), and dynamic scripts may include scripts of any format supported by the programming language of the code.

[0041] It should be understood that the specific content of dynamic statements can only be determined when the application is run, thus determining whether a risk exists. Therefore, a static approach cannot detect potential risks in the code. By utilizing some implementations of this disclosure, potential risks in the code can be detected more accurately by running the application and examining dynamic query statements and / or dynamic scripts.

[0042] According to some implementations of this disclosure, in response to determining that the code includes predetermined risk characteristics, risk elements corresponding to the risk characteristics are identified in the code based on the risk characteristics and the type of programming language used by the code. These risk elements can cause potential risks in the application. Subsequently, the risk path can be determined based on the call path of the risk element in the code. It should be understood that the code can be written using different types of programming languages. The type of programming language used by the code can be determined first, and then it can be determined whether the code includes risk elements corresponding to the risk characteristics. For example, in the Go language, the dynamic statement `Exec()` can be used to dynamically call external statements. In this case, `Exec()` may cause potential risks in the application; therefore, `Exec()` is a risk element. Further, `Exec()` can be searched in the code to determine the call path of `Exec()`.

[0043] See Figure 4 for further details, which illustrates a block diagram 400 for establishing a mapping between code features and risk features according to some implementations of this disclosure. As shown in Figure 4, risk features that may cause risk can be taken as input to determine the corresponding rule output. Specifically, at block 410, risk features (e.g., the execution risk of dynamic SQL) can be input to determine abstract rules. Specifically, dynamic SQL can be received, which can perform different tasks and make these tasks difficult to detect and control. For example, dynamic SQL can access different fields in different databases and lead to the risk of unauthorized access to certain fields. In this case, the abstract rule can specify that such dynamic SQL needs to be monitored.

[0044] At box 420, the code characteristics corresponding to the risk features can be identified; that is, the specific code elements that conform to dynamic SQL can be identified from the code. Specifically, different programming languages ​​may have different dynamic execution capabilities. In this case, it is necessary to determine the specific statements with dynamic execution capabilities based on the specific type and abstraction rules of the programming language. For example, in Go, a mapping relationship can be established between dynamic SQL and `Exec()`.

[0045] At box 430, a risk rule, also known as a risk path, can be defined for detecting risks and can indicate the call path of code elements that cause potential risks in the application. According to some implementations of this disclosure, in determining a risk path based on the call path of a risk element in the code, the starting point of the risk path can be determined based on the starting point of the call path. Here, the starting point of the call path represents the initial entry point of the risk element, such as a Remote Procedure Call (RPC) entry point or a Hypertext Transfer Protocol (HTTP) entry point. Furthermore, the ending point of the risk path can be determined based on the risk element. Specifically, the ending point of the risk path can be represented as Exec().

[0046] At box 440, the final rule can be output, which can include: the starting point, the propagation parameters of the risk path, and the ending point. Specifically, the propagation parameters of the risk path can be determined based on the parameters of the code elements in the call path. Continuing the example above, it can be determined whether the parameters of the code elements in the call path match the predetermined parameters of concern. Here, the parameters of concern can be pre-specified parameters that may cause data security risks, i.e., parameters that are expected to be protected. For example, the parameters of concern can be parsed from the programming specification, specified from the code security specification, or manually specified.

[0047] In determining the propagation parameters of a risk path, in response to determining that the parameters of a code element in the call path match predetermined parameters of concern, the propagation parameters of the risk path can be determined based on these parameters of concern. Specifically, assuming that the parameters of a code element in the call path include Parameter1, and Parameter1 is a parameter of concern, then Parameter1 can be determined as the propagation parameter of the risk path. In this case, the output rule can be represented as: RPC / HTTP, Parameter1, Exec(), which represents the risk path used to detect risks in the code.

[0048] It should be understood that only one parameter of interest is illustrated herein. Alternatively and / or additionally, one or more parameters of interest may exist, such as Parameter2, Parameter3, etc. Furthermore, although the above example using Go as the programming language illustrates the process of identifying risk elements, code written in other languages ​​can be processed in a similar manner to determine corresponding risk paths.

[0049] According to some implementations of this disclosure, potential risks in application code can be determined based on call relationships, data flow, and risk paths. Specifically, the entry point in the code that causes a potential risk can be determined based on the call relationships and the starting point of the risk path. Continuing the example above, the entry point in the code that causes a potential risk can be determined to be RPC / HTTP. Further, the risk data portion in the data flow located after the entry point can be determined, that is, the RPC / HTTP parameters at the code point of that entry point can be determined. Subsequently, the potential risk can be determined based on the risk data portion and propagation parameters. Specifically, assuming that the parameter of concern Parameter1 exists in the RPC / HTTP parameters, it can be determined that a risk exists; otherwise, it can be determined that no risk exists.

[0050] According to some implementations of this disclosure, risk reports can be provided. For example, a risk report may include at least one of the following: a description of the risk, the starting point of the risk, and the ending point of the risk, etc. For example, Table 1 shows an example of a risk report. Furthermore, based on detected potential risks, application code can be optimized to reduce the risk of data breaches.

[0051] Table 1 Example of a risk report

[0052] The various steps in some implementations of this disclosure have been described. Below, with reference to Figure 5, a complete process for managing code is described. Figure 5 shows a block diagram 500 for determining risks in code according to some implementations of this disclosure. As shown in Figure 5, the methods described above can be performed using a code analysis module 520, a feature analysis module 530, and a risk analysis module 540. The method may begin at box 510. At box 511, the application's source code can be compiled, and at box 512, an intermediate representation can be generated.

[0053] Furthermore, the code analysis module 520 can parse the individual code elements in the code and determine the call relationships 521 between them. It should be understood that although Figure 5 shows the call relationships determined from the intermediate representation 512, alternatively and / or additionally, the call relationships can be determined directly from the source code. The control flow 522 (used to control the order of calls between individual code elements in the code) can be determined based on the call relationships 521. Further, the data flow 523 processed by each code element in the application can be determined, thereby determining the corresponding modeling information 524. Here, the modeling information 524 represents data items in the data flow, where the specific business meaning of each data item is unknown.

[0054] In a subsequent stage, the feature analysis module 530 can establish a mapping between data items and the business data to be detected, that is, identify data items that are expected to be protected and may involve security risks. Specifically, it can identify risk characteristics 531 (e.g., dynamic SQL) and corresponding code characteristics 532 (e.g., Exec() in Go). Furthermore, it can identify technical facts 533 during application execution, thereby generating corresponding risk rules 534 (e.g., RPC / HTTP, Parameter1, Exec()).

[0055] Subsequently, the risk analysis module 540 can generate a risk report 550 based on the output of the feature analysis module 530. Specifically, the risk analysis module 540 can receive risk rules 534, as well as control flow 522 and data flow 523, as the data source 541 to be analyzed. It can determine the risk points to be analyzed 542 (e.g., Exec()), construct an analysis engine 544 based on the data detected at box 543, and then perform risk analysis 545. Post-processing 546 can be performed, for example, specifying the content and format of the risk report, and generating the risk report 550. In response to determining that a risk exists in the code, the code can be optimized and the risk eliminated at box 551, and the method ends at box 552.

[0056] According to some implementations of this disclosure, different applications can be handled in a general manner. Specifically, the code analysis module 520 can determine the relevant control flow and data flow of each application, and then perform subsequent risk detection. Using some implementations of this disclosure, the application's code can be automatically analyzed and the call relationships of corresponding code elements and the data flow processed by the application can be obtained. Furthermore, risk paths can be used to specify the association between code and potential risks, thereby identifying potential risks in the code. In this way, it is not necessary to perform a dedicated risk analysis process for each application, but rather to identify potential risks in the code of different applications in a more general way.

[0057] Example process

[0058] Figure 6 illustrates a flowchart of a method 600 for managing application code according to some implementations of this disclosure. At box 610, the call relationships of at least one code element in the application's code are determined. At box 620, a data flow processed by the application's code is obtained, the data flow including at least one data item processed by at least one code element. At box 630, risk paths associated with the application's code are determined, the risk paths indicating call paths of code elements that cause potential risks in the application. At box 640, potential risks in the application's code are determined based on the call relationships, data flows, and risk paths.

[0059] According to some implementations of this disclosure, determining the risk path associated with the application's code includes: in response to determining that the code includes a predetermined risk feature, determining risk elements in the code corresponding to the risk feature based on the risk feature and the type of programming language used by the code, the risk elements causing potential risks in the application; and determining the risk path based on the call path of the risk element in the code.

[0060] According to some implementations of this disclosure, risk characteristics include dynamic statements, which include dynamic query statements or dynamic scripts.

[0061] According to some implementations of this disclosure, determining the risk path based on the call path of the risk element in the code includes: determining the starting point of the risk path based on the starting point of the call path; determining the propagation parameters of the risk path based on the parameters of the code elements in the call path; and determining the ending point of the risk path based on the risk element.

[0062] According to some implementations of this disclosure, determining the propagation parameters of a risk path includes: in response to determining that the parameters of a code element in the call path match predetermined concerns, determining the propagation parameters of the risk path based on the concerns.

[0063] According to some implementations of this disclosure, determining potential risks in an application's code based on call relationships, data flow, and risk paths includes: determining the entry point in the code that causes potential risks based on the start point of the call relationships and risk paths; determining the risk data portion in the data flow located after the entry point; and determining potential risks based on the risk data portion and propagation parameters.

[0064] According to some implementations of this disclosure, acquiring a data stream includes: providing the application with labeled input data; and tracking the labeled input data during the operation of the application in order to acquire the data stream.

[0065] Example devices and equipment

[0066] Figure 7 shows a block diagram of an apparatus 700 for managing application code according to some implementations of the present disclosure. The apparatus 700 includes: a relationship determination module 710 configured to determine call relationships of at least one code element in the application's code; an acquisition module 720 configured to acquire a data stream processed by the application's code, the data stream including at least one data item processed by at least one code element; a path determination module 730 configured to determine risk paths associated with the application's code, the risk paths indicating call paths of code elements that cause potential risks in the application; and a risk determination module 740 configured to determine potential risks in the application's code based on call relationships, data streams, and risk paths.

[0067] According to some implementations of this disclosure, the path determination module 730 is further configured to: in response to determining that the code includes predetermined risk characteristics, determine risk elements in the code corresponding to the risk characteristics, the risk elements causing potential risks in the application, based on the risk characteristics and the type of programming language used in the code; and determine risk paths based on the call paths of the risk elements in the code.

[0068] According to some implementations of this disclosure, risk characteristics include dynamic statements, which include dynamic query statements or dynamic scripts.

[0069] According to some implementations of this disclosure, the path determination module 730 is further configured to: determine the starting point of the risk path based on the starting point of the call path; determine the propagation parameters of the risk path based on the parameters of the code elements in the call path; and determine the ending point of the risk path based on the risk elements.

[0070] According to some implementations of this disclosure, the path determination module 730 is further configured to: determine the propagation parameters of the risk path based on the parameters of the determined code element in the call path, in response to determining that the parameters of the determined code element match the predetermined parameters of concern.

[0071] According to some implementations of this disclosure, the risk determination module 740 is further configured to: determine the entry point in the code that causes a potential risk based on the call relationship and the starting point of the risk path; determine the risk data portion in the data stream located after the entry point; and determine the potential risk based on the risk data portion and propagation parameters.

[0072] According to some implementations of this disclosure, the acquisition module 720 is further configured to: provide tagged input data to the application; and during the operation of the application, track the tagged input data in order to acquire a data stream.

[0073] Figure 8 shows a block diagram of a device 800 capable of implementing various implementations of the present disclosure. It should be understood that the computing device 800 shown in Figure 8 is merely exemplary and should not constitute any limitation on the functionality and scope of the implementations described herein. The computing device 800 shown in Figure 8 can be used to implement the methods described above.

[0074] As shown in Figure 8, the computing device 800 is in the form of a general-purpose computing device. Components of the computing device 800 may include, but are not limited to, one or more processors 810, memory 820, storage devices 830, one or more communication units 840, one or more input devices 850, and one or more output devices 860. The processor 810 may be a physical or virtual processor and is capable of performing various processes based on programs stored in memory 820. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of the computing device 800.

[0075] Computing device 800 typically includes multiple computer storage media. Such media can be any available media accessible to computing device 800, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 820 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 830 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data (e.g., training data for training) and can be accessed within computing device 800.

[0076] The computing device 800 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG8, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks may be provided. In these cases, each drive may be connected to a bus (not shown) via one or more data media interfaces. The memory 820 may include a computer program product 825 having one or more program modules configured to perform various methods or actions of various implementations of the present disclosure.

[0077] The communication unit 840 enables communication with other computing devices via a communication medium. Additionally, the components of the computing device 800 can function as a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the computing device 800 can operate in a networked environment using logical connections to one or more other servers, networked personal computers (PCs), or another network node.

[0078] Input device 850 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 860 can be one or more output devices, such as a monitor, speaker, printer, etc. Computing device 800 can also communicate as needed with one or more external devices (not shown) via communication unit 840. These external devices, such as storage devices, display devices, etc., can communicate with one or more devices that enable user interaction with computing device 800, or with any device (e.g., network card, modem, etc.) that enables computing device 800 to communicate with one or more other computing devices. Such communication can be performed via input / output (I / O) interfaces (not shown).

[0079] According to an implementation of this disclosure, a computer-readable storage medium is provided, on which computer-executable instructions are stored, wherein the computer-executable instructions are executed by a processor to implement the method described above. According to an implementation of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the method described above. According to an implementation of this disclosure, a computer program product is provided, on which a computer program is stored, which, when executed by a processor, implements the method described above.

[0080] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0081] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0082] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

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

[0084] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for managing application code, comprising: Determine the call relationship of at least one code element in the application's code; Obtain a data stream processed by the code of the application, the data stream including at least one data item processed by the at least one code element; Identify risk paths associated with the code of the application, the risk paths indicating the call paths of code elements that cause potential risks in the application; as well as Based on the call relationships, the data flow, and the risk paths, the potential risks in the application's code are determined.

2. The method of claim 1, wherein determining the risk path associated with the code of the application comprises: In response to determining that the code includes predetermined risk characteristics, risk elements corresponding to the risk characteristics are determined in the code based on the risk characteristics and the type of programming language used by the code, the risk elements causing the potential risks in the application; as well as The risk path is determined based on the call path of the risk element in the code.

3. The method according to claim 2, wherein the risk feature includes dynamic statements, and the dynamic statements include dynamic query statements or dynamic scripts.

4. The method of claim 2, wherein determining the risk path based on the call path of the risk element in the code comprises: Based on the starting point of the call path, determine the starting point of the risk path; Based on the parameters of the code elements in the call path, determine the propagation parameters of the risk path; as well as Based on the risk elements, the endpoint of the risk path is determined.

5. The method according to claim 4, wherein the propagation parameters for determining the risk path include: In response to determining that the parameters of the code element in the call path match predetermined concern parameters, the propagation parameters of the risk path are determined based on the concern parameters.

6. The method of claim 4, wherein determining the potential risks in the application's code based on the call relationship, the data flow, and the risk path includes: Based on the call relationship and the starting point of the risk path, determine the entry point in the code that causes the potential risk; Identify the risk data portion of the data stream located after the entry point; as well as The potential risks are determined based on the risk data and the propagation parameters.

7. The method of claim 1, wherein acquiring the data stream comprises: Provide labeled input data to the application; as well as During the operation of the application, the input data with the aforementioned tags is tracked in order to acquire the data stream.

8. An apparatus for managing application code, comprising: A relationship determination module is configured to determine the call relationship of at least one code element in the code of the application; An acquisition module is configured to acquire a data stream processed by the code of the application, the data stream including at least one data item processed by the at least one code element; A path determination module is configured to determine risky paths associated with the code of the application, the risky paths indicating the call paths of code elements that cause potential risks in the application; as well as A risk determination module is configured to determine the potential risks in the application's code based on the call relationships, the data flow, and the risk paths.

9. An electronic device, comprising: At least one processor; as well as At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to any one of claims 1 to 7 when executed by the at least one processor.

10. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

11. A computer instruction product comprising computer instructions, wherein the computer instructions, when executed by a processor, implement the method according to any one of claims 1 to 7.

Images