1. Overview
The term 'DevSecOps' is familiar to many, and it is also one of the most frequently mentioned terms in recent times. From a security perspective, its origin is the application scenario of the SDL (Security Development Lifecycle) concept. In the past, there have been many debates about the differences between SDL and DevSecOps. In fact, this question is not difficult to answer. SDL is a methodology for the 'security left shift' concept, and from the perspective of development, it is generally divided into two modes: waterfall development and agile development. Therefore, DevSecOps is the application scenario of agile development. Many enterprises, in order to adapt to the rapid development and iteration model, have integrated a set of DevOps toolchains, which has connected development and operations as a whole to achieve rapid deployment of applications. This has also posed a challenge to security, and the new security model must adapt to the agile mindset. Thus, the practical implementation of the DevSecOps scenario has emerged accordingly.
2. Starting Point
The starting point of the life cycle of development is business requirements and architecture design, therefore, the starting point of the security life cycle is still the analysis and design of security requirements. We have built the DevSecOps security empowerment platform, which is mainly for the construction of the security design library, security threat library, security requirement library, and lightweight threat modeling, among other things. However, due to these tasks being unable to be processed in a pipeline compared to agile development, I chose SAST as the initial point for pipeline operations. Although SAST has a relatively high false positive rate, its advantage lies in its ability to provide a high level of visibility into the project source code. Based on code rules, it can detect more security issues, including the detection of sensitive personal information and other data security-related issues that are emphasized now. In the later stages of the project, the review of these tasks undoubtedly extends the time to market and is prone to significant false negatives. At the same time, it is emphasized that the detection of sensitive data, CWE and OWASP classified vulnerabilities, and security configuration at the code stage is relatively cost-effective and can reduce the likelihood of false negatives.
During the selection phase of SAST, we discussed the comparison of open-source software and commercial software. I have tested open-source tools such as FindsecBugs, Snoar Qube, and commercial tools such as Fortify and other domestic tools. The tool integration is not complex, as we install the plugin into jenkins and configure the GitHub project address. When jenkins builds, it triggers the scanning engine to work. I would like to emphasize that we use asynchronous calls, and the purpose of this is that the project code itself is quite large, and if it enters a waiting state, it will cause the entire business line to be delayed. This approach is faster for R&D. At the same time, when merging several branches of the project, the engine's detection will also be triggered. The purpose of this is that the code of a single branch is far less accurate than the overall code detection of the project, and code branch merging also needs to trigger security quality assessment to prevent the introduction of threatening code into stable versions.
Figure (1) SAST Trigger Process
3. Software Dependency Security Analysis
SAST has only solved the security issues of self-developed code, but now most business systems use open-source frameworks for rapid development or introduce some third-party middleware to iterate projects. However, this also brings the security issues of third parties into the business systems, and these third-party component vulnerabilities often play a crucial role in the HW phase. During the HW process, red team members collect information about what intermediaries and corresponding versions are used in the business system, thereby exploiting vulnerabilities to achieve RCE. By sorting out supply chain security, it is not difficult to find that high-risk frameworks or intermediaries include Struts2, Weblogic, and Jboss, etc., while commonly used third-party components include fastjson, shiro, Jackson, etc. Therefore, we have deployed SCA services. As an atom, the SCA service analyzes the dependencies of third-party components used in the project during the project construction phase, finds potential security threats of components, including discovering known CVE vulnerabilities or impersonated malicious components. However, we often encounter that R&D always says that some jar packages or components have been introduced into the project, but they have not been used. Therefore, we will also perform dynamic detection on third-party components, and in the UAT environment, we will monitor and analyze the runtime of third-party open-source components. The vulnerabilities found at this stage have greater value to the project.
Figure (2) SCA Detection Process
4. Gray-scale Testing in UAT Environment
From the perspective of the security lifecycle, we have experienced code detection during the development phase, conducted software dependency analysis during the project construction phase, resolved most of the application issues, maintained the quality gate of security, but SAST has a high rate of false positives. At the same time, due to various reasons, the漏扫 devices cannot crawl all the system interfaces during the DAST phase, resulting in missing reports. Therefore, the gray-scale testing in the UAT environment not only solves the problem of high false positives in the SAST phase but also compensates for the missing reports in the DAST phase. During the first phase of construction, the桩插 method was ultimately adopted, using dynamic taint tracking technology to analyze the security of the code. When parameters are passed in, they are marked, and the flow of parameters is analyzed to determine whether it has passed through a filter. If it is not filtered during the taint convergence, it can be determined that a vulnerability exists, thereby improving the accuracy of vulnerability detection. However, in order to support more application environments, it is considered that in the future, the payload mode sent at the scanning end will also be introduced.
5. Concluding Remarks
The core objective of DevSecOps is to build a unified security operation environment for development, operations, and security, enabling organizational members to participate in the construction of the security system in an agile manner, transforming from a team-based security approach to a responsibility-by-everyone approach. Although the DevSecOps model covers the entire process of the software development cycle, in practice, most of it is still concentrated in the development and testing stages, which include code security scanning, supply chain security detection, UAT environment gray-scale testing, and vulnerability scanning before going live. As the integration of security in the development and testing stages becomes increasingly mature, the security concept will further shift to the demand and architecture levels, which is also the main goal of the second stage.
评论已关闭