What is DevSecOps and Why Is It Important ?
Investigation of security integration part 1
1- Introduction
As software development improves in the agile model, people have developed methods that focus on greater collaboration with customer needs, ongoing delivery, ongoing feedback, and communication between developers and users. This has led many to become proponents of evolving agile thinking.
However, to improve the performance of IT services and give organizations a competitive advantage, we need more than simple and agile methods. The DevOps movement stems from the need to improve the agility of IT services, and by emphasizing people and their culture, seeks to improve the collaboration between development and operations teams while using agile concepts. And to a lesser extent remove unnecessary barriers to the provision of services and their application. For this reason, DevOps can be seen as the result of the integration and application of different software development methods, operational processes and social psychological beliefs to transform IT services delivery. From this perspective, DevOps is a new way of thinking, spirit and philosophy. It is for the evolution of organizations.
On the other hand, despite the capabilities of DevOps in the automatic development and delivery of software and ensuring their accuracy and reliability in terms of performance, it does not in itself have any control over software security challenges because security is a need that is not in the functional cycle and therefore does not affect the product performance. Therefore, in order to eliminate this shortcoming in the cycle of research, development, and operations, they thought of including security models in this cycle, which led to the evolution of DevOps to DevSecOps.
2- DevOps Approach
According to the AWS definition, DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
Challenges
Every organization that wants to use one of the SDLC models tries to choose the method that has the maximum optimization and efficiency for it. In this regard, the DevOps approach, with more and better cooperation with the operations team, leads to faster and better software release, which leads to greater agility, flexibility and quality, as well as cost reduction. But it has also created new and sometimes formidable challenges.
Security is a need that is not in the operational cycle and therefore does not affect product performance, so it is often directed to the end of the process. Although significant improvements were made to deliverable products with DevOps, there were numerous security holes in many products that required major changes to the software architecture to address them. This architectural change usually takes a long time and reduces reliability and increases inefficiency in the work process. Although some expectations can be met despite the lack of security, it ultimately poses a major security concern to the project. However, the most important requirement for using the DevOps method is to achieve high reliability, which fails. In other words, security problems occur when the construction and testing stages are completed and we have entered the operational stage. Obviously, if we want to discover and fix these security holes at this stage, the organization will incur heavy costs and the development team will have to spend a lot of time reviewing the source code from the beginning. Therefore, it is clear that not considering security in the DevOps cycle will lead to many similar problems in the future. Report also refers to this issue.
DevSecOps Approach
Numerous security challenges and problems with DevOps synchronization with security testing complicate the benefits of using the DevOps ecosystem. Does this slow down the cycle? This is one of the major concerns and challenges of integrating security into development teams.
To overcome these challenges, development and security teams must adopt new ways of working together, develop new processes, and use new tools. Therefore, to address security concerns, while keeping up with the rapid delivery of software, appropriate processes, cultures, and tools should be adopted through automation to maintain rapid development replications. This is a DevSecOps approach that enables development teams to integrate security tools into their pipelines to identify vulnerabilities early on and to establish healthy collaboration between security and DevOps teams.
Therefore, what we intend to gain from this research is a better insight into the methods and tools that accelerate the acceptance of DevSecOps.
DevSecOps is a combination of development, security and operations. Adding the term “sec” to DevOps means adding more confidence, clarity, and a clearer understanding of potential risks. It is an accelerated approach in which security parameters are applied at the beginning of the project and penetration tests are used throughout the development cycle so that all factors involved in the software life development cycle, including operators, programmers, security professionals and even other non-technical teams will interact with this approach.
The implementation of DevSecOps culture in the organization is based on shared responsibility, which causes efficient software development, reduces costs, reduces risk, and corporate growth. Therefore, it is observed that in the DevSecOps ecosystem, we are faced with two aspects of culture-building and tools. In reference, the way of communication of these aspects is in the form of a pyramid.
DevSecOps Tools
Automation aspect of DevSecOps involves using tools to automate security testing. Automating security allows processes to be predictable and scalable. It is also an essential part of keeping up the necessary fast pace in DevOps. If tests are run automatically, it also frees up more time for developers to write code and focus on business logic instead of managing tests.
In this regard, we will generally encounter and two simple tools base on static software security testing (SAST) and dynamic software security testing (DAST).
On the other hand, in addition to SAST and DAST, there are other tools for security testing of various components that should be used at the right time and place according to the scenarios in the software life cycle. For example, in an organization that works on specific software and puts its source code into the public repository, developers may, when sending their modified code to the repository, may include sensitive files such as passwords, etc., which are sometimes part of the source. Send the code used as well. For this reason, in creating a pipeline integrated with automated security testing tools, the test and search step in the relevant repositories to find sensitive files is also added. Therefore, the Container Image Security Test (CIST) tool should also be considered in integrating the development cycle and operations.
3- Case simulation
Base on my GitHub demo project
In order to investigate the practical role of security testing automation, a similar experiment was conducted in the field of building and testing cycle up to the staging. First, using Python language and Flask micro-framework, we considered a website under development without considering security, and the source code is placed in the code repository as follows:
For the initial stage of website health testing, which
is introduced as a unit test, the CI phase is implemented in the form of a pipeline using common tools used to build and operate.
According to Figure[2] , our simple Jenkins pipeline is completed in three common stages: Build, Test, and Deploy. In the build stage, first, using the Docker, to build image containing our project.
In the testing stage, we use a container for running tests, a unit test is performed by the developer to assess the initial health of the webapp written in Python, and the output is displayed in xml format in addition to the console The report is presented which is successfully passed in the above experiment and then enters the third stage.
In the deployment stage, after Jenkins successfully passes the test, the commands inside the third phase are executed. Which contains the instructions for making and executing the container from the image Docker made in the previous steps.
The continuous integration are now complete and the three build, test and deployment stages are implemented automatically using common tools. Figure 3 shows the success of our simple pipeline.
Now that the project has been deployed in the local Test Environment using DevOps Approach it is time to visit website. Therefore, we enter the website through the browser.
It can be seen that the website is accessible in full health through the IP address of the Docker container. But the first question that comes to mind is whether the DevOps mission, which is to achieve high reliability, has been achieved in this project? Is it possible to start the process of merging the branches into the main branch and starting the final product deployment process with sufficient confidence?
For this purpose, initial security checks are performed. In the first few minutes of the initial search of the website in the search section, we noticed an XSS security bug and many other security vulnerabilities…. (as shown in Figure 4)
The figures above show that despite the completion of the operation development cycle and the deployment of the website based on the DevOps approach, numerous security holes can be seen using security testing tools (such as OWASP-Zap). Obviously, fixing them takes a long time and in many cases it is impossible to detect and fix these bugs at such a stage.
Therefore, in the continuation of the project, which was carried out based on the DevOps approach, it is time to integrate security testing tools in the cycle with the DevSecOps tools:
According to Figure 5 example, in addition to the common three stages of build, test, and deployment in the DevOps approach, the three stages of SAST, CIST, and DAST are added to integrate security tests into the automated software development and deployment cycle, in the hope that, unlike the previous case, the lack of the security model can be compensated. This feature eliminates the vulnerabilities of the code before it is finally deployed in the operating environment.
Note that these are just simple examples and we can customize these stages as needed. actually it depends on our project
According to our Jenkinsfile in source code, Sonarqube tool for SAST, OWASP-ZAP tool for DAST and Phonito scanner for Docker image security test are used. The following are description of the steps:
Step 1 — SAST: In this step, using the pom.xml file through the Sonarqube tool API, static test operations are performed on the main project code located in the src folder. The tool finally provides a complete report through the link created, which includes the checks performed and the bugs found. This report can be delivered to the development team to review and troubleshoot identified problem codes.
Step 2 — Build: In this step, similarly, a new image is created from the existing dockerfile and the base image inside it and saved by the Stash command.
Step 3 — Unit Test: In this step, as before, the tests written by the development team for the performance of the website are automatically performed by Jenkins in the pipeline.
As shown in Figure 6, the Phonito scanner detected 141 security holes (including 16 critical holes, 81 high risk holes, 43 medium risk holes, and 1 low risk hole). It can be seen that due to the finding of high-risk security holes, the Phonito tool prevents the Jenkins tool from continuing the pipeline, and the DevSecOps cycle ends early with a fail. This represents the first advantage of using the DevSecOps tool approach and the use of a pipeline integrated with automated security testing tools. Figure 6 shows the error received from step 4 and the early completion of the cycle without performing the next steps.
In order to continue the development and operational implementation of the project, in order to re-run the cycle after testing the image security error, we must move to change the base image and secure it. But to continue the process, by adding the command “true ||” The pipeline file allows Jenkins to continue through the pipeline process despite receiving numerous security issues.
Step 5 — DAST: In this step, using the console version of the OWASP-Zap tool, which was used in the project after the final deployment of the website in the graphical environment, it was integrated into the pipeline and after running and building the container, the image of the construction stage (Step Two), starts testing the security dynamics. The result is similar to that of Figure 7, which, like step 4, prevents the Jenkins tool from continuing to run, and the DevSecOps cycle ends early with a fail.
Therefore, it can be seen from the output of steps 4 and 5 that the new version of the pipeline, which was created using the DevSecOps tools, prevents the deployment of the website in the operating environment. Also, after receiving numerous reports and feedback during the implementation of these steps, the problems are already identified and the development and operations team are fully informed.
Figure 8 shows that the command “true ||” added to step 4 and 5 executable commands to get the Jenkins tool to run the pipeline completely. As shown in the figure, in the final stage of deployment, the process of running the pipeline with the question “Continue to Deploy” has stopped. Deploying such an order in the pipeline file allows us to inform the responsible teams of the results of each phase by receiving continuous reports in various stages (from the moment the code is loaded in the repository to the end of the pipeline) to make appropriate decisions.
4- Conclusions
The importance of security and the need to improve the reliability of a software product is not hidden from anyone. Despite the spread of the DevOps culture as a best solution for the rapid release and delivery of software in the form of interaction between development and operations teams, there is still the traditional idea of using security tests. The DevOps model has the ability to integrate security approach. Conventional automated security testing is available to enable the development and safe operation cycle and achieve the results needed to increase the reliability of the final product based on the output of the security testing process and the ongoing awareness of the development and operations teams.
In this report, this issue was demonstrated by presenting the case simulation results. After a relatively description of the DevOps and its challenges from a security perspective, by presenting the basic concept of DevSecOps as an evolved approach of DevOps, a case simulation was performed in which the necessary DevSecOps tools in the development and operation stages were added in practice. In this way, by integrating automated security testing tools, manual security testing that slows down the delivery cycle. By integrating automated security testing tools, in addition to preventing the final deployment of insecure code, the ability to detect and fix security bugs in this cycle is achieved and automatically in the shortest possible time.
Finally ..
links that I recommend:
