JP7488976B1 - Security Test System - Google Patents

Abstract

[Problem] Supports the user in manually examining application vulnerabilities automatically detected by methods such as DAST to determine whether the detection was correct or incorrect, and in providing countermeasures. [Solution] The system has an inspection execution unit 11 that inspects a target website 3 for vulnerabilities, records information related to the detected vulnerabilities as inspection results 13 and presents them to the user, and a dialogue processing unit 12 that accepts questions related to the target vulnerability designated by the user, creates answers using the LLM 4, and responds to the questions, and the dialogue processing unit 12 inputs detailed information related to the target vulnerability to the LLM 4. [Selected Figure] Figure 1

Description

The present invention relates to application testing technology, and in particular to technology that is effective when applied to a security testing system that checks for vulnerabilities in web applications.

Web applications are premised on the use of a network, so from a security perspective it is extremely important to inspect and test for vulnerabilities. There are a variety of tools and services available for inspecting web applications for vulnerabilities, and these are being investigated and developed on a daily basis.

Web application security testing methods can be broadly divided into SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). While SAST statically analyzes source code, etc., DAST sends simulated attack (inspection) requests from an external source, based on an attacker's perspective, to a running application and determines whether there are any vulnerabilities from changes in the application's behavior (response).

As an example of a technology related to security testing using such a method, JP2023-545625A (Patent Document 1) describes a method for triaging software vulnerabilities by using methods such as SAST and DAST to scan software to detect potential vulnerability issues, generating an electronic document report that lists these issues, extracting features for each potential vulnerability issue from the electronic document report, determining a vector based on the extracted features and a token determined based on the source code of the potential vulnerability issue, selecting a vulnerability scoring method based on the vector, and determining a vulnerability accuracy score.

JP 2023-545625 A

According to conventional technology, it is possible to identify the most relevant vulnerabilities and propose solutions by scanning software for vulnerabilities using techniques such as SAST and DAST and quantifying the degree of vulnerability (possibility of attack).

On the other hand, when using DAST as a security testing method, DAST is a black-box method in which a simulated attack is performed from the outside on a running application to determine whether or not there is a vulnerability, so it is difficult to fully understand the internal processing of the application at the time of the attack, and errors may occur in detecting vulnerabilities. In particular, in the case of a system that automatically performs inspection and diagnosis, such as a security test system, there is a higher possibility of false positives compared to manual inspection and diagnosis. Therefore, users must manually examine automatically detected vulnerabilities to determine whether they are true positives or false positives.

At this time, a user with knowledge of application vulnerabilities can focus on the appropriate information from the detailed information related to the automatically detected vulnerability and perform a highly accurate examination. On the other hand, a user with no knowledge of vulnerabilities may not know what to focus on in order to make a judgment, and may not be able to perform an appropriate examination. Furthermore, even when a vulnerability is correctly detected, there may be cases where the user is unable to determine how to specifically modify the source code, for example.

The object of the present invention is to provide a security testing system that assists users in manually examining application vulnerabilities that are automatically detected using techniques such as DAST to determine whether the detection is correct or incorrect, and that supports the user in presenting countermeasures.

The above and other objects and novel features of the present invention will become apparent from the description of this specification and the accompanying drawings.

The following is a brief summary of the representative inventions disclosed in this application:

A security test system that is a representative embodiment of the present invention is a security test system that checks for security vulnerabilities in a Web application, and includes an inspection execution unit that checks for vulnerabilities in the Web application, records information related to the detected vulnerabilities as inspection results, and presents the results to a user, and a dialogue processing unit that accepts questions related to target vulnerabilities specified by the user in the inspection results, creates answers using an LLM (large-scale language model), and answers the questions. The dialogue processing unit inputs detailed information related to the target vulnerabilities to the LLM.

The effects achieved by the representative inventions disclosed in this application can be briefly explained as follows:

In other words, according to a representative embodiment of the present invention, in a website vulnerability inspection system, it becomes possible to assist users in manually examining vulnerabilities automatically detected by a method such as DAST to determine whether the detection was correct or incorrect, and to present countermeasures to the user.

1 is a diagram showing an overview of a configuration example of a security test system according to an embodiment of the present invention. 1 is a flowchart outlining an example of a process flow for vulnerability testing in one embodiment of the present invention. FIG. 1 is a diagram showing an overview of an example of vulnerability testing according to an embodiment of the present invention. 1A and 1B are diagrams outlining examples of vulnerability testing patterns according to an embodiment of the present invention. FIG. 13 is a diagram outlining an example of a prompt for inputting vulnerability details into an LLM in one embodiment of the present invention. FIG. 11 outlines example prompts for prompting the LLM to determine information required to respond in one embodiment of the present invention. FIG. 11 outlines example prompts that may cause an LLM to generate responses in one embodiment of the present invention. 13A to 13C are diagrams outlining examples of replies on a chat screen according to an embodiment of the present invention. FIG. 2 is a diagram showing an overview of an example of a data configuration of a test result in one embodiment of the present invention. FIG. 2 is a diagram showing an overview of an example of a data configuration of a vulnerability master according to an embodiment of the present invention.

The following describes in detail an embodiment of the present invention with reference to the drawings. In all drawings used to explain the embodiment, the same parts are generally given the same reference numerals, and repeated explanations will be omitted. However, there are cases where parts that have been described with reference numerals in one drawing will be referred to with the same reference numerals when explaining other drawings, although they will not be shown again.

＜Overview＞
As described above, the DAST website security test is a black-box method in which a request related to a pseudo attack is sent from the outside to a running application, and the presence or absence of a vulnerability is judged based on the response from the application to the request. Therefore, it is difficult to fully grasp the internal processing of the application during an attack, and errors may occur in vulnerability detection. In particular, in the case of a system that automatically performs inspection and diagnosis, such as a security test system, the possibility of false positives is higher than in manual inspection and diagnosis. Therefore, the user needs to manually examine whether an automatically detected vulnerability is a true positive or a false positive.

When conducting an examination, the information to focus on varies depending on the type of vulnerability and the inspection pattern, as described below. For example, there are cases where the original request (before tampering) to the application should be focused on, and cases where the response to the request after tampering should be focused on. There are also cases where the difference between the response to the original request and the response to the request after tampering should be focused on. In this case, a user with knowledge of vulnerabilities can perform an examination with high accuracy by focusing on the appropriate information from the detailed information related to the automatically detected vulnerability. On the other hand, a user with no knowledge of vulnerabilities may not know what to focus on in order to make a judgment, and may not be able to perform an appropriate examination. In addition, even when a vulnerability is correctly detected, there may be cases where it is not possible to determine the countermeasure, such as how to specifically modify the source code.

Furthermore, DAST is merely a black-box inspection method for applications, and is not an inspection method that requires an understanding of the internal structure of the application. Therefore, when a user inspects an application, the accuracy of determining whether or not it is a false positive can be improved by providing knowledge about the various technical elements that make up the application (for example, source code, framework settings, etc.). However, in the case of a security testing system or other system that automatically performs inspection and diagnosis, it is not possible to know internal information that would be useful for inspection from outside the application. Therefore, this information needs to be provided separately by the administrator or developer of the application.

The security testing system according to one embodiment of the present invention interactively accepts and answers questions from users in chatbot format regarding the examination and countermeasures for vulnerabilities automatically detected in a target application using techniques such as DAST. When answering, the system determines in advance the information required for the answer and answers based on the information provided by the user, thereby improving the accuracy of the answer. Furthermore, by using generative AI (Artificial Intelligence) and LLMs (Large Language Models) (hereinafter, these may be collectively referred to as "LLMs") to collect the above-mentioned information and answer questions, the system realizes judgments equivalent to those of a knowledgeable user about vulnerabilities.

<System Configuration>
1 is a diagram showing an overview of an example of the configuration of a security test system according to an embodiment of the present invention. The security test system 1 is configured, for example, by a server device or a virtual server constructed on a cloud computing service, and is configured such that a user terminal 2 such as a PC (Personal Computer) used by a user accesses the system using a web browser or a dedicated application (not shown) via a network such as the Internet, a VPN (Virtual Private Network), or a LAN (Local Area Network) (not shown).

The security test system 1 realizes various functions related to the implementation of security tests by, for example, using a CPU (Central Processing Unit) (not shown) to execute middleware such as an OS (Operating System), a DBMS (DataBase Management System), and a Web server program that are deployed onto memory from a recording device such as a HDD (Hard Disk Drive) or SSD (Solid State Drive), and software that runs on the OS and the DBMS. This security test system 1 has various parts such as an inspection execution unit 11 and an interaction processing unit 12 that are implemented by software. It also has various data stores such as an inspection result 13 implemented by a database, file table, etc., and a vulnerability master 14.

The inspection execution unit 11 has a function of inspecting vulnerabilities using the DAST method for each web page in the target website 3 that is the inspection target. That is, for each target web page, when sending a request to the target website 3, it sends a pseudo attack request by, for example, entering invalid values in a form. It then analyzes the response from the target website 3 to determine whether or not there is a vulnerability, and records the determination result in the inspection result 13.

The dialogue processing unit 12 has a function of accepting and answering questions from the user about the examination and countermeasures for the vulnerabilities detected by the inspection execution unit 11 in a chatbot format via the user terminal 2. In this embodiment, the configuration is such that questions are accepted and answered interactively in a chatbot format, but the user interface for questions and answers is not limited to this. When answering, the information required for the answer is determined using an external or internal LLM 4, and an answer is generated by the LLM 4 based on the content of this information provided by the user. Details of the processing in the dialogue processing unit 12 will be described later.

<Processing flow>
2 is a flowchart outlining an example of a process flow of vulnerability testing in an embodiment of the present invention. First, the testing execution unit 11 tests the target website 3 for vulnerability using DAST. In the test, a first loop process is started (S01), which repeats all URLs (Uniform Resource Locators) to be tested in the target website 3. The URLs to be tested are obtained and listed in advance, for example, by automatically crawling the target website 3 and analyzing the links in each web page. In the first loop process, a scenario is played back to send an original (before tampering) request to the target URL (S02).

Figure 3 is a diagram outlining an example of vulnerability testing in one embodiment of the present invention. Here, the diagram shows that, as an original (before tampering) scenario, a request as shown in the diagram below is sent via HTTP (Hyper Text Transfer Protocol) to the URL to be processed, which is surrounded by a dashed line in the list of URLs to be tested as shown in the diagram above, and the response shown in the diagram is obtained.

Returning to FIG. 2, a second loop process is then started, which repeats all of the preset test patterns (S03). In the second loop process, a scenario is played back in which a request tampered with according to the test pattern being processed is sent to the URL being processed (S04). Then, based on the response from the web page related to the URL being processed, it is determined whether or not a vulnerability has been detected (S05), and the process moves to the next test pattern (S06).

Figure 4 is a diagram outlining an example of a vulnerability testing pattern in one embodiment of the present invention. Figure 4(a) shows an example of a tampered request and a response to the request in one testing pattern for testing SQL (Structured Query Language) injection. In SQL injection, a request is tampered with by embedding an invalid SQL statement. The example in Figure 4(a) shows that the portion of the request surrounded by a dashed line has been tampered with from the original request shown in the example in Figure 3 above, and that there is no difference between the content of the response to this request and the response shown in the example in Figure 3 above. In the case of this testing pattern, if there is no difference between the response to the original request and the response to the tampered request, it is determined that an SQL injection vulnerability has been detected.

On the other hand, FIG. 4(b) shows an example of a tampered request and a response in one of the test patterns for testing cross-site scripting. In cross-site scripting, a request is tampered with to embed a malicious script in the target website 3, which is then executed when accessed by a third party. The example in FIG. 4(b) shows that the part surrounded by the dashed line in the request has been tampered with from the original request shown in the example in FIG. 3 above, and that there is a difference in the content of the response to this request from the response shown in the example in FIG. 3 above, as shown in the example in the figure. In the case of this test pattern, it is determined that a cross-site scripting vulnerability has been detected if, for example, the <script> tag embedded in the request is also reflected in the response, as in the example in the figure.

In this way, depending on the inspection pattern, a vulnerability may be detected if there is no difference between the original request and response and the request and response related to the attack, or a vulnerability may be detected if there is a difference. In other cases, a judgment may be made based on the content of the response regardless of whether there is a difference. Since the information to focus on differs for each inspection pattern, in this embodiment, as described below, information regarding the logic used to detect and judge the presence or absence of a vulnerability for each inspection pattern (vulnerability) is input in advance to LLM4.

Returning to FIG. 2, when the second loop process is completed after steps S04 to S05 have been performed for all test patterns, the first loop process moves on to processing the next URL to be tested (S07). Then, when the first loop process is completed after steps S02 to S06 have been performed for all test target URLs, the dialogue processing unit 12 displays the test results for the target website 3 on the user terminal 2 (S08). For example, each detected vulnerability is displayed as a list, and for a vulnerability selected by the user from the list, the test pattern, URL, parameters within the web page, etc. are displayed on a details screen. Furthermore, a button such as "Ask a question" is displayed on the details screen, and when the user presses this button, questions about the target vulnerability can be accepted via a chat screen.

Then, it is determined whether the user has pressed a button such as "Consult" to launch the chat screen (S09). If the chat screen is not launched and the inspection result screen is closed by the user (No in step S09), the inspection process ends. On the other hand, if the chat screen is launched by the user (Yes in step S09), first the dialogue processing unit 12 inputs and instructs the LLM 4 to provide detailed information about the target vulnerability (S10).

Figure 5 is a diagram outlining an example of a prompt for inputting detailed vulnerability information to the LLM 4 in one embodiment of the present invention. Here, by generating a vulnerability detailed information input prompt as shown in the figure and inputting it to the LLM 4, necessary information for the target vulnerability (SQL injection in the example of Figure 5), such as an overview of the vulnerability, the logic used to detect it, and a method for determining whether it is a false positive, is obtained from the vulnerability master 14 and input into the LLM 4 in advance. Note that the information items shown in the example of Figure 5 are the bare minimum, and it goes without saying that other information items required for each vulnerability can be added. In this vulnerability detailed information input prompt, by instructing not to output a response, the process moves directly to the next step.

Returning to FIG. 2, the next process accepts input of a question from the user via the chat screen (S11). When input of a question is accepted, the dialogue processing unit 12 causes the LLM 4 to determine the information necessary to answer the question (S12), causes the LLM 4 to create an answer to the question based on the information determined to be necessary (S13), and displays the obtained answer to the user on the chat screen as an answer from the system (S14).

Figure 6 is a diagram outlining an example of a prompt for the LLM to determine the information required for answering in step S12 in one embodiment of the present invention. Here, a prompt for determining the information required for answering as shown in the upper diagram is generated and input to LLM4, and the information required for answering the question from the user is obtained as output from LLM4 as shown in the lower diagram.

The prompt for determining information required for an answer shown in the example of Figure 6 indicates, in addition to the target vulnerability and the content of the question from the user, the keys of information available for the answer (in the example of Figure 6, five types: tampered value (tamperedValue), original request (originalRequest), original response (originalResponse), request when tampered (tamperedRequest), and response when tampered (tamperedResponse)) and the data items included in the answer output in JSON (JavaScript Object Notation) format. In response to this prompt, the example of Figure 6 shows that in the JSON format output from LLM4, all five of the above keys are required as information (required) required to answer the question.

Note that in the prompt for determining information required for an answer shown in the example of Figure 6, two types of requests and responses are specified for the information available for the answer: original (during normal communication) and tampered (during an attack). However, depending on the vulnerability, multiple tamperings may be performed in a single attack, so two or more types of requests and responses may be specified for tampering. Also, the information available for the answer shown in the example of Figure 6 is just an example, and it goes without saying that other items of available information may be added.

Figure 7 is a diagram outlining an example of a prompt that causes LLM4 to create an answer in step S13 in one embodiment of the present invention. Here, an answer creation prompt such as that shown in the upper diagram is generated and input to LLM4, and an answer to the user's question such as that shown in the lower diagram is obtained as output from LLM4.

The answer creation prompt shown in the example of FIG. 7 indicates the target vulnerability and the content of the question from the user, as well as the information required for the answer obtained in step S12 (in the example of FIG. 7, the actual content of each of the tampered value, original request, original response, request when tampered, and response when tampered), and the items to be included in the output in JSON format. The actual content of the information required for the answer can be obtained, for example, from the inspection result 13. Note that there is an upper limit to the amount of information (number of tokens) that can be input into LLM4, so if the amount of information to be input is large, the limitations of LLM4 can be avoided, for example, by cutting out unnecessary parts of the actual content of the input request and response or by dividing and inputting them.

Figure 8 is a diagram outlining an example of a response on the chat screen in step S14 in one embodiment of the present invention. Figure 8(a) shows an example of a case where the response ends in one exchange. In this example, in response to a question from a user asking whether the detected vulnerability is a false positive, LLM4 presents the definitive response created in step S13 that there is a high possibility that it is a false positive, and the exchange ends.

