The Service Life Cycle plan documents the phases of a major software release.
The purpose of this control is to formalize the documentation and approval of software changes before those changes are implemented. This rigid process helps protect GitLab from insecure code being quickly pushed out into production without proper vetting.
This control applies to all major software releases to GitLab.com.
Most of this process is already captured in current GitLab workflow; the difficult part of this process will be coverage of all major software changes. Below is a detailed description of the workflow by stages:
Step 1: Planning
Createsteps of the cycle.
Step 2: Create - coding
The entire engineering workflow is documented here, which describes the process from the basics such as how to pick something to work on and includes the link to the project where the issues are housed – this is the starting point for the testing of SLC artifacts
Instructions on scoped labels used in updating issues using the scoped labels
workflow:: series through development to the product development timeline – following the scoped labels can be useful in testing the different parts of the cycle
The handbook section on code review process– this is represented within issues as the
Reviewer Roulette function
in the GitLab Docs, guidelines are documented.
Step 3: Verify - code review/ security review
The security release process is documented in the handbook– *is useful for testing the
Verify step of the DevOps cycle and
Secure value stage
Step 4: Change Management
Step 5: Packing and Release
Infrastructure for the GitLab system is defined as code and deployed using Terraform and Chef. These act as baseline configurations for our production systems. Changes made to those repositories - and therefore to our infrastructure - is subject to the same review process as our codebase.
For other Infrastructure team specifics, there's the Infrastructure Library page.
Step 6: Configure and Monitor
The design of the CI/CD pipeline for GitLab.com is documented in the handbook
For a description of how GitLab uses the CI/CD internally for the GitLab system, there's this Infrastructure page.
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the Service Lifecycle Workflow control issue.
Examples of evidence an auditor might request to satisfy this control: