CN118036009A - Method and device for processing security vulnerabilities and electronic equipment - Google Patents

Abstract

The application discloses a method for processing security vulnerabilities, which comprises the following steps: determining at least one security hole type to be tested corresponding to a target application; processing source codes corresponding to target applications by using a large language model aiming at each security hole type to be tested in the at least one security hole type to be tested, and generating at least one test script corresponding to the security hole type to be tested; executing the test script in a test environment for each test script in at least one test script, and judging whether the test script successfully detects the security hole; when the security hole is successfully detected, determining a hole repair suggestion according to the detected hole information and the source code of the security hole; in response to confirmation operation input by a developer, repairing the detected security holes according to the hole repairing suggestions, and the method provided by the application can efficiently and accurately detect and repair the security holes existing in the target application.

Description

Method and device for processing security vulnerabilities and electronic equipment

Technical Field

The application belongs to the field of testing, and particularly relates to a method and device for processing security vulnerabilities and electronic equipment.

Background

With the widespread use of Web applications in various industries, security issues are also becoming an increasing concern. The security hole can cause serious problems such as information leakage, data tampering, service interruption and the like, and brings about great security threat.

The security breach processing includes detecting and repairing two parts. The traditional security hole detection method mostly depends on manual auditing or an automatic tool based on fixed rules, and has the problems of low efficiency, insufficient accuracy, incapability of timely responding to new security threats and the like. In addition, after the security hole is detected, the repair of the security hole often depends on the experience of a developer, which can cause problems such as incomplete repair of the security hole or reintroduction of a new security hole.

Therefore, how to efficiently and accurately detect and repair security holes of Web applications is a technical problem to be solved.

Disclosure of Invention

The application aims to provide a method, a system device and electronic equipment for processing security holes, which can efficiently and accurately detect and repair the security holes of Web applications.

In a first aspect, an embodiment of the present application provides a method for handling security vulnerabilities, where the method includes:

determining at least one security hole type to be tested corresponding to a target application;

Processing source codes corresponding to the target application by utilizing a large language model LLM aiming at each security vulnerability type to be tested in the at least one security vulnerability types to be tested, and generating at least one test script corresponding to the security vulnerability type to be tested;

Executing the test script in a test environment for each test script in at least one test script, and judging whether the test script successfully detects the security hole;

When the security hole is successfully detected, determining a hole repair suggestion according to the hole information and the source code of the detected security hole, wherein the hole information is used for representing the characteristics of the detected security hole;

And responding to the confirmation operation input by the developer, and repairing the detected security vulnerabilities according to the vulnerability repairing suggestions.

In a possible implementation manner of the first aspect, for each security hole type to be tested in the at least one security hole type to be tested, processing source code corresponding to the target application by using the large language model LLM, generating at least one test script corresponding to the security hole type to be tested, including:

Integrating a source code corresponding to a target application and the security hole type to be tested according to a first preset template aiming at each security hole type to be tested in at least one security hole type to be tested to obtain first prompt information;

and processing the first prompt information by using a large language model LLM to generate at least one test script corresponding to the security hole type to be tested.

In a possible implementation manner of the first aspect, when a security hole is successfully detected, determining a hole repair suggestion according to the detected hole information and source code of the security hole includes:

Performing code analysis on the source code to obtain a code analysis result;

comparing the detected vulnerability information of the security vulnerability, and screening out target code analysis results related to the vulnerability information from the code analysis results;

and matching out the bug repair suggestions corresponding to the target code analysis result from a repair policy library, wherein the repair policy library comprises a plurality of bug repair suggestions corresponding to various security bugs, and the bug repair suggestions comprise repair policies and repair code examples.

In a possible implementation manner of the first aspect, the code analysis result includes a static code analysis result and a dynamic code analysis result, where the static code analysis result is obtained by performing a static code analysis on the source code, and the dynamic code analysis result is obtained by performing a dynamic code analysis on the source code.

In a possible implementation manner of the first aspect, the method further includes:

and when the bug repairing suggestion corresponding to the target code analysis result is not matched in the repairing policy library, integrating the bug information and the target code analysis result according to a second preset template to obtain second prompting information, and processing the second prompting information by utilizing a large language model LLM to obtain the bug repairing suggestion.

In a possible implementation manner of the first aspect, the method further includes:

and updating the repair strategy library in response to feedback information input by the user, wherein the feedback information comprises evaluation and supplement proposed by the user for the bug repair suggestion.

In a possible implementation manner of the first aspect, the method further includes:

And generating a bug report by using the bug information, the target code analysis result and the bug repairing suggestion of the detected security bug, and reporting the bug report to a developer, and waiting for the developer to confirm whether to repair the security bug according to the bug repairing suggestion.

In a second aspect, the present application also provides an apparatus for handling security vulnerabilities, the apparatus having functionality to implement the method of the first aspect or any possible implementation thereof. In particular, the apparatus comprises means for implementing the method of the first aspect or any possible implementation thereof.

In one embodiment thereof, the apparatus comprises:

The detection unit is used for determining at least one security hole type to be tested corresponding to the target application; processing source codes corresponding to target applications by utilizing a large language model LLM aiming at each security vulnerability type to be tested in at least one security vulnerability type to be tested, and generating at least one test script corresponding to the security vulnerability type to be tested; executing the test script in a test environment for each test script in at least one test script, and judging whether the test script successfully detects the security hole;

the repairing unit is used for determining a bug repairing suggestion according to bug information and source codes of the detected security bugs when the security bugs are successfully detected, wherein the bug information is used for representing the characteristics of the detected security bugs; and responding to the confirmation operation input by the developer, and repairing the detected security vulnerabilities according to the vulnerability repairing suggestions.

In a third aspect, the application further provides electronic equipment. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor, when executing the computer program, implements the method of any implementation manner of the first aspect.

In a fourth aspect, the present application also provides a computer-readable storage medium. The computer readable storage medium stores a computer program which when executed by a processor implements the method of any one of the implementations of the first aspect described above.

In a fifth aspect, the application also provides a computer program product for causing an electronic device to perform the method of any one of the implementations of the first aspect described above when the computer program product is run on the electronic device.

Compared with the prior art, the embodiment of the application has the beneficial effects that:

According to the method, the penetration test is carried out by simulating malicious attacks in the test environment, potential security holes in the target application are automatically found and mined, and hole repair suggestions are timely given. Compared with the traditional manual inspection code, the method provided by the application has the advantages that the large language model LLM is introduced, the test script for detecting the security holes is provided, and then the test script is utilized to simulate and attack the target application, so that whether the security holes exist in the target application or not can be accurately distinguished, and compared with the manual inspection code, the method provided by the application has higher efficiency and more accurate detection; the security holes can be detected by using the static or dynamic program security testing tool, however, the test results obtained by the static or dynamic program security testing tool often have a great number of irrelevant warnings or errors, which need to be identified manually one by one, have higher professional requirements on the developing personnel, and are time-consuming and labor-consuming. In addition, after the security hole is successfully detected, a repair suggestion is further automatically given, a reliable reference is provided for a developer to repair the security hole, and repair can be immediately performed after the developer confirms the security hole, so that the repair efficiency is effectively improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments or the description of the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is an application environment diagram of a method for handling security vulnerabilities provided by the present application.

Fig. 2 is a flow chart of a method for handling security vulnerabilities according to the present application.

FIG. 3 is a flow chart of a method for determining bug fix suggestions provided by the present application.

FIG. 4 is a schematic diagram of a system for handling security vulnerabilities provided by the present application.

Fig. 5 is a schematic structural diagram of an apparatus for handling security vulnerabilities according to the present application.

Fig. 6 is a schematic structural diagram of an electronic device provided by the present application.

Detailed Description

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

FIG. 1 is an application environment diagram of a method for handling security vulnerabilities provided by the present application.

The security hole in the application refers to the security hole of the Web application, and comprises security holes related to the Web application, such as source codes, source code running environments, middleware and the like.

Web applications refer to a generic term for providing services using Browser/server architecture (Browser/Server Architecture, B/S), over hypertext transfer protocol (Hyper Text Transfer Protocol, HTTP) or hypertext transfer security protocol (HyperText Transfer Protocol Secure, HTTPs). With the popularization of the internet, web applications have been widely used. In the enterprise informatization process, more and more applications are also erected on the Web platform. Most current Web applications are not simple static Web browsing, but rather involve more complex server-side dynamic processing. For example, in the application scenario shown in fig. 1, data is transmitted between the Web browser 110 and the Web server 120 through HTTP/HTTPs, the Web browser 110 serves as an HTTP client, sends a request message to the Web server 120, which is an HTTP server, through a uniform resource locator (Uniform Resource Locator, URL), the Web server 120 sends a response message to the Web browser 110 according to the received request message, and the Web browser 110 parses and renders the response message and then displays a page of the Web application. Assuming that the client is inputting login credentials (such as an account and a password), a login request is sent, if security awareness of a developer is insufficient, for example, inspection of parameter input of a user is not strict, an attacker may input some characters related to operation of a background database, at this time, the attacker can access or modify the background data, or attack by utilizing a potential database vulnerability, tamper webpage content slightly, steal private data again, and even be implanted with malicious codes, so that a website visitor is infringed.

Existing Web application security vulnerability detection techniques can be broadly divided into the following categories: a. static application security test (Static Application Security Testing, SAST): the security holes are found by analyzing the source code, bytecode, or binary code of the application. b. Dynamic application security test (Dynamic Application Security TestingDAST): the application is tested at runtime for security vulnerabilities independent of the actual code of the application. c. Interactive application security test (INTERACTIVE APPLICATION SECURITY TESTING, IAST): and combining a static method and a dynamic method, collecting and monitoring function execution and data transmission when the Web application program runs by using a instrumentation technique, and performing real-time interaction with a server to detect the loopholes. d. Manual code review: the source code is manually inspected by a professional to identify potential security issues.

The above detection technique inevitably causes the following problems: a. efficiency problem: conventional SAST and manual code review require a significant amount of time, which may take weeks or even months for large Web applications, with less efficiency. b. Accuracy problem: DAST, IAST, and fixed rule-based tools to detect vulnerabilities often create false positives or false negatives. c. Update delay problem: with the continuous advent of new attack techniques, if detection rules cannot be updated in time, there is an implicit security threat. d. Repair problems: after the security hole is detected in the prior art, a developer is required to repair according to experience, and the artificial and subjective repair can cause incomplete repair or introduce a new security hole in the repair process.

Therefore, the application provides a method for processing security holes, which discovers and digs potential security holes in Web application in a mode of simulating malicious attacks. Specifically, a large language model (Large Language Model, LLM) is utilized to sniff a target application, automatically generate a test script, and discover potential security vulnerabilities by executing the test script in a test environment to simulate an attacker to attack the target application. After the security holes are detected, hole repair suggestions are provided for developers, so that the security holes in the Web application can be efficiently and accurately detected and repaired.

Fig. 2 is a flow chart of a method for handling security vulnerabilities according to the present application.

S201, determining at least one security hole type to be tested corresponding to the target application.

The target application is the target Web application, namely the Web application to be tested. Security vulnerabilities in Web applications can be broadly divided into command injection vulnerabilities, cross-site scripting attacks (Cross SITE SCRIPTING, XSS), cross-site request forging (Cross Site Request Forgery, CSRF), session hijacking, file uploading vulnerabilities, SQL injection vulnerabilities, unauthorized access vulnerabilities, and the like. Cross site scripting attack and SQL injection vulnerabilities are described in detail below by way of example.

Cross-site scripting refers to an attacker inserting malicious hypertext markup language (Hyper Text Markup Language, HTML) code into a Web page, embedding the malicious HTML code into the Web page when the user browses the Web page, thereby stealing user information or otherwise violating user security privacy.

SQL injection loopholes refer to SQL injection threats generated when an application programs splice content input by a user into SQL sentences to be submitted to a database for execution. Because the input of the user is also a part of the SQL sentence, an attacker can inject a custom sentence by utilizing the controllable content of the part, change the execution logic of the SQL sentence and enable the database to execute the custom instruction. By controlling part SQL sentences, an attacker can inquire any data required by the attacker in the database, and can directly acquire the system authority of the database server by utilizing the characteristics of the database.

The security hole types which may exist in the target application are limited, so that whether the target application has the enumerated security hole types can be judged one by one.

Further, the type of security hole to be tested can be determined according to the features of the target application, such as the function, the API endpoint, the URL structure and the like. For example, assuming the target application is a login interface, it may be determined that the target application may have SQL injection holes, and at this time, it is not necessary to verify whether the target application has file upload holes. For another example, assuming that the target application includes a file upload interface, it may be determined that the target application may have a file upload vulnerability.

It should be appreciated that more than one security hole may exist for a Web application, and therefore, in determining the type of security hole to be tested that matches the target application, at least one type of security hole to be tested should be selected for subsequent testing. The application does not limit the number of security hole types to be tested, and it can be understood that the more the number of the determined security hole types to be tested is, the more comprehensive the security hole detection of the target application is.

S202, processing source codes corresponding to target applications by utilizing a large language model LLM aiming at each security vulnerability type to be tested in at least one security vulnerability type to be tested, and generating at least one test script corresponding to the security vulnerability type to be tested.

