WO2022222499A1

WO2022222499A1 - Code processing method, and system, cluster, medium and program product

Info

Publication number: WO2022222499A1
Application number: PCT/CN2021/137848
Authority: WO
Inventors: 梁广泰; 石敏
Original assignee: 华为云计算技术有限公司
Priority date: 2021-04-24
Filing date: 2021-12-14
Publication date: 2022-10-27
Also published as: CN115237743A

Abstract

Provided in the present application is a code processing method. The method comprises: acquiring a tested code, wherein the tested code comprises an open source component and a self-contained component; performing compliance analysis on the open source component; and performing defect analysis on the self-contained component, so as to obtain an analysis result of the tested code. By means of the method, different analysis methods are respectively used for an open source component and a self-contained component, for example, simple and efficient compliance analysis is performed on the open source component, and defect analysis is performed on the self-contained component, such that it is possible to focus on the self-contained component, thereby improving the analysis efficiency and meeting service requirements.

Description

Code processing method, system, cluster, medium and program product

This application claims the priority of the Chinese patent application filed on April 24, 2021 with the State Intellectual Property Office of China, the application number is 202110446948.X, and the invention name is "code processing method, system, cluster, medium and program product", which The entire contents of this application are incorporated by reference.

technical field

The present application relates to the technical field of software development and testing, and in particular, to a code processing method, a code processing system, a computer cluster, a computer-readable storage medium, and a computer program product.

Background technique

In software development, in order to improve efficiency, developers can use a lot of automated processes, such as the Development & Security & Operations (DevSecOps) process to get through development, compilation, testing, release, deployment, and operation and maintenance. And other links, and the introduction of automatic analysis technology to improve the production efficiency of each link.

In order to improve code quality, mainstream code defect detection and testing technologies in the industry have increasingly become an essential part of the DevSecOps tool chain, providing developers with automated and intelligent software quality analysis capabilities, helping developers identify problems early and reduce Defect repair cost.

The mainstream code defect detection includes static defect analysis (static application security testing, SAST). SAST is a technology that directly analyzes software source code, bytecode, and binary packages in a static way to achieve code defect analysis. Specifically, given the code under inspection, the SAST tool combines the knowledge of defect patterns or repair patterns to perform systematic scanning and analysis, thereby identifying potential defects and providing possible repair solutions.

The above analysis methods usually consume a lot of time, and the analysis efficiency is relatively low, and it is difficult to meet business requirements.

SUMMARY OF THE INVENTION

The present application provides a code processing method. This method obtains open source components and self-owned components from the code under inspection, and then adopts different analysis methods for open source components and self-owned components, such as simple and efficient compliance analysis for open source components, and defect detection for self-owned components. Analysis, so that it can focus on its own components, improve analysis efficiency, and meet business needs. The present application also provides a code processing system, a computer cluster, a computer-readable storage medium, and a computer program product corresponding to the above method.

In a first aspect, the present application provides a code processing method. The method may be performed by a code processing system. The code processing system may be a software system with code analysis and repair functions, or a hardware system with code analysis and repair functions.

Specifically, the code processing system obtains the inspected code, and the inspected code includes open source components and self-owned components, and then the code processing system can perform compliance analysis on the open source components, and perform defect analysis on the self-owned components, and obtain Analysis results of the code under test.

This method obtains open source components and self-owned components from the code under inspection, and then adopts different analysis methods for open source components and self-owned components, such as simple and efficient compliance analysis for open source components, and defect detection for self-owned components. Analysis, so that it can focus on its own components, improve analysis efficiency, and meet business needs.

In some possible implementations, the open source components include open source components. Considering the situation that its own components depend on open source components, such as the situation of relying on open source components, the code processing system may also, when performing defect analysis on the own components, according to the knowledge of the open source components that the own components depend on, Defect analysis is performed on the own components. This can further improve the validity and coverage of defect analysis results for own components.

In some possible implementations, the knowledge of the open source component includes at least one of usage constraints, defect patterns, and semantic models. Usage constraints refer to the specifications or requirements that need to be followed when using open source components. When open source components are provided to upper-layer applications for calling, they often need to follow the usage constraints of open source components to ensure the correctness, reliability, and stability of logic. The user can configure whether to start the detection rule set related to the open source component. The detection rule set defines a defect mode, and the defect mode can be characterized by the regular code sequence corresponding to the defect type. The code processing system can initiate a more comprehensive analysis based on the defect patterns defined in the detection rule set, improving the accuracy of the analysis results.

The semantic model of open source components defines the specific operations and behavioral logic that open source components perform when given input. The code processing system may recommend a semantic model corresponding to the above-mentioned open source components for the open source components included in the open source components of the code under inspection. Specifically, the code processing system receives the identifier of the semantic model selected by the user, then determines the corresponding semantic model according to the identifier, and performs defect analysis through the semantic model. The semantic model can be used to help defect analysis, improve analysis efficiency, and avoid repetitive semantic analysis of common open source components.

In some possible implementations, the code processing system may further present the analysis result to the user through a user interface, where the analysis result includes the problems existing in the code under inspection. The user interface may specifically include a graphical user interface or a command user interface.

By showing the analysis results to the user, the code processing system can provide help for the user to fix the problems in the inspected code and improve the user experience. Moreover, the analysis result focuses on the own components, so it can guide the user to focus on repairing the defects of the own components, reduce unnecessary repair actions, and improve the repair efficiency and user experience.

