Risk management method and device, storage medium and electronic equipment

Abstract

The application discloses a risk management and control method and device, a storage medium and electronic equipment, and relates to the technical field of information security. The method comprises the following steps: performing security detection processing on development demand data, performing risk identification processing on a development environment associated with the development demand data in the case that the development demand data does not have potential risks, and generating target code in the case that the development environment does not have potential risks; performing risk detection processing on the target code, and generating a target software package in the case that the target code meets preset security rules; performing risk test processing on the target software package, and generating a to-be-released software package in the case that the target software package does not have security vulnerabilities; performing security prevention processing on the to-be-released software package to obtain a to-be-released version, and performing security deployment processing on the to-be-released version to realize online of a target software product. The application solves the technical problem of low risk management and control efficiency in the prior art.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and more specifically, to a risk management method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the continuous development of information technology, DevOps (Development Operations) platforms have emerged. A DevOps platform is a collective term for a set of processes, methods, and systems used to promote communication, collaboration, and integration between development, technical operations, and quality assurance departments. It is a culture, movement, or practice that emphasizes communication and collaboration between software developers (Dev) and IT operations personnel (Ops). By automating the processes of software delivery and architectural changes, it makes building, testing, and releasing software faster, more frequent, and more reliable.

[0003] However, traditional DevOps platforms neglect security, lack security control measures, and are fraught with potential risks, failing to support secure software development. Currently, security control for DevOps platforms primarily relies on manual risk management at each stage of the software development process, which suffers from low efficiency, impacting development progress and hindering rapid delivery requirements.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a risk management method, apparatus, storage medium, and electronic device to at least address the technical problem of low risk management efficiency in existing technologies that rely on manual risk management at each stage of the software development process.

[0006] According to one aspect of the present invention, a risk management method is provided, comprising: acquiring development requirement data of a target software product; performing security detection processing on the development requirement data using a target detection model to obtain a first detection result, wherein the target detection model is trained based on sample data, and the first detection result characterizes whether the development requirement data has potential risks; if the first detection result characterizes that the development requirement data does not have potential risks, performing risk identification processing on the development environment associated with the development requirement data to obtain a risk identification result, and if the risk identification result characterizes that the development environment does not have potential risks, generating target code based on the development requirement data and the development environment; performing risk detection processing on the target code using a target platform to obtain a second detection result, and if the second detection result characterizes that the target code conforms to preset security rules, generating a target software package based on the target code and the target platform; performing risk testing processing on the target software package using the target platform to obtain a test result, and if the test result characterizes that the target software package does not have security vulnerabilities, generating a release software package based on the target software package and the target platform; performing security protection processing on the release software package using the target platform to obtain a release version, and performing security deployment processing on the release version according to preset deployment rules to realize the launch of the target software product, wherein the security protection processing is used to set attack barriers for the release software package.

[0007] Furthermore, the risk management method also includes: after the target software product is launched by performing secure deployment processing on the version to be released according to the preset deployment rules, simulating attacks on the target software product through the target platform to generate a vulnerability report of the target software product; determining the operation and maintenance strategy for the target software product based on the vulnerability report, and performing operation and maintenance on the target software product based on the operation and maintenance strategy.

[0008] Furthermore, the risk management method also includes: after the target software product is launched by performing security deployment processing on the version to be released according to the preset deployment rules, monitoring the traffic data associated with the target software product through the target platform, wherein the traffic data includes at least one of the following: access traffic data, public opinion traffic data; if abnormal data is detected in the traffic data, security defense is carried out on the target software product according to the preset security feedback mechanism, and alarm information is sent to the target object.

[0009] Furthermore, the target detection model includes a first prediction model and a second prediction model, with different prediction objects for the first and second prediction models. The risk management method further includes: performing a risk assessment on the development requirement data using the first prediction model to obtain a first prediction result, wherein the first prediction result represents the probability that risky data exists in the development requirement data; determining that risky data exists in the development requirement data if the first prediction result is greater than a first threshold; acquiring risky data, predicting the risky data using the second prediction model to obtain a second prediction result, wherein the second prediction result represents the probability that the risk corresponding to the risky data will occur; and determining the first detection result based on the second prediction result.

[0010] Furthermore, the risk management method also includes: if the second prediction result is greater than the second threshold, determining that the first detection result indicates that there is a potential risk in the development demand data; if the second prediction result is less than or equal to the second threshold, determining that the first detection result indicates that there is no potential risk in the development demand data.

[0011] Furthermore, the risk management method also includes: after determining that the first detection result indicates that there is a potential risk in the development requirement data, performing security hardening on the risk data to obtain hardened development requirement data; performing threat modeling analysis on the hardened development requirement data to obtain analysis results; and determining the hardened development requirement data as the target development requirement data if the analysis results indicate that there is no potential risk in the hardened development requirement data.

[0012] Furthermore, the risk control method also includes: performing risk testing on the target software package using each of the multiple test scripts on the target platform to obtain multiple test results, wherein the multiple test scripts include at least a test script for dynamic application security detection, a test script for interactive application security detection, and a test script for penetration testing; if all multiple test results are passed, the test results indicate that the target software package does not have security vulnerabilities; if at least one of the multiple test results is a failed test, the test results indicate that the target software package has security vulnerabilities.

[0013] Furthermore, security measures include at least digital signature processing and code obfuscation. Risk control methods also include: digitally signing the software package to be released through the target platform to obtain a digitally signed software package to be released; and obfuscating the code of the digitally signed software package to obtain a release version.

[0014] According to another aspect of the present invention, a risk management device is also provided, comprising: an acquisition module, configured to acquire development requirement data of a target software product, perform security detection processing on the development requirement data through a target detection model to obtain a first detection result, wherein the target detection model is trained based on sample data, and the first detection result characterizes whether the development requirement data has potential risks; a first processing module, configured to, when the first detection result characterizes that the development requirement data does not have potential risks, perform risk identification processing on the development environment associated with the development requirement data to obtain a risk identification result, and, when the risk identification result characterizes that the development environment does not have potential risks, generate target code based on the development requirement data and the development environment; and a second processing module, configured to, through the target... The target platform performs risk detection on the target code, obtains a second detection result, and generates a target software package based on the target code and the target platform if the second detection result indicates that the target code conforms to preset security rules. The third processing module performs risk testing on the target software package through the target platform, obtains a test result, and generates a release software package based on the target software package and the target platform if the test result indicates that the target software package does not have security vulnerabilities. The fourth processing module performs security protection processing on the release software package through the target platform, obtains a release version, and performs security deployment processing on the release version according to preset deployment rules to realize the launch of the target software product. The security protection processing is used to set up attack barriers for the release software package.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, wherein the computer program is configured to execute the above-described risk management method at runtime.

