We are responsible for developing solutions to give customers the functionality to apply policies to enforce scans and to require security approvals when vulnerabilities are found.
We use our Security Policies Priorities list in our direction page to track what we are doing, and what order to do it in. Each initiative includes these fields:
Complete items are removed from the table once the code is in production without a feature flag, and a release post, if applicable, has been merged. The epic is closed at this point.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (SUS) impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
(Sisense↗) Flaky test are problematic for many reasons.
The Security Policies group largely follows GitLab's Product Development Flow.
Additional information about how we operate can be found on the Planning page.
Our current workflow is visualized as flowchart on the Workflow page.
We follow these guidelines when submitting MRs for review when the change is within the Security Policies domain:
GitLab has a labeling convention for issues and Merge Requests. We follow this convention, though there are specific labels required to route artifacts to us. We use these labels to filter issues meant for us on our issue boards. They are also used for metrics and KPI reporting.
| Label | Meaning |
|---|---|
| ~"section::sec" | Identifies the issue or MR as belonging to the Sec Section's roadmap. |
| ~devops::govern | Identifies the issue or MR as belonging to the Govern Stage's roadmap. |
| ~"group::security policies" | Identifies the Security Policies group as the collection of individuals who will work on the issue or MR. |
| ~"Category:Security Policy Management" | Identifies the issue or MR as being part of the Security Policy Management feature category. |
| ~backend | Identifies the issue or MR as being part of GitLab's backend. |
| ~frontend | Identifies the issue or MR as being part of GitLab's frontend. |
When creating a new issue, use the /copy_metadata #373191 quick command to copy required labels.
It is advisable to manually trigger the Package and QA downstream E2E job in an MR and review the results when there are changes in:
To manually trigger the QA job:
> arrow on the right of the Stages and click the package-and-qa item.It's advisable to run the QA job on the latest pipeline at least once during the MR review cycle.
When a feature needs to check the current license tier, it's important to make sure this also works on GitLab.com.
To emulate this locally, follow these steps:
export GITLAB_SIMULATE_SAAS=11gdk restartSee the related handbook entry for more details.
We encourage frontend engineers to contribute to the backend and vice versa. In such cases we should work closely with a domain expert from within our group and also keep the initial review internal.
This will help ensure that the changes follow best practice, are well tested, have no unintended side effects, and help the team be across any changes that go into the Security Policies codebase.
The Security Policies group welcomes community contributions. Any community contribution should get prompt feedback from one of the Security Policies engineers. All engineers on the team are responsible for working with community contributions. If a team member does not have time to review a community contribution, please tag the Engineering Manager, so that they can assign the community contribution to another team member.
There are many ways to pass an environment variable to your local GitLab instance. For example, you can create a env.runit file in the root of your GDK with the above snippet. ↩