In some possible implementations, the code processing system may also present to the user repair suggestions for the problems existing in the code under inspection, such as repair suggestions for defects in its own components, through the user interface, and then the code processing system may According to the operation of the user on the repair suggestion, accept or reject the repair suggestion. In this way, the user is guided to repair, the repair action is simplified, and the defect repair of its own components is focused, the repair workload is reduced, and the repair efficiency is improved.

In some possible implementation manners, the code processing system may perform defect analysis on the self-owned components when the open source components (eg, open source components or open source code fragments) pass the compliance analysis. In this way, repeated analysis can be avoided and the analysis efficiency can be improved.

In some possible implementations, the code processing system may repair the open source component when the compliance analysis of the open source component fails until the compliance analysis passes. Among them, the code processing system can guide the user to repair the open source component through the user interface. For example, the code processing system can present compliance risk points and risk elimination suggestions to users through a user interface, and users can eliminate compliance risk points according to the risk elimination suggestions, such as upgrading or replacing open source components.

Defect analysis of self-owned components under the condition that the risk points of open-source components are eliminated can effectively improve the accuracy of defect analysis results of self-owned components, and improve the reliability of analysis results.

In some possible implementations, the code processing system may perform compliance analysis on the open source components based on licenses or security vulnerabilities. On the one hand, the code processing system may query the license type according to the open source component, and determine the legality of the use method of the open source component according to the license type. Among them, the types of licenses can include different types such as loose type and public copyright type, and different types of licenses have different requirements for the use method, so the code processing system can determine the legality of the current use method of open source components according to the type of license. On the other hand, the code processing system may match the open source component with a set of open source code with security vulnerabilities (for example, a set of open source components with security vulnerabilities or a set of open source code fragments), and determine whether the open source component is associated with a security vulnerability .

The amount of computation for compliance analysis based on licenses or security vulnerabilities is much smaller than that for direct defect analysis. Therefore, compliance analysis for open source components can effectively reduce the amount of computation and improve the overall analysis efficiency of the code under inspection.

In a second aspect, the present application provides a code processing system. The system includes:

a communication module, used to obtain the code to be inspected, the code to be inspected includes open source components and self-owned components;

An analysis module, configured to perform compliance analysis on the open source components, and perform defect analysis on the self-owned components, to obtain analysis results of the code under inspection.

In some possible implementations, the open source components include open source components, and the analysis module is specifically used for:

Defect analysis is performed on the own component based on the knowledge of the open source component on which the own component depends.

In some possible implementations, the knowledge of the open source component includes at least one of usage constraints, defect patterns, and semantic models.

In some possible implementations, the system further includes:

The display module is used for presenting the analysis result to the user through the user interface, and the analysis result includes the problems existing in the code under inspection.

In some possible implementations, the system further includes:

a display module, used for presenting a repair suggestion for the problem existing in the code under inspection to a user through a user interface;

A repairing module, configured to accept or reject the repairing suggestion according to the operation of the user on the repairing suggestion.

In some possible implementations, the analysis module is specifically used for:

When the open source component compliance analysis passes, perform defect analysis on the self-owned component.

In some possible implementations, the system further includes:

A repairing module, configured to repair the open source component until the compliance analysis passes when the open source component does not pass the compliance analysis.

In some possible implementations, the analysis module is specifically used for:

Query the type of license according to the open source component, and determine the legality of the use method of the open source component according to the type of the license; and/or,

Matching the open source component with a set of open source code with security vulnerabilities to determine whether the open source component is associated with a security vulnerability.

In a third aspect, the present application provides a computer cluster. The computer cluster includes at least one computer, the computer including a processor and a memory having computer readable instructions stored in the memory, the processor executing the computer readable instructions to perform the first aspect or the first aspect. The code processing method in any one of the implementations of an aspect.

In a fourth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium includes computer-readable instructions, which, when executed on a computer, cause the computer to execute the code processing method in the first aspect or any implementation manner of the first aspect .

In a fifth aspect, the present application provides a computer program product. The computer program product includes computer-readable instructions that, when executed on a computer, cause the computer to execute the code processing method according to the first aspect or any one of the implementations of the first aspect.

On the basis of the implementation manners provided by the above aspects, the present application may further combine to provide more implementation manners.

Description of drawings

In order to illustrate the technical methods of the embodiments of the present application more clearly, the following briefly introduces the accompanying drawings used in the embodiments.

1 is a system architecture diagram of a code processing system provided by an embodiment of the present application;

FIG. 2 is an interactive flowchart of a code processing method provided by an embodiment of the present application;

3 is a schematic flowchart of a code processing method provided by an embodiment of the present application;

4 is a schematic diagram of a code component analysis interface provided by an embodiment of the present application;

5 is a schematic diagram of a code component analysis result interface provided by an embodiment of the present application;

6 is a schematic diagram of a configuration interface provided by an embodiment of the present application;

7 is a schematic diagram of a configuration interface provided by an embodiment of the present application;

FIG. 8 is a schematic structural diagram of a code processing system provided by an embodiment of the present application.

FIG. 9 is a schematic structural diagram of a computer cluster according to an embodiment of the present application.

Detailed ways

The terms "first" and "second" in the embodiments of the present application are only used for the purpose of description, and cannot be understood as indicating or implying relative importance or implying the number of indicated technical features. Thus, a feature defined as "first" or "second" may expressly or implicitly include one or more of that feature.

First, some technical terms involved in the embodiments of this application are introduced.

