The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
"The call is coming from inside the house"
A lot of security practices are focused on preventing someone from getting into systems, but what happens when someone is already inside? That's the premise of Insider Threat. We want to detect, identify, and respond to threats inside the GitLab platform as well as your deployed applications.
Insider Threats can be grouped into a few types:
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. Given the broad scope of insider threats—and considering this is a single engineer group—we will take a "build-up, then out" approach. This way, we can provide immediate value in small increments. We will add new anomaly detection capabilities as distinct features. These can be configured and improved incrementally, independent of other detection capabilities. Over time, these features will converge, joining underlying analytics and detection capabilities to provide more horizontal insights and detection capabilities. We intend our Insider Threat capabilities to be "batteries included" with minimal to no configuration for initial usage. We will default to presenting actionable insights but will leave the decision to block up to GitLab administrators unless specifically configured otherwise.
This is our second focus of the AI Assisted Group and, as such, we will update our Roadmap goals soon. In the meantime, here are some goals we are considering:
Detecting issue abuse and spam - Today, GitLab’s Trust and Safety team responds daily to spammers and reported content. Much of this activity is manually reported by a person. This will help automate daily tasks for the Trust and Safety team and hopefully allow us to start automatically quarantining high-scoring spam and abuse such that real users don't ever see it. This is an easy first application of data science to actively score and automate initial reviews of potential issue abuse and spam.
This effort is a joint project between GitLab’s Trust and Safety team, the Govern stage team, and the AI Assisted team.
In the spirit of MVC, we will look to productize existing capabilities developed by our Trust and Safety team. This will include a signal-based system that detects behaviors from pre-defined rules. It may also include machine learning (ML) models that can identify runner abuse, specifically when used for crypto mining. This will help lay the foundation for future behavioral models by starting to define how they are configured by end users as well as the underlying deployment and upgrade model. In addition to providing valuable new capabilities for our users, it will also allow us to dogfood our security tools within GitLab itself.
Many of today's Threat Detection products are focused on the desktop environment, using deployed agents to gather data and monitor behavior and User Entity Behavior Analytics (UEBA). Most solutions are run as a physical appliance or in an on-premises data center. Virtual machines for cloud deployment are in the minority; cloud-native UEBA is even less common. Additionally, there continues to be a convergence of UEBA features with adjacent products such as SIEMs or the acquisition of standalone vendors by larger security companies. According to Gartner, "by 2022, 95% of all UEBA deployments will be 'as a feature' of broader security platforms."
The priority list for Instance Resiliency is maintained here.
Last Reviewed: 2023-02-01
Last Updated: 2023-02-01
