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_eng#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 Kamil Niechajewicz.
We use our Threat Insights Priorities page 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.
(Sisense↗) Slow tests are impacting the GitLab pipeline duration.
The Threat Insights group largely follows GitLab's Product Development Flow.
Additional information can be found on the Planning page.
~Deliverable label as well as Health Status: On Track at the beginning of the milestone.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.
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.
We encourage running the e2e: package-and-test downstream E2E job in merge requests at least once and review the results when there are changes in:
Standalone E2E specs can be run against your local GDK instance.
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. ↩