The inspected code specifically refers to the code to be inspected. The inspected code may be code written by the developer during the application development process and to be subjected to application security testing (application security testing, AST). Among them, AST can be divided into static application security test (static AST, SAST), dynamic application security test (dynamic AST, DAST) and interactive security test (interactive AST, IAST) and so on.

SAST is a type of technology that directly analyzes source code, bytecode or binary packages in a static way for defect analysis. Generally, it is automatically integrated into integrated development environment (integrated development environment, IDE) plug-ins or code submission access control for automatic defect scanning. . DAST is a type of technology that detects program errors by performing a series of tests on the code under test in a dynamic running mode. Specifically, IAST performs intrusive instrumentation of the code under inspection through the instrumentation technology, so that the code under inspection can collect interesting operation data during the test run, so as to identify possible defects in the code under inspection.

At present, SAST is widely used in the industry due to its low threshold for use and fast defect identification. However, SAST is usually a systematic scan and analysis combined with knowledge of defect patterns or repair patterns, so as to identify potential defects and give possible repair solutions. In this way, it takes a lot of time, the analysis efficiency is relatively low, and it is difficult to meet business needs.

In view of this, embodiments of the present application provide a code processing method. This method obtains open source components and self-owned components from the code under inspection, and then adopts different analysis methods for open source components and self-owned components, such as simple and efficient compliance analysis for open source components, and defect detection for self-owned components. Analysis, so that it can focus on its own components, improve analysis efficiency, and meet business needs.

The foregoing code processing method provided by the embodiment of the present application may be executed by a computing device. The computing device may be a terminal, and the terminal includes but is not limited to a desktop computer, a notebook computer, a tablet computer, and the like. In some possible implementations, the computing device may also be a server, and the server may be a cloud server (a server in a cloud computing cluster), an edge server (a server in an edge computing cluster), or a local server. The local server refers to the server in the data center to which the user belongs.

The above code processing method may be stored in a computing device in the form of a computer program. The computer program may be software or a client with independent functions. In some embodiments, the computer program may also be a small program or a plug-in integrated on other programs, such as a plug-in integrated in an IDE. The terminal or server can execute the above-mentioned computer program, thereby executing the code processing method. Wherein, when the server executes the above code processing method, it can interact with the terminal to display the analysis result of the code under inspection to the terminal.

In order to make the technical solutions of the present application clearer and easier to understand, the following describes the system architecture of the code processing method provided by the embodiments of the present application with reference to the accompanying drawings.

Referring to the system architecture diagram of the code processing method shown in FIG. 1 , as shown in FIG. 1 , the system 100 includes a terminal 102 and a server 104 . Server 104 may be a cloud server. The terminal 102 can receive the inspected code from the user, the inspected code specifically includes open source components and self-owned components, and then the server 104 can perform compliance analysis on the open source components and defect analysis on the self-owned components, thereby obtaining the analysis results. .

The analysis results may include problems in the code under inspection. Further, the terminal 102 can receive the analysis result sent by the server 104, and then present the analysis result to the user through a user interface, such as a graphical user interface (graphical user interface, GUI) or a command user interface (command user interface).

In some possible implementations, the terminal 102 may receive the repair suggestion sent by the server 104, and then present the above repair suggestion to the user through a GUI or a CUI. The user can choose to accept or reject the repair suggestions through the GUI. When all the repair suggestions have been accepted or rejected, the processing of the inspected code is completed.

Next, the code processing method provided by the embodiment of the present application will be introduced in detail from the perspective of interaction. Referring to the flowchart of the code processing method shown in FIG. 2, the method includes:

S202: The terminal 102 sends the checked code to the server 104.

Specifically, an IDE or an editor (editor) may be deployed on the terminal 102, the user may write code through the IDE or the editor, and the terminal 102 receives the code written by the user, thereby obtaining the inspected code. Then, the terminal 102 sends the checked code to the server 104 to perform detection and analysis on the checked code.

S204: The server 104 identifies the code under inspection, and obtains open source components and proprietary components of the code under inspection.

Open source components are specifically code derived from open source software. The so-called open source software, also known as development source code software, refers to a computer software whose source code is publicly available. Distribute this software to anyone for any purpose. The self-owned component is specifically the code that the user owns the copyright, such as the code developed by the user.

Specifically, the server 104 may identify the inspected code through a software composition analysis (SCA) technology, so as to obtain open source components and proprietary components of the inspected code. Among them, SCA generally realizes the analysis of the components of the code under inspection through technologies such as compilation dependency analysis and component component matching. When identifying the open source components, the server 104 may further identify open source components and open source code fragments in the open source components. Among them, a component is an object formed by simply encapsulating data and methods. This object can be reused. Code snippets are usually unencapsulated data, methods, etc. code.

It should be noted that the SCA is only a schematic implementation manner for the server 104 to obtain the open source components and its own components of the code under inspection, and in other possible implementation manners of the embodiments of the present application, the server 104 may also obtain the code in other ways. Open source and proprietary components of the code under review.

S206: The server 104 performs compliance analysis on the open source components. When the open source component compliance analysis fails, execute S208; when the open source component compliance analysis passes, execute S216.

Since the open source component can be maintained by its copyright holder, the server 104 may not need to perform defect analysis on the open source component, but may directly perform compliance analysis on the open source component. Among them, compliance refers to compliance with regulations. For open source components, compliance may be compliance with the relevant open source agreement.

The compliance analysis may include at least one of a license-based usage pattern legality analysis and a security vulnerability analysis. The following is a detailed description of the legality analysis and security vulnerability analysis of license-based usage.

