Vulnerability processing method and device, equipment and storage medium

By acquiring test cases from the IAST scheme and utilizing the Gini index and training set attribute analysis, vulnerabilities are automatically verified, solving the problem of high manpower and time costs in the IAST scheme and achieving efficient and accurate vulnerability verification.

CN113326200BActive Publication Date: 2026-06-12WEBANK (CHINA)

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
WEBANK (CHINA)
Filing Date
2021-06-21
Publication Date
2026-06-12

AI Technical Summary

Technical Problem

Existing interactive application security testing (IAST) solutions require the execution of a large number of test cases, increasing testing manpower and time costs, and requiring project personnel to be familiar with the vulnerability detection process.

Method used

By acquiring test cases, vulnerabilities can be verified using an application security testing platform, and the Gini index and training set attribute analysis can be used to automate vulnerability verification, reducing manpower and time costs.

🎯Benefits of technology

It has achieved automated vulnerability verification, reducing manpower and time costs and improving the accuracy and efficiency of vulnerability verification.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113326200B_ABST
    Figure CN113326200B_ABST
Patent Text Reader

Abstract

Embodiments of the present application provide a vulnerability processing method and device, electronic equipment and computer storage medium; the method comprises: obtaining a test case for application security, executing the test case through an application security test platform, and receiving a to-be-verified vulnerability returned by the application security test platform; when the to-be-verified vulnerability is a first-discovered vulnerability, and a selected attribute of a vulnerability in a first training set exists in the attributes of the to-be-verified vulnerability, verifying the to-be-verified vulnerability according to the proportion of the number of vulnerabilities corresponding to the selected attribute in the first training set to the total number of vulnerabilities corresponding to the first training set, and the number of vulnerabilities of each level in each vulnerability corresponding to the first training set; wherein the first training set comprises a plurality of attribute sets of vulnerabilities, and the attribute set comprises at least one attribute.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to automated testing technology for financial technology (Fintech), including but not limited to a vulnerability handling method, apparatus, electronic device, and computer storage medium. Background Technology

[0002] With the development of computer technology, more and more technologies are being applied in the financial field, and the traditional financial industry is gradually transforming into financial technology. However, due to the security and real-time requirements of the financial industry, higher demands are also being placed on technology.

[0003] Among related technologies, Interactive Application Security Testing (IAST) is a novel application security testing solution. It can collect and monitor the execution of runtime functions and data transmission of web applications through proxies, virtual private networks (VPNs), or by deploying agent programs on the server side, and interact with the scanner in real time to detect security flaws and vulnerabilities.

[0004] However, the IAST vulnerability scanning solution requires a large number of test cases to be executed as traffic-driven processes, which needs to be handled at the business testing level. This undoubtedly increases the testing manpower cost. At the same time, project personnel need to be familiar with the IAST vulnerability detection process; that is, project personnel need to write test cases to determine whether the vulnerability is a false alarm, which increases the manpower and time costs. Summary of the Invention

[0005] This application provides a vulnerability processing method, apparatus, electronic device, and computer storage medium, which can automatically verify vulnerabilities, reducing labor and time costs.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a vulnerability handling method, the method comprising:

[0008] Obtain test cases for application security, execute the test cases through the application security testing platform, and receive the vulnerabilities to be verified returned by the application security testing platform;

[0009] When the vulnerability to be verified is a newly discovered vulnerability, and the selected attribute of the vulnerability in the first training set exists in the attributes of the vulnerability to be verified, the vulnerability to be verified is verified based on the ratio of the number of vulnerabilities corresponding to the selected attribute in the first training set to the total number of vulnerabilities in the first training set, and the number of vulnerabilities of each level in each vulnerability in the first training set; wherein, the first training set includes attribute sets of multiple vulnerabilities, and the attribute set includes at least one attribute.

[0010] In some embodiments of this application, the method further includes:

[0011] When the vulnerability to be verified is a newly discovered vulnerability, the smallest Gini index is determined among the Gini indices corresponding to various attributes in the first training set; and the attribute corresponding to the smallest Gini index is selected as the selected attribute.

[0012] Understandably, the Gini index represents the probability that a randomly selected sample in a sample set will be misclassified. The smaller the Gini index, the lower the probability that the selected sample in the set will be misclassified, that is, the higher the purity of the set. In this embodiment, after determining the smallest Gini index among the Gini indices corresponding to various attributes in the first training set, the attribute corresponding to the smallest Gini index is selected as the selected attribute. As can be seen from the above explanation of the Gini index, compared with other attributes, the data mixing degree of the group corresponding to the selected attribute is the lowest, which is beneficial to accurately analyze the error rate of the vulnerability to be verified from the perspective of the selected attribute in the first training set.

[0013] In some embodiments of this application, the method further includes:

[0014] When the selected attribute does not exist in the attributes of the vulnerability to be verified, the i-th training set is excluded from the values ​​of the selected attribute to obtain the (i+1)-th training set.

[0015] When i is an integer greater than or equal to 1, the selected attribute is re-determined from the various attributes of the (i+1)th training set according to the Gini index corresponding to the various attributes of the (i+1)th training set.

[0016] Understandably, by continuously updating the selected attributes until the determined selected attributes exist in the attributes of the vulnerability to be verified, it is appropriate to analyze the error rate of the vulnerability to be verified from the perspective of the selected attributes in the first training set.

[0017] In some embodiments of this application, the method further includes:

[0018] When the vulnerability to be verified does not meet the preset conditions, the selected attribute is determined from the various attributes in the first training set according to the Gini index corresponding to various attributes in the first training set; wherein, the preset conditions include: the values ​​of various attributes of the vulnerability to be verified all exist in the first training set, or the values ​​of various attributes of the vulnerability to be verified do not belong to the first training set.

[0019] As can be seen, in this embodiment of the application, if the vulnerability to be verified does not meet the preset conditions, the selected attribute can be determined from various attributes in the first training set; if the vulnerability to be verified meets the preset conditions, there is no need to determine the selected attribute and verify the vulnerability to be verified based on the selected attribute, which improves the verification efficiency of the vulnerability to be verified to a certain extent.

[0020] In some embodiments of this application, the method further includes:

[0021] When the values ​​of various attributes of the vulnerability to be verified are the same as those of any vulnerability in the first training set, the verification result of the other vulnerability is determined as the verification result of the vulnerability to be verified.