[0016] According to another aspect of the present invention, an electronic device is also provided, the electronic device including one or more processors; a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are configured to run the programs, wherein the programs are configured to execute the above-described risk management method during runtime.

[0017] In this embodiment of the invention, a security control approach is adopted that incorporates security management into the entire development process of the DevOps platform. First, development requirement data for the target software product is acquired. This data is then subjected to security testing using a target detection model to obtain a first detection result. If the first detection result indicates that the development requirement data does not pose any potential risks, the development environment associated with the development requirement data is subjected to risk identification processing to obtain a risk identification result. If the risk identification result indicates that the development environment does not pose any potential risks, target code is generated based on the development requirement data and the development environment. This target code is then subjected to risk testing using the target platform to obtain a second detection result. If the second detection result indicates that the target code conforms to preset security rules, a target software package is generated based on the target code and the target platform. This package is then subjected to risk testing using the target platform to obtain test results. If the test results indicate that the target software package does not have any security vulnerabilities, a release software package is generated based on the target software package and the target platform. Finally, the release software package is subjected to security protection processing using the target platform to obtain a release version. According to preset deployment rules, the release version is then deployed securely, thus enabling the target software product to go live. The target detection model is trained based on sample data. The first detection result characterizes whether there are potential risks in the development requirement data. The security protection process is used to set up attack barriers for the software package to be released.

[0018] In the above process, by performing security detection processing on development requirement data, the security of development requirements is fully considered during the planning phase. This allows for the identification and handling of as many security risks as possible in software development, significantly reducing the potential attack surface and thus lowering the remediation costs associated with discovering security issues later in development. By performing risk identification processing on the development environment associated with the development requirement data, the security of the coding environment is fully considered during the coding phase. This allows for the identification and resolution of potential security vulnerabilities in the development environment, ensuring the security of the development environment and equipment. Finally, by performing risk detection processing on the target code through the target platform, the security of the generated software package is fully considered during the build phase, enabling the identification and resolution of security vulnerabilities. This approach addresses potential security vulnerabilities in the source code, ensuring code security and improving the efficiency of risk management. By conducting risk testing on the target software package through the target platform, the security of the target software package is fully considered during the testing phase, enabling the discovery of vulnerabilities and defects, and facilitating timely remediation, further improving risk management efficiency. Security protection measures are applied to the software package to be released through the target platform, ensuring the security of the software package to be released during the release phase, thus guaranteeing the security of the software product. Secure deployment of the version to be released ensures the security of the software going live during the deployment phase, further strengthening the delivered product and improving its reliability.

[0019] Therefore, the technical solution of this invention achieves the goal of improving the security development efficiency and development quality of software products, thereby realizing the technical effect of improving the risk management efficiency of the entire software development life cycle. It also solves the technical problem of low risk management efficiency in the existing technology that uses manual risk management for each stage of the software development process. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0021] Figure 1 This is a flowchart of an optional risk management method according to an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram of an optional DevOps platform-based development process that incorporates security control according to an embodiment of the present invention.

[0023] Figure 3 This is a schematic diagram of an optional risk management device according to an embodiment of the present invention;

[0024] Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of the present invention. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] It should be noted that all relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this invention are information and data authorized by the user or fully authorized by all parties. For example, this system has an interface with the relevant user or organization. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving consent from the aforementioned user or organization.

[0028] Example 1

[0029] According to an embodiment of the present invention, an embodiment of a risk management method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] Figure 1 This is a flowchart of an optional risk management method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0031] Step S101: Obtain the development requirement data of the target software product, perform security detection processing on the development requirement data through the target detection model, and obtain the first detection result. The target detection model is trained based on the sample data, and the first detection result indicates whether there are potential risks in the development requirement data.

[0032] In the steps described above, development requirement data for the target software product can be obtained through application systems, processors, electronic devices, and other means. Optionally, development requirement data for the target software product can be obtained through a risk management system; this development requirement data can be data generated during the planning phase of software product development.

[0033] Figure 2 This is a schematic diagram illustrating an optional DevOps platform-based development process that incorporates security control according to an embodiment of the present invention, such as... Figure 2 As shown, it includes the planning phase, coding phase, building phase, testing phase, release phase, deployment phase, operation and maintenance phase, and monitoring phase.

[0034] The planning phase is the preparation phase before software development. In this phase, developers need to determine development requirements and clarify delivery goals. These development requirements can be proposed directly by the customer, or they can be new ideas from the product department, or they can be derived from the analysis of security issues reported in the monitoring phase.

[0035] The planning phase is located at the beginning of the software development lifecycle of the DevOps platform and is crucial to ensuring the security of the entire software development project. Therefore, fully considering security requirements during the planning phase and identifying and addressing as many security risks as possible can greatly reduce the potential attack surface, thereby reducing the increased remediation costs of discovering security issues later in development.

[0036] Optionally, in this embodiment, risk management during the planning phase is achieved through security measures such as security requirements engineering, inherent risk assessment, and threat modeling. Security requirements engineering refers to assessing the security of identified development requirements, including but not limited to steps such as standardizing definitions, identifying security objectives, selecting heuristics, developing artifacts, deriving security requirements, classifying requirements, performing risk assessments, optimizing requirements, and requirement inspection. This integrates security requirements into specific project development. For example, by developing a framework that maps security requirements to executable code, the additional burden of security requirements engineering can be simplified, improving response speed and avoiding impacts on software development progress.

[0037] Optionally, software design needs to avoid inherent security issues. Inherent risk assessment is the process of summarizing the inherent security risks faced by the software, judging the potential impact of these risks, and the likelihood of these risks becoming reality. Optionally, inherent risk assessment is a process that needs to be repeated continuously. Risk assessment is conducted at different stages for different purposes. For example, inherent risk assessment is mainly conducted in the early stages of the software development cycle to strengthen the security design of the product, while in the later stages it is mainly to verify the effectiveness of the security design.

[0038] In one optional embodiment, the target detection model includes a first prediction model and a second prediction model. The first and second prediction models correspond to different prediction objects. In the process of performing security detection processing on the development requirement data using the target detection model to obtain a first detection result, the first prediction model is first used to perform a risk assessment on the development requirement data to obtain a first prediction result. Then, if the first prediction result is greater than a first threshold, it is determined that risky data exists in the development requirement data. The risky data is then acquired, and the second prediction model is used to predict the risky data to obtain a second prediction result. Finally, the first detection result is determined based on the second prediction result. The first prediction result represents the probability that risky data exists in the development requirement data, and the second prediction result represents the probability that the risk corresponding to the risky data will occur.