Specifically, the server 104 can query the type of the corresponding license according to the open source component. For example, the server 104 can query the corresponding license information according to the source of the third-party library corresponding to the open source component. The license information can include the type of the license, and then the server 104 The legality of the current use of open source components can be judged according to the type of license.

Among them, the type of license may include loose type and public copyright (copyleft) type. The loose type has almost no restrictions on users, and the public copyright type has relatively strict restrictions on users. Each of them will be described below.

The permissive license has the following characteristics: (1) no usage restrictions, users can use the code, and can also modify the code; (2) no warranty, users are at their own risk; (3) users must disclose the original author. Common loose licenses allow users to use code arbitrarily. The difference between different loose licenses is mainly in the conditions that users are required to abide by. For example, some licenses require that the original license statement must be retained when distributing an application. Further, some licenses require not only retaining the original license statement, but also not using the original author's name for promotion. In addition, some licenses require that when distributing an application, the original license statement must be retained, and modified files must declare to the user that they have been modified, and files that have not been modified must keep the license unchanged.

The public copyright type license has the following characteristics: (1) if the binary format is distributed, the source code must be provided; (2) the modified source code must be in the same license as the original source code; (3) it must not be used in addition to the original license Additional restrictions apply. Different public copyright-type licenses may have different restrictions on users. For example, some licenses require that when the open source code used in the cloud service adopts the license, the code of the cloud service needs to be open source; other licenses require that if the project includes the source code using the license, the entire project must use the license. It should be noted that open source may not be required if the following conditions are met. For example, some licenses require that if the project uses dynamic linking to call the library of the license, the project may not use open source. Other licenses require that as long as the code using the license is in a separate file, other new files may not be open sourced. It should be noted that the four kinds of licenses listed above may be different.

Based on this, the server 104 can determine whether the usage mode of the license meets the requirements of the license. If so, it indicates that the current usage mode of the open source component is legal, and the legality analysis of the usage mode based on the license passes. If not, it indicates that the current open source component is valid. The usage of the ingredients is illegal, and the legality analysis of the usage based on the license fails.

Similarly, the server 104 may match the open source component with a set of open source code with security vulnerabilities to determine whether the open source component is associated with a security vulnerability. Wherein, when the open source component is an open source component, the open source code set with security vulnerabilities may be an open source component set, and the server 104 determines the current open source component by matching the current open source component with the open source component pre-collected in the open source component set with security vulnerability. Whether the component is associated with a security vulnerability. When the open source component is an open source code fragment (usually unpackaged code), the open source code set may be an open source code fragment set. Matches are made to determine whether the current open source code fragment is associated with a security vulnerability. If a security vulnerability is associated, it indicates that the security vulnerability analysis fails, and if the security vulnerability is not associated, it indicates that the security vulnerability analysis passes.

It should be noted that when at least one of the legality analysis and security vulnerability analysis based on the license-based usage method fails, it indicates that the compliance analysis fails. When both the legality analysis and security vulnerability analysis based on the license-based usage method pass , it indicates that the compliance analysis passed. When the compliance analysis passes, the server 104 may continue to perform S210 to analyze the own components. When the compliance analysis fails, the server 104 may execute S208 to guide the user to modify the open source component until the compliance analysis of the open source component passes.

S208: The server 104 sends a compliance risk prompt to the terminal 102.

The compliance risk prompt is used to prompt the user of the risk points discovered by the compliance analysis of the open source components. Specifically, the compliance risk prompt can carry detailed information of risk points, such as the location of the risk point, the cause of the risk, and so on. Further, the compliance risk alert can also carry suggestions for eliminating risk points.

S210: The terminal 102 presents a compliance risk prompt to the user.

The terminal 102 may present the risk points discovered by the compliance analysis of the open source components when presenting the inspected code, for example, presenting the open source components of the inspected code. The terminal 102 may present the above risk points by means of highlighting or linking or the like.

Further, when the terminal 102 presents the risk points found by the compliance analysis of the open source components, it can also present the position of the risk point and the cause of the risk, so that the user can understand the position of the risk point and the cause of the risk, in order to eliminate the risk. Click to help.

In some possible implementations, when the compliance risk prompt carries a risk point elimination suggestion, the terminal 102 may also present the elimination suggestion to the user, thereby guiding the user to eliminate the risk point and improve the open source components in the inspected code.

S212: The terminal 102 receives the modification of the open source component by the user.

Specifically, the user can trigger a modification operation on the open source component in combination with the modification suggestion presented by the terminal 102, and the terminal 102 receives the user's modification of the open source component in response to the operation, so that the open source component is compliant.

In some embodiments, open source components include non-compliant open source components. Users can upgrade or replace the non-compliant open source components, so as to realize intelligent repair of non-compliant open source components, and ensure that the open source components that the inspected code depends on are trusted open source components.

In other embodiments, the open source components include non-compliant pieces of open source code. Users can remove non-compliant open source code fragments or rectify non-compliant open source code fragments according to the suggestions for eliminating risk points, so as to turn the above open source code fragments into a trusted state. It should be noted that the server 104 can also introduce the patch intelligent integration capability of the open source community to repair the non-compliant open source components.

In other possible implementation manners of the embodiments of the present application, the server 104 may also directly repair the open source components, specifically the risk points of the open source components, in the background, so that the repaired open source components are compliant. In this way, the code processing system 100 does not need to perform the above steps S208 to S212 to guide the user to eliminate risks, thereby reducing user operations and improving user experience.

