The Hitchhiker’s Guide to DevSecOps

Tze Shin Choo
3 min readJan 2, 2021

Embedding Security Operations into DevOps

DevSecOps refers to the DevOps practice with embedded security operations. This is realized through automating and integrating security processes into Continuous Integration / Continuous Delivery (CI/CD). Ideally, we should not need to call out the Sec (in DevSecOps) because DevOps should include the security operations. However, security was an after thought in many early DevOps implementations, hence DevSecOps.

My favourite DevSecOps definition comes from Atlassian,

The term DevSecOps is used to describe a security focused, continuous delivery, software development life cycle (SDLC).

For recap of DevOps key concepts, refer the bottom of this article.

Motivations for DevSecOps

In traditional SDLC, security tests are usually performed right before production releases. Vulnerabilities are found at the 11th hour, resulting in unnecessary release delays or technical debt acceptance.

Although developers are not security experts but they play the main role in resolving these security issues, shift left for security test accelerates the delivery of secured applications to the velocity of DevOps and puts developers responsible for securing their applications.

Application CI/CD Pipelines for DevSecOps

Application CI/CD Pipelines for DevSecOps

The application CI/CD pipelines for DevSecOps involve 5 logical building blocks:

  1. Application Repository — the repository(s) that manages application source code. The branch used for security test is agreed as part of branching strategy.
  2. Build Pipelines or CI Pipelines — the automated pipelines that build and test the application code. Code Quality Verification stage provides feedback on writing clean and maintainable code while Static Application Security Testing (SAST) stage provides feedback in vulnerabilities found in the code. The outputs (packages like container images, JAR and etc.) are published or pushed into the Artifact Repository.
  3. Artifact Repository or Universal Repository Manager — the repository(s) that stores the packages used for releases. The enterprise version usually includes continuous compliance features such as dependency scanning, license compliance and vulnerability scanning.
  4. Release Pipelines or CD Pipelines — the automated pipelines that deploy the application packages into environments. These pipelines could trigger external automated testing tools to validate the deployed application. Using a single Release Pipeline with deployment approvals to deploy the artifacts across all environments provide parity control and audit trail.
  5. Environments — the purposed infrastructure that hosts the application runtime. A controlled environment will only accept deployments from the Release Pipelines.

Continuously Continuous Integration

Everything is perfect in Google (including this article). However, the complications for DevOps in practice are

  1. The developers will always have urgent requests for build and deploy new applications. Start with the basic CI/CD pipelines i.e. build, publish and deploy to unblock the developers then continuously integrate tests (and security tests) into the pipelines.
  2. The DevOps tools landscape is continuously maturing in the market and within the enterprise. Your SAST could be undergoing an upgrade or DAST implementation could be in progress, your pipelines will continue to evolve along with these tools.

As a result of that, building your CI/CD pipelines will be a continuous process too.

I hope this article provides a practical guide for your DevOps journey.

Lastly, I would like to thank my amazing team for making DevSecOps the first-class citizen in engineering.

--

--