[0039] Optionally, in this embodiment, security requirements engineering and inherent risk assessment are implemented through a target detection model, that is, the development requirement data is processed for security detection using the target detection model. Optionally, a pre-trained first prediction model is used to perform risk assessment on the development requirement data to implement security requirements engineering, that is, to determine whether there is risky data in the development requirement data. Further, if the first prediction result is greater than a first threshold, it is determined that there is risky data in the development requirement data, and a pre-trained second prediction model is used to predict the risky data to implement inherent risk assessment, that is, to predict the possibility of the risk becoming a reality.

[0040] Furthermore, based on the second prediction result, the first detection result is determined.

[0041] In one optional embodiment, during the process of determining the first detection result based on the second prediction result, if the second prediction result is greater than the second threshold, it is determined that the first detection result indicates that there is a potential risk in the development requirement data; if the second prediction result is less than or equal to the second threshold, it is determined that the first detection result indicates that there is no potential risk in the development requirement data.

[0042] Optionally, if the second prediction result is greater than the second threshold, it is determined that there is a potential risk in the development demand data, that is, the possibility of the risk turning into reality is higher than the preset threshold (i.e., the second threshold), and it is considered that the risk will occur; if the second prediction result is less than or equal to the second threshold, it is determined that there is no potential risk in the development demand data.

[0043] In one optional embodiment, after determining that the first detection result indicates that the development requirement data has potential risks, the risk data is subjected to security hardening processing to obtain hardened development requirement data. Then, threat modeling analysis is performed on the hardened development requirement data to obtain analysis results. If the analysis results indicate that the hardened development requirement data does not have potential risks, the hardened development requirement data is determined as the target development requirement data.

[0044] Optionally, threat modeling is another important process in software security design. Threat modeling can help identify security threats to a system early in the software development lifecycle. It is a structured approach to identify, quantify, and properly address threats to a system.

[0045] Optionally, after determining that the first detection result indicates that there is a potential risk in the development requirement data, the risk data is subjected to security hardening processing to obtain hardened development requirement data, which enables timely handling of potential risks and can improve the security and reliability of software products.

[0046] Furthermore, threat modeling analysis is performed on the hardened development requirement data to obtain the analysis results. Specifically, in the threat modeling process, important data information (i.e., critical assets) is first identified, then potential attacker behaviors and all possible threats and vulnerabilities in the system are determined, and these identified threats are then hardened or redesigned. Optionally, to adapt to the iterative speed of DevOps, a lightweight threat modeling approach is adopted to improve the efficiency of threat modeling, so as to more accurately identify more security threats within a limited time.

[0047] Furthermore, if the analysis results indicate that the hardened development requirement data does not pose any potential risks, then the hardened development requirement data is determined as the target development requirement data. In other words, after risk management during the planning phase, secure development requirement data is obtained, and the coding phase begins.

[0048] It should be noted that by assessing the security of development requirements, the security of development requirements is fully considered during the planning phase. This allows for the identification and handling of as many security risks as possible in software development, thereby reducing the security vulnerabilities of the delivered products or services.

[0049] Step S102: If the first detection result indicates that there is no potential risk in the development requirement data, risk identification processing is performed on the development environment associated with the development requirement data to obtain the risk identification result. If the risk identification result indicates that there is no potential risk in the development environment, target code is generated based on the development requirement data and the development environment.

[0050] In the above steps, the development environment associated with the development requirements data includes the coding environment and open-source components. The coding phase is the process by which developers use programming languages ​​to implement the development requirements. During this process, developers need to frequently submit their code to the designated repository in the DevOps pipeline. Since the code produced during the coding phase is the core part of the final delivered product or service, well-structured and secure code can significantly reduce rework issues later on. Therefore, if... Figure 2 As shown, during the coding phase, risk control measures such as development environment scanning, open-source component security scanning, integration of security plugins, use of security frameworks, coding standards, and code review are implemented to improve the quality of the code produced.

[0051] Optionally, before carrying out specific software development work, the development environment can be scanned, that is, the development environment associated with the development requirements data can be risk-identified and processed. For example, the development environment can be scanned through authentication, sensitive point detection and other methods to identify and resolve potential security risks in the development environment, ensure the security of the development environment and equipment, and further improve the credibility of the delivered code.

[0052] Optionally, in order to meet the increasingly rapid product release requirements, developers will use open source components during the development process to save time and costs. Therefore, in this embodiment, when using open source components for development, the relevant open source components are scanned by a security scanning tool to identify and resolve security vulnerabilities in the open source components, and to avoid using open source components or open source code fragments containing security vulnerabilities.

[0053] In addition, in this embodiment, when using open source components for development, risk identification is performed on the development behavior, that is, it is determined whether there is any development behavior that does not meet the behavior requirements stipulated in the open source component license, so as to avoid losses caused by abnormal development behavior.

[0054] Optionally, by installing a unified security plugin in the development environment, developers can promptly identify security issues in their code during the coding process. These security plugins begin working as developers code, proactively scanning the code for security. If security issues are found during the scan, developers are promptly prompted to perform corresponding verification and remediation. Alternatively, to match the speed of DevOps, lightweight integrated security plugins can be used to perform security scans on the code written by developers, ensuring that the scanning process of the security plugins does not excessively impact the normal development process.

[0055] It should be noted that by integrating security plugins, developers can fix security issues in the code early in the development process, thereby improving the security of the code entering the DevOps pipeline.

[0056] Optionally, a suitable security framework can be determined by comprehensively considering factors such as specific business scenarios and the actual performance of the framework. The security framework can then be used to implement risk control measures such as authentication processing, authorization management, session management, encryption processing, and thread safety management to improve development efficiency and coding quality.

[0057] Optionally, in this embodiment, developers code according to security development requirements data and pre-configured coding standards, which helps with subsequent code review, makes it easier to discover security vulnerabilities hidden behind highly complex code, and can also improve code readability and robustness, thereby reducing the cost of secondary development and maintenance. The coding standards may include coding style, comment writing, naming rules, etc.

[0058] Optionally, code review can be conducted manually or using code review tools to check whether the submitted code conforms to pre-configured coding standards, whether it is fully functional, whether it uses dangerous functions, and whether it takes security coding into account, so as to avoid oversights made by developers during the writing process and further reduce potential security risks.

[0059] Optionally, by implementing a series of risk control measures during the coding phase, secure source code (i.e., generating target code based on development requirements data and the development environment) can be obtained and the code can enter the build phase.

[0060] It should be noted that by performing risk identification processing on the development environment associated with development requirement data, the security of the coding environment is fully considered during the coding stage. This enables the identification and resolution of potential security risks in the development environment, ensuring the security of the development environment and equipment.

[0061] Step S103: Perform risk detection processing on the target code through the target platform to obtain a second detection result. If the second detection result indicates that the target code conforms to the preset security rules, generate a target software package based on the target code and the target platform.

[0062] In the above steps, the target platform can be a DevOps platform, the target code can be secure source code, and the preset security rules can be established security rules corresponding to the code. The main content of the build phase is the automated operation of integrating, compiling, unit testing, packaging, and generating runnable binaries from the source code. The entire build phase relies on the DevOps pipeline and is a continuous process. When developers submit their code to the DevOps pipeline, the integrated security detection tools can automatically complete the integration, testing, and packaging of the new code. If a problem occurs during this automated process, the DevOps pipeline will also trigger the corresponding protection mechanism, reject the integration, and provide feedback on the detected problem and its cause to the developers for handling until the integration is completed.

[0063] Optionally, in this embodiment, security measures (i.e., security testing tools) are pre-integrated into the DevOps pipeline, such as... Figure 2 As shown, risk management during the build phase is achieved by integrating static application security testing and repeatable build tools into the DevOps pipeline.

[0064] Optionally, Static Application Security Testing (SAST) does not actually run the code. Instead, it uses scanning tools to automatically analyze multiple elements of the source code, such as lexical, syntactic, semantic, and structural aspects, to determine whether the source code violates established security rules (i.e., preset security rules). In other words, it uses the scanning tools of the DevOps pipeline to perform risk detection on the source code.

[0065] Optionally, repeatable construction refers to the consistent output of binary files with identical bit values ​​after multiple compilations of the same source code, ensuring that the source code has not been tampered with during the binary file conversion process. However, in practice, such binary file consistency is difficult to guarantee. For example, if developers add operations such as obtaining timestamps or using random numbers to the source code, the output after each compilation is unlikely to be exactly the same. Therefore, in this embodiment, during the continuous processes of encoding and construction, risk management measures such as configuring automated processes and avoiding the use of uncontrollable functions are used to control these potentially changing factors to ensure the consistency of the binary files.

[0066] Optionally, by implementing risk control measures during the build phase, a secure software package (i.e., generating a target software package based on the target code and target platform) can be obtained and then enter the testing phase.

[0067] It should be noted that by incorporating automated risk management measures into the continuous integration process during the build phase, the DevOps pipeline can effectively verify the content entering the pipeline without wasting excessive time, thus ensuring code security.

[0068] Step S104: Perform risk testing on the target software package through the target platform to obtain test results. If the test results indicate that the target software package does not have any security vulnerabilities, generate a release software package based on the target software package and the target platform.

[0069] Optionally, during the testing phase, the built software package or binary file needs to be verified (i.e., tested) to identify any security issues and report them to the developers for fixing. Therefore, as... Figure 2 As shown, risk management during the testing phase is achieved by integrating tools such as dynamic application security testing, interactive application security testing, and penetration testing into the DevOps pipeline.

[0070] In one optional embodiment, during the risk testing of the target software package using the target platform to obtain test results, each of the multiple test scripts on the target platform performs risk testing on the target software package separately, obtaining multiple test results. If all multiple test results pass, it is determined that the test results indicate the target software package has no security vulnerabilities. If at least one of the multiple test results fails, it is determined that the test results indicate the target software package has security vulnerabilities. The multiple test scripts include at least test scripts for dynamic application security detection, interactive application security detection, and penetration testing.

[0071] Alternatively, Dynamic Application Security Testing (DAST) differs from static testing in that it does not require analyzing the internal logical structure of the program's source code. Instead, it provides data input to the running application and determines whether the program's dynamic behavior and output meet expectations, thereby analyzing the application's robustness and security.

[0072] Optionally, Interactive Application Security Testing (IAST) is divided into active IAST and passive IAST. Both can run automatically without additional configuration. Active IAST's detection function is based on an external source that can trigger detected agents in the application. This type of IAST requires the DAST tool to activate. In passive IAST, the agent is independent and monitors and analyzes the code while the application is running to find security vulnerabilities. It can work in parallel with existing test automation and provide immediate results. Applying IAST can provide broader code coverage, discover more sensitive vulnerabilities, and provide timely feedback on detected results.

[0073] Optionally, penetration testing is a testing method that, from an attacker's perspective, simulates malicious hacker attacks to proactively discover security vulnerabilities in a system. It can independently examine the security mechanisms of a network and system, serving as a verification and supplement to the results of routine security scans. Optionally, a penetration test can be conducted when a product has accumulated a sufficient number of new features.

[0074] Optionally, risk testing is performed on the target software package (i.e., the secure software package obtained during the build phase) using test scripts for dynamic application security detection, interactive application security detection, and penetration testing from the DevOps platform. If multiple test results are all passed, the test results indicate that the target software package does not have any security vulnerabilities. If at least one test result among multiple test results is a failure, the test results indicate that the target software package has security vulnerabilities.

[0075] Optionally, security practices during the testing phase focus on the security testing of binary files or software packages. Before the official product release, vulnerabilities and defects in these binary files or software packages are discovered by actually running the program, and then timely fixes are implemented. A variety of testing methods and tools are available. To avoid excessive testing affecting the product release speed, appropriate testing methods and tools can be selected according to requirements; no specific limitations are imposed here.

[0076] Optionally, by implementing risk control measures during the testing phase, a secure release package (i.e., generating a release package based on the target package and target platform) can be obtained and then proceed to the release phase.

[0077] It should be noted that by performing risk testing on the target software package through the target platform, the security of the target software package is fully considered during the testing phase. This allows for the discovery of vulnerabilities and defects in the target software package, enabling timely remediation and improving the efficiency of risk management.

[0078] Step S105: The target platform performs security protection processing on the software package to be released to obtain the version to be released. According to the preset deployment rules, the version to be released is deployed securely to achieve the online launch of the target software product. The security protection processing is used to set up attack barriers for the software package to be released.

[0079] Optionally, before releasing the official version, it is necessary to take various levels of preventative measures for these software products to improve their ability to respond to security threats such as unauthorized tampering and reverse engineering of the binary or software packages after release. Optionally, such as... Figure 2 As shown, risk management during the release phase is achieved by integrating digital signature processing and code obfuscation tools into the DevOps pipeline.

[0080] In one optional embodiment, the security protection process includes at least digital signature processing and code obfuscation processing. In the process of obtaining the release version by performing security protection processing on the release package through the target platform, the release package is digitally signed by the target platform to obtain a release package with added digital signature. Then, the release package with added digital signature is obfuscated to obtain the release version.

