Understanding the DevSecOps Pipeline

In traditional software development practices of the past, organizations implemented security (both application and infrastructure) after the testing phase. In DevSecOps, security is implemented directly into the DevOps pipeline, i.e., security is integrated at the same time the code is being written, and the application is being developed.

Since security is implemented beforehand and at an early stage in a flowchart that reads left to right, it is also called “Shift Left,” indicating that security needs to be integrated into the earlier (left side) part of the process. 

Why do we need to “Shift Left”?

Here are the primary reasons why the industry is adopting the Shift Left approach over traditional software development methodologies:

1. Quick provisioning of infrastructure and resources with less hassle. This is achieved by adopting cloud computing and many services offered by the cloud service provider
2. Faster and more efficient software development and delivery
3. Reduced costs in development and testing
4. Effective usage of time and resources
5. Proactive security with a secure codebase since security is a part of the development lifecycle

Sample DevSecOps Pipeline

A typical DevSecOps pipeline comprises various stages of operation, as shown in the figure below:

Figure 1: Sample DevSecOps Pipeline

A variety of security measures are taken into consideration at different stages in the pipeline. Depending on what stage of development we are at, suitable actions and tools need to be used for implementing and integrating security in the pipeline.

Let’s go through various stages and understand what security measures are taken at each stage and their importance.

Pipeline Stages

1. Development

In this stage, the developer/coder, writes the code in the IDE and pushes it to the repo where the code is hosted. In the above diagram, it is hosted on GitHub. In this case, the developer writes the code in the IDE and pushes it to GitHub. 

Security measure: IDE plugins and linters 

These are used to find and analyze source code to flag programming errors and bugs, syntactical and stylistic mistakes, and malformed constructs, as well as to assist in writing with best practices. 

2. Source code repo 

After the development phase is completed, the code is pushed to the repo, where all the code is hosted. In our case, it is GitHub. 

Security Measure: Secret Scanning 

Sometimes, developers may knowingly or unknowingly add secrets like passwords, API tokens, credentials, sensitive info, etc., to the repo. Secret scanning tools are used for scanning the repo to identify the presence of any secret in it and take care of this.

3. Testing 

Once GitHub has been scanned for secrets, the next stage in the pipeline is testing. 

Security measure 1: SAST 

Now comes the testing phase. In this phase, along with functional load and unit testing, SAST is performed. SAST stands for Static Application Security Testing. In SAST, the source code is scanned to identify any security vulnerabilities, like SQL Injection, Input validation, Stack/Buffer overflow etc. In short, SAST covers OWASP’s Top 10 vulnerabilities.

Security measure 2: SCA

SCA stands for Source Composition Analysis. SCA identifies vulnerabilities in Open Source Software (OSS) being used by the application. An application may be using an old jQuery version, which may be vulnerable to XSS. SCA scans the code and identifies such issues in the OSS being used. 

4. Build 

After the testing phase comes the build phase. In this phase, Docker, Terraform, and Kubernetes are used. 

After testing, Docker images are built and pushed to the repo. Several Docker images may need to be managed by a container orchestration tool. Kubernetes is widely used as a container orchestration tool. Also, Kubernetes clusters are created using IaC, like Terraform. Thus, this phase mainly focuses on Docker, Kubernetes and Terraform. 

Security measures:  

1. Docker file scanning: Examines the Docker file for any misconfiguration, for example, avoid the sudo command, use trusted base image, Healthcheck instructions etc.
2. Docker image scanning: Scanning the Docker image to see if there are any vulnerabilities.
3. IaC scanning: Scanning Terraform scripts and HelmChart for any misconfiguration. 

5. Deployment

At this stage, the Docker image is deployed for running the application. 

Security Measures 

1. DAST: DAST stands for Dynamic Application Security Testing. A DAST scan is performed during the runtime using tools such as BurpSuite, OWASP ZAP, Acunetix, etc. Using the DAST tool, the application is usually scanned to find OWASP Top 10 vulnerabilities.
2. Infrastructure scanning: Infrastructure Scanning entails scanning the entire Infrastructure to find and exploit loopholes like unnecessary open ports, old services etc.
3. Compliance check: Compliance Check mainly involves server hardening checks by following the CIS Benchmark as an auditing standard and reference. 

6. Monitoring

As the name suggests, in this phase, the whole infrastructure is monitored by collecting, aggregating, and analyzing the data from various sources to maintain uptime, identifying any anomalies and malicious activities within the infrastructure/network.

Understanding the DevSecOps pipeline

The many stages that are often present in a typical DevSecOps pipeline have been covered in this post, along with the security measures that must be taken at each stage.

The many tools used at various stages of the pipeline will be covered in the next post. Stay tuned!

Sources:

• What is Shift Left DevOps?, Cloud Native Wiki by Aqua
• OWASP DevSecOps Guidelines, OWASP
• Shift Left Testing: What It Means, and Why It Matters, BrowserStack
• A Concise Guide to DevSecOps and Their Importance in CI/CD Pipeline, DevOps Zone