The large language model LLM, also known as a large language model, is an artificial intelligence language model that aims to understand and generate human language. Large language models are trained on large amounts of text data and can perform a variety of tasks including code understanding, code generation, emotion analysis, and the like.

Illustratively, the large language model may be an open source artificial intelligence large language model (Large Language Model Meta AI, LLaMA).

In one implementation, the large language model may be deployed in a local server. Therefore, the target application does not need to be uploaded to the cloud for processing, and leakage of privacy data such as source codes can be avoided.

The source code corresponding to the target application includes HTML code. The nature of Web applications is HTML, which is interpreted by a browser to present data to a user. By using other Web technologies in combination, such as scripting languages, public gateway interfaces, components, etc., powerful Web applications can be created.

For each security hole type to be tested in the at least one security hole type to be tested determined in step S201, since the large language model has the capability of understanding codes and the training data also includes various technical documents, security research reports, a hole database, and the like, how to detect whether the security hole type to be tested exists in the source code corresponding to the target application can be queried to the large language model. And automatically generating a test script corresponding to the security hole type to be tested by the large language model according to the requirement of the inquiry. Since security vulnerabilities may exist in a variety of trigger conditions, test scripts generated by a large language model may also exist in a plurality.

S203, executing the test script in the test environment for each test script in the at least one test script, and judging whether the test script successfully detects the security hole.

In order to avoid the loss of the target application in the real production environment (the environment for users) caused by simulation attack, the embodiment of the application executes the test script in the test environment after the test script is taken. The test environment is generally a relevant configuration for cloning a production environment, is an excessive environment from a development environment to the production environment, is generally deployed on a server proprietary to a company or a local area network server, and is mainly used for testing whether the code has defects.

And executing the test scripts generated by the large language model in the test environment one by one, and judging whether the test scripts successfully trigger the security vulnerabilities of the corresponding types according to the execution result. For example, assuming that the target application has a login interface at this time, when the executed test script detects the SQL injection hole, after the execution, the login verification is actually bypassed and the login is successful, then it may be determined that the test script successfully detects the security hole and is the SQL injection hole.

Illustratively, assume that the form source code for user login in the target application is as follows:

<form action＝"/login"method＝"POST">

<p>Username:<input type＝"text"name＝"username"/></p>

<p>Password:<input type＝"password"name＝"password"/></p>

< p > < input type= "subset" value= "login"/> </p > </form >

In the code, after the user inputs the user name and the password, the user inquires whether the user name and the password correspond to each other in the database through the back end, if so, the user can log in when the user password is correctly input, and if not, the user password cannot log in when the user password is incorrectly input.

Illustratively, assume that the query statement in the target application that the backend queries in the database is as follows:

let querySQL＝`SELECT*FROM user WHERE username＝'${username}'AND psw＝'${password}'`；

Normally, the SQL statement execution should be SELECT FROM user WHERE username = 'admin' AND psw= 'password', but if the user name has some characters related to the SQL execution, the SQL statement execution will change, for example, the user name contains "'OR'1 '=' 1", AND the password is input at will, the query statement becomes: SELECT FROM user WHERE username = "OR '1' = '1'", since OR '1' = '1' is always true, so that its authentication will pass, successfully logged in, regardless of whether the password is correct OR not.

Therefore, when similar commands exist in the test script, whether SQL injection holes exist can be detected by judging whether logging is successful or not. For example, a test script generated by a large language model for SQL injection security hole testing may be "Curl-X POST https:// test-web-app.com/logic-d" user=admin ' OR '1' = '1'; - - & password = random "", which uses the curl tool to attempt to send a POST request containing the SQL injection payload to the login interface of the target application. If the admin account is successfully logged in, the target application is indicated to have SQL injection security holes.

It should be appreciated that the test scripts generated by the large language model for different security hole types may be one or more, since the trigger conditions are not identical even for the same type of security hole. For example, when the security hole type to be tested is a file upload hole, the test script of the large language model may be a script for detecting malicious JS, a script for detecting directory traversal attack, or the like.

By executing the test script given by the large language model in the test environment, whether the corresponding type of security hole exists or not can be intuitively judged according to the execution result, and the result is actually verified and has higher credibility. Compared with the prior art that the large language model directly analyzes the source code to give out the existing loopholes, the method is more convincing and has higher accuracy.

S204, when the security hole is successfully detected, determining a hole repair suggestion according to the detected security hole information and source codes.

Wherein the vulnerability information is used to characterize the detected security vulnerability.