[0081] Optionally, a digital signature can be added to the software package before release. This involves digitally signing the package through a DevOps platform to increase the software's credibility and trustworthiness. Furthermore, once a digitally signed package is released, it cannot be easily modified. If the software is tampered with after release, the message digest in the digital signature will change, and users will receive an alert when they actually use the tampered software.

[0082] Optionally, application masking technology is a technique that modifies the binary code of an application to enhance its ability to resist intrusion, tampering, and reverse engineering. Specifically, it involves obfuscating the code of a digitally signed software package, making the code more complex and difficult to analyze, thus strengthening the application's protective capabilities. Furthermore, application masking technology can also protect the asset security of application software, significantly reducing the workload required for reverse engineering, and effectively preventing piracy and digital information theft, thereby giving companies a competitive edge over similar products.

[0083] Optionally, by implementing risk control measures during the release phase, a secure release version can be obtained (i.e., the release version is obtained by performing security protection processing on the release software package through the target platform). Then, the release phase begins, where the release version is securely deployed according to preset deployment rules, thus enabling the target software product to go live.

[0084] Optionally, the deployment phase involves deploying the version to be released to the production environment, ensuring its continuous availability as a service. Alternatively, such as... Figure 2 As shown, during the deployment phase, risk control measures such as enhanced cloud deployment and container hardening are used to ensure the secure deployment of the version to be released, thereby enabling the launch of the target software product.

[0085] Optionally, because DevOps and cloud technology are closely integrated, operations personnel need to consider numerous post-deployment issues when making secure deployments in multi-cloud environments. For example, how to ensure high availability of computing resources, achieve relatively balanced load, and rationally allocate storage resources while ensuring system security. To address these issues, the security configuration of numerous components in the infrastructure sometimes relies on the personal experience of operations personnel, which undoubtedly increases the security risks to the infrastructure. Strengthening cloud deployment integrates validated deployment guidelines and tested configurations into a framework, relying on automated security configuration detection mechanisms to accelerate the deployment process, avoid erroneous deployments, greatly simplify the operations of operations personnel, and enhance centralized management of the infrastructure.

[0086] Optionally, while container technology offers advantages such as lightweight design, high flexibility, and low cost, the extensive privileges inherent in containers necessitate security hardening measures when deploying them into infrastructure to reduce the potential attack surface. Common hardening measures are numerous, including configuring access control groups and removing unnecessary root privileges using native container security features, employing external tools such as Bench Security scripts to assess container security and apply necessary patches, and performing security scans on container images to ensure the integrity of the image source.

[0087] Optionally, the target software product is launched through the deployment phase. After that, the software product runs in the production environment to provide services to the outside world, and the operation and maintenance personnel begin its daily operation and maintenance work.

[0088] It should be noted that by implementing security precautions on the target platform for the software package to be released, the security of the software package to be released is fully considered during the release phase, thereby ensuring the security of the software product; by implementing secure deployment procedures for the version to be released, the security of the software going live is fully considered during the deployment phase, thereby further strengthening the delivered product and improving its reliability.

[0089] Based on the scheme defined in steps S101 to S105 above, it can be understood that in this embodiment of the invention, a security control method is adopted to incorporate security management into the entire development process of the DevOps platform. First, the development requirement data of the target software product is obtained. The development requirement data is then subjected to security detection processing by a target detection model to obtain a first detection result. If the first detection result indicates that there are no potential risks in the development requirement data, the development environment associated with the development requirement data is subjected to risk identification processing to obtain a risk identification result. If the risk identification result indicates that there are no potential risks in the development environment, target code is generated based on the development requirement data and the development environment. Then, the target code is subjected to risk detection processing by the target platform to obtain a second detection result. If the second detection result indicates that the target code conforms to preset security rules, a target software package is generated based on the target code and the target platform. Then, the target software package is subjected to risk testing processing by the target platform to obtain a test result. If the test result indicates that the target software package has no security vulnerabilities, a release software package is generated based on the target software package and the target platform. Then, the release software package is subjected to security protection processing by the target platform to obtain a release version. According to preset deployment rules, the release version is subjected to security deployment processing to achieve the launch of the target software product. The target detection model is trained based on sample data. The first detection result characterizes whether there are potential risks in the development requirement data. The security protection process is used to set up attack barriers for the software package to be released.

[0090] It is noteworthy that, in the above process, by performing security checks on the development requirement data, the security of development requirements is fully considered during the planning phase. This allows for the identification and handling of as many security risks as possible in software development, significantly reducing the potential attack surface and thus lowering the remediation costs associated with security issues discovered later in development. By performing risk identification on the development environment associated with the development requirement data, the security of the coding environment is fully considered during the coding phase. This allows for the identification and resolution of potential security vulnerabilities in the development environment, ensuring the security of the development environment and equipment. Finally, by performing risk checks on the target code through the target platform, the security of the generated software package is fully considered during the build phase, thereby ensuring... Identifying and resolving potential security vulnerabilities in the source code ensures code security and improves the efficiency of risk management. By conducting risk testing on target software packages through the target platform, the security of the target software packages is fully considered during the testing phase, enabling the discovery of vulnerabilities and defects, and facilitating timely remediation, further improving risk management efficiency. Security protection measures are applied to the software packages to be released through the target platform, ensuring the security of the software packages to be released during the release phase, thus guaranteeing the security of the software product. Secure deployment of the version to be released ensures the security of the software going live during the deployment phase, further strengthening the delivered product and improving its reliability.

[0091] Therefore, the technical solution of this invention achieves the goal of improving the security development efficiency and development quality of software products, thereby realizing the technical effect of improving the risk management efficiency of the entire software development life cycle. It also solves the technical problem of low risk management efficiency in the existing technology that uses manual risk management for each stage of the software development process.

[0092] In one optional embodiment, after the target software product is launched by performing secure deployment processing on the version to be released according to preset deployment rules, the target software product is simulated by attacking it through the target platform to generate a vulnerability report of the target software product. Then, based on the vulnerability report, an operation and maintenance strategy for the target software product is determined, and the target software product is operated and maintained based on the operation and maintenance strategy.

[0093] Optionally, during routine operations and maintenance, online products are frequently subjected to malicious attacks from external or internal sources, resulting in the loss of their ability to provide normal services or causing security issues such as massive information leaks, which can have a significant negative impact on enterprises. Therefore, such as Figure 2As shown, during the operation and maintenance phase, measures such as red team / blue team exercises, chaos engineering, control of technical debt, and security vulnerability remediation plans are used to test the security performance of products and services in actual production, improve the ability to handle sudden security issues, and achieve risk management during the operation and maintenance phase.

[0094] Optionally, red team / blue team exercises are a practice that simulates continuous network attack and defense scenarios in a production environment to improve an enterprise's security defense capabilities. Based on an understanding of the enterprise's actual security situation, it simulates real network attack and defense against the enterprise's important core business, thereby revealing the actual vulnerabilities in the system and helping the business improve its security capabilities. In other words, it simulates attacks on target software products through the target platform, generates vulnerability reports for the target software products, and then determines the operation and maintenance strategy for the target software products based on the vulnerability reports, and performs operation and maintenance on the target software products based on the operation and maintenance strategy.

[0095] Alternatively, chaos engineering is a method for experimenting with software systems in a production environment. This method allows for testing the system's security and resilience by randomly shutting down services and simulating network failures in a production environment, thereby ensuring that the system can still provide high-quality services even when some nodes fail.

[0096] Alternatively, technical debt refers to the additional rework costs incurred during software development when a development team chooses easily implemented solutions based on short-term gains. The continuous accumulation of technical debt severely hinders the long-term scalability and security of a system, requiring more time to repay it in the future. For example, if existing technologies are not properly maintained and upgraded, using components with significant and difficult-to-fix security vulnerabilities will undoubtedly pose serious security threats, necessitating refactoring or other methods to repay all previous technical debt. Therefore, controlling technical debt is crucial.

[0097] Optionally, a security vulnerability remediation plan supports the verification of security vulnerabilities and the implementation of corresponding remedial measures, thereby continuously protecting the security of the entire application system. When verifying the authenticity of potential vulnerabilities in vulnerability reports, the priority of remediation can be determined based on factors such as the number of affected users and the degree of risk. Specific remediation solutions are determined for vulnerabilities of different levels, striving to reduce the scope of impact of vulnerabilities until they are completely resolved.

[0098] It should be noted that many unexpected security issues only emerge in actual production environments. When these issues are exposed and subjected to actual malicious attacks, security defenses can be effectively implemented by incorporating security practices into the DevOps operations process.

[0099] In one optional embodiment, after the target software product is launched by performing secure deployment processing on the version to be released according to preset deployment rules, the traffic data associated with the target software product is monitored through the target platform. The traffic data includes at least one of the following: access traffic data and public opinion traffic data. Then, if abnormal data is detected in the traffic data, the target software product is protected by a preset security feedback mechanism, and an alarm message is sent to the target object.

[0100] Optionally, in a production environment, effective security monitoring should be implemented at every stage of software service development and operation. Once a problem is detected, it needs to be reported and addressed promptly. Different response measures should be taken based on the severity of the reported problem and its specific cause, forming a complete security remediation process. Optionally, such as... Figure 2 As shown, risk control during the monitoring phase is achieved through risk management measures such as intrusion detection, compliance monitoring, and public opinion monitoring.

[0101] Optionally, an intrusion detection system (IDS) is a detection system that detects suspicious activity by inspecting network traffic and issuing alerts when such activity is detected. It can scan for violations of regulations within a network or system. IDS are divided into network intrusion detection systems and host-based intrusion detection systems. A network intrusion detection system can detect and analyze traffic entering and leaving all devices on the network. Once malicious attacks or abnormal behavior are identified, it issues warning messages. Specifically, it monitors traffic data associated with the target software product on the target platform. If abnormal data is detected in the traffic data, it implements security defenses on the target software product according to a preset security feedback mechanism and sends alarm information to the target. Optionally, host-based intrusion detection requires obtaining a snapshot of the current system files and comparing it with previous snapshots to prevent the modification or deletion of critical system files.

[0102] Optionally, compliance monitoring primarily uses compliance as code to monitor the behavior of development, operations, and other personnel.

[0103] Optionally, after the software is officially deployed and launched, by monitoring public opinion on discussions about security issues and security trends on major websites and forums, self-checks and repairs can be completed as soon as possible before any security vulnerabilities are exploited.

[0104] It should be noted that by automating the monitoring of the products that provide services, we can understand the operational status of the products in a timely manner, and fix or rectify any problems found in a timely manner. This will generate new requirements and feed them back into the planning stage of the DevOps process, starting a new round of iteration.

[0105] Therefore, the technical solution of this invention achieves the goal of improving the security development efficiency and development quality of software products, thereby realizing the technical effect of improving the risk management efficiency of the entire software development life cycle. It also solves the technical problem of low risk management efficiency in the existing technology that uses manual risk management for each stage of the software development process.

[0106] Example 2

[0107] According to an embodiment of the present invention, a risk management device is provided, wherein, Figure 3 This is a schematic diagram of an optional risk management device according to an embodiment of the present invention, such as... Figure 3 As shown, the device includes: an acquisition module 301, used to acquire development requirement data of a target software product, perform security detection processing on the development requirement data using a target detection model, and obtain a first detection result, wherein the target detection model is trained based on sample data, and the first detection result indicates whether the development requirement data has potential risks; a first processing module 302, used to perform risk identification processing on the development environment associated with the development requirement data when the first detection result indicates that the development requirement data does not have potential risks, obtain a risk identification result, and generate target code based on the development requirement data and the development environment when the risk identification result indicates that the development environment does not have potential risks; and a second processing module 303, used to process the target code through a target platform. The system performs risk detection processing to obtain a second detection result. If the second detection result indicates that the target code conforms to preset security rules, a target software package is generated based on the target code and the target platform. The third processing module 304 is used to perform risk testing processing on the target software package through the target platform to obtain test results. If the test results indicate that the target software package does not have security vulnerabilities, a release software package is generated based on the target software package and the target platform. The fourth processing module 305 is used to perform security protection processing on the release software package through the target platform to obtain a release version. According to preset deployment rules, the release version is used to perform security deployment processing to realize the launch of the target software product. The security protection processing is used to set attack barriers for the release software package.

[0108] It should be noted that the above-mentioned acquisition module 301, first processing module 302, second processing module 303, third processing module 304 and fourth processing module 305 correspond to steps S101 to S105 in the above embodiments. The five modules and the corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed in the above embodiment 1.

[0109] Optionally, the risk management device further includes: a first generation module, used to simulate attacks on the target software product through the target platform and generate a vulnerability report for the target software product; and a first determination module, used to determine the operation and maintenance strategy for the target software product based on the vulnerability report, and to perform operation and maintenance on the target software product based on the operation and maintenance strategy.