[0022] Understandably, when the values ​​of various attributes of the vulnerability to be verified are the same as those of any vulnerability in the first training set, since the verification result of any vulnerability in the first training set is clearly known information, the vulnerability to be verified can be verified quickly and accurately.

[0023] In some embodiments of this application, the method further includes:

[0024] When the values ​​of all attributes of the vulnerability to be verified do not belong to the first training set, an analysis instruction is generated for the vulnerability to be verified. The analysis instruction is used to instruct the user to analyze the vulnerability to be verified through the vulnerability processing platform.

[0025] Understandably, when the values ​​of various attributes of the vulnerability to be verified do not belong to the first training set, further analysis of the vulnerability to be verified can help to accurately verify the vulnerability.

[0026] In some embodiments of this application, the method further includes:

[0027] After verifying the vulnerability to be verified, the first training set is updated by adding the attribute value of the vulnerability to be verified to the first training set.

[0028] Understandably, after verifying the vulnerability to be verified, adding the attribute values ​​of the vulnerability to be verified to the first training set helps to make the content of the first training set richer and more accurate. Thus, based on the first training set, the vulnerability to be verified again can be verified more accurately; that is, adaptive decision-making can be achieved for vulnerability verification.

[0029] In some embodiments of this application, the method further includes:

[0030] When it is determined that the selected attribute exists in the attributes of the vulnerability to be verified, and the selected attribute is an interface path, the selected attribute is updated to the subsystem to which the interface path belongs.

[0031] Understandably, when the selected attribute is the interface path, updating the selected attribute to the subsystem to which the interface path belongs allows for more flexible determination of the selected attribute.

[0032] In some embodiments of this application, the step of verifying the vulnerability to be verified based on the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, and the number of vulnerabilities of each level in each vulnerability in the first training set, includes:

[0033] For each vulnerability in the first training set, determine the ratio of the number of false positives for the vulnerability level of the vulnerability to be verified to the number of false positives for other vulnerability levels; the other vulnerability levels refer to the vulnerability levels other than the vulnerability level of the vulnerability to be verified.

[0034] The error rate of the vulnerability to be verified is determined based on the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, and the ratio of the number of false positives for the vulnerability level to be verified to the number of false positives for other vulnerability levels.

[0035] The vulnerability to be verified is verified based on its error rate.

[0036] Understandably, the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, as well as the ratio of the number of vulnerabilities of the vulnerability level to be verified to the number of vulnerabilities of other vulnerability levels, helps to accurately determine the error rate of the vulnerability to be verified, and thus helps to accurately verify the vulnerability to be verified.

[0037] In some embodiments of this application, verifying the vulnerability to be verified based on its error rate includes:

[0038] When the error rate of the vulnerability to be verified is less than a set value, the vulnerability to be verified is determined to be a valid vulnerability; when the error rate of the vulnerability to be verified is greater than or equal to the set value, the vulnerability to be verified is determined to be a false alarm vulnerability.

[0039] Understandably, embodiments of this application can more easily verify vulnerabilities based on their error rates.

[0040] In some embodiments of this application, the method further includes:

[0041] The correct vulnerability's attribute value is sent to the vulnerability processing platform, enabling the platform to fix the vulnerability.

[0042] Thus, the embodiments of this application can promptly fix vulnerabilities and achieve automated processing of correct vulnerabilities.

[0043] In some embodiments of this application, the method further includes:

[0044] When the vulnerability to be verified is not a newly discovered vulnerability, the vulnerability to be verified is verified according to the status of the vulnerability on the vulnerability processing platform.

[0045] As can be seen, the embodiments of this application can combine the status of the vulnerability to be verified on the vulnerability processing platform to more accurately verify the vulnerability to be verified.

[0046] In some embodiments of this application, the method further includes:

[0047] Based on the verification results of the vulnerability to be verified, the test cases executed by the application security testing platform are marked with the verification results.

[0048] As can be seen, the embodiments of this application can automatically label the test cases executed by the application security testing platform after the vulnerability to be verified is verified. Since no manual intervention is required, it can reduce labor and time costs.

[0049] This application provides a vulnerability handling device, which includes: a first processing module and a second processing module, wherein...

[0050] The first processing module is used to obtain test cases for application security, execute the test cases through the application security testing platform, and receive the vulnerabilities to be verified returned by the application security testing platform.

[0051] The second processing module is used to verify the vulnerability to be verified when the vulnerability to be verified is a newly discovered vulnerability and the selected attribute of the vulnerability in the first training set exists in the attributes of the vulnerability to be verified, based on the ratio of the number of vulnerabilities corresponding to the selected attribute in the first training set to the total number of vulnerabilities in the first training set, and the number of vulnerabilities of each level in each vulnerability in the first training set; wherein, the first training set includes attribute sets of multiple vulnerabilities, and the attribute set includes at least one attribute.

[0052] This application provides an electronic device, the electronic device comprising:

[0053] Memory, used to store executable instructions;

[0054] The processor, when executing executable instructions stored in the memory, implements any of the above-described vulnerability handling methods.

[0055] This application provides a computer-readable storage medium storing executable instructions, which, when executed by a processor, implement any of the above-described vulnerability handling methods.

[0056] In this embodiment, test cases for application security are obtained, the test cases are executed through an application security testing platform, and vulnerabilities to be verified are received from the application security testing platform. When the vulnerability to be verified is a newly discovered vulnerability, and the selected attribute of the vulnerability in the first training set exists in the attributes of the vulnerability to be verified, the vulnerability to be verified is verified based on the ratio of the number of vulnerabilities corresponding to the selected attribute in the first training set to the total number of vulnerabilities in the first training set, and the number of vulnerabilities of each level in each vulnerability in the first training set. The first training set includes attribute sets of multiple vulnerabilities, and the attribute set includes at least one attribute.

[0057] As can be seen, the embodiments of this application obtain the vulnerabilities to be verified returned by the application security testing platform by executing test cases. Then, if the vulnerability to be verified is a newly discovered vulnerability, the vulnerability to be verified is accurately verified by combining the information of the vulnerabilities in the first training set. Since project personnel do not need to write test cases to implement vulnerability verification, it is beneficial to reduce labor and time costs. Attached Figure Description

[0058] Figure 1 This is a flowchart of a vulnerability handling method according to an embodiment of this application;

[0059] Figure 2 This is a diagram of the closed-loop architecture for container-based IAST vulnerability testing, tracking, and verification in this application embodiment;