The vulnerability information of the security vulnerability is used for uniquely identifying the vulnerability, and the vulnerability information comprises the characteristics of the security vulnerability, such as the name, the type, the attack path, the return result and the like. The attack path refers to a way that an attacker uses the security hole to perform malicious operation, and the return result is a result which is caused by triggering the security hole. After determining that the target application has a security hole in step S203, the present application automatically provides corresponding hole repair suggestions for developers according to the detected security hole information and source codes.

Even the same type of security hole, the triggering conditions may be different, and in the source code, that is, the problem code possibly causing the security hole is not unique, so that the method for providing the hole repair suggestion directly according to the hole information is not specific, the given repair suggestion is wider, and the follow-up needs to be screened one by one, so that the efficiency is not high. Therefore, the method combines the source code to carry out specific analysis, and provides specific feasible bug fix suggestions through mutual comparison of the source code and bug information.

S205, responding to the confirmation operation input by the developer, and repairing the detected security vulnerabilities according to the vulnerability repairing suggestions.

Bug fixes often contain modifications to the source code, thus requiring the developer to confirm the specific modification. In other words, the bug fix suggestion provided in step S204 is a feasible technical solution, and it is required to confirm whether or not to execute and how to execute the bug fix suggestion by the developer to ensure stability and integrity of the target application.

In the embodiment of the application, the penetration test is carried out by executing the test script in the test environment, potential security holes in the target application are automatically found and mined, and the hole repair suggestion is timely given. Compared with the traditional manual inspection code, the method provided by the application has higher efficiency and higher credibility.

FIG. 3 is a flow chart of a method for determining bug fix suggestions provided by the present application. The steps in fig. 3 can be regarded as one specific example of step S204.

When the security vulnerability of the target application is detected, and the vulnerability information of the security vulnerability is known, including the characteristics of the name, the type, the attack path, the return result and the like of the security vulnerability, the vulnerability restoration suggestion can be given even if the vulnerability information is only used. However, these repair suggestions are only a general solution and are not targeted. And, even with the same type of security hole, there may be multiple trigger conditions. Reflecting in the source code, both the code blocks a and B may cause the security hole P, so further detailed analysis of the source code is required to determine what part of the code the security hole P is. Then, the problem code causing the security hole is repaired in a targeted manner. Specifically, the method of determining vulnerability fix suggestions includes the following steps.

S301, performing code analysis on the source code to obtain a code analysis result.

In one implementation, the code analysis results include a static code analysis result and a dynamic code analysis result, wherein the static code analysis result is obtained by performing a static code analysis on the source code, and the dynamic code analysis result is obtained by performing a dynamic code analysis on the source code.

In one implementation, the source code may be scanned using a static analysis tool to obtain static code analysis results. Static analysis tools are a technique by which code can be checked without running the code. The static analysis tool can discover potential errors, security holes and other problems of source codes in coding based on preset coding rules. Illustratively, the static analysis tool may be SonarQube et al. The embodiment of the present application is not limited as to which static analysis tool is specifically used.

In one implementation, a dynamic analysis tool may be used to analyze the target application behavior to obtain dynamic code analysis results. The dynamic analysis tool is a tool for detecting when a program runs. The execution flow is changed to a controllable state by monitoring the run-time behavior of the target application, such as a database query process, a file operation process, a network communication process, and the like.

S302, screening target code analysis results related to the vulnerability information from the code analysis results.

Because the static code analysis result and the dynamic code analysis result often contain repeated information and information irrelevant to security holes. For some large-scale applications, a large number of warnings and error prompts appear in the code analysis results, so that it is necessary to screen out target code analysis results related to the vulnerability information from the code analysis results. That is, not all warnings and errors in the code analysis result can cause security holes, and the application firstly performs screening operation, thereby being beneficial to reducing false alarms.

In one implementation, the code analysis result obtained in step 301 may be deduplicated, and then screened by using the keywords in the vulnerability information, where the screened code analysis result is determined to be the target code analysis result. Or in another implementation, the similarity between the vulnerability information and the code analysis result can be judged by using the neural network model, and the code analysis result with the similarity larger than the preset threshold value is determined as the target code analysis result. It should be noted that, in the embodiment of the present application, a specific means for obtaining the analysis result of the target code by screening is not limited.

Further, the problem code may be located while the object code analysis result is obtained. In one implementation, an abstract syntax tree (Abstract Syntax Tree, AST) may be built on the problem code, analyzing the code logic of the problem code in depth, thereby determining precisely and comprehensively where the problem is. An abstract syntax tree is an abstract representation of the source code syntax structure, representing the syntax structure of the programming language in tree form. It should be appreciated that the object code analysis results may also include analysis results from constructing an abstract syntax tree for analysis.

Furthermore, the instrumentation technique can be utilized to dynamically track the problem code path while obtaining the analysis result of the target code, so as to obtain the detailed execution flow and execution state. The instrumentation technique is to insert probes at specific locations of an application program to collect information in a problem code (e.g., methods, parameter values, return values, etc. in the problem code) on the basis of ensuring the logical integrity of the original application program, thereby collecting the dynamic execution flow and execution state of the program during running. It should be appreciated that the object code analysis results may also include analysis results obtained by dynamically analyzing the problem code using instrumentation techniques.

S303, matching the bug fix suggestions corresponding to the target code analysis results from the fix policy library.

The repair policy library is pre-established and comprises a plurality of bug repair suggestions corresponding to a plurality of security vulnerabilities, wherein the bug repair suggestions generally comprise repair policies and repair code examples. The repair strategy refers to the idea of repairing the security hole, and the repair code example is an intuitive presentation of the repair strategy in a code form. Based on the object code analysis results, relevant bug fix suggestions can be matched from the fix policy library. In one implementation, the keywords in the target code analysis result can be directly matched, and the similarity matching between the target code analysis result and the repair suggestions in the repair policy library can be used to obtain the corresponding bug repair suggestions.

In one implementation, when the bug fix suggestion corresponding to the target code analysis result is not matched from the fix policy library, the bug information and the target code analysis result may be integrated according to a second preset template to obtain second hint information, and the second hint information is processed by using the large language model LLM to obtain the bug fix suggestion. For example, a large language model may be queried "how to fix P vulnerabilities that occur in B code blocks, assuming you are a security vulnerability fix expert? Please give a specific repair suggestion ", the large language model may output the corresponding repair suggestion in a customized manner.

In one implementation, a developer may feedback provided repair suggestions, and the repair policy library may be iteratively updated in response to developing input feedback information including evaluations and supplements presented by the developer for vulnerability repair suggestions. For example, a developer may find that the repair suggestion M is not applicable or that there is a better repair approach N, and by collecting these feedback, the repair policy library may be continuously refined in order to improve the accuracy and practicality of the repair suggestion.

FIG. 4 is a schematic diagram of a system for handling security vulnerabilities provided by the present application.

As shown in fig. 4, the system 1000 includes a sniffing and attempting module 1001, a code checking module 1002, a repair suggestion generation module 1003, and an alerting module 1004.

The sniff and try module 1001 generates test scripts using the large language model LLM and tests the target application for potential security vulnerabilities.

The type of security hole to be tested of the target application needs to be determined first, and can be determined according to the features of the target application, such as functions, URL addresses and the like. In general, there are often multiple types of security vulnerabilities to be tested. And then taking the source code of the target application as the input of the large language model to obtain a test script corresponding to the type of the security hole to be tested.

In one implementation, for each security hole type to be tested in at least one security hole type to be tested, a source code corresponding to a target application and the security hole type to be tested can be integrated according to a first preset template to obtain first prompt information; and processing the first prompt information by using a large language model LLM to generate at least one test script corresponding to the security hole type to be tested. For example, assuming that the source code of the target application is denoted by "< code >" and the type of security hole to be tested is denoted by "P", the first hint information integrated according to the first preset template may be "assuming that you are a test expert, how to test the security hole P for the HTML code described below? Please give test script. < code > ". And taking the first Prompt information as the Prompt of the large language model, so that the large language model can output a test script relative to the type of the security hole to be tested.

The sniff and try module 1001 then executes the test script generated by the large language model in the test environment. And judging whether the target application has a corresponding security hole according to the execution result. If the security hole of the type is judged to exist, the hole information of the security hole is recorded, and if the security hole of the type is judged not to exist, the security hole corresponding to the test script is marked as empty.

When the sniffing and attempting module 1001 detects a security breach, the breach information of the detected security breach is recorded and sent to the code checking module 1002. The code check module 1002 performs code analysis on the source code of the target application to determine the problem code that caused the security hole. And based on the results of the code check module 1002, the alert module 1004 may send alert information to the developer. The alarm information is used for identifying the security hole of the code. Specifically, the alarm module 1004 may alarm by means of a short message, mail, or pop-up notification. The application is not limited to the form of the alarm.