S214: The terminal 102 submits the modified open source component to the server 104. The server 104 then executes S206.

The terminal 102 sends the modified open source component to the server 104, so that the server 104 re-analyzes the compliance of the modified open source component. When the compliance analysis passes, execute S216, and when the compliance analysis fails, execute S208 until the open source component compliance analysis passes.

S216: The server 104 performs defect analysis on its own components to obtain an analysis result.

The self-owned components depend on the above-mentioned open-source components, so the server 104 can perform systematic defect analysis on the above-mentioned self-owned components after the open-source component compliance analysis has passed, for example, by performing defect analysis through SAST to obtain the analysis results. The analysis results may include defects in the own components. By focusing on its own components for defect analysis, the analysis efficiency can be improved, and the analysis results can be located in the range that can cause users such as developers to repair behaviors, which can improve the action rate of the analysis results and reduce unnecessary repair work.

Further, considering the fact that its own components depend on open source components, when performing defect analysis on the own components, the server 104 may also perform defect analysis on the own components according to the knowledge of the open source components in the open source components that the own components depend on. analyze. The knowledge of the open source component may include at least one of usage constraints, defect patterns and semantic models of the open source component.

In some possible implementations, the server 104 presets a semantic model for common open source components in advance, and the semantic model can be used to help defect analysis, improve analysis efficiency, and avoid repeated semantic analysis for common open source components. Specifically, the semantic model of the open source component defines the specific operation and behavior logic that the open source component performs when given input. The server 104 may recommend a semantic model corresponding to the above-mentioned open source component for the open source components included in the open source component of the code under inspection. The server 104 receives the identifier of the semantic model selected by the user, and then determines the corresponding semantic model according to the identifier. Perform defect analysis.

Further, when open source components are provided to upper-layer applications for invocation, they often need to follow the usage constraints of open source components, such as specifications or requirements that need to be followed during use, to ensure the correctness, reliability and stability of logic. In addition, the user can continue to configure whether to start the detection rule set related to the open source component. The detection rule set defines a defect mode, and the defect mode can be characterized by a regular code sequence corresponding to the defect type. The server 104 can initiate a more comprehensive analysis based on the defect patterns defined in the detection rule set, improving the accuracy of the analysis results.

In some possible implementations, the server 104 may first perform defect analysis on its own components according to the defect mode, and then perform defect analysis according to usage constraints, semantic models, and the like. This embodiment of the present application does not limit the sequence of performing defect analysis according to the semantic model, usage constraints, and defect mode.

Based on usage constraints, defect patterns and semantic models, a more complete defect analysis can be achieved, the accuracy of defect analysis can be improved, and code defect analysis in the use of application programming interfaces (APIs) related to open source components can also be performed.

It should be noted that the above S206 to S210 are only an implementation manner of analyzing the code under inspection. In other possible implementation manners of the implementation of the present application, the foregoing S206 and S210 may also be executed in parallel, or sequentially executed in a set order, which is not limited in this embodiment of the present application.

S218: The server 104 sends the analysis result and the repair suggestion to the terminal 102.

Specifically, defects are used to describe problems with the code itself, independent of execution results and expected specifications. The categories of defects are limited and enumerable, and the defects do not depend on business logic, so the server 104 can obtain the defect types and the corresponding repair methods for each defect type, and build a knowledge base according to the defect types and their corresponding repair methods, After the server 104 determines the defect of the own component of the inspected code through defect analysis, it may generate a repair suggestion based on the above-mentioned knowledge base. The server 104 then returns the analysis results and repair suggestions to the terminal 102 .

It should be noted that, in FIG. 2 , the server 104 simultaneously sends the analysis result and the repair suggestion to the terminal 102 for illustration. In some possible implementations, the server 104 may also send the above analysis result and repair suggestion respectively, for example, the server 104 may first send the analysis result and then send the repair suggestion.

S220: The terminal 102 presents the analysis results and repair suggestions to the user through the user interface.

The user interface may be an analysis results interface. The analysis result interface can be GUI or CUI. For ease of understanding, the embodiments of the present application use GUI for illustration. Specifically, the terminal 102 can present the checked code and the problems existing in the checked code to the user through the GUI. Among them, the problems existing in the code under inspection may include defects in the own components of the code under inspection. Further, the problems existing in the inspected code may also include code that fails the compliance analysis in the open source components of the inspected code, such as open source components associated with security vulnerabilities or code fragments that use illegal licenses.

When the terminal 102 presents the checked code and the problems existing in the checked code to the user through the GUI, it can be displayed in different styles. For example, the terminal 102 can highlight the problems existing in the code under inspection to achieve the effect of highlighting the problems and reminding the user to pay attention. There are various ways for the terminal 102 to highlight the problems existing in the code under inspection. One way is that the terminal 102 simultaneously highlights the problem with the code under inspection. Another way is that the terminal 102, in response to the user's operation, displays the problems existing in the checked codes one by one. For example, a jump control can be carried on the GUI, and the jump control is used to jump from the current question to the next question. The terminal 102 highlights one of the problems existing in the code under inspection through the GUI. When the user passes the jump control A jump operation is triggered, and the terminal 102 highlights the next question of the question through the GUI.

