IBM provides a DevSecOps reference implementation that I’ve used to build our SaaS reference architecture. This article describes the CI pipeline, especially the part to enforce branch protection.
This article is part of a mini series.
- DevSecOps for SaaS Reference Architecture on OpenShift
- This article: Shift-Left Continuous Integration with DevSecOps Pipelines
- Change, Evidence and Issue Management with DevSecOps
- Continuous Delivery with DevSecOps Reference Architecture
- Tekton without Tekton in DevSecOps Pipelines
A core concept of DevSecOps is ‘shift left testing and security’. The basic idea is simple. Do as much security and functional testing as early as possible in the software development lifecycle. The earlier issues are detected, the easier and cheaper is it to fix the issues.
These are the main tasks of the first of the two CI pipelines that are part of the IBM DevSecOps reference implementation.
- Branch protection is ensured so that developers cannot push to the main branch directly
- CIS checks are run
- Secrets in code and config files are detected
- Unit tests are run
- Vulnerability scans are performed
Changes from developers are not pushed into the main branch directly. Instead feature branches are used which is a good pattern anyway.
After the pull request has been created, the first CI pipeline starts automatically to perform the various security and functional tests.
I like the integration in GitHub. As a developer I can see most of the results directly in the GitHub experience. In the background the pipeline on the IBM Cloud is run.
Even if the various security checks have been successful, the pull request still cannot be merged. A second developer (in this case my colleague Adam) needs to approve first. From my personal experience I can say that these reviews are another very good pattern.