After locating the problem code that caused the security hole, the fix suggestion generation module 1003 combines the problem code and the type of the detected security hole to provide a specific fix suggestion to the developer. The implementation process of the repair suggestion generation module 1003 is described with reference to fig. 3, and will not be described herein.

In one implementation, the repair suggestion generation module 1003 further reports the detected vulnerability information, the code analysis result and the vulnerability repair suggestion generation vulnerability report to a developer, and waits for the developer to confirm whether to repair the security vulnerability according to the provided vulnerability repair suggestion. When the developer confirms that the repair is performed according to the provided repair suggestion, in response to the confirmation operation input by the developer, the system 1000 automatically repairs the security hole of the target application according to the repair suggestion.

In addition, in one implementation, the developer may also modify or supplement the provided repair suggestion, and after confirmation of submission, the system 1000 automatically performs the repair process according to the modified or supplemented repair suggestion.

The embodiment of the application provides the test command by using the large language model, automatically sniffs and tries to detect the potential security holes in the target application, and effectively improves the detection efficiency. Meanwhile, the method provided by the embodiment of the application also provides professional bug fix suggestions for developers to refer by combining bug information and specific source codes, so that the bug fix efficiency is effectively improved. In addition, under the condition that the existence of the loopholes of the target application is known, the method can accurately locate the problem codes causing the security loopholes in the source codes of the target application by screening the code analysis results, and then specific executable loophole restoration suggestions are given to the problem codes.

The method of the embodiment of the present application is mainly described above with reference to the drawings. It should be noted that all values presented above are only examples and do not limit the application in any way. It should also be understood that, although the steps in the flowcharts related to the embodiments described above are shown in order, these steps are not necessarily performed in the order shown in the figures. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages. The following describes an apparatus according to an embodiment of the present application with reference to the accompanying drawings. For brevity, the description of the apparatus will be omitted appropriately, and the related content may refer to the related description in the description of the method above, and the description will not be repeated.

Fig. 5 is a schematic structural diagram of an apparatus for handling security vulnerabilities according to the present application.

As shown in fig. 5, the apparatus 2000 includes a detection unit 2001 and a repair unit 2002. The apparatus 2000 is capable of performing any of the methods of handling security vulnerabilities described above. For example, the detection unit 2001 may be used to perform steps S201 to S203, and the repair unit 2002 may be used to perform steps S204 to S205. For another example, the repair unit 2002 may be used to perform the steps in fig. 3.

In one implementation, the apparatus 2000 may further include a storage unit, configured to store data such as vulnerability information. The memory unit may be integrated in any one of the above units, or may be a unit independent of all the above units.

Fig. 6 is a schematic structural diagram of an electronic device provided by the present application. As shown in fig. 6, the electronic apparatus 3000 of this embodiment includes: at least one processor 3001 (only one is shown in fig. 6), a memory 3002, and a computer program 3003 stored in the memory 3002 and executable on the at least one processor 3001, the steps in the above embodiments being implemented by the processor 3001 when executing the computer program 3003.