[0060] Figure 3This is a flowchart illustrating the vulnerability handling and parsing process in an embodiment of this application.

[0061] Figure 4 This is a schematic diagram of the vulnerability handling device in the embodiments of this application;

[0062] Figure 5 This is a schematic diagram of the structure of the electronic device in the embodiments of this application. Detailed Implementation

[0063] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the embodiments provided herein are merely illustrative of the present application and are not intended to limit the present application. Furthermore, the embodiments provided below are some embodiments for implementing the present application, and not all embodiments for implementing the present application. Unless otherwise specified, the technical solutions described in the embodiments of the present application can be implemented in any combination.

[0064] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the apparatus, such as portions of circuitry, processors, programs, or software, etc.) in the method or apparatus that includes that element.

[0065] For example, the vulnerability handling method provided in this application includes a series of steps, but the vulnerability handling method provided in this application is not limited to the steps described. Similarly, the vulnerability handling device provided in this application includes a series of modules, but the device provided in this application is not limited to the modules explicitly described, but may also include modules that need to be set up for obtaining relevant information or processing based on information.

[0066] The embodiments of this application can be applied to electronic devices, which can be small computer systems, large computer systems, and distributed cloud computing environments including any of the above systems, etc. Electronic devices can include program modules capable of executing instructions. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or can process specific abstract data types.

[0067] For example, the aforementioned electronic device may be a quality platform, used to provide testing tools, test exploration, and task scheduling methods to facilitate communication, collaboration, and integration between the development department and the quality assurance department.

[0068] Figure 1 This is a flowchart of a vulnerability handling method according to an embodiment of this application, such as... Figure 1 As shown, the process may include:

[0069] Step 101: Obtain test cases for application security, execute the test cases through the application security testing platform, and receive the vulnerabilities to be verified returned by the application security testing platform.

[0070] Here, the application security testing platform can be the IAST platform or other platforms used for testing application security.

[0071] In this embodiment of the application, after obtaining test cases for application security, the electronic device can request the application security testing platform to execute the test cases. The application security testing platform can obtain the execution results of the test cases by executing them. The execution results of the test cases can include the vulnerability to be verified and the attribute set of the vulnerability to be verified. For example, after executing the test cases, the application security testing platform can mark the test cases as executed in the database (DB).

[0072] The attribute set of the vulnerability to be verified includes at least the vulnerability level of the vulnerability, that is, the vulnerability level of the vulnerability to be verified is known information. For example, the vulnerability level of the vulnerability to be verified can be one of the following levels: high, medium, low, and info (ignorable).

[0073] For example, since the IAST platform does not obtain the execution result immediately after executing the test case, but obtains the execution result after a delay after executing the test case, electronic devices can periodically execute test cases through the IAST platform and periodically obtain the vulnerabilities to be verified by the IAST platform.

[0074] Step 102: When the vulnerability to be verified is a newly discovered vulnerability, and the selected attribute of the vulnerability in the first training set exists in the attributes of the vulnerability to be verified, the vulnerability to be verified is verified according to the ratio of the number of vulnerabilities corresponding to the selected attribute in the first training set to the total number of vulnerabilities in the first training set, and the number of vulnerabilities of each level in each vulnerability in the first training set; wherein, the first training set includes attribute sets of multiple vulnerabilities, and the attribute set includes at least one attribute.

[0075] For example, after an electronic device acquires a vulnerability to be verified, it can store the vulnerability in the database. If the vulnerability to be verified currently acquired by the electronic device is not a previously stored vulnerability, it means that the vulnerability to be verified is a newly discovered vulnerability. If the vulnerability to be verified currently acquired by the electronic device is a previously stored vulnerability, it means that the vulnerability to be verified is not a newly discovered vulnerability.

[0076] In this embodiment, the vulnerability attribute set includes a vulnerability level. For example, the vulnerability attribute set may also include at least one of the following attributes: vulnerability type, version repository, subsystem, and interface path. There is a certain correlation between different attributes in the attribute set. For example, when an interface path exists in the attribute set, a subsystem exists in the attribute set, and the correspondence between the subsystem and the interface path is one-to-many. The core attribute for verifying the vulnerability to be verified may be the vulnerability type. The correspondence between the vulnerability type and the version repository may be M:N, where M and N may be the same integer or different integers. When the vulnerability type is clearly known, the vulnerability level can also be determined. For example, if the vulnerability type is an Extensible Markup Language External Entity Injection (XXE) attack, then the vulnerability level may be a high-risk level.

[0077] In this embodiment of the application, a first training set can be pre-established based on vulnerabilities with known attribute values. After obtaining the first training set, an attribute can be selected from the attribute set of the vulnerabilities in the first training set, i.e., the selected attribute can be obtained. For example, the vulnerability type, version library, subsystem or interface path can be used as the selected attribute.

[0078] Since the attribute values ​​of each vulnerability in the first training set are known, the number of vulnerabilities corresponding to the selected attributes in the first training set and the total number of vulnerabilities in the first training set can be determined. Given that the vulnerability levels of each vulnerability in the first training set are known, the number of vulnerabilities of each level in each vulnerability in the first training set can be determined.

[0079] In some embodiments, the error rate of the vulnerability to be verified can be determined based on the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, and the number of vulnerabilities of each level in each vulnerability in the first training set. Here, the error rate of the vulnerability to be verified is used to reflect the probability that the vulnerability to be verified is a correct vulnerability. Therefore, the vulnerability to be verified can be verified based on the error rate of the vulnerability to be verified.

[0080] In this embodiment of the application, if the vulnerability to be verified is a correct vulnerability, it means that the vulnerability to be verified is a vulnerability that needs to be fixed; if the vulnerability to be verified is not a correct vulnerability, it means that the vulnerability to be verified is a false alarm.

[0081] In practical applications, steps 101 to 102 can be implemented based on a processor in an electronic device. This processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), CPU, controller, microcontroller, or microprocessor. It is understood that other electronic devices can also implement the above processor functions, and this application embodiment does not impose any limitations.

[0082] As can be seen, the embodiments of this application obtain the vulnerabilities to be verified returned by the application security testing platform by executing test cases. Then, if the vulnerability to be verified is a newly discovered vulnerability, the vulnerability to be verified is accurately verified by combining the information of the vulnerabilities in the first training set. Since project personnel do not need to write test cases to implement vulnerability verification, it is beneficial to reduce labor and time costs.

