DevSecOps with GitLab CI

What is DevSecOps

DevSecOps is the practice of integrating security testing at the stages of the software development process. It uses tools to ensure the building of secure and reliable software. Similar to the term DevOps, it brings cultural transformation to all parties in the team, indicating that security is a shared responsibility. Compared to the traditional mindset, developers, security specialists, and operation teams should work together on a security-first target.

The term DevSecOps is combined with three different words, which are development, security, and operation. Security is the extent of the common DevOps practice. Each of them represents a role and responsibility in a software team.

Development (Dev)

The “Development” represents mainly the process of coding, building, and testing the application, and it could sometimes include planning.

Security (Sec)

This part is to make security testing take part in an early stage or every stage of the software development cycle. For example, developers use it to detect any security vulnerabilities, and operation teams test the software right before they release it.

Operation (Ops)

Operation teams in this part are to release, monitor, and be the final gatekeeper if any issues can be found before releasing the software.

Why DevSecOps

The purpose is to address the security issues efficiently in a much earlier stage. For traditional security practices, security scanning usually takes time and requires a lot of human resources. It cannot keep up with a tight timeline and rapid software updates.

DevSecOps pipelines find security vulnerabilities depending on some predefined lists or AI and then indicate them by reports and dashboards. The pipelines are running at every stage of the software development lifecycle, like secret detection on every commit and container scanning on every build. As the testing was done automatically and simultaneously within the pipelines based on the trigger, it saved time in waiting for testing results. It means the developers can fix the issue before sending the changes to the next stage.

Moreover, security issues sometimes are difficult to find. Having a test at every stage means all the changes will go through different types but comprehensive testing. It is reliable and easier to indicate where the issue is from.

DevSecOps lifecycle

In the usual software development lifecycle, we usually have four stages. They are planning and development, building and testing, deployment, and monitoring. With DevSecOps, they also have their corresponding tasks and duties.

Planning and Development

Includes security practices from the start by secure coding practices and threat modeling. Adding code reviews and branch protection if you are using Git as the version control system.

Building and Testing

Using automated security testing for each new build process ensures they are all clean. When there is a new issue discovered, we will know where it is starting from. Additionally, it is common to add SAST, dependency testing, and secret detection in this stage.

Deployment

Thanks for all previous stages of checking and testing, we need to ensure a secure deployment. Only deploying what we have tested is the first and most important rule. It could be achieved by deploying the same Docker image that had been tested and scanned in different stages. Furthermore, you can apply DAST to scan the staging environment.

Monitoring

Even after the deployment, we still need to continuously monitor the software. By leveraging proper monitoring tools, alert systems, and dashboards, we can get accurate post-deployment details and see if there are any further actions required.

GitLab CI

GitLab CI is a software development tool, also the core feature of GitLab, that allows users or organizations to implement continuous methodologies, including continuous integration (CI), continuous delivery, or deployment (CD). With all other features provided by GitLab, like version control and collaboration, you will be able to build a complete DevOps solution. Moreover, they provide built-in security testing tools that can be easily integrated into your pipelines for your DevSecOps solutions.

Let’s dive into their support of application security.

GitLab analyses your applications by using either CI/CD pipelines or scheduled jobs. It covers your source code, dependencies in your projects or container images, vulnerabilities in a running web application, and infrastructure as code configuration. Each of the tools provided is relevant to a specific stage of the feature development workflow.

Commit stage:

• SAST
• Secret Detection
• IaC Scanning
• Dependency Scanning
• Coverage-guided Fuzz Testing

Build stage:

• Container Scanning

Test stage:

• API Security
• DAST

Deploy stage:

• Operational Container Scanning

For some examples of when to use those tools,

1. SAST to analyze source code for vulnerabilities.
2. Secret Detection to analyze your Git repository for any secret leaks.
3. DAST to test applications for known attack vectors.
4. API Security to test APIs for known attack vectors.
5. IaC Scanning to validate your infrastructure as code configuration files.
6. Container Scanning to scan the building or in-use container images.

Setting Up a Pipeline

To set pipelines using GitLab CI, it is straightforward to write a “.gitlab-ci.yml” file and store it in your Git repository. The “.gitlab-ci.yml” file lets you define scripts to run, configuration files, templates, dependencies, and caches. The steps and jobs can be defined in sequence or parallel. The pipeline can also be triggered manually or automatically.

Once you have a “.gitlab-ci.yml” file in the correct location, GitLab detects it and runs the jobs defined inside using GitLab Runners.

Basic Pipeline

Now, we will create a simple pipeline that includes several stages and jobs running in sequence.

stages:
- build
- test
- deploy

build-job:  
  stage: build  
  script:    
    - echo "this is a build job and it runs first"


test-job:  
  stage: test  
  script:    
    - echo "this is a test job and runs if build-job succeeded"


deploy-job:  
  stage: deploy  
  script:    
    - echo "this is a deploy job and runs if test-job succeeded"

From the above definition, we see three stages and a job in each stage. This is a similar structure while creating pipelines for your applications. Depending on your project’s complexity, there could be multiple jobs in each stage, and jobs within the same stage are usually running in parallel. For example, building images for different OS, different types of automated testing, or deploying to multiple infrastructures.

Integrate Security Tool

From the basic pipeline, we can add some security testing using the built-in tools provided by GitLab. For the coming example, we will add a secret detection job.

stages:
- build
- test
- deploy

include:  
- template: Security/Secret-Detection.gitlab-ci.yml

build-job:  
  stage: build  
  script:    
    - echo "this is a build job and it runs first"

test-job:  
  stage: test  
  script:    
    - echo "this is a test job and runs if build-job succeeded"

deploy-job:  
  stage: deploy  
  script:    
    - echo "this is a deploy job and runs if test-job succeeded"

Benefits from the well-integrated security tools by GitLab, we can simply add the “include” section with the correct template to use the default secret detection testing.

You now see a new job named “secret_detection” has been automatically added under the test stage.

The secret detection job will run through your Git repository using its logic. If you are using the GitLab-managed detector, everything will just run as expected. You are also allowed to maintain your detector and integrate it into the pipeline.

Finally, the default detector will generate a report as a job artifact after each check. You can download it from the pipeline artifact.

Handling Security Issues

When the tool discovers security issues for us, it will categorize them into different severities and display them on its built-in dashboard. The dashboard provides a visualization of metrics to indicate recent trends. You can see the number of issues per project or group. GitLab has also integrated it with its project management features by creating Issues directly from the security dashboard. Then, your team can work on each security issue individually.

Best Practise

DevSecOps should always be incorporated into the security control process of your team. With the earlier and more frequent security testing on your application, issues could be indicated as earliest as possible.

There are some best practices you can follow.

• Shift-Left Security
  You should emphasize the importance of early security testing.
• Continuous learning and improvement
  It is important to keep security practices up to date, as there are new threats every day. If the security testing process is no longer up to date, the test result is not reliable anymore.
• Collaboration between teams
  Cross-team collaboration should be encouraged between development, operations, and security teams, to find the perfect balance and exchange knowledge to continuously improve the security solution.
• Compliance and governance
  Security always has its standards to follow. You should ensure compliance with industry standards and regulations.