Disclaimer: This page is part of a POC and should not be used without validation of your Manager. If you're a Manager and want your team to be part of the experiment, please comment in this issue.
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.
This framework is meant to be used for all significant engineering changes in services or features, and more precisely for changes in:
The framework is organized in different stages, each of them having their own set of activities:
(Source: https://docs.google.com/drawings/d/1eQZppzngBJ9Xssvt514GHbs7rKHuRiLRk8cYbQtD5bI/edit)
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.
(Source: https://docs.google.com/drawings/d/1kj3KoU7UePUzoEdWCQFoppDEQgltUedmj6R-I0BqSZ8/edit)
The framework is architected around 3 stages:
| Activity | Security Team | Green & Yellow Data | Orange Data | Red Data |
|---|---|---|---|---|
| Data classification | Security Assurance | N/A | N/A | N/A |
| Architecture | Security Architects | Optional | Recommended | Required |
| Define Target Environment | InfraSec | Optional | Required | Required |
| Threat Modeling | AppSec | Optional | Recommended | 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: Green, Yellow, Orange, or Red.
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.
Create or update a corresponding Threat Model.
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
efforts.