[0083] In some embodiments, when the vulnerability to be verified is a newly discovered vulnerability, the smallest Gini index is determined among the Gini indices corresponding to various attributes in the first training set; and the attribute corresponding to the smallest Gini index is selected as the selected attribute.

[0084] In this embodiment of the application, the Gini index of the first training set can be calculated according to formula (1):

[0085]

[0086] Where D represents the first training set, and c represents the number of attribute types in the first training set. For example, if the attribute set of vulnerabilities in the first training set includes: vulnerability type, version library, subsystem, and interface path, then c takes the value of 4; p i Gini(D) represents the proportion of the number of attributes of type i in the first training set out to the total number of attributes in the training set. It can be understood that the higher the degree of mixing of the data in the first training set, the higher the Gini index, thus providing a more accurate representation of the attribute factors for key decisions.

[0087] For each attribute in the first training set, the corresponding Gini index can be derived; the following explanation uses vulnerability types as an example.

[0088] After obtaining the first training set, the attribute values ​​in the first training set can be grouped according to the vulnerability type. The attribute values ​​of different vulnerabilities belong to different groups, and the vulnerability type values ​​in different groups are different. The same group may include one vulnerability type value or multiple identical vulnerability type values.

[0089] For example, the first training set includes the attribute set of vulnerability 1, the attribute set of vulnerability 2, and the attribute set of vulnerability 3. The attribute set of vulnerability 1 includes vulnerability type, repository, subsystem, and interface path. The vulnerability type of vulnerability 1 is vulnerability type A1, the repository of vulnerability 1 is repository B1, the subsystem of vulnerability 1 is subsystem C1, and the interface path of vulnerability 1 is interface path D1. The attribute set of vulnerability 2 includes vulnerability type, repository, and subsystem. The vulnerability type of vulnerability 2 is vulnerability type A1, the repository of vulnerability 2 is repository B2, and the subsystem of vulnerability 2 is subsystem C2. The attribute set of vulnerability 3 includes vulnerability type and repository. The vulnerability type of vulnerability 3 is vulnerability type A2, and the repository of vulnerability 3 is repository B3. In this case, according to the value of the vulnerability type, the values ​​of each attribute of vulnerability 1 and the values ​​of each attribute of vulnerability 2 can be divided into group 1, and the values ​​of each attribute of vulnerability 3 can be divided into group 2.

[0090] After grouping the attribute values ​​in the first training set, the Gini index corresponding to the vulnerability type in the first training set can be determined based on the attribute values ​​in each group.

[0091] For example, the Gini index corresponding to the vulnerability type in the first training set can be calculated according to formula (2):

[0092]

[0093] Among them, D j This represents the attribute values ​​in the j-th group of the first training set, where D in formula (1) is replaced with D. j In the case of Gini(D) j The result can be calculated using formula (1); |D| represents the number of attribute values ​​in the first training set. j | represents the number of attribute values ​​in the j-th group of the first training set, k represents the number of groups in the first training set, Gini TYPE (D) represents the Gini index corresponding to the vulnerability type in the first training set.

[0094] Similarly, the Gini index corresponding to the version library, subsystem, and interface path in the first training set can be calculated.

[0095] In this embodiment, the attribute corresponding to the smallest Gini coefficient can be understood as the attribute corresponding to the largest Gini exponential gain value. Taking vulnerability type as an example, the Gini exponential gain value corresponding to the vulnerability type in the first training set can be calculated according to formula (3):

[0096] ΔGini TYPE (D)=Gini(D)-Gini TYPE (D) (3)

[0097] Among them, ΔGini TYPE (D) represents the Gini index gain value corresponding to the vulnerability type in the first training set.

[0098] Understandably, the Gini index represents the probability that a randomly selected sample in a sample set will be misclassified. The smaller the Gini index, the lower the probability that the selected sample in the set will be misclassified, that is, the higher the purity of the set. In this embodiment, after determining the smallest Gini index among the Gini indices corresponding to various attributes in the first training set, the attribute corresponding to the smallest Gini index is selected as the selected attribute. As can be seen from the above explanation of the Gini index, compared with other attributes, the data mixing degree of the group corresponding to the selected attribute is the lowest, which is beneficial to accurately analyze the error rate of the vulnerability to be verified from the perspective of the selected attribute in the first training set.

[0099] In some embodiments, if the selected attribute does not exist in the attributes of the vulnerability to be verified, it indicates that it is not suitable to analyze the error rate of the vulnerability to be verified from the perspective of the selected attribute in the first training set. In this case, if i is greater than or equal to 1, the value of the selected attribute can be excluded from the i-th training set to obtain the (i+1)-th training set. Then, based on the Gini index corresponding to the various attributes of the (i+1)-th training set, the selected attribute is re-determined among the various attributes of the (i+1)-th training set.

[0100] Here, the implementation method of the selected attribute is re-determined from the various attributes of the (i+1)th training set based on the Gini index corresponding to the various attributes of the (i+1)th training set. This is the same as the implementation method of determining the selected attribute from the various attributes of the first training set based on the Gini index corresponding to the various attributes of the (i+1)th training set, and will not be repeated here.

[0101] In this embodiment of the application, if the selected attribute determined at any time does not exist in the attributes of the vulnerability to be verified, a new training set can be determined based on the content described above (i.e., the i+1th training set is obtained based on the i-th training set), and the selected attribute is determined based on the new training set until the selected attribute exists in the attributes of the vulnerability to be verified.

[0102] Understandably, by continuously updating the selected attributes until the determined selected attributes exist in the attributes of the vulnerability to be verified, it is appropriate to analyze the error rate of the vulnerability to be verified from the perspective of the selected attributes in the first training set.

[0103] In some embodiments, after identifying the vulnerability to be verified, preliminary verification can be performed based on the attribute values ​​of the vulnerability. If the vulnerability meets preset conditions, it can be directly verified without determining the selected attribute and verifying the vulnerability based on the selected attribute. Here, the preset conditions include either all the values ​​of the various attributes of the vulnerability to be verified existing in the first training set, or none of the values ​​of the various attributes of the vulnerability to be verified belonging to the first training set.

[0104] For example, when the values ​​of various attributes of the vulnerability to be verified are the same as those of any vulnerability in the first training set, the verification result of that any vulnerability is determined as the verification result of the vulnerability to be verified.

[0105] Understandably, when the values ​​of various attributes of the vulnerability to be verified are the same as those of any vulnerability in the first training set, since the verification result of any vulnerability in the first training set is clearly known information, the vulnerability to be verified can be verified quickly and accurately.

