We are responsible for developing solutions to give customers insights into threats and enable them to manage their security risks effectively and efficiently.
#g_govern_threat_insights#g_govern_threat-insights_standup#g_govern_threat_insights_navy#g_govern_threat_insights_tangerine@govern_threat_insights_be, @govern_threat_insights_feThreat Insights is a large group, and to reduce planning overhead, engineering is organized into two teams, Navy and Tangerine, that each approach work in vertical slices. This is more efficient because it virtually eliminates the cross-team dependency that comes from organizing a large group by technical expertise.
Both teams have Backend and Frontend engineers, and as such work on any part of our codebase. However, Team Navy primarily focuses on features that affect the user interface, while Team Tangerine concentrates on data management.
We use the scoped labels ~"Threat Insights::Navy" ~"Threat Insights::Tangerine" to designate work for each team. Navy engineers report to Neil McCorrison and Tangerine engineers report to Thiago Figueiró.
We use our Threat Insights Priorities issue to track what we are doing, and what order to do it in.
(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 Threat Insights group largely follows GitLab's Product Development Flow. Additional information about how we operate can be found on the Planning page.
We follow these guidelines when submitting MRs for review when the change is within the Threat Insights domain:
These boards show current status of issues. See also priorities and milestone planning.
Our teams use the Health Status feature within issues to indicate the likelyhood of completion within the milestone. We assign On Track at the beginning of a milestone to a small number of issues where we have high confidence in delivery during that milestone. If there is concern with marking something as initially on track, then we should discuss why.
Raising risk early is important. The more time we have, the more options we have. For example, issues that have not gone into review by the 10th of the month may not have enough time to get merged. These should be considered Needs Attention or At Risk depending on their complexity and other factors.
Follow these steps when raising or downgrading risk:
On Track - high confidence - there is no indication the work won't get merged by the 15th.Needs Attention - medium confidence - the issue is blocked or has other factors that need to be discussed.At Risk - low confidence - the issue is in jeopardy of missing the merge cutoff of the 15th.Note that an issue probably shouldn't go directly from On Track to At Risk. That pattern indicates we have missed an opportunity to discuss earlier. Consider the progression: On Track -> Needs Attention -> At Risk.
Additionally, we make use of our automated policy that automatically degrades the health of scheduled issue based on conditions. This enabled per issue by adding the ~Track Health Status label.
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.
E2E tests should pass with a feature flag enabled before it is enabled on Staging or on GitLab.com.
Therefore, it's important to confirm this when introducing a new feature flag. Adding or editing a feature flag definition file starts two e2e:package-and-test jobs (one with the feature flag turned on and another where it's turned off).
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 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.
We hold weekly group discussions alternating on APAC/AMER, and EMEA/AMER time zones. Everyone is invited to attend, and it's a great forum to ask questions about Vulnerability Management, customer queries, our road map, and what the Threat Insights team might be thinking about. You can find the meetings on the Threat Insights calendar; take a look at the agenda (internal link). We hope to see you there!
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. ↩