We are responsible for developing solutions to give customers insights into threats and enable them to manage their security risks effectively and efficiently.
We use our Threat Insights Priorities issue 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 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.
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
Stagesand click the
It's advisable to run the QA job on the latest pipeline at least once during the MR review cycle.
As part of FY22-Q1 OKRs, we've started tracking and monitoring the Largest Contentful Paint for our web pages. The results can be viewed on this Grafana dashboard.
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:
See 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 Threat Insights codebase.
The Threat Insights grop welcomes community contributions. Any community contribution should get prompt feedback from one of the Threat Insights 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. ↩