The terminal 102 can present the user with repair suggestions for problems existing in the code under inspection through the GUI or CUI. Similar to the problem of presenting the checked code to the user, the terminal 102 presents repair suggestions in various ways. An implementation manner is that the terminal 102 simultaneously displays repair suggestions for multiple problems. Another implementation manner is that the terminal 102 displays the repair suggestions for the problems one by one in response to the user operation. For example, a jump control may be carried on the GUI, and the jump control is used to jump from the current problem to the next problem. When the user triggers the jump operation through the jump control, the terminal 102 displays the repair suggestion for the next problem through the GUI.

Considering the reading experience, the terminal 102 may present a repair suggestion for the problem at a position near the problem, such as after the problem, when the problem is presented. In some embodiments, the terminal 102 may also present a repair suggestion under a specific area of the GUI, such as a code display area, so that the user can repair according to the repair suggestion.

The terminal 102 may simultaneously present the analysis results and repair suggestions, or may display the analysis results and repair suggestions sequentially in a set order according to business requirements, which is not limited in this embodiment of the present application.

S222: The terminal 102 accepts or rejects the repair suggestion according to the user's operation on the repair suggestion.

Specifically, the terminal 102 may receive the user's operation on the above repair suggestion through GUI or CUI, and accept or reject the above repair suggestion. The user interface is used as an example to illustrate the GUI, and the repair suggestions for each problem on the GUI are provided with accept and reject controls. The user can trigger an operation through the accepting control, and accordingly, the terminal 102 can accept the repair suggestion in response to the operation. The user can also trigger an operation through the rejection control, and accordingly, the terminal 102 can also reject the repair suggestion in response to the operation.

Based on the above content description, an embodiment of the present application provides a code processing method. This method obtains open source components and self-owned components from the code under inspection, and then adopts different analysis methods for open source components and self-owned components, such as simple and efficient compliance analysis for open source components, and defect detection for self-owned components. Analysis, so that it can focus on its own components, improve analysis efficiency, and meet business needs.

In order to make the technical solution of the present application clearer and easier to understand, the code processing method of the present application will be described in detail below with reference to a specific example.

First, referring to the schematic flowchart of the code processing method shown in FIG. 3, in this example, the tested code is analyzed by open source components, and its own components and open source components can be obtained, wherein the open source components can be further divided into open source components and open source components. code segment. In some embodiments, the open source components may be jar packages.

SCA tools provide code cloning analysis, big data analysis or distributed indexing for component analysis of inspected code. The code processing system 100 may perform component analysis through the SCA tool. Referring to the schematic diagram of the code component analysis interface shown in FIG. 4 , the interface 400 carries the address input control 402 of the checked item, and the address input control 402 includes any one or more of the local path input control and the remote code warehouse input control. The user can select the local path input control or the remote code warehouse input control according to the storage location of the tested code, input the address of the tested code, and then trigger the code component analysis through the startup analysis control 404 carried on the interface 400 . The terminal 102 in the code processing system 100 generates a code component analysis request in response to the code component analysis operation triggered by the user. In addition, the interface 400 may also provide other address input controls. Correspondingly, the user may also input the address of the code under inspection in other ways, so as to process the code under inspection according to the current state.

The server 104 may, in response to the code component analysis request, identify the components of the inspected code through code clone analysis, big data analysis or distributed indexing provided by the SCA tool, for example, the inspected code may be compared with pre-collected codes of open source communities through the above-mentioned techniques Big data is matched to locate open source code fragments of the code under inspection. Then, the code component analysis result is returned to the terminal 102, and the terminal 102 presents the above code component analysis result to the user.

Referring to the schematic diagram of the code component analysis result interface shown in FIG. 5 , the interface 500 displays the components of the code under inspection. The inspected code may be the code of a inspected project, and the inspected code may include multiple code files. The interface 500 shows that each code file is an own component, an open source component, or a referenced open source code fragment. Further, the interface 500 is further provided with a revision control 502, and the revision control 502 is used to support the user to revise the code component analysis result. The user can examine each code file to determine whether or not to revise the component corresponding to each code file. After the components corresponding to each code file are confirmed to be correct, the user can click the confirmation control 504 to confirm the code component analysis result.

For open source components and proprietary components, the server 104 activates different analysis methods respectively. In this embodiment, the server 104 starts compliance analysis for open source components, and starts systematic defect analysis for self-owned components. The analysis process of the server 104 will be described in detail below.

Specifically, for open source components, the server 104 starts compliance analysis, such as security vulnerability analysis, license-based legality analysis of usage methods, and gives an early warning when compliance risks are analyzed. Further, the server 104 can guide the user to perform intelligent repair of non-compliant components, such as intelligent repair through operations such as library upgrade or replacement, so as to ensure that the open source components on which the inspected code depends are adjusted to trusted open source components.

Next, for the open source code fragments, the server 104 starts compliance analysis, such as security vulnerability analysis, license-based legality analysis of usage methods, and conducts the analysis when a compliance risk is analyzed, for example, the open source code fragments include untrusted open source code fragments Warning. Similar to open source components, the server 104 can guide the user to process untrusted open source code fragments, so as to quickly remove, rectify and repair the untrusted open source code fragments.

When the open source components and open source code fragments on which the code under inspection depends have become trusted, the server 104 can then perform defect detection and repair on its own components. Wherein, the server 104 can perform a more comprehensive defect analysis of its own components in combination with the open source components on which its own components depend, such as information related to open source components.