[0106] For example, when the values ​​of all attributes of the vulnerability to be verified do not belong to the first training set, the vulnerability to be verified can be defined as a new vulnerability. In this case, analysis instructions can be generated for the vulnerability to be verified. The analysis instructions are used to instruct the user to analyze the vulnerability to be verified through the vulnerability processing platform. That is to say, the user needs to perform further analysis on the vulnerability to be verified through the vulnerability processing platform.

[0107] Understandably, when the values ​​of various attributes of the vulnerability to be verified do not belong to the first training set, further analysis of the vulnerability to be verified can help to accurately verify the vulnerability.

[0108] In some embodiments, when the vulnerability to be verified does not meet the preset conditions, the selected attribute can be determined from the various attributes in the first training set based on the Gini index corresponding to various attributes in the first training set.

[0109] As can be seen, in this embodiment of the application, if the vulnerability to be verified does not meet the preset conditions, the selected attribute can be determined from various attributes in the first training set; if the vulnerability to be verified meets the preset conditions, there is no need to determine the selected attribute and verify the vulnerability to be verified based on the selected attribute, which improves the verification efficiency of the vulnerability to be verified to a certain extent.

[0110] In some embodiments, after the vulnerability to be verified is verified, the first training set is updated by adding the attribute value of the vulnerability to be verified to the first training set.

[0111] Understandably, after verifying the vulnerability to be verified, adding the attribute values ​​of the vulnerability to be verified to the first training set helps to make the content of the first training set richer and more accurate. Thus, based on the first training set, the vulnerability to be verified again can be verified more accurately; that is, adaptive decision-making can be achieved for vulnerability verification.

[0112] In some embodiments, when it is determined that the selected attribute exists in the attributes of the vulnerability to be verified, and the selected attribute is an interface path, the selected attribute is updated to the subsystem to which the interface path belongs.

[0113] As can be seen from the above description, when an interface path exists in the attribute set, the subsystem will also exist in the attribute set; for example, if the value of the interface path in the attribute set is ias-mg / api / XXXX, the value of the subsystem is ias-mg.

[0114] Understandably, when the selected attribute is the interface path, updating the selected attribute to the subsystem to which the interface path belongs allows for more flexible determination of the selected attribute.

[0115] In some embodiments, the implementation of verifying the vulnerability to be verified may include:

[0116] For each vulnerability in the first training set, determine the ratio of the number of false positives for the vulnerability level to be verified to the number of false positives for other vulnerability levels; other vulnerability levels refer to the vulnerability levels excluding the vulnerability level to be verified.

[0117] The error rate of the vulnerability to be verified is determined by the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, and the ratio of the number of false positives for the vulnerability level to be verified to the number of false positives for other vulnerability levels.

[0118] The vulnerability to be verified is verified based on its error rate.

[0119] The following examples illustrate other vulnerability levels. Vulnerability levels are categorized as high-risk, medium-risk, and low-risk. If the vulnerability to be verified is classified as low-risk, then other vulnerability levels include high-risk and medium-risk.

[0120] For example, the error rate of the vulnerability to be verified can be calculated according to formula (4):

[0121] p = p value *λ level (4)

[0122] Where, p value λ represents the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set. level This represents the ratio of the number of vulnerabilities at the vulnerability level to the number of vulnerabilities at other vulnerability levels.

[0123] For example, when the vulnerability to be verified is of low risk, and other vulnerability levels include high risk and medium risk, λ can be calculated according to formula (5). level :

[0124]

[0125] Where, p low p represents the proportion of low-risk false positives in the first training set out of all false positives. high p represents the proportion of high-risk false positive vulnerabilities in the first training set out of all false positive vulnerabilities. med p represents the proportion of medium-risk vulnerabilities in the first training set out of all false positive vulnerabilities; high +p med +p low =1.

[0126] Understandably, the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, as well as the ratio of the number of vulnerabilities of the vulnerability level to be verified to the number of vulnerabilities of other vulnerability levels, helps to accurately determine the error rate of the vulnerability to be verified, and thus helps to accurately verify the vulnerability to be verified.

[0127] In some embodiments, a vulnerability to be verified can be determined to be a valid vulnerability if its error rate is less than a set value. If the error rate of a vulnerability to be verified is greater than or equal to a set value, the vulnerability to be verified is determined to be a false alarm, and in this case, the vulnerability to be verified can be ignored.

[0128] In this embodiment of the application, the set value can be preset according to actual needs. For example, the set value can be 0.4, 0.5 or 0.6.

[0129] Understandably, embodiments of this application can more easily verify vulnerabilities based on their error rates.

[0130] In some embodiments, the correct vulnerability attribute values ​​can be sent to the vulnerability handling platform so that the platform can fix the correct vulnerability.

[0131] Thus, the embodiments of this application can promptly fix vulnerabilities and achieve automated processing of correct vulnerabilities.

[0132] In some embodiments, when the vulnerability to be verified is not a newly discovered vulnerability, the vulnerability to be verified can be verified based on the status of the vulnerability on the vulnerability handling platform.

[0133] As can be seen from the above description, if the vulnerability to be verified is stored in the database, it can be considered that the vulnerability to be verified is a newly discovered vulnerability. In this case, it is necessary to verify the vulnerability to be verified in combination with the status of the vulnerability to be verified on the vulnerability handling platform.

[0134] In this embodiment of the application, after receiving a vulnerability, the vulnerability handling platform can re-verify the vulnerability. If the vulnerability is verified to be a false alarm, it can be rejected; if the vulnerability is verified to be a valid vulnerability, it can be fixed.

[0135] The various states of a vulnerability to be verified can include unresolved, reopened, closed, rejected, legacy, and resolved. Unresolved indicates that the vulnerability has neither been rejected nor fixed. Reopened indicates that if the vulnerability reappears after being fixed, the processing task for the vulnerability is reopened for further repair. Closed indicates that the processing task for the vulnerability has been closed after the vulnerability was rejected or fixed. This can be done automatically or manually by the user. Rejected indicates that the vulnerability has been rejected. Legacy indicates that the vulnerability does not currently require processing but will be addressed in the next version of the application. Resolved indicates that the vulnerability has been fixed.

[0136] For example, when the status of the vulnerability to be verified is unresolved or reopened, it means that the vulnerability processing platform is processing the vulnerability to be verified. At this time, the received vulnerability to be verified can be ignored.