[0110] Optionally, the risk control device further includes: a first monitoring module, used to monitor traffic data associated with the target software product through the target platform, wherein the traffic data includes at least one of the following: access traffic data, public opinion traffic data; and a first alert module, used to perform security defense on the target software product and send alarm information to the target object according to a preset security feedback mechanism when abnormal data is detected in the traffic data.

[0111] Optionally, the target detection model includes a first prediction model and a second prediction model, with different prediction objects for the first and second prediction models. The acquisition module includes: a first prediction module, used to perform risk assessment on the development requirement data using the first prediction model to obtain a first prediction result, wherein the first prediction result represents the probability that risky data exists in the development requirement data; a second determination module, used to determine that risky data exists in the development requirement data if the first prediction result is greater than a first threshold; a second prediction module, used to acquire risky data and predict the risky data using the second prediction model to obtain a second prediction result, wherein the second prediction result represents the probability that the risk corresponding to the risky data will occur; and a third determination module, used to determine the first detection result based on the second prediction result.

[0112] Optionally, the third determining module includes: a fourth determining module, used to determine that the first detection result indicates that the development demand data has potential risks when the second prediction result is greater than the second threshold; and a fifth determining module, used to determine that the first detection result indicates that the development demand data does not have potential risks when the second prediction result is less than or equal to the second threshold.

[0113] Optionally, the risk management device also includes: a fifth processing module for performing security hardening processing on the risk data to obtain hardened development requirement data; a first analysis module for performing threat modeling analysis on the hardened development requirement data to obtain analysis results; and a sixth determination module for determining the hardened development requirement data as the target development requirement data if the analysis results indicate that the hardened development requirement data does not have any potential risks.

[0114] Optionally, the third processing module includes: a sixth processing module, used to perform risk testing on the target software package using each of the multiple test scripts of the target platform, to obtain multiple test results, wherein the multiple test scripts include at least a test script for dynamic application security detection, a test script for interactive application security detection, and a test script for penetration testing; a seventh determining module, used to determine that the test results indicate that the target software package does not have security vulnerabilities if all multiple test results are passed; and an eighth determining module, used to determine that the test results indicate that the target software package has security vulnerabilities if at least one of the multiple test results is failed.

[0115] Optionally, the security protection process includes at least digital signature processing and code obfuscation processing. The fourth processing module includes: a seventh processing module, used to perform digital signature processing on the software package to be released through the target platform to obtain a software package to be released with added digital signature; and an eighth processing module, used to perform code obfuscation processing on the software package to be released with added digital signature to obtain a version to be released.

[0116] Example 3

[0117] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the above-described risk management method at runtime.

[0118] Example 4

[0119] According to another aspect of the present invention, an electronic device is also provided, wherein, Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of the present invention, such as... Figure 4As shown, the electronic device includes one or more processors; and a memory for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to run the programs, wherein the programs are configured to execute the aforementioned risk management methods during runtime. When the processor executes the program, it performs the following steps: First, it acquires development requirement data for the target software product. Then, it performs security detection on the development requirement data using a target detection model to obtain a first detection result. The target detection model is trained based on sample data, and the first detection result indicates whether the development requirement data has potential risks. If the first detection result indicates that the development requirement data has no potential risks, it performs risk identification processing on the development environment associated with the development requirement data to obtain a risk identification result. If the risk identification result indicates that the development environment has no potential risks, it generates target code based on the development requirement data and the development environment. Next, it performs risk detection processing on the target code using the target platform to obtain a second detection result. If the second detection result indicates that the target code conforms to preset security rules, it generates a target software package based on the target code and the target platform. Finally, it performs risk testing on the target software package using the target platform to obtain test results. If the test results indicate that the target software package has no security vulnerabilities, it generates a release software package based on the target software package and the target platform. Finally, it performs security protection processing on the release software package using the target platform to obtain a release version. According to preset deployment rules, it performs security deployment processing on the release version to achieve the launch of the target software product. The security protection processing is used to set up attack barriers for the release software package.

[0120] Optionally, the processor may also perform the following steps when executing the program: after performing security deployment processing on the version to be released according to preset deployment rules and launching the target software product, simulate an attack on the target software product through the target platform to generate a vulnerability report for the target software product; determine the operation and maintenance strategy for the target software product based on the vulnerability report, and perform operation and maintenance on the target software product based on the operation and maintenance strategy.

[0121] Optionally, the processor may also perform the following steps when executing the program: After performing secure deployment processing on the version to be released according to preset deployment rules and launching the target software product, the processor monitors the traffic data associated with the target software product through the target platform. The traffic data includes at least one of the following: access traffic data and public opinion traffic data. If abnormal data is detected in the traffic data, the processor performs security defense on the target software product according to the preset security feedback mechanism and sends alarm information to the target object.

[0122] Optionally, the target detection model includes a first prediction model and a second prediction model. The first prediction model and the second prediction model correspond to different prediction objects. When the processor executes the program, it also implements the following steps: performing a risk assessment on the development requirement data using the first prediction model to obtain a first prediction result, wherein the first prediction result represents the probability that risky data exists in the development requirement data; if the first prediction result is greater than a first threshold, determining that risky data exists in the development requirement data; acquiring risky data, predicting the risky data using the second prediction model to obtain a second prediction result, wherein the second prediction result represents the probability that the risk corresponding to the risky data will occur; and determining a first detection result based on the second prediction result.

[0123] Optionally, the processor may further perform the following steps when executing the program: if the second prediction result is greater than the second threshold, determine that the first detection result indicates that the development requirement data has potential risks; if the second prediction result is less than or equal to the second threshold, determine that the first detection result indicates that the development requirement data does not have potential risks.

[0124] Optionally, the processor may also perform the following steps when executing the program: after determining that the first detection result indicates that the development requirement data has potential risks, perform security hardening on the risk data to obtain hardened development requirement data; perform threat modeling analysis on the hardened development requirement data to obtain analysis results; if the analysis results indicate that the hardened development requirement data does not have potential risks, determine the hardened development requirement data as the target development requirement data.

[0125] Optionally, the processor, when executing the program, also performs the following steps: performing risk testing on the target software package using each of multiple test scripts from the target platform, obtaining multiple test results, wherein the multiple test scripts include at least a test script for dynamic application security detection, a test script for interactive application security detection, and a test script for penetration testing; if all multiple test results are passed, determining that the test results indicate the target software package does not have security vulnerabilities; if at least one of the multiple test results is a failed test, determining that the test results indicate the target software package has security vulnerabilities.

[0126] Optionally, the security measures include at least digital signature processing and code obfuscation processing. When the processor executes the program, it also performs the following steps: digitally signing the software package to be released through the target platform to obtain a digitally signed software package to be released; and obfuscating the code of the digitally signed software package to be released to obtain a release version.

[0127] The devices mentioned in this article can be servers, PCs, tablets, mobile phones, etc.

[0128] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0129] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0131] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0132] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0133] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, 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 personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0134] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A risk management method, characterized in that, include: The development requirement data of the target software product is obtained, and the development requirement data is subjected to security detection processing through a target detection model to obtain a first detection result. The target detection model is trained based on sample data, and the first detection result characterizes whether the development requirement data has potential risks. The target detection model includes a first prediction model and a second prediction model. The first prediction model and the second prediction model correspond to different prediction objects. The process of performing security detection processing on the development requirement data using the target detection model to obtain a first detection result includes: performing a risk assessment on the development requirement data using the first prediction model to obtain a first prediction result, wherein the first prediction result represents the probability that risky data exists in the development requirement data; determining that risky data exists in the development requirement data when the first prediction result is greater than a first threshold; acquiring the risky data; predicting the risky data using the second prediction model to obtain a second prediction result, wherein the second prediction result represents the probability that the risk corresponding to the risky data will occur; and determining the first detection result based on the second prediction result. If the first detection result indicates that there is no potential risk in the development requirement data, risk identification processing is performed on the development environment associated with the development requirement data to obtain a risk identification result. If the risk identification result indicates that there is no potential risk in the development environment, target code is generated based on the development requirement data and the development environment. The risk identification processing includes: identity verification and sensitive point detection. The target code is subjected to risk detection processing by the target platform to obtain a second detection result. If the second detection result indicates that the target code conforms to the preset security rules, a target software package is generated based on the target code and the target platform. The target software package is subjected to risk testing through the target platform to obtain test results. If the test results indicate that the target software package does not have any security vulnerabilities, a release software package is generated based on the target software package and the target platform. The target platform performs security protection processing on the software package to be released to obtain a release version. According to preset deployment rules, the release version is then deployed securely to achieve the launch of the target software product. The security protection processing is used to set up attack barriers for the software package to be released.

2. The method according to claim 1, characterized in that, After performing secure deployment processing on the version to be released according to preset deployment rules and launching the target software product, the method further includes: Simulated attacks are conducted on the target software product using the target platform to generate a vulnerability report for the target software product. Based on the vulnerability report, an operation and maintenance strategy for the target software product is determined, and the target software product is operated and maintained based on the operation and maintenance strategy.

3. The method according to claim 1, characterized in that, After performing secure deployment processing on the version to be released according to preset deployment rules and launching the target software product, the method further includes: The target platform monitors the traffic data associated with the target software product, wherein the traffic data includes at least one of the following: access traffic data and public opinion traffic data; If abnormal data is detected in the traffic data, the system will perform security defense on the target software product according to the preset security feedback mechanism and send alarm information to the target object.

4. The method according to claim 1, characterized in that, Based on the second prediction result, the first detection result is determined, including: If the second prediction result is greater than the second threshold, it is determined that the first detection result indicates that the development requirement data has a potential risk; If the second prediction result is less than or equal to the second threshold, it is determined that the first detection result indicates that the development requirement data does not pose a potential risk.

5. The method according to claim 4, characterized in that, After determining that the first detection result indicates a potential risk in the development requirement data, the method further includes: The risk data is then subjected to security hardening processing to obtain hardened development requirement data; Threat modeling analysis was performed on the hardened development requirement data to obtain the analysis results; If the analysis results indicate that the reinforced development requirement data does not pose any potential risks, then the reinforced development requirement data is determined to be the target development requirement data.

6. The method according to claim 1, characterized in that, The target software package is subjected to risk testing through the target platform to obtain test results, including: The target software package is subjected to risk testing using each of the multiple test scripts of the target platform, resulting in multiple test results. The multiple test scripts include at least test scripts for dynamic application security detection, test scripts for interactive application security detection, and test scripts for penetration testing. If all the test results are passed, it is determined that the test results indicate that the target software package does not have any security vulnerabilities. If at least one of the multiple test results is a test failure, the test result is determined to indicate that the target software package has a security vulnerability.

7. The method according to claim 1, characterized in that, The security measures include at least digital signature processing and code obfuscation. Specifically, the security measures applied to the software package to be released via the target platform to obtain the release version include: The digital signature process is performed on the software package to be released through the target platform to obtain a software package to be released with an added digital signature; The code obfuscation process is performed on the digitally signed software package to obtain the release version.

8. A risk management device, characterized in that, include: The acquisition module is used to acquire development requirement data of the target software product, and to perform security detection processing on the development requirement data through a target detection model to obtain a first detection result. The target detection model is trained based on sample data, and the first detection result indicates whether there are potential risks in the development requirement data. The target detection model includes a first prediction model and a second prediction model. The first prediction model and the second prediction model correspond to different prediction objects. The acquisition module includes: a first prediction module, used to perform a risk assessment on the development requirement data using the first prediction model to obtain a first prediction result, wherein the first prediction result represents the probability that risky data exists in the development requirement data; a second determination module, used to determine that the risky data exists in the development requirement data when the first prediction result is greater than a first threshold; a second prediction module, used to acquire the risky data and predict the risky data using the second prediction model to obtain a second prediction result, wherein the second prediction result represents the probability that the risk corresponding to the risky data occurs; and a third determination module, used to determine the first detection result based on the second prediction result. The first processing module is configured to perform risk identification processing on the development environment associated with the development requirement data when the first detection result indicates that there is no potential risk in the development requirement data, to obtain a risk identification result, and generate target code based on the development requirement data and the development environment when the risk identification result indicates that there is no potential risk in the development environment; the risk identification processing includes: identity verification and sensitive point detection; The second processing module is used to perform risk detection processing on the target code through the target platform to obtain a second detection result, and generate a target software package based on the target code and the target platform when the second detection result indicates that the target code conforms to the preset security rules. The third processing module is used to perform risk testing on the target software package through the target platform, obtain test results, and generate a release software package based on the target software package and the target platform if the test results indicate that the target software package does not have any security vulnerabilities. The fourth processing module is used to perform security protection processing on the software package to be released through the target platform to obtain the version to be released, and to perform security deployment processing on the version to be released according to preset deployment rules to realize the online launch of the target software product. The security protection processing is used to set attack barriers for the software package to be released.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the risk management method described in any one of claims 1 to 7 when it is run.

10. An electronic device, characterized in that, The electronic device includes one or more processors; A memory for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to be configured to run the programs, wherein the programs are configured to execute the risk management method as described in any one of claims 1 to 7.

Images