Risk detection method and device
By obtaining historical risk data and analysis strategies of multiple feature dimensions in software products, determining the risk estimate and weight of the target feature dimension, combining risk measurement values and thresholds, the accuracy and efficiency of risk detection of software products in the prior art are solved. Problem, efficient risk detection is achieved.
Patent Information
- Application Number
- CN202411397282.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2022-03-10
- Publication Date
- 2025-01-14
- Estimated Expiration
- 2042-03-10
AI Technical Summary
The prior art has problems with accuracy and efficiency in the risk detection of software products. The difficulty in identifying code semantics and inability to run independently leads to detection omissions.
By obtaining the characteristic data of the target software product under multiple target feature dimensions, using historical risk data analysis and risk analysis strategies, determining the risk estimate and weight of the target feature dimension, combining the risk measurement values and thresholds of multiple feature dimensions, and achieving risk The accuracy of the test results is improved.
It improves the accuracy and efficiency of risk detection of software products, does not need to identify obfuscated or encrypted code semantics, and can effectively detect without relying on software operation, avoiding the detection missed by traditional methods.
Smart Images

Figure CN119312346A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present specification relate to the field of computer technology, and in particular to a risk detection method. Background Art
[0002] The life cycle of a software product includes design, production, delivery, deployment, use, operation, and termination. The division of labor, joint research, and platform environment involved in this life cycle are the main contents of the software supply chain, and the main types of attacks on the software supply chain are also closely related to these links. In recent years, security attacks on the software supply chain have been growing rapidly, and the harm caused has become more and more serious. The development of software products is inseparable from the software supply chain, so it is necessary to conduct risk detection on software products.
[0003] Currently, risks of software products are usually detected by code scanning, which may result in scanning failure and inability to obtain detection results. Therefore, a more accurate and efficient way to detect risks of software products is urgently needed. Summary of the invention
[0004] In view of this, an embodiment of this specification provides a risk detection method. One or more embodiments of this specification also relate to a risk detection device, a computing device, a computer-readable storage medium and a computer program to solve the technical defects existing in the prior art.
[0005] According to a first aspect of an embodiment of this specification, a risk detection method is provided, including: Acquire characteristic data generated by a target software product under multiple target characteristic dimensions, where the multiple target characteristic dimensions are obtained by analyzing historical risk data of the target software product; For any target feature dimension, adopt the risk analysis strategy corresponding to the target feature dimension, perform risk analysis on the feature data generated under the target feature dimension, and obtain the risk estimation of the target feature dimension; Based on the risk estimation of multiple target feature dimensions, the risk detection results of the target software product are determined.
[0006] In one or more embodiments of this specification, the risk detection result of the target software product is determined based on the risk estimation of multiple target feature dimensions, including: Determine the risk metric value of the target software product based on the risk estimation of multiple target characteristic dimensions; Based on the risk measurement value of the target software product, a risk detection result of the target software product is determined.
[0007] In one or more embodiments of this specification, determining a risk metric value of a target software product based on risk estimates of multiple target feature dimensions includes: Determine the risk weight for each target characteristic dimension; Based on the risk estimation of each target feature dimension and the risk weight of the target feature dimension, a risk metric value of the target software product is determined.
[0008] In one or more embodiments of this specification, determining the risk weight of each target characteristic dimension includes: Acquire historical risk data of multiple sample software products, where the historical risk data includes risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; For any sample software product, based on the preset weight of each target feature dimension and the feature data generated under the target feature dimension, determine the risk measurement value of the sample software product; Based on the risk measurement values and risk detection results of multiple sample software products, the preset weights are adjusted until the risk measurement values of a preset number of sample software products match the risk detection results of the sample software products, thereby obtaining the risk weights of each target feature dimension.
[0009] In one or more embodiments of this specification, based on the risk metric value of the target software product, determining the risk detection result of the target software product includes: Obtaining a risk threshold and comparing the risk metric value of the target software product with the risk threshold; If the risk metric value is greater than the risk threshold, the risk detection result of the target software product is determined to be that there is a risk.
[0010] In one or more embodiments of this specification, obtaining the risk threshold includes: Acquire historical risk data of multiple sample software products, where the historical risk data includes risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; For any sample software product, based on the risk weight of each target feature dimension and the feature data generated under the target feature dimension, determine the risk measurement value of the sample software product; Determine the risk prediction result of each sample software product based on the risk measurement value and the preset risk threshold of each sample software product; Based on the risk prediction results and risk detection results of each sample software product, the preset risk threshold is adjusted until the risk prediction results and risk detection results of a preset number of software products are consistent, and the risk threshold is obtained.
[0011] In one or more embodiments of this specification, before acquiring feature data generated by a target software product under multiple target feature dimensions, the method further includes: Acquire historical risk data of a target software product, where the historical risk data includes historical feature data generated by the target software product under multiple feature dimensions, and the target software product includes multiple software products of the same category; Analyze the historical feature data of multiple feature dimensions to obtain the changing rules of each feature dimension in multiple software products; The number of first characteristic dimensions with the same change pattern in multiple software products is counted, and if the number is greater than a preset number, the first characteristic dimension is determined as a target characteristic dimension, and the first characteristic dimension is any characteristic dimension among the multiple characteristic dimensions.
[0012] In one or more embodiments of the present specification, the risk analysis strategy includes a feature value conversion strategy and a risk estimation strategy; using the risk analysis strategy corresponding to the target feature dimension, performing risk analysis on the feature data generated under the target feature dimension, and obtaining a risk estimation of the target feature dimension, including: Adopting a feature value conversion strategy corresponding to the target feature dimension, and determining a feature value corresponding to the target feature dimension based on feature data generated under the target feature dimension; A risk estimation strategy corresponding to the target feature dimension is adopted, and a risk estimation of the target feature dimension is determined based on the eigenvalue corresponding to the target feature dimension.
[0013] According to a second aspect of an embodiment of this specification, there is provided a risk detection device, including: An acquisition module is configured to acquire feature data generated by a target software product under multiple target feature dimensions, where the multiple target feature dimensions are obtained by analyzing historical risk data of the target software product; The risk analysis module is configured to, for any target feature dimension, adopt a risk analysis strategy corresponding to the target feature dimension, perform risk analysis on feature data generated under the target feature dimension, and obtain a risk estimate for the target feature dimension; The determination module is configured to determine the risk detection result of the target software product based on the risk estimation of multiple target feature dimensions.
[0014] According to a third aspect of an embodiment of this specification, a computing device is provided, including: Memory and processor; The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the above-mentioned risk detection method are implemented.
[0015] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the above-mentioned risk detection method are implemented.
[0016] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned risk detection method.
[0017] An embodiment of the present specification realizes obtaining feature data generated by a target software product under multiple target feature dimensions, where the multiple target feature dimensions are obtained by analyzing the historical risk data of the target software product; for any target feature dimension, a risk analysis strategy corresponding to the target feature dimension is used to perform risk analysis on the feature data generated under the target feature dimension to obtain a risk estimate for the target feature dimension; and based on the risk estimates of the multiple target feature dimensions, a risk detection result of the target software product is determined. The above method obtains a target feature dimension with a relatively high degree of risk correlation with whether the target software product has risks based on the historical risk data analysis of the target software product, and determines the risk detection result of the target software product through the feature data generated under the multiple target feature dimensions, which can improve the accuracy of risk detection. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Figure 1 is a flow chart of a risk detection method provided by an embodiment of this specification; Figure 2 is a process flow chart of a risk detection method provided by an embodiment of this specification; Figure 3 It is a structural schematic diagram of a risk detection device provided by an embodiment of this specification; Figure 4 It is a structural block diagram of a computing device provided by an embodiment of this specification. DETAILED DESCRIPTION
[0019] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.
[0020] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.
[0021] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".
[0022] First, the terms involved in one or more embodiments of this specification are explained.
[0023] Software supply chain products: various open source and closed source software libraries used in the design, development, and delivery of software products.
[0024] Code static scanning: Analyze the code semantics and behavior without actually executing the program, thereby finding abnormal program semantics or undefined behavior caused by incorrect coding in the program.
[0025] Dynamic code scanning: Executed when the code is running, it simulates automatic attacks on applications by imitating malicious attackers to discover unexpected consequences or results that may be used by attackers to harm applications.
[0026] Next, the application scenarios of the risk detection method provided by one or more embodiments of this specification are described.
[0027] A report once pointed out that under the current development model, most of the code in the application is "assembled" rather than "developed". According to its statistics, more than 95% of organizations actively or passively use important open source software (OSS) assets in key IT systems of projects; research shows that 80% to 90% of the code of application software comes from open source components. Therefore, the security of open source components is directly related to the security of information system infrastructure, but the security of open source software is not optimistic at present, and it has become an important factor in the growth of software supply chain security issues.
[0028] XX Lab released the "XX Software Supply Chain Security Analysis Report". The report analyzed the test results of 2,188 enterprise software projects and concluded the security status of open source use: all software projects use open source software, with an average of 135 open source software per project. The most used open source software appears in 581 projects, with a penetration rate of 26.6%; on average, each software project has 52.5 open source software vulnerabilities, and the number of projects with open source software vulnerabilities, high-risk open source software vulnerabilities, and super-risk open source software vulnerabilities is 1,695, 1,599, and 1,319 respectively, accounting for 77.5%, 71.3%, and 60.3% respectively; the open source software vulnerability with the greatest impact (Spring Frame Work vulnerability) appears in 973 projects, with a penetration rate of 44.5%. Once the vulnerability is exploited by attackers, it will affect nearly half of enterprise software, and the number of affected enterprises will be countless.
[0029] In addition, according to another security test on the firmware of networked devices conducted by XX Lab, the open source software security issues of smart networked devices such as cameras and routers are also prominent: many old vulnerabilities from many years ago have not been repaired in time, and the latest firmware of 86.4% of devices has at least one old open source software vulnerability, and the firmware with the most vulnerabilities has 74 old open source software vulnerabilities. Even the "Heartbleed" vulnerability exposed in 2014 still exists in 5.3% of the latest devices. Therefore, risk detection of software products is urgent.
[0030] In the field of risk detection of traditional software products, static code scanning or dynamic code scanning technology is usually used to scan and analyze the source code, and potential security risks are discovered through means such as feature matching and semantic analysis.
[0031] Static code scanning technology, because software products are usually provided in the form of packaged products, and the code in the products is compared with the source code, some of the code has been compiled, obfuscated, encrypted, etc., static code scanning technology often cannot correctly identify the code semantics, cannot accurately hit the code features, and leads to detection omissions. Dynamic code scanning technology relies on the detection capability of the software at runtime, but software products are part of the software system and cannot run independently in most cases. The runtime detection capability is invalid at this time and cannot be detected normally.
[0032] To this end, one or more embodiments of this specification provide a risk detection method that can solve the above-mentioned problems. For specific implementation, please refer to the relevant descriptions of the following embodiments.
[0033] In this specification, a risk detection method is provided. This specification also relates to a risk detection device, a computing device, and a computer-readable storage medium, which are described in detail one by one in the following embodiments.
[0034] See also Figure 1 , Figure 1 A flow chart of a risk detection method provided by an embodiment of the present specification is shown, which specifically includes the following steps.
[0035] Step 102: Acquire feature data generated by a target software product under multiple target feature dimensions, where the multiple target feature dimensions are obtained by analyzing historical risk data of the target software product.
[0036] In the embodiments of this specification, the target software product may also be referred to as a software supply chain product, which is a software product that requires risk detection. It may be a category of software products or a software product, and this embodiment of this specification does not limit this.
[0037] In some embodiments, the target feature dimension is a feature dimension with a high degree of correlation with whether the target software product has risks, that is, the feature data of the target feature dimension can be used to determine whether the target software product has risks. That is, it can be understood that the target feature dimension corresponds to a class of software products, or the target feature dimension corresponds to a software product. The target feature dimension determined in this way is more targeted and more consistent with the relationship between the feature data of the target software product and the risk of the target software product, thereby improving the accuracy of risk detection.
[0038] In one or more embodiments of the present specification, the multiple target feature dimensions may include a basic feature dimension and a code feature dimension. The basic feature dimension is a dimension where features related to basic information of the target software product are located, and the code feature dimension is a dimension where features related to the code of the target software product or need to be determined through the code are located.
[0039] In some embodiments, the basic feature dimension may include at least a download usage dimension, a release time dimension, and a product name dimension, and the code feature dimension may include at least a code volume dimension, a code obfuscation feature dimension, and a code static scanning feature dimension. Therefore, the feature data generated by the target software product under multiple target feature dimensions may include: the download usage of the target software product in the download usage dimension, the release time feature in the release time dimension, the product name feature in the product name dimension, the code volume in the code volume dimension, the code obfuscation feature in the code obfuscation feature dimension, and the code static scanning feature in the code static scanning feature dimension.
[0040] Among them, the download usage volume indicates the number of times the target software product has been downloaded and used by users; the release time feature refers to the release time of the target software product; the product name feature refers to whether the product name is the same or similar to the product name used within the company, or has other obvious anomalies, such as the name contains a large number of meaningless letters; the code volume indicates the sum of the sizes of all files in the target software product; the code obfuscation feature refers to whether the code of the target software product has been obfuscated and the degree of obfuscation; the code static scanning feature refers to whether there are vulnerabilities in the code static scanning results of the target software product.
[0041] In some embodiments, basic information such as the product name, version, download link, and technology stack (software basic components that the product implementation depends on) of the target software product may be first obtained, and then the download usage and release time characteristics of the target software product may be obtained from the platform that releases the target software product based on the product name, version, download link, and technology stack, and the target software product may be downloaded, the installation package of the target software product may be decompressed to obtain the source code of the target software product, the sum of the sizes of all code files in the source code of the target software product may be calculated to obtain the code volume of the target software product, the source code may be detected by a code scanning tool to determine whether the source code of the target software product is obfuscated and the degree of obfuscation of the source code of the target software product, the source code may be scanned by a code static scanning technology to obtain code static scanning characteristics, and the product name characteristics of the target software product may be determined based on the product name and the enterprise name of the enterprise that develops the target software product.
[0042] In one or more embodiments of the present specification, before acquiring the feature data generated by the target software product under multiple target feature dimensions, the method further includes: Acquire historical risk data of a target software product, the historical risk data including historical feature data generated by the target software product under multiple feature dimensions, and the target software product including multiple software products of the same category; analyze the historical feature data of multiple feature dimensions to obtain the change pattern of each feature dimension in the multiple software products; count the number of times the change pattern of the first feature dimension in the multiple software products is the same, and if the number is greater than a preset number, determine the first feature dimension as the target feature dimension, and the first feature dimension is any feature dimension among the multiple feature dimensions.
[0043] As an example, historical risk data is data related to the risk of the target software product, including at least historical feature data generated by the target software product under multiple feature dimensions during historical time, and may include historical feature data generated under risk conditions or under non-risk conditions. In addition, the multiple feature dimensions include at least the dimension of download usage, the dimension of release time, the dimension of product name, the dimension of code volume, the dimension of code obfuscation feature, and the dimension of code static scanning feature.
[0044] In some embodiments, before performing risk detection on a target software product, it is necessary to first determine a target feature dimension that is highly correlated with the risk of the target software product. Therefore, historical feature data of multiple software products of the same category as the target software product can be obtained first, and then for a first feature dimension, the change pattern of the first feature dimension in each software product is determined, and the number of software products with the same change pattern of the first feature dimension in multiple software products is counted. If the number is greater than a preset number, it can be considered that the feature data of the first feature dimension is highly correlated with whether the target software product has a risk, and the first feature dimension can be determined to be the target feature dimension.
[0045] It should be noted that the preset number can be set by the device by default, or can be set by the user according to actual needs, and can be adaptively adjusted during use, and the embodiments of this specification do not limit this.
[0046] As an example, the changing rule of the first characteristic dimension in a software product can be the correlation between the first characteristic dimension and the software product. For example, the lower the download and usage of the software product, the higher the risk, which can be understood as the download and usage being negatively correlated with the risk; the lower the code volume of the software product, the higher the risk, which can be understood as the code volume being negatively correlated with the risk; the shorter the release time of the software product, the higher the risk, which can be understood as the code volume being negatively correlated with the risk; the more code obfuscation features a software product has, the higher the risk, which can be understood as the code obfuscation feature being positively correlated with the risk; the more static scanning features a software product has, the higher the risk, which can be understood as the code static scanning feature being positively correlated with the risk; the higher the similarity between the product name of the software product and the company name, the higher the risk, which can be understood as the product name being positively correlated with the risk.
[0047] As an example, taking the code volume dimension as an example, the code volume of multiple software products in the code volume dimension and the risk level of each software product are obtained. If the code volume dimension is negatively correlated with the risk level of the software product in N software products, and N is greater than a preset number, it can be determined that the code volume dimension is the target feature dimension. After performing the above operations on multiple feature dimensions, the target feature dimension can be determined from the multiple feature dimensions.
[0048] In the embodiments of the present specification, through the historical feature data of the existing target software product in multiple feature dimensions, a target feature dimension with a high correlation with the risk level of the target product can be determined, and the target feature dimension is targeted to the target software product and is more consistent with the relationship between the risk and feature dimension of the target software product. Therefore, risk detection of the target software product based on the feature data of the target feature dimension can obtain more accurate risk detection results.
[0049] Step 104: For any target feature dimension, adopt the risk analysis strategy corresponding to the target feature dimension, perform risk analysis on the feature data generated under the target feature dimension, and obtain the risk estimation of the target feature dimension.
[0050] In one or more embodiments of the present specification, the risk analysis strategy is used to perform risk analysis on the feature data of the target feature dimension to determine the risk level (risk estimation) of the target feature dimension. Moreover, for different target feature dimensions, different risk analysis strategies are used, so that the strategy that conforms to the data situation of the target feature dimension can be used for risk analysis, and the risk estimation obtained is more accurate.
[0051] In one or more embodiments of the present specification, the risk analysis strategy includes a feature value conversion strategy and a risk estimation strategy; using the risk analysis strategy corresponding to the target feature dimension, performing risk analysis on the feature data generated under the target feature dimension, and obtaining a risk estimation of the target feature dimension, including: Adopt the eigenvalue conversion strategy corresponding to the target feature dimension, and determine the eigenvalue corresponding to the target feature dimension based on the feature data generated under the target feature dimension; adopt the risk estimation strategy corresponding to the target feature dimension, and determine the risk estimation of the target feature dimension based on the eigenvalue corresponding to the target feature dimension.
[0052] Among them, the feature value conversion strategy is used to convert the feature data into a feature value, that is, a numerical value, to facilitate subsequent calculations. The risk estimation strategy is used to determine the risk estimation based on the feature value, which may be a predetermined function or a pre-set threshold, etc., which is not limited in the embodiments of this specification. In addition, the feature conversion strategy and the risk estimation strategy can be set by the user according to the risk situation of the target software product, or can be set based on experience, and can also be adjusted according to actual conditions during use, which is not limited in the embodiments of this specification.
[0053] In some embodiments, the feature data of the corresponding target feature dimension can be first converted into feature values according to a feature value conversion strategy, and then the feature values can be converted into risk estimates based on a corresponding risk estimation strategy, so that the risk estimation of the target feature dimension can be obtained.
[0054] As an example, for the code volume dimension, since the feature data code volume itself is a numerical value, the feature value conversion strategy corresponding to the code volume dimension is to determine the feature data as a feature value; for the code obfuscation feature dimension, the feature value can be converted according to the obfuscation degree of the code obfuscation feature, such as the feature value corresponding to no obfuscation is 0, the feature value corresponding to weak obfuscation is 1, the feature value corresponding to medium-intensity obfuscation is 2, and the feature value corresponding to strong obfuscation is 3; for the code static scanning feature dimension, the feature value can be converted according to the possibility of whether there is a vulnerability, such as the possibility of a vulnerability is 0%, the corresponding feature value is 0, The possibility of a vulnerability is 1%-80%, and the corresponding feature value is 1. The possibility of a vulnerability is 81%-90%, and the corresponding feature value is 2. The possibility of a vulnerability is 91%-100%, and the corresponding feature value is 3. For the product name feature, the feature value can be converted according to the possibility of anomalies. For example, the possibility of anomalies is 0%, and the corresponding feature value is 0. The possibility of anomalies is 1%-80%, and the corresponding feature value is 1. The possibility of anomalies is 81%-90%, and the corresponding feature value is 2. The possibility of anomalies is 91%-100%, and the corresponding feature value is 3.
[0055] In the above manner, the feature data of each target feature dimension can be converted into a feature value, and then the risk estimation is determined based on the feature value according to the risk estimation strategy.
[0056] For example, with respect to the amount of code, by analyzing the differences between existing software products with risks and software products without risks, it can be determined that the amount of code in software products with risks is much less than that in software products without risks, so a threshold for the amount of code can be set. When the amount of code is less than the threshold for the amount of code, the smaller the amount of code, the higher the risk level, and the higher the risk estimate; when the amount of code is greater than the threshold for the amount of code, the risk estimate can be determined to be 0.
[0057] As an example, assume that the target feature dimensions include dimension 1, dimension 2, and dimension 3, and the feature data of the three target feature dimensions are a1, a2, and a3, respectively. If the risk estimation strategy is a function, assume that the risk estimation strategies corresponding to the three target feature dimensions are f1, f2, and f3, respectively, then the risk estimate of dimension 1 is b1=f1(a1), the risk estimate of dimension 2 is b2=f2(a2), and the risk estimate of dimension 3 is b3=f3(a3).
[0058] In one or more embodiments of the present specification, for each target feature dimension, a feature value conversion strategy and a risk estimation strategy corresponding to the target feature dimension are adopted to specifically determine the risk estimation of each target feature dimension, thereby improving the accuracy of the determined risk estimation.
[0059] Step 106: Determine the risk detection result of the target software product based on the risk estimation of multiple target feature dimensions.
[0060] The risk detection result may be whether a risk exists or the degree of risk, which is not limited in the embodiments of this specification.
[0061] In one or more embodiments of the present specification, determining the risk detection result of the target software product according to the risk estimation of multiple target feature dimensions includes: According to the risk estimation of multiple target characteristic dimensions, the risk measurement value of the target software product is determined; based on the risk measurement value of the target software product, the risk detection result of the target software product is determined.
[0062] Among them, the risk measurement value can be used to measure the risk of the target software product.
[0063] That is to say, after determining the risk estimates of multiple target feature dimensions, the risk estimates of multiple target feature dimensions are integrated to obtain the risk measurement value of the target software product. Based on the risk measurement value of the target software product, the risk detection result of the target software product can be obtained, thereby realizing risk detection of the target software product.
[0064] In some embodiments, the sum of the risk estimates of multiple target feature dimensions can be added together to determine the risk metric value of the target software product. Alternatively, the relationship between multiple target feature dimensions and the relationship between the multiple target feature dimensions and the risk level of the target software product can be determined based on experience or big data to obtain a risk metric function, and the multiple target feature dimensions can be substituted into the risk metric function to obtain the risk metric value of the target software product.
[0065] The above method determines the risk detection result of the target software product based on the risk estimation of multiple target feature dimensions, and can combine risk detection with multiple feature dimensions, so that the obtained risk detection result is more accurate.
[0066] In some other embodiments, determining the risk metric value of the target software product based on the risk estimates of multiple target feature dimensions includes: Determine the risk weight of each target feature dimension; and determine the risk metric value of the target software product based on the risk estimate of each target feature dimension and the risk weight of the target feature dimension.
[0067] As an example, since different target feature dimensions have different degrees of impact on the risks of the target software product, different risk weights need to be determined for different target feature dimensions. Therefore, the risk weight of each target feature dimension can be determined first, and the risk weight of each target feature dimension can be multiplied by the risk estimate of the target feature dimension. Then, a product can be determined for each target feature dimension, and the sum of multiple products is determined as the risk measurement value of the target software product.
[0068] For example, assuming that the target feature dimensions include dimension 1, dimension 2 and dimension 3, and the risk estimate of dimension 1 is b1, the risk estimate of dimension 2 is b2, the risk estimate of dimension 3 is b3, the risk weight of dimension 1 is c1, the risk weight of dimension 2 is c2, and the risk weight of dimension 3 is c3, then the risk measurement value of the target software product can be determined as s=c1*b1+c2*b2+c3*b3.
[0069] The above method assigns different risk weights to risk estimates of different feature dimensions, and determines the risk measurement value of the target software product based on the risk estimates of different feature dimensions and the corresponding risk weights. Since different risk weights distinguish the impact of different feature dimensions on the risk level of the target software product, the determined risk measurement value will be more accurate.
[0070] In some embodiments, determining the risk weight of each target characteristic dimension includes: Acquire historical risk data of multiple sample software products, the historical risk data including risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; for any sample software product, determine the risk measurement value of the sample software product based on a preset weight of each target feature dimension and the feature data generated under the target feature dimension; adjust the preset weight based on the risk measurement values and risk detection results of the multiple sample software products until the risk measurement values of a preset number of sample software products match the risk detection results of the sample software product, and obtain the risk weight of each target feature dimension.
[0071] The sample software product may be an existing software product of the same category as the target software product, and the risk detection result of the sample software product is known, and the feature data generated by the sample software product in multiple feature dimensions is also known.
[0072] As an example, the risk detection result of the sample software product can be obtained first, the feature data generated by the sample software product under multiple target feature dimensions can be obtained, and the preset weights can be obtained. Based on the feature data of the multiple target feature dimensions and the corresponding preset weights, the risk measurement value of the sample software product can be determined in the same manner as the above step 106. The risk prediction result of the sample software product can be determined based on the risk measurement value. The risk prediction result of each sample software product can be compared with the risk detection result of the sample software product. If the risk prediction results of more than a preset number of sample software products do not match the risk detection results, the preset weights can be adjusted, and the risk measurement value of each sample software product can be determined again. Until the risk estimates of more than or equal to the preset number of sample software products match the risk detection results of the sample software product, it can be determined that the preset weight at this time is more appropriate, and the preset weight of each target feature dimension at this time is determined as the risk weight of the target feature dimension.
[0073] In one or more embodiments of the present specification, the preset weights are adjusted according to the characteristic data and risk detection results of the sample software products to obtain the risk weights of the target characteristic dimensions. The risk weights that make the risk detection results of most sample software products match the risk prediction results can be determined. The risk weights are the same as the risk distribution of the target software products in multiple characteristic dimensions, and therefore the determined risk weights are more appropriate and more accurate.
[0074] In one or more embodiments of the present specification, based on the risk metric value of the target software product, determining the risk detection result of the target software product includes: A risk threshold is obtained, and the risk measurement value of the target software product is compared with the risk threshold; if the risk measurement value is greater than the risk threshold, it is determined that the risk detection result of the target software product is that there is a risk.
[0075] Among them, the risk threshold can be set by the user according to actual needs, or can be set by the device by default, or can be obtained based on big data analysis, which is not limited in the embodiments of this specification.
[0076] As an example, a risk threshold may be obtained first, and then the risk threshold may be compared with the risk measurement value. If the risk measurement value is greater than the risk threshold, it may be considered that the possibility of the target software product being at risk is relatively high. Therefore, it may be determined that the risk detection result of the target software product is that there is a risk. If the risk measurement value is less than or equal to the risk threshold, it may be considered that the possibility of the target software product being at risk is relatively low. Therefore, it may be determined that the risk detection result of the target software product is that there is no risk.
[0077] The above method determines the risk detection result of the target software product by comparing the risk metric value with the pre-set risk threshold, and implements the risk detection of the target software product in a simple manner, thereby improving the efficiency of risk detection.
[0078] In another possible implementation of the present specification, determining the risk detection result of the target software product by a risk threshold may be too broad. Therefore, the risk levels may also be divided. Different risk levels correspond to different risk measurement value ranges. The risk level of the target software product can be determined based on the risk measurement value range in which the risk measurement value of the target software product lies, and the risk level is determined as the risk detection result of the target software product.
[0079] As an example, assume that the risk level includes high risk, medium risk, low risk and no risk, and the risk metric value is divided into four ranges of 0-60, 61-80, 81-90, and 91-100, and the risk level corresponding to the risk metric value 0-60 is no risk, the risk level corresponding to the risk metric value 61-80 is low risk, the risk level corresponding to the risk metric value 81-90 is medium risk, and the risk level corresponding to the risk metric value 91-100 is high risk. If the risk metric value of the target software product is 88, it can be determined that the risk level of the target software product is medium risk.
[0080] The above method detects the risks of the target software product according to the risk level. The risk levels are divided more detailedly, and the risk detection results of the target software product are determined to be more accurate.
[0081] In one or more embodiments of this specification, obtaining a risk threshold includes: Acquire historical risk data of multiple sample software products, the historical risk data including risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; for any sample software product, determine the risk measurement value of the sample software product based on the risk weight of each target feature dimension and the feature data generated under the target feature dimension; determine the risk prediction result of each sample software product based on the risk measurement value and a preset risk threshold of each sample software product; adjust the preset risk threshold based on the risk prediction result and risk detection result of each sample software product until the risk prediction results and risk detection results of a preset number of software products are consistent, thereby obtaining the risk threshold.
[0082] The sample software product may be an existing software product of the same category as the target software product, and the risk detection result of the sample software product is known, and the feature data generated by the sample software product in multiple feature dimensions is also known.
[0083] As an example, risk detection results of multiple sample software products and feature data generated by each sample software product under multiple target feature dimensions can be obtained, and the aforementioned adjusted risk weights can be obtained. Based on the feature data of the multiple target feature dimensions and the corresponding risk weights, the risk measurement value of the sample software product can be determined in the same manner as the above step 106. The risk measurement value is compared with a preset risk threshold to determine the risk prediction result of the sample software product. The risk prediction result of each sample software product is compared with the risk detection result of the sample software product. If the risk prediction results of more than a preset number of sample software products do not match the risk detection results, the preset risk threshold is adjusted, and the risk measurement value of each sample software product is determined again until the risk prediction results of more than a preset number of sample software products match the risk detection result of the sample software product. In this case, it can be determined that the preset risk threshold at this time is more appropriate, and the preset risk threshold at this time is determined as the risk threshold.
[0084] It should be noted that the above process is actually to adjust the risk threshold so that the risk measurement values of software products known to have risks are higher than the risk threshold, and the risk measurement values of software products known to have no risks are lower than the risk threshold, so as to ensure accuracy and make the risk measurement values of as few software products known to have no risks as possible higher than the risk threshold, reduce the false alarm rate, and finally obtain an accurate risk threshold.
[0085] The above method adjusts the preset risk threshold according to the characteristic data and risk detection results of the sample software products to obtain the risk threshold. The risk threshold that makes the risk detection results of most sample software products match the risk prediction results can be determined. The risk detection results of the target software product are determined based on the risk threshold, which can obtain more accurate detection results.
[0086] It should be noted that in other embodiments of the present specification, the preset weight and the preset risk threshold may be adjusted together according to the historical risk data of the sample software product to obtain the risk weight and the risk threshold.
[0087] An embodiment of the present specification realizes obtaining feature data generated by a target software product under multiple target feature dimensions, wherein the multiple target feature dimensions are obtained by analyzing the historical risk data of the target software product; for any target feature dimension, the risk analysis strategy corresponding to the target feature dimension is adopted to perform risk analysis on the feature data generated under the target feature dimension to obtain the risk estimation of the target feature dimension; and the risk detection result of the target software product is determined according to the risk estimation of the multiple target feature dimensions. The above method obtains the target feature dimension with a relatively high degree of risk correlation with whether the target software product has risk according to the historical risk data analysis of the target software product, and determines the risk detection result of the target software product through the feature data generated under the multiple target feature dimensions, which can improve the accuracy of risk detection. In addition, after adopting this scheme, there is no need to identify the semantics of the obfuscated and encrypted code, and it is only necessary to determine whether the current code has been obfuscated or encrypted as part of the feature data, and there is no need to run the software. The risk measurement value can be obtained by combining the feature data of other feature dimensions, and there will be no scanning failure or detection leakage due to code obfuscation and encryption or the inability of the software supply chain product to run independently.
[0088] The following combination Figure 2 , taking the application of the risk detection method provided in this specification in monitoring software supply chain intrusion events as an example, the risk detection method is further explained. Figure 2 A process flow chart of a risk detection method provided by an embodiment of this specification is shown, which specifically includes the following steps: Step 202: Acquire historical risk data of a target software product, where the historical risk data includes historical feature data generated by the target software product under multiple feature dimensions, and the target software product includes multiple software products of the same category.
[0089] For example, obtain a list of multiple software supply chain products used within the company, obtain historical feature data generated by multiple software supply chain products in the dimensions of download usage, release time, product name, code volume, code obfuscation feature, and code static scanning feature, as well as risk detection results for whether each software supply chain product has risks.
[0090] Step 204: Analyze the historical feature data of multiple feature dimensions to obtain the change rules of each feature dimension in multiple software products.
[0091] Step 206: Count the number of first feature dimensions with the same change pattern in multiple software products. If the number is greater than a preset number, determine the first feature dimension as the target feature dimension. The first feature dimension is any feature dimension among the multiple feature dimensions.
[0092] For example, based on the historical feature data generated by the above-mentioned multiple software supply chain products in multiple feature dimensions, analysis shows that the lower the download and usage of the software supply chain product, the lower the code volume, the shorter the release time, the more code obfuscation features, the more static scanning features, and the higher the similarity between the supply chain product name and the enterprise keywords, the higher the risk.
[0093] Step 208: Acquire feature data generated by the target software product under multiple target feature dimensions.
[0094] For example, for a target software product that needs to be risk-detected, obtain feature data generated by the target software product in the dimensions of download usage, release time, product name, code volume, code obfuscation feature, and code static scanning feature.
[0095] Step 210: For any target feature dimension, adopt the feature value conversion strategy corresponding to the target feature dimension, and determine the feature value corresponding to the target feature dimension based on the feature data generated under the target feature dimension.
[0096] For example, the feature value conversion strategy can be determined based on experience. For the code obfuscation feature dimension, the feature value can be converted according to the obfuscation degree of the code obfuscation feature, such as the feature value corresponding to no obfuscation is 0, the feature value corresponding to weak obfuscation is 1, the feature value corresponding to medium intensity obfuscation is 2, and the feature value corresponding to strong obfuscation is 3.
[0097] Step 212: adopting the risk estimation strategy corresponding to the target feature dimension, and determining the risk estimation of the target feature dimension based on the feature value corresponding to the target feature dimension.
[0098] Continuing with the above example, the risk estimation strategy can be determined based on experience. For the code obfuscation feature dimension, it is assumed that the risk estimation strategy is to determine the feature value as the risk estimate.
[0099] Step 214: Determine the risk weight for each target characteristic dimension.
[0100] For example, preset weights and preset risk thresholds are set, and the characteristic data of multiple software supply chain products used within the company under multiple characteristic dimensions are analyzed. The risk estimation of each software supply chain product under multiple characteristic dimensions is determined according to the preset weights, and then the risk measurement value of each software supply chain product is determined based on the risk estimation. The risk prediction result of each software supply chain product is determined based on the risk measurement value and the preset risk threshold. The preset weights and preset risk thresholds are dynamically adjusted according to the risk prediction results and risk detection results, so that the risk measurement values of software products known to have risks are higher than the risk threshold, and the risk measurement values of software products known not to have risks are lower than the risk threshold, so as to ensure accuracy, and the risk measurement values of as few software products known not to have risks as possible are higher than the risk threshold, so as to reduce the false alarm rate, and finally obtain accurate risk weights and risk thresholds.
[0101] Step 216: Determine a risk metric value of the target software product based on the risk estimate of each target feature dimension and the risk weight of the target feature dimension.
[0102] For example, assuming that the target feature dimensions include dimension 1 and dimension 2, and the risk estimate of dimension 1 is b1, the risk estimate of dimension 2 is b2, the risk weight of dimension 1 is c1, and the risk weight of dimension 2 is c2, then the risk measurement value of the target software product can be determined as s=c1*b1+c2*b2.
[0103] Step 218: Obtain a risk threshold, and compare the risk metric value of the target software product with the risk threshold.
[0104] Step 220: If the risk metric value is greater than the risk threshold, determine that the risk detection result of the target software product is that there is a risk.
[0105] For example, assuming that the risk threshold is 90 and the risk measurement value is 95, it can be determined that the target software product has risks.
[0106] For example, the download logs of the company's internal software warehouse can be continuously monitored, the downloaded target software products can be analyzed, and the risk measurement value of the target software product can be compared with the risk threshold. If it is greater than the risk threshold, it means that an employee has downloaded and used a risky product and may be invaded by external forces, and subsequent emergency investigation work can be started.
[0107] An embodiment of the present specification realizes obtaining feature data generated by a target software product under multiple target feature dimensions, wherein the multiple target feature dimensions are obtained by analyzing the historical risk data of the target software product; for any target feature dimension, the risk analysis strategy corresponding to the target feature dimension is adopted to perform risk analysis on the feature data generated under the target feature dimension to obtain the risk estimation of the target feature dimension; and the risk detection result of the target software product is determined according to the risk estimation of the multiple target feature dimensions. The above method obtains the target feature dimension with a relatively high degree of risk correlation with whether the target software product has risk according to the historical risk data analysis of the target software product, and determines the risk detection result of the target software product through the feature data generated under the multiple target feature dimensions, which can improve the accuracy of risk detection. In addition, after adopting this scheme, there is no need to identify the semantics of the obfuscated and encrypted code, and it is only necessary to determine whether the current code has been obfuscated or encrypted as part of the feature data, and there is no need to run the software. The risk measurement value can be obtained by combining the feature data of other feature dimensions, and there will be no scanning failure or detection leakage due to code obfuscation and encryption or the inability of the software supply chain product to run independently.
[0108] Corresponding to the above method embodiment, this specification also provides a risk detection device embodiment, Figure 3 FIG. 1 is a schematic diagram showing the structure of a risk detection device provided by an embodiment of the present specification. Figure 3 As shown, the device comprises: An acquisition module 302 is configured to acquire feature data generated by a target software product under multiple target feature dimensions, where the multiple target feature dimensions are obtained by analyzing historical risk data of the target software product; The risk analysis module 304 is configured to perform risk analysis on the feature data generated under any target feature dimension by using the risk analysis strategy corresponding to the target feature dimension to obtain a risk estimate of the target feature dimension; The determination module 306 is configured to determine the risk detection result of the target software product according to the risk estimation of multiple target feature dimensions.
[0109] In one or more embodiments of this specification, the determination module 306 is further configured to: Determine the risk metric value of the target software product based on the risk estimation of multiple target characteristic dimensions; Based on the risk measurement value of the target software product, a risk detection result of the target software product is determined.
[0110] In one or more embodiments of this specification, the determination module 306 is further configured to: Determine the risk weight for each target characteristic dimension; Based on the risk estimation of each target feature dimension and the risk weight of the target feature dimension, a risk metric value of the target software product is determined.
[0111] In one or more embodiments of this specification, the determination module 306 is further configured to: Acquire historical risk data of multiple sample software products, where the historical risk data includes risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; For any sample software product, based on the preset weight of each target feature dimension and the feature data generated under the target feature dimension, determine the risk measurement value of the sample software product; Based on the risk measurement values and risk detection results of multiple sample software products, the preset weights are adjusted until the risk measurement values of a preset number of sample software products match the risk detection results of the sample software products, thereby obtaining the risk weights of each target feature dimension.
[0112] In one or more embodiments of this specification, the determination module 306 is further configured to: Obtaining a risk threshold and comparing the risk metric value of the target software product with the risk threshold; If the risk metric value is greater than the risk threshold, the risk detection result of the target software product is determined to be that there is a risk.
[0113] In one or more embodiments of this specification, the determination module 306 is further configured to: Acquire historical risk data of multiple sample software products, where the historical risk data includes risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; For any sample software product, based on the risk weight of each target feature dimension and the feature data generated under the target feature dimension, determine the risk measurement value of the sample software product; Determine the risk prediction result of each sample software product based on the risk measurement value and the preset risk threshold of each sample software product; Based on the risk prediction results and risk detection results of each sample software product, the preset risk threshold is adjusted until the risk prediction results and risk detection results of a preset number of software products are consistent, and the risk threshold is obtained.
[0114] In one or more embodiments of this specification, the acquisition module 302 is further configured to: Acquire historical risk data of a target software product, where the historical risk data includes historical feature data generated by the target software product under multiple feature dimensions, and the target software product includes multiple software products of the same category; Analyze the historical feature data of multiple feature dimensions to obtain the changing rules of each feature dimension in multiple software products; The number of first characteristic dimensions with the same change pattern in multiple software products is counted, and if the number is greater than a preset number, the first characteristic dimension is determined as a target characteristic dimension, and the first characteristic dimension is any characteristic dimension among the multiple characteristic dimensions.
[0115] In one or more embodiments of this specification, the risk analysis module 304 is further configured to: Adopting a feature value conversion strategy corresponding to the target feature dimension, and determining a feature value corresponding to the target feature dimension based on feature data generated under the target feature dimension; A risk estimation strategy corresponding to the target feature dimension is adopted, and a risk estimation of the target feature dimension is determined based on the eigenvalue corresponding to the target feature dimension.
[0116] The risk detection device provided in the embodiment of this specification obtains the feature data generated by the target software product under multiple target feature dimensions, and the multiple target feature dimensions are obtained by analyzing the historical risk data of the target software product; for any target feature dimension, the risk analysis strategy corresponding to the target feature dimension is adopted to perform risk analysis on the feature data generated under the target feature dimension to obtain the risk estimation of the target feature dimension; and the risk detection result of the target software product is determined according to the risk estimation of the multiple target feature dimensions. The above method obtains the target feature dimension with a relatively high degree of risk correlation with whether the target software product has risk according to the historical risk data analysis of the target software product, and determines the risk detection result of the target software product through the feature data generated under the multiple target feature dimensions, which can improve the accuracy of risk detection. In addition, after adopting this scheme, there is no need to identify the semantics of the obfuscated and encrypted code. It is only necessary to determine whether the current code has been obfuscated or encrypted as part of the feature data, and there is no need to run the software. The risk measurement value can be obtained by combining the feature data of other feature dimensions, and there will be no scanning failure or detection leakage due to code obfuscation and encryption or the inability of the software supply chain product to run independently.
[0117] The above is a schematic scheme of a risk detection device of this embodiment. It should be noted that the technical scheme of the risk detection device and the technical scheme of the risk detection method described above are of the same concept, and the details not described in detail in the technical scheme of the risk detection device can be found in the description of the technical scheme of the risk detection method described above.
[0118] Figure 4The structure block diagram of a computing device 400 provided in one embodiment of the present specification is shown. The components of the computing device 400 include but are not limited to a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and the database 450 is used to store data.
[0119] The computing device 400 also includes an access device 440 that enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 440 may include one or more of any type of network interface (e.g., a network interface card (NIC)) of wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a world-wide interoperability for microwave access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.
[0120] In one embodiment of the present specification, the above components of the computing device 400 and Figure 4 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Figure 4 The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.
[0121] Computing device 400 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. Computing device 400 may also be a mobile or stationary server.
[0122] The processor 420 is used to execute the following computer executable instructions, which, when executed by the processor, implement the steps of the above-mentioned risk detection method.
[0123] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the risk detection method described above are of the same concept, and the details not described in detail in the technical scheme of the computing device can be found in the description of the technical scheme of the risk detection method described above.
[0124] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which can implement the steps of the above-mentioned risk detection method when executed by a processor.
[0125] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the risk detection method described above are of the same concept, and the details not described in detail in the technical scheme of the storage medium can be found in the description of the technical scheme of the risk detection method described above.
[0126] An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned risk detection method.
[0127] The above is a schematic scheme of a computer program of this embodiment. It should be noted that the technical scheme of the computer program and the technical scheme of the risk detection method described above are of the same concept, and the details not described in detail in the technical scheme of the computer program can be found in the description of the technical scheme of the risk detection method described above.
[0128] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0129] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.
[0130] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.
[0131] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0132] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.
Claims
1. A risk detection method, comprising: Acquire historical risk data of multiple sample software products, wherein the historical risk data includes risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; For any sample software product, based on the preset weight of each target feature dimension and the feature data generated under the target feature dimension, determine the risk metric value of the sample software product, wherein the multiple target feature dimensions include a basic feature dimension and a code feature dimension; Based on the risk metrics and risk detection results of multiple sample software products, the preset weights are adjusted until the risk metrics of a preset number of sample software products match the risk detection results of the sample software products, thereby obtaining the risk weights of each target feature dimension; The risk detection result of the target software product is determined according to the risk weight of each target feature dimension of the target software product.
2. The method according to claim 1, wherein determining the risk detection result of the target software product according to the risk weight of each target feature dimension of the target software product comprises: Determining a risk metric value of the target software product based on a risk estimate of each target feature dimension of the target software product and a risk weight of the target feature dimension; Based on the risk metric value of the target software product, a risk detection result of the target software product is determined.
3. The method according to claim 2, before determining the risk metric value of the target software product based on the risk estimation of each target feature dimension of the target software product and the risk weight of the target feature dimension, further comprising: For any target feature dimension of the target software product, the risk analysis strategy corresponding to the target feature dimension is adopted to perform risk analysis on the feature data generated under the target feature dimension to obtain the risk estimation of the target feature dimension.
4. The method according to claim 2, wherein determining the risk detection result of the target software product based on the risk metric value of the target software product comprises: Obtaining a risk threshold, and comparing the risk metric value of the target software product with the risk threshold; If the risk metric value is greater than the risk threshold, it is determined that the risk detection result of the target software product is that there is a risk.
5. The method according to claim 4, wherein obtaining the risk threshold comprises: Acquire historical risk data of multiple sample software products, wherein the historical risk data includes risk detection results of the sample software products and feature data generated by the sample software products under multiple target feature dimensions; For any sample software product, based on the risk weight of each target feature dimension and the feature data generated under the target feature dimension, determine the risk measurement value of the sample software product; Determine the risk prediction result of each sample software product based on the risk measurement value and the preset risk threshold of each sample software product; Based on the risk prediction results and risk detection results of each sample software product, the preset risk threshold is adjusted until the risk prediction results and risk detection results of a preset number of software products are consistent, thereby obtaining the risk threshold.
6. The method according to claim 3, before the risk analysis strategy corresponding to the target feature dimension is used for any target feature dimension of the target software product to perform risk analysis on the feature data generated under the target feature dimension to obtain the risk estimate of the target feature dimension, the method further comprises: Acquire historical risk data of a target software product, wherein the historical risk data includes historical feature data generated by the target software product under multiple feature dimensions, and the target software product includes multiple software products of the same category; Analyze the historical feature data of the multiple feature dimensions to obtain the change rules of each feature dimension in the multiple software products; The number of first characteristic dimensions having the same change pattern in the multiple software products is counted, and if the number is greater than a preset number, the first characteristic dimension is determined as a target characteristic dimension, wherein the first characteristic dimension is any characteristic dimension among the multiple characteristic dimensions.
7. The method according to claim 3 or 6, wherein the risk analysis strategy comprises a feature value conversion strategy and a risk estimation strategy; wherein the risk analysis strategy corresponding to the target feature dimension is adopted to perform risk analysis on the feature data generated under the target feature dimension to obtain the risk estimation of the target feature dimension, comprising: Adopting a feature value conversion strategy corresponding to the target feature dimension, and determining a feature value corresponding to the target feature dimension based on feature data generated under the target feature dimension; A risk estimation strategy corresponding to the target feature dimension is adopted, and a risk estimation of the target feature dimension is determined based on the eigenvalue corresponding to the target feature dimension.
8. A risk detection device, comprising: An acquisition module is configured to acquire historical risk data of a plurality of sample software products, wherein the historical risk data includes risk detection results of the sample software products and feature data generated by the sample software products under a plurality of target feature dimensions; A risk metric value determination module is configured to determine, for any sample software product, a risk metric value of the sample software product based on a preset weight of each target feature dimension and feature data generated under the target feature dimension, wherein the multiple target feature dimensions include a basic feature dimension and a code feature dimension; A risk weight determination module is configured to adjust the preset weight based on the risk metric values and risk detection results of multiple sample software products until the risk metric values of a preset number of sample software products match the risk detection results of the sample software products, thereby obtaining a risk weight for each target feature dimension; The risk detection result determination module is configured to determine the risk detection result of the target software product according to the risk weight of each target feature dimension of the target software product.
9. A computing device comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the risk detection method according to any one of claims 1 to 7 are implemented.
10. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the steps of the risk detection method according to any one of claims 1 to 7.
Citation Information
Patent Citations
Software quality assessment method, device and equipment and computer storage medium
CN109684851A
Risk assessment method and device, risk management method and device, equipment and storage medium
CN110163532A
Program code risk assessment method and device
CN110245848A
Software vulnerability risk prediction method, device, equipment and storage medium
CN110826071A
Risk object positioning method and device, computer storage medium and electronic equipment
CN111950829A