The Processor 3001 may be a central processing unit (Central Processing Unit, CPU), the Processor 3001 may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSPs), application SPECIFIC INTEGRATED Circuits (ASICs), off-the-shelf Programmable gate arrays (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

Memory 3002 may be an internal storage unit of electronic device 3000 in some embodiments, such as a hard disk or memory of electronic device 3000. The memory 3002 may also be an external storage device of the electronic device 3000 in other embodiments, such as a plug-in hard disk provided on the electronic device 3000, a smart memory card (SMART MEDIA CARD, SMC), a Secure Digital (SD) card, a flash memory card (FLASH CARD), or the like. Further, the memory 3002 may also include both internal storage units and external storage devices of the electronic device 3000. The memory 3002 is used for storing an operating system, application programs, boot Loader (Boot Loader) data, other programs, and the like, such as program codes of computer programs, and the like. The memory 3002 may also be used to temporarily store data that has been output or is to be output.

It should be noted that, because the content of information interaction and execution process between the above units is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and will not be described herein.

It will be apparent to those skilled in the art that the above-described functional units are merely illustrated in terms of division for convenience and brevity, and that in practical applications, the above-described functional units and modules may be allocated to different functional units or modules according to needs, i.e., the internal structure of the apparatus may be divided into different functional units or modules to perform all or part of the above-described functions. The functional units in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, the specific names of the functional units are also only for distinguishing from each other, and are not used to limit the protection scope of the present application. The specific working process of the units in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

The embodiments of the present application also provide a computer readable storage medium storing a computer program, which when executed by a processor implements steps of the above-described respective method embodiments.

The computer readable medium may include at least: any entity or device capable of carrying computer program code to a camera device/electronic apparatus, a recording medium, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.

Embodiments of the present application provide a computer program product enabling the implementation of the above-mentioned methods when the computer program product is run on a computer. The computer program comprises computer program code which may be in source code form, object code form, executable file or in some intermediate form, etc.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each of the method embodiments described above.

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application. In the description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

Furthermore, in the description of the application and the claims that follow, the terms "comprise," "include," "have" and variations thereof are used to mean "include but are not limited to," unless specifically noted otherwise.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus, computer device and method may be implemented in other manners. For example, the apparatus, computer device embodiments described above are merely illustrative, e.g., the partitioning of elements is merely a logical functional partitioning, and there may be additional partitioning in actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims (10)

1. A method of handling security vulnerabilities, comprising:

determining at least one security hole type to be tested corresponding to a target application;

Processing source codes corresponding to the target application by utilizing a large language model LLM aiming at each security vulnerability type to be tested in the at least one security vulnerability types to be tested, and generating at least one test script corresponding to the security vulnerability type to be tested;

executing the test script in a test environment for each test script in the at least one test script, and judging whether the test script successfully detects the security hole;

When the security hole is successfully detected, determining a hole repair suggestion according to the hole information of the detected security hole and the source code, wherein the hole information is used for representing the characteristics of the detected security hole;

And responding to a confirmation operation input by a developer, and repairing the detected security vulnerability according to the vulnerability repairing suggestion.

2. The method of claim 1, wherein the processing the source code corresponding to the target application with the large language model LLM for each security hole type to be tested in the at least one security hole type to be tested, generating at least one test script corresponding to the security hole type to be tested, comprises:

Integrating a source code corresponding to the target application and the security hole type to be tested according to a first preset template aiming at each security hole type to be tested in the at least one security hole type to be tested to obtain first prompt information;

And processing the first prompt information by using the large language model LLM to generate at least one test script corresponding to the security vulnerability type to be tested.

3. The method of claim 1, wherein when a security breach is successfully detected, determining a breach remediation recommendation based on the detected breach information of the security breach and the source code, comprises:

performing code analysis on the source code to obtain a code analysis result;

Comparing the detected vulnerability information of the security vulnerability, and screening out target code analysis results related to the vulnerability information from the code analysis results;

And matching the bug repair suggestions corresponding to the target code analysis result from a repair policy library, wherein the repair policy library comprises a plurality of bug repair suggestions corresponding to various security bugs, and the bug repair suggestions comprise repair policies and repair code examples.

4. A method according to claim 3, wherein the code analysis results comprise static code analysis results obtained by static code analysis of the source code and dynamic code analysis results obtained by dynamic code analysis of the source code.

5. A method according to claim 3, characterized in that the method further comprises:

And when the bug repairing suggestion corresponding to the target code analysis result is not matched in the repairing policy library, integrating the bug information and the target code analysis result according to a second preset template to obtain second prompting information, and processing the second prompting information by using the large language model LLM to obtain the bug repairing suggestion.

6. A method according to claim 3, characterized in that the method further comprises:

And responding to feedback information input by a developer, and updating the repair strategy library, wherein the feedback information comprises evaluation and supplement proposed by a user for the bug repair suggestion.

7. The method according to any one of claims 1 to 6, further comprising:

And generating a bug report by using the bug information of the detected security bug, the target code analysis result and the bug repairing suggestion, and reporting the bug report to a developer, and waiting for the developer to confirm whether to repair the security bug according to the bug repairing suggestion.

8. An apparatus for handling security vulnerabilities, comprising:

The detection unit is used for determining at least one security hole type to be tested corresponding to the target application; processing source codes corresponding to the target application by utilizing a large language model LLM aiming at each security vulnerability type to be tested in the at least one security vulnerability types to be tested, and generating at least one test script corresponding to the security vulnerability type to be tested; executing the test script in a test environment for each test script in the at least one test script, and judging whether the test script successfully detects the security hole;

The repairing unit is used for determining a bug repairing suggestion according to bug information of the detected security bug and the source code when the security bug is successfully detected, wherein the bug information is used for representing the characteristics of the detected security bug; and responding to a confirmation operation input by a developer, and repairing the detected security vulnerability according to the vulnerability repairing suggestion.

9. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, causes the electronic device to implement the method of any one of claims 1 to 7.

10. A computer readable storage medium storing a computer program, characterized in that the computer program, when executed by an electronic device, implements the method of any one of claims 1 to 7.