Specifically, the server 104 presets semantic models of common open source components (for example, APIs of open source components), and these semantic models define the specific operation process and behavior logic performed by the API when given specific input data. The user can configure the open source components that need to enable the semantic model for analysis, so that the server 104 can use the corresponding semantic model for analysis according to the user's configuration. Referring to the schematic diagram of the configuration interface shown in FIG. 6 , the terminal 102 presents the open source components 602 included in the currently inspected code to the user through the configuration interface 600 , and presents the user with the status 604 of the semantic model corresponding to the open source components. The status of the semantic model can include pre-analyzed or not pre-analyzed. When the semantic model has been pre-analyzed (generated), the user can configure whether to activate the semantic model in the configuration interface to improve the analysis accuracy. After the user completes the configuration of each open source component, the user can click the "confirm" control to submit the above configuration information to the server 104, so that the configuration information becomes effective.

Further, when open source components are provided to upper-layer applications for calling, they usually need to follow API usage constraints to ensure the correctness, reliability, and stability of logic. Defect patterns can be formed when self-contained components such as upper-layer applications violate usage constraints. Defect patterns can be characterized by regular code sequences corresponding to specific defect types. Defect detection rules can also be generated based on defect patterns, wherein a defect detection rule can be used to detect one or more defect patterns.

Specifically, referring to the schematic diagram of the configuration interface shown in FIG. 7 , the terminal 102 presents the defect detection rules 704 that can be provided by each open source component 702 to the user through the configuration interface 700 , and the defect detection rules cover multiple dimensions, such as covering correctness, stability , security and other dimensions, the user can configure whether to enable defect detection rules related to open source components through the configuration interface 700, thereby enabling a more comprehensive analysis. After the user completes the configuration of each open source component, the user can click the "confirm" control to submit the above configuration information to the server 104, so that the configuration information becomes effective.

Based on the configuration information submitted by the terminal 102, the server 104 loads the preset semantic model of the open source component, so as to speed up the analysis and improve the analysis accuracy. In addition, the server 104 activates a corresponding defect detection set based on the configuration information submitted by the terminal 102, conducts a systematic analysis around the use problem of the open source components, and obtains the analysis result. This increases the validity and coverage of defect analysis results for own components. Further, the server 104 can also provide an intelligent repair capability based on the analysis result, so as to assist the user to repair the defect more quickly.

This method organically integrates the capabilities of open source component analysis tools and code defect detection and repair tools, opens up the analysis results between the two tools, supports mutual utilization, further improves the effectiveness of each other's results, and can also reduce invalid analysis. Computing costs.

The code processing method provided by the embodiments of the present application has been described in detail above with reference to FIGS. 1 to 7 , and the code processing system provided by the embodiments of the present application will be introduced below from the perspective of functional modularity with reference to the accompanying drawings.

Referring to the schematic diagram of the code processing system shown in FIG. 8 , the code processing system 800 may be a software system or a hardware system. For convenience of description, the present application uses the code processing system as a software system for illustration. The software system includes several modules. These multiple modules can be centrally deployed on one computer, or can be deployed on different computers in a distributed manner. For example, some modules may be deployed on the terminal 102 and other modules may be deployed on the server 104 . As shown in Figure 8, the system 800 includes:

a communication module 802, configured to obtain a code to be inspected, where the code to be inspected includes open source components and self-owned components;

The analysis module 804 is configured to perform compliance analysis on the open source component, and perform defect analysis on the self-owned component to obtain an analysis result of the inspected code.

In some possible implementations, the open source components include open source components, and the analysis module 804 is specifically used for:

In some possible implementations, the system 800 further includes:

A display module 806, configured to present the analysis result to the user through a user interface, where the analysis result includes the problems existing in the code under inspection.

In some possible implementations, the system 800 further includes:

A display module 806, configured to present a repair suggestion for the problem existing in the code under inspection to the user through a user interface;

A repairing module 808, configured to accept or reject the repairing suggestion according to the operation of the user on the repairing suggestion.

In some possible implementations, the analysis module 804 is specifically used for:

In some possible implementations, the system 800 further includes:

A repairing module 808, configured to repair the open source component until the compliance analysis passes when the open source component does not pass the compliance analysis.

The code processing system 800 according to the embodiments of the present application may correspond to executing the methods described in the embodiments of the present application, and the above-mentioned and other operations and/or functions of the modules/units of the code processing system 800 are respectively in order to realize the implementation shown in FIG. 2 . For the sake of brevity, the corresponding flow of each method in the example will not be repeated here.

The embodiment of the present application also provides a computer cluster. The computer cluster may be a computer cluster formed by at least one computer in a cloud environment, an edge environment or a terminal device. The computer cluster is specifically used to implement the functions of the code processing system 800 in the embodiment shown in FIG. 8 .

FIG. 9 provides a schematic structural diagram of a computer cluster. As shown in FIG. 9 , the computer cluster 90 includes at least one computer 900 , and the computer 900 includes a bus 901 , a processor 902 , a communication interface 903 and a memory 904 . The processor 902 , the memory 904 and the communication interface 903 communicate through the bus 901 .

The bus 901 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of presentation, only one thick line is used in FIG. 9, but it does not mean that there is only one bus or one type of bus.

The processor 902 can be a central processing unit (central processing unit, CPU), a graphics processing unit (graphics processing unit, GPU), a microprocessor (micro processor, MP), or a digital signal processor (digital signal processor, DSP), etc. any one or more of the devices.

The communication interface 903 is used for external communication. For example, the communication interface 903 of one computer may be used to communicate with the communication interface 903 of another computer to obtain the code under inspection, or to transmit the analysis result of the code under inspection, which may include the existence of the code under inspection. question.

Memory 904 may include volatile memory, such as random access memory (RAM). The memory 904 may also include non-volatile memory (non-volatile memory), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (solid state drive) , SSD).

Executable code is stored in the memory 904, and the processor 902 executes the executable code to execute the aforementioned code processing method.

Specifically, when the embodiment shown in FIG. 8 is implemented, and each module of the code processing system 800 described in the embodiment of FIG. 8 is implemented by software, the function of the communication module 802 in FIG. 8 is controlled by the communication interface 903 To implement, the software or program code required to perform the functions of the analysis module 804 , the display module 806 , and the repair module 808 in FIG. 8 may be stored in the memory 904 . The processor 802 executes the program codes corresponding to the aforementioned modules stored in the memory 804 to execute the aforementioned code processing method.

Embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium may be any available medium that a computing device can store, or a data storage device such as a data center that contains one or more available media. The usable media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid state drives), and the like. The computer-readable storage medium includes instructions that instruct a computing device to execute the code processing method described above.

The embodiments of the present application also provide a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on the computing device, all or part of the processes or functions described in the embodiments of the present application are generated.

The computer instructions may be stored in or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted over a wire from a website site, computer or data center. (eg coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (eg infrared, wireless, microwave, etc.) to another website site, computer or data center.

The computer program product may be a software installation package, and when any one of the aforementioned code processing methods needs to be used, the computer program product may be downloaded and executed on a computing device.

The descriptions of the processes or structures corresponding to each of the above-mentioned drawings have their own emphasis, and for the parts that are not described in detail in a certain process or structure, reference may be made to the related descriptions of other processes or structures.

Claims

A code processing method, characterized in that the method comprises:

Obtain the inspected code, the inspected code includes open source components and self-owned components;

Compliance analysis is performed on the open source component, and defect analysis is performed on the self-owned component to obtain an analysis result of the inspected code.
The method according to claim 1, wherein the open source components include open source components, and the performing defect analysis on the self-owned components includes:

Defect analysis is performed on the own component based on the knowledge of the open source component on which the own component depends.
The method of claim 2, wherein the knowledge of the open source components includes at least one of usage constraints, defect patterns, and semantic models.
The method according to any one of claims 1 to 3, wherein the method further comprises:

The analysis results are presented to the user through a user interface, and the analysis results include problems with the code under inspection.
The method according to any one of claims 1 to 4, wherein the method further comprises:

Presenting repair suggestions to the problems existing in the code under inspection to the user through the user interface;

Accept or reject the repair suggestion according to the user's action on the repair suggestion.
The method according to any one of claims 1 to 5, wherein the performing defect analysis on the own components comprises:

When the open source component compliance analysis passes, perform defect analysis on the self-owned component.
The method according to claim 6, wherein the method further comprises:

When the compliance analysis of the open source component fails, repair the open source component until the compliance analysis passes.
The method according to any one of claims 1 to 7, wherein the performing a compliance analysis on the open source components comprises:

Query the type of license according to the open source component, and determine the legality of the use method of the open source component according to the type of the license; and/or,

Matching the open source component with a set of open source code with security vulnerabilities to determine whether the open source component is associated with a security vulnerability.
A code processing system, characterized in that the system comprises:

a communication module, used to obtain the code to be inspected, the code to be inspected includes open source components and self-owned components;

An analysis module, configured to perform compliance analysis on the open source components, and perform defect analysis on the self-owned components, to obtain analysis results of the code under inspection.
The system according to claim 9, wherein the open source component comprises an open source component, and the analysis module is specifically used for:

Defect analysis is performed on the own component based on the knowledge of the open source component on which the own component depends.
The system of claim 10, wherein the knowledge of the open source component includes at least one of usage constraints, defect patterns, and semantic models.
The system according to any one of claims 9 to 11, wherein the system further comprises:

The display module is used for presenting the analysis result to the user through the user interface, and the analysis result includes the problems existing in the code under inspection.
The system according to any one of claims 9 to 12, wherein the system further comprises:

a display module, used for presenting a repair suggestion for the problem existing in the code under inspection to a user through a user interface;

A repairing module, configured to accept or reject the repairing suggestion according to the operation of the user on the repairing suggestion.
The system according to any one of claims 9 to 13, wherein the analysis module is specifically used for:

When the open source component compliance analysis passes, perform defect analysis on the self-owned component.
The system of claim 14, wherein the system further comprises:

A repairing module, configured to repair the open source component until the compliance analysis passes when the open source component does not pass the compliance analysis.
The system according to any one of claims 9 to 15, wherein the analysis module is specifically used for:

Query the type of license according to the open source component, and determine the legality of the use method of the open source component according to the type of the license; and/or,

Matching the open source component with a set of open source code with security vulnerabilities to determine whether the open source component is associated with a security vulnerability.
A computer cluster, characterized in that the computer cluster includes at least one computer, the computer includes a processor and a memory, the memory stores computer-readable instructions, and the processor executes the computer-readable instructions , to execute the code processing method according to any one of claims 1 to 8.
A computer-readable storage medium, characterized by comprising computer-readable instructions, which, when the computer-readable instructions are executed on a computer, cause the computer to execute the code processing according to any one of claims 1 to 8 method.
A computer program product is characterized by comprising computer-readable instructions, which, when the computer-readable instructions are executed on a computer, cause the computer to execute the code processing method according to any one of claims 1 to 8.