On the other hand, FIG. 8(b) shows an example of a case where additional information is required from the user. Here, as in FIG. 8(a), in response to a question from the user as to whether the detected vulnerability is a false positive, LLM4 creates a response in step S13, but asks the user for confirmation because further information is needed to determine whether it is a false positive. It then shows that a definitive response is presented that there is a high possibility of a false positive based on the additional information entered by the user. In this way, by using LLM4, it is possible to answer questions while obtaining additional information from the user through repeated interactive exchanges.

Figure 8 (c) shows an example of presenting the user with a method for modifying the code of the target website 3 in response to a detected vulnerability. In this example, the system requests the user to input additional information (in the example shown in the figure, the current source code and technical information) in order to answer the user's question about how to modify the code. The system then shows an answer on how to modify the code based on the additional information entered by the user.

Note that questions from the user are expected to be questions related to the examination of the detected vulnerability, such as, for example, "Please explain why this vulnerability was detected," "Please confirm whether this vulnerability is a false positive," and "Please tell me what to do to confirm whether this vulnerability exists." In this case, the dialogue processing unit 13 and the LLM 4 can create a response based on, for example, the detailed information on the vulnerability input in step S10 described above and the information stored in the vulnerability master 14.

Questions about vulnerabilities in general, such as "Please explain SQL injection" or "Please tell me what kind of dangers there are if cross-site scripting is left unchecked," are also anticipated. In this case, the dialogue processing unit 13 and the LLM 4 can create answers based on information stored in the vulnerability master 14, for example.

It is also possible to envision a question about how to modify the target website 3, such as, for example, "Please tell me how to modify the code." In this case, the dialogue processing unit 13 and the LLM 4 can, for example, as described above, ask the user to input source code and technical information (language used, library, etc.) for the relevant part, and create a response based on the input information and the information stored in the vulnerability master 14.

As for questions from users, for example, the user may be allowed to freely input questions such as those described above through a chat screen, or anticipated questions may be prepared in advance as templates, from which the user may select and ask a question.

Returning to FIG. 2, the dialogue processing unit 13 determines whether or not the interaction with the user on the chat screen as shown in the example of FIG. 8 has ended (for example, whether or not the user has closed the chat screen) (S15), and if it has not ended (No in step S15), the process returns to step S11 and continues to accept input from the user on the chat screen. On the other hand, if the interaction with the user on the chat screen has ended (Yes in step S15), the inspection process ends.

In the series of processes shown in the example of Figure 2, the shaded processes (steps S10, S12, and S13) indicate that LLM4 is used.

<Data structure>
9 is a diagram showing an overview of an example of the data structure of the inspection result 13 in one embodiment of the present invention. The inspection result 13 is a table that holds information related to the result for each inspection of the target website 3 by the inspection implementation unit 11, and for example, has items such as an inspection ID, a URL parameter ID, an inspection pattern ID, and an inspection status as items related to the inspection, and has items such as a URL parameter ID, a URL, and parameters as items related to the inspected URL parameters. In addition, the request has items such as a request ID, a URL parameter ID, an original flag, a detected vulnerability ID, a tampering value, a request header, and a request body as items related to the response, and has items such as a response ID, a request ID, a response header, and a response body as items related to the response.

Among the items related to the test, the Test ID item holds ID information that uniquely identifies the target test. The URL parameter ID and test pattern ID items hold ID information that uniquely identifies the URL parameter and test pattern used in the target test, respectively. The detection status item holds information indicating whether or not a vulnerability was detected in the target test.

In the items related to the URL parameters to be inspected, the URL Parameter ID item holds ID information that uniquely identifies the URL parameter used in the target inspection. The URL and parameter items hold information on the URL to be inspected and the specified parameter, respectively.

In the items related to the request, the Request ID and URL Parameter ID items each hold ID information that uniquely identifies the request in the target inspection and the URL parameters used. The Original Flag item holds flag information (True if original) indicating whether the target request is an original request that has not been tampered with. The Detected Vulnerability ID and Tampering Value items are both items whose values are set only when the value of the above original flag is False (a tampered request), and each hold ID information that uniquely identifies a vulnerability detected in the target inspection and tampered value information in the target request. The Request Header and Request Body items each hold information related to the header and body contents in the target request.

In the response-related items, the response ID and request ID items hold ID information that uniquely identifies the response and request in the target test, respectively. The response header and response body items hold information related to the header and body contents of the target response, respectively.

Figure 10 is a diagram showing an overview of an example of the data configuration of the vulnerability master 14 in one embodiment of the present invention. The vulnerability master 14 is a table that holds master information related to known vulnerabilities, and has items such as a vulnerability ID, vulnerability name, detailed explanation, risk explanation, examination method explanation, and internal detection logic as items related to vulnerabilities, and has items such as an inspection pattern ID, vulnerability ID, and detection reason as items related to inspection patterns.

In the items related to vulnerabilities, the Vulnerability ID item holds information on an ID that uniquely identifies the target vulnerability. The Vulnerability Name item holds information on the name of the target vulnerability. The Detailed Description, Risk Description, and Examination Method Description items each hold information such as text explaining the details of the target vulnerability, the expected risks, and the method of examining whether or not the vulnerability truly corresponds to the target vulnerability. The Detection Internal Logic item holds information related to the contents of the internal logic used to detect the target vulnerability.

In the items related to the test pattern, the test pattern ID and vulnerability ID items respectively hold information on the test pattern for testing the target vulnerability and an ID that uniquely identifies the target vulnerability. The detection reason item holds information such as text explaining the detection reason when the target vulnerability is detected by the target test pattern.

As described above, according to the security test system 1, which is one embodiment of the present invention, questions from users regarding the examination and countermeasures for vulnerabilities automatically detected for the target website 3 by a method such as DAST can be interactively accepted and answered in chatbot format. When answering, the information required for the answer can be determined in advance, and the answer can be based on the information provided by the user, thereby improving the accuracy of the answer. Furthermore, by using the LLM 4 to collect the above-mentioned information and answer questions, it is possible to realize judgments equivalent to those of a user with knowledge of vulnerabilities.

The invention made by the inventor has been specifically described above based on the embodiment, but it goes without saying that the present invention is not limited to the above embodiment and can be modified in various ways without departing from the gist of the invention. Furthermore, the above embodiment has been described in detail to explain the invention in an easy-to-understand manner, and the invention is not necessarily limited to having all of the configurations described. Furthermore, it is possible to add, delete, or replace part of the configuration of the above embodiment with other configurations.

Furthermore, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits. Furthermore, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information on the programs, tables, files, etc. that realize each function can be stored in a recording device such as a memory, hard disk, or SSD, or in a recording medium such as an IC card, SD card, or DVD.

In addition, in each of the above diagrams, the control lines and information lines shown are those considered necessary for explanation, and do not necessarily show all of the control lines and information lines in the actual implementation. In reality, it can be assumed that almost all components are interconnected.

The present invention can be used in a security testing system that checks for vulnerabilities in web applications.

1...security test system, 2...user terminal, 3...target website, 4...LLM,
11: Test execution unit, 12: Dialogue processing unit, 13: Test result, 14: Vulnerability master

Claims (6)

A security test system for testing whether or not there is a security vulnerability in a web application, comprising:
an inspection execution unit that inspects the Web application for vulnerabilities, records information on the detected vulnerabilities as inspection results, and presents the information to a user;
a dialogue processing unit that receives a question related to a target vulnerability designated by a user in the test result, and creates and responds to the question using a large-scale language model (LLM);
The dialogue processing unit inputs detailed information related to the target vulnerability to the LLM. 2. The security test system according to claim 1,
The dialogue processing unit inputs a first prompt including the detailed information related to the target vulnerability to the LLM, inputs a second prompt to the LLM to determine necessary answer information required to answer the question from the user, obtains content related to the necessary answer information output from the LLM from the inspection results, inputs a third prompt to the LLM to answer the question from the user, and presents the content output from the LLM to the user as an answer. 2. The security test system according to claim 1,
The dialogue processing unit obtains the detailed information related to the target vulnerability from a vulnerability master that previously stores detailed information related to known vulnerabilities. 3. The security test system according to claim 2,
A security testing system in which the first prompt includes, as the detailed information related to the target vulnerability, at least a name of the target vulnerability, an explanatory information overview of the target vulnerability, logic for detecting the target vulnerability, and information related to a method for determining whether the detection of the target vulnerability is a false positive. 3. The security test system according to claim 2,
In a security test system, the information to be answered includes at least one of a request to the Web application and a response to the request, a tampered request to the Web application and a response to the request, and a value of the tampering. 2. The security test system according to claim 1,
The dialogue processing unit accepts the question based on a question selected by a user from a preset question template.

Images