Our goal is to provide Insider Threat features for your applications as well as GitLab itself. We will help proactively identify malicious activity, accidental risk, compromised user accounts or infrastructure components, anomalous use of the GitLab platform, and various high-risk behaviors where actionable remediation steps are possible.
The following people are permanent members of the Anti-Abuse Group:
|Alex Buijs||Senior Fullstack Engineer|
|Eugie Limpin||Senior Fullstack Engineer|
|Hinam Mehra||Fullstack Engineer|
|Jay Swain||Engineering Manager|
|Jensen Stava||Sr. Product Manager|
Building the team and detecting and preventing spam and cryptomining abuse of the GitLab SaaS platform.
Our team uses a hybrid of Scrum for our project management process. This process follows GitLab's monthly milestone release cycle.
(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.
Our team use the following workflow stages defined in the Product Development Flow:
We use a team specific issue board to track issue progress on a daily basis. Issue boards are our single source of truth for the status of our work.
We follow the iteration process outlined by the Engineering function.
Refinement is the responsibility of every team member. While planning out an epic or a feature we break it down into small consumable chunks. This process is challenging, and takes time. This is why we've set a weekly refinement meeting.
We use planning issues to discuss priorites (GitLab internal).
We use issue labels to keep us organized. Every issue has a set of required labels that the issue must be tagged with. Every issue also has a set of optional labels that are used as needed.
MR labels can mirror issue labels (which is automatically done when created from an issue), but only certain labels are required for correctly measuring engineering performance.
We tag each issue and MR with the planned milestone or the milestone at time of completion.
Our group holds synchronous meetings to gain additional clarity and alignment on our async discussions. We aspire to record all of our meetings as our team members are spread across several time zones and often cannot attend at the scheduled time.
We have a weekly refinement session Friday 00:00 UTC.
PVS is an internal service that belongs to the Anti-abuse team. It’s a combination of heuristic-based (text matching, etc) and behavior-based rules (duplicate builds, etc). The Trust and Safety team leverages this service the most, and acts as the customer for feature requests.
Due to the nature of cryptomining attacks, heuristics are going to change quickly and need to be implemented rapidly. Accordingly, T&S is invited to submit MR’s to PVS that are heuristic based, or alternatively request these changes from the Anti-abuse team.
Behavior rules are more slow to change and potentially cast a much wider net (vs a very targeted heuristic rule). Changes to behavior rules are expected to come from T&S, and implemented by the Anti-abuse team.
Severity and priority will be added on all issues/merge requests created by T&S so that Anti-abuse can act on them accordingly.
Priority will be based on impact and likelihood of the attacker returning.
Anti-abuse will periodically review the accuracy of PVS alerts to see where there are opportunities to reduce the False Positive rate, without impacting the true positives, and Trust and Safety will help provide the required information to do this.