GitLab Continuous Security Framework
Gitlab Continuous Security Framework
Security is often being involved late in the life cycle of feature development. To prevent this, security is bundled into the Software Development Lifecycle, in every stage of the workflow. Eventually, features are meant to reach production, but have to pass the production readiness review gate first. In order to facilitate this process, the framework supports the engineering team all along the life cycle of the feature, to facilitate the creation of the required documentation and other artifacts.
The framework relies heavily on the data classification of the feature in scope. It is not necessary for features managing Green data, and more activities are required as the level increases, up to Red data.
The framework targets mostly Engineering Managers and their team, but also Product Managers, to track progress from the early phases of the Product Development Workflow, to the release or deployment to production.
Once released or deployed, the SDLC loops and a new iteration can start. The framework continues to support the team with insights and recommendations. More importantly, changes in the framework should also affect previous projects, hence the “continuous” part of the name: our security requirements and guidelines evolve with time and it’s important to keep our features aligned.
When to use this framework?
This framework is meant to be used for all significant engineering changes in services or features, and more precisely for changes in:
- The GitLab Architecture
- The GitLab.com infrastructure
- The classification of the data being managed (stored, transferred, or updated)
The framework is organized in different stages, each of them having their own set of activities:
Activities have a “deliverable”, which the expected artifacts of the activity. They can be of various forms, from markdown pages to the state of a dashboard.
The framework is architected around 3 stages:
Activities and deliverables
|Activity||Security Team||Green & Yellow Data||Orange Data||Red Data|
|Data classification||Security Assurance||N/A||N/A||N/A|
|Define Target Environment||InfraSec||Optional||Required||Required|
Identify the kind of data transiting, transformed, or being stored by the system. If only one field in a database is RED, the whole system must be considered RED entirely. This step impacts all activities of the framework and must be re-evaluated regularly.
A value among:
- The Data Classification Standard handbook page
The goal of this activity is to provide (and improve over time) a documentation of the system to be created or changed, along with architecture decisions. Architecture helps to balance customer demand and delivery capacity to create a sustainable and coherent system. This system should strive to meet its functional requirements as well as the relevant quality attributes.
This activity is supported by a set of principles and tools. The artifacts (Architecture description and decisions) help to achieve the following activities. For example, a better understanding of the system helps to get started with the Threat Modeling activity.
Define Target Environment
Create or update a corresponding Threat Model.
OSS Ecosystem Testing
In case the proposed architectural change introduces new Open Source Software components to our
infrastructure or our product inform the Security Research Team
@gitlab-com/gl-security/security-research) for potential inclusion of the dependency into the
OSS Ecosystem Testing
Additional resources and references