[0137] For example, when the status of the vulnerability to be verified is closed, the status before the vulnerability to be verified was determined. If the status before the vulnerability to be verified was rejected, it means that the vulnerability to be verified is a false alarm and can be ignored. If the vulnerability to be verified was a correct vulnerability before the vulnerability to be verified was closed, it means that the vulnerability to be verified has occurred again. At this time, the task of processing the vulnerability to be verified needs to be reopened, and the development team needs to check whether the application version has been overwritten.

[0138] For example, when the status of the vulnerability to be verified is rejected, it means that the vulnerability to be verified is a false alarm. The received vulnerability to be verified can be ignored, and the task of processing the vulnerability to be verified can be closed directly.

[0139] For example, when the vulnerability to be verified is in a legacy state, the vulnerability to be verified is not processed temporarily.

[0140] For example, when the status of the vulnerability to be verified is "resolved", it means that the vulnerability to be verified has occurred again. At this time, it is necessary to reopen the task of processing the vulnerability to be verified, notify the developers to fix it, and after the vulnerability is fixed, it is necessary to send the test cases corresponding to the vulnerability to be verified to the IAST platform.

[0141] As can be seen, the embodiments of this application can combine the status of the vulnerability to be verified on the vulnerability processing platform to more accurately verify the vulnerability to be verified.

[0142] In some embodiments, regardless of whether the vulnerability to be verified is a newly discovered vulnerability, the test cases executed by the application security testing platform can be marked with verification results based on the verification results of the vulnerability to be verified.

[0143] For example, the verification result of the vulnerability to be verified can be a correct vulnerability or a false positive vulnerability.

[0144] As can be seen, the embodiments of this application can automatically label the test cases executed by the application security testing platform after the vulnerability to be verified is verified. Since no manual intervention is required, it can reduce labor and time costs.

[0145] The implementation of the embodiments of this application will be illustrated by an example below.

[0146] Figure 2 This is a diagram illustrating the closed-loop architecture for container-based IAST vulnerability testing, tracking, and verification in this application embodiment. Figure 2 As shown, the TctpTest platform is the electronic device described above, and the DPMS (Data Process Management System) platform is the vulnerability handling platform described above. The DPMS platform is a software development process management system that can better support product-oriented development processes and provide unified and standardized management of the product development process. The TctpTest platform has multiple interfaces that can interact with the DPMS platform, IAST platform, WeChat platform, database, etc.

[0147] The TctpTest platform automatically executes all test cases for the subsystems daily on a scheduled basis, and also retrieves vulnerabilities from the IAST platform in two batches on a scheduled basis. Here, the TctpTest platform can send test case execution requests to the engine processor, which can then execute the test cases through the IAST platform and obtain the execution results.

[0148] After executing test cases, the engine processor can mark the test cases as executed in the database.

[0149] After obtaining the vulnerability to be verified, it can be analyzed to determine whether a bug report needs to be submitted to D PMS. A bug report represents the task of handling the vulnerability to be verified.

[0150] For example, the vulnerability to be verified is parsed to obtain the verification result of the vulnerability, referring to... Figure 2 The verification results can be marked in the database.

[0151] Figure 3 This is a flowchart of vulnerability handling and parsing in an embodiment of this application, referred to... Figure 3 The TctpTest platform attempts to identify vulnerabilities. If no vulnerabilities are found, the bug report is closed on DPMS, and the IAST platform's tagging process (i.e., the tagging process for the verification results of the vulnerability to be verified) is completed.

[0152] Reference Figure 3 When a vulnerability to be verified is discovered, it is determined whether verification analysis for all vulnerabilities to be verified has been completed. If not, it is determined whether the vulnerability to be verified is a newly discovered vulnerability. If the vulnerability to be verified is a newly discovered vulnerability, an adaptive decision algorithm can be used to determine whether the vulnerability to be verified is a valid vulnerability. If the vulnerability to be verified is a valid vulnerability, a bug report can be submitted to DPMS, or the vulnerability can be handled by relevant personnel. If the vulnerability to be verified is not a valid vulnerability, it is determined whether verification analysis for all vulnerabilities to be verified has been completed.

[0153] The following explains how to use an adaptive decision-making algorithm to determine whether a vulnerability to be verified is a valid vulnerability.

[0154] The principle of the adaptive decision-making algorithm is to adaptively adjust the decision on whether the vulnerability to be verified is a correct vulnerability based on a large training set and with reference to the Gini index and risk weight influence factor corresponding to the vulnerability attributes.

[0155] The five attributes of a vulnerability to be verified include vulnerability type, repository, subsystem, interface path, and vulnerability level. The vulnerability level is not involved in the selection of vulnerability attributes; it is used to correct errors and make the verification result of the vulnerability to be verified more accurately. Based on the four values ​​of vulnerability type, repository, subsystem, and interface path, a unique vulnerability can be identified. Vulnerability levels can be divided into high-risk, medium-risk, low-risk, and warning, with the risk weighting factor denoted as λ. The risk weighting factors corresponding to high-risk, medium-risk, and low-risk levels are p, respectively. high p med and p low .

[0156] The verification result of the vulnerability to be verified can be determined according to the following formula (6):

[0157] (x,res)={x type ,x base ,x system ,x api ,λ} (6)

[0158] Where x represents the vulnerability to be verified, and res represents the verification result of the vulnerability to be verified; x type x base x system and x api These represent the values ​​for the vulnerability type, repository, subsystem, and interface path of the vulnerability to be verified.

[0159] Whether the vulnerability to be verified meets the preset conditions or not, the aforementioned procedures can be followed to obtain the verification result. If the vulnerability to be verified is correct, a bug report can be initiated on DPMS. If the vulnerability to be verified is a false positive, it can be ignored.

[0160] Reference Figure 3 If the vulnerability to be verified is not a newly discovered vulnerability, it can be verified by combining the bug status on the DPMS platform. The implementation method of verifying the vulnerability to be verified by combining the bug status on the DPMS platform has been described in the foregoing embodiments.

[0161] Reference Figure 3After completing the verification analysis for all vulnerabilities to be verified, it can be determined whether the count value is equal to n. Here, the initial value of the count value is 0, and n represents the number of vulnerabilities to be verified. In this embodiment, the count value can be incremented by 1 each time the verification result of a vulnerability to be verified is obtained or when the status of a vulnerability to be verified is determined to be in a legacy state. Therefore, if the count value is equal to n, it can be confirmed that the labeling process of the IAST platform is over; if the count value is not equal to n, it means that the labeling process of the IAST platform is not over, but the current process of vulnerability processing and analysis can be terminated.

[0162] In this embodiment, after the vulnerability to be verified is found to be correct, the attribute value of the vulnerability to be verified can be added to the first training set. Through continuous training, an adaptive decision-making effect can be achieved, thereby improving the processing accuracy of the adaptive decision-making algorithm.

[0163] Reference Figure 2 The TctpTest platform, by receiving vulnerability notifications and confirming the completion of the vulnerability handling and parsing process, can monitor whether the vulnerability status on the DPMS platform is resolved. If the vulnerability status on the DPMS platform is resolved, it initiates a corresponding test case execution request and determines whether the vulnerability has been fixed by obtaining the execution result of the test case. If the execution result of the test case confirms that the vulnerability has been fixed, it marks the vulnerability verification result. If the execution result of the test case confirms that the vulnerability has not been fixed, it can reopen the bug report, increment the number of tests for the vulnerability by 1, and notify the developers to fix the vulnerability through the WeChat platform, thus achieving a closed loop for the entire process.

[0164] In summary, this application proposes a complete solution for automatic vulnerability verification. It can use an adaptive decision algorithm to accurately analyze whether the vulnerability to be verified is a valid vulnerability, reduce the error rate, reduce the intervention of development and testing personnel, and reduce labor costs. Furthermore, by monitoring the vulnerability status of the DPMS platform, timely reverse verification can be achieved to realize a closed loop, thereby achieving the goal of automating IAST testing for each version, truly freeing up testing manpower, and realizing automated vulnerability verification.

[0165] Based on the vulnerability handling method proposed in the foregoing embodiments, this application also proposes a vulnerability handling device; Figure 4 This is a schematic diagram of an optional component structure of the vulnerability handling device according to an embodiment of this application, such as... Figure 4 As shown, the vulnerability handling device 400 may include: a first processing module 401 and a second processing module 402, wherein,

[0166] The first processing module 401 is used to obtain test cases for application security, execute the test cases through the application security testing platform, and receive the vulnerabilities to be verified returned by the application security testing platform.

[0167] The second processing module 402 is used to verify the vulnerability to be verified when the vulnerability to be verified is a newly discovered vulnerability and the selected attribute of the vulnerability in the first training set exists in the attributes of the vulnerability to be verified, based on the ratio of the number of vulnerabilities corresponding to the selected attribute in the first training set to the total number of vulnerabilities in the first training set, and the number of vulnerabilities of each level in each vulnerability in the first training set; wherein, the first training set includes attribute sets of multiple vulnerabilities, and the attribute set includes at least one attribute.

[0168] In some embodiments, the second processing module 402 is further configured to:

[0169] When the vulnerability to be verified is a newly discovered vulnerability, the smallest Gini index is determined among the Gini indices corresponding to various attributes in the first training set; and the attribute corresponding to the smallest Gini index is selected as the selected attribute.

[0170] In some embodiments, the second processing module 402 is further configured to:

[0171] When the selected attribute does not exist in the attributes of the vulnerability to be verified, the i-th training set is excluded from the values ​​of the selected attribute to obtain the (i+1)-th training set.

[0172] When i is an integer greater than or equal to 1, the selected attribute is re-determined from the various attributes of the (i+1)th training set according to the Gini index corresponding to the various attributes of the (i+1)th training set.

[0173] In some embodiments, the second processing module 402 is further configured to:

[0174] When the vulnerability to be verified does not meet the preset conditions, the selected attribute is determined from the various attributes in the first training set according to the Gini index corresponding to various attributes in the first training set; wherein, the preset conditions include: the values ​​of various attributes of the vulnerability to be verified all exist in the first training set, or the values ​​of various attributes of the vulnerability to be verified do not belong to the first training set.

[0175] In some embodiments, the second processing module 402 is further configured to:

[0176] When the values ​​of various attributes of the vulnerability to be verified are the same as those of any vulnerability in the first training set, the verification result of the other vulnerability is determined as the verification result of the vulnerability to be verified.

[0177] In some embodiments, the second processing module 402 is further configured to:

[0178] When the values ​​of all attributes of the vulnerability to be verified do not belong to the first training set, an analysis instruction is generated for the vulnerability to be verified. The analysis instruction is used to instruct the user to analyze the vulnerability to be verified through the vulnerability processing platform.

[0179] In some embodiments, the second processing module 402 is further configured to:

[0180] After verifying the vulnerability to be verified, the first training set is updated by adding the attribute value of the vulnerability to be verified to the first training set.

[0181] In some embodiments, the second processing module 402 is further configured to:

[0182] When it is determined that the selected attribute exists in the attributes of the vulnerability to be verified, and the selected attribute is an interface path, the selected attribute is updated to the subsystem to which the interface path belongs.

[0183] In some embodiments, the second processing module 402 is specifically used for:

[0184] For each vulnerability in the first training set, determine the ratio of the number of false positives for the vulnerability level of the vulnerability to be verified to the number of false positives for other vulnerability levels; the other vulnerability levels refer to the vulnerability levels other than the vulnerability level of the vulnerability to be verified.

[0185] The error rate of the vulnerability to be verified is determined based on the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, and the ratio of the number of false positives for the vulnerability level to be verified to the number of false positives for other vulnerability levels.

[0186] The vulnerability to be verified is verified based on its error rate.

[0187] In some embodiments, the second processing module 402 is specifically used for:

[0188] When the error rate of the vulnerability to be verified is less than a set value, the vulnerability to be verified is determined to be a valid vulnerability; when the error rate of the vulnerability to be verified is greater than or equal to the set value, the vulnerability to be verified is determined to be a false alarm vulnerability.

[0189] In some embodiments, the second processing module 402 is further configured to:

[0190] The correct vulnerability's attribute value is sent to the vulnerability processing platform, enabling the platform to fix the vulnerability.

[0191] In some embodiments, the second processing module 402 is further configured to:

[0192] When the vulnerability to be verified is not a newly discovered vulnerability, the vulnerability to be verified is verified according to the status of the vulnerability on the vulnerability processing platform.

[0193] In some embodiments, the second processing module 402 is further configured to:

[0194] Based on the verification results of the vulnerability to be verified, the test cases executed by the application security testing platform are marked with the verification results.

[0195] In practical applications, both the first processing module 401 and the second processing module 402 can be implemented using a processor of an electronic device. The processor can be at least one of an ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, or microprocessor. It is understood that other electronic devices can also implement the above-mentioned processor functions, and this application embodiment does not impose any limitations.

[0196] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0197] It should be noted that, in the embodiments of this application, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0198] Accordingly, this application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the vulnerability handling methods provided in the above embodiments.

[0199] This application also provides an electronic device. Figure 5 A schematic diagram of an optional component structure of the electronic device provided in an embodiment of this application is shown below. Figure 5 As shown, the electronic device 50 includes:

[0200] Memory 501 is used to store executable instructions;

[0201] The processor 502 is used to execute executable instructions stored in the memory 501 to implement any of the above methods for determining a domain name server.

[0202] The processor 502 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0203] The aforementioned computer-readable storage medium / memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; it can also be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0204] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0205] It should be understood that the phrase "some embodiments" mentioned throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "some embodiments" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0206] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0207] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0208] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0209] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0210] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause the device automatic test line to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0211] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0212] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0213] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vulnerability handling method, characterized in that, The method includes: Obtain test cases for application security, execute the test cases through the application security testing platform, and receive the vulnerabilities to be verified returned by the application security testing platform; When the vulnerability to be verified is a newly discovered vulnerability, the smallest Gini index is determined from the Gini indices corresponding to various attributes in the first training set; the attribute corresponding to the smallest Gini index is selected as the selected attribute; wherein, the first training set includes attribute sets of multiple vulnerabilities, and the attribute set includes at least one attribute; When the selected attribute does not exist in the attributes of the vulnerability to be verified, the i-th training set is excluded from the values ​​of the selected attribute to obtain the (i+1)-th training set. When i is an integer greater than or equal to 1, the selected attribute is re-determined from the various attributes of the (i+1)-th training set according to the Gini index corresponding to the various attributes of the (i+1)-th training set. When the re-determined selected attribute does not exist in the attributes of the vulnerability to be verified, the current training set is excluded from the values ​​of the current selected attribute to obtain the next training set. The selected attribute is then re-determined according to the Gini index corresponding to the various attributes of the next training set until the re-determined selected attribute exists in the attributes of the vulnerability to be verified. When the selected attribute of a vulnerability in the first training set exists in the attribute of the vulnerability to be verified, for each vulnerability corresponding to the first training set, the ratio of the number of false positives at the vulnerability level of the vulnerability to be verified to the number of false positives at other vulnerability levels is determined; the other vulnerability levels refer to the vulnerability levels other than the vulnerability level of the vulnerability to be verified. The error rate of the vulnerability to be verified is determined based on the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, and the ratio of the number of false positives for the vulnerability level to be verified to the number of false positives for other vulnerability levels. The vulnerability to be verified is verified based on its error rate.

2. The method according to claim 1, characterized in that, The method further includes: When the vulnerability to be verified does not meet the preset conditions, the selected attribute is determined from the various attributes in the first training set according to the Gini index corresponding to various attributes in the first training set; wherein, the preset conditions include: the values ​​of various attributes of the vulnerability to be verified all exist in the first training set, or the values ​​of various attributes of the vulnerability to be verified do not belong to the first training set.

3. The method according to claim 1, characterized in that, The method further includes: When the values ​​of various attributes of the vulnerability to be verified are the same as those of any vulnerability in the first training set, the verification result of that vulnerability is determined as the verification result of the vulnerability to be verified; or When the values ​​of all attributes of the vulnerability to be verified do not belong to the first training set, an analysis instruction is generated for the vulnerability to be verified. The analysis instruction is used to instruct the user to analyze the vulnerability to be verified through the vulnerability processing platform.

4. The method according to claim 1, characterized in that, The method further includes: After verifying the vulnerability to be verified, the first training set is updated by adding the attribute value of the vulnerability to be verified to the first training set.

5. The method according to claim 1, characterized in that, The method further includes: When it is determined that the selected attribute exists in the attributes of the vulnerability to be verified, and the selected attribute is an interface path, the selected attribute is updated to the subsystem to which the interface path belongs.

6. The method according to claim 1, characterized in that, The step of verifying the vulnerability to be verified based on its error rate includes: When the error rate of the vulnerability to be verified is less than a set value, the vulnerability to be verified is determined to be a valid vulnerability; when the error rate of the vulnerability to be verified is greater than or equal to the set value, the vulnerability to be verified is determined to be a false alarm vulnerability.

7. A vulnerability handling device, characterized in that, The device includes: a first processing module and a second processing module, wherein... The first processing module is used to obtain test cases for application security, execute the test cases through the application security testing platform, and receive the vulnerabilities to be verified returned by the application security testing platform. The second processing module is used to determine the smallest Gini index among the Gini indices corresponding to various attributes in the first training set when the vulnerability to be verified is a newly discovered vulnerability; and to select an attribute corresponding to the smallest Gini index as the selected attribute; wherein the first training set includes attribute sets of multiple vulnerabilities, and the attribute set includes at least one attribute. When the selected attribute does not exist in the attributes of the vulnerability to be verified, the i-th training set is excluded from the values ​​of the selected attribute to obtain the (i+1)-th training set. When i is an integer greater than or equal to 1, the selected attribute is re-determined from the various attributes of the (i+1)-th training set according to the Gini index corresponding to the various attributes of the (i+1)-th training set. When the re-determined selected attribute does not exist in the attributes of the vulnerability to be verified, the current training set is excluded from the values ​​of the current selected attribute to obtain the next training set. The selected attribute is then re-determined according to the Gini index corresponding to the various attributes of the next training set until the re-determined selected attribute exists in the attributes of the vulnerability to be verified. When the selected attribute of a vulnerability in the first training set exists in the attribute of the vulnerability to be verified, for each vulnerability corresponding to the first training set, the ratio of the number of false positives at the vulnerability level of the vulnerability to be verified to the number of false positives at other vulnerability levels is determined; the other vulnerability levels refer to the vulnerability levels other than the vulnerability level of the vulnerability to be verified. The error rate of the vulnerability to be verified is determined based on the ratio of the number of vulnerabilities corresponding to the selected attributes in the first training set to the total number of vulnerabilities in the first training set, and the ratio of the number of false positives for the vulnerability level to be verified to the number of false positives for other vulnerability levels. The vulnerability to be verified is verified based on its error rate.

8. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores executable instructions for implementing the method of any one of claims 1 to 6 when executed by a processor.