We know spam can be a big problem. Beyond being annoying, abusive behavior, we know it affects workflows and performance and puts a strain on rate limits and brand reputation. We’re here to help. Our security team works around the clock to actively detect and mitigate spam for GitLab.com users and our product utilizes filters, captcha and user-defined configuration to help self-managed instances prevent and mitigate spam and abuse. But, there’s always more that can be done. Below, we detail the work we do to protect .com users, offer up tips and best practices for self-managed users, and talk about some new automation and tooling we’re exploring that will help all users prevent spam.
How we work to detect and mitigate spam on GitLab.com
Our Trust and Safety team works to investigate and protect against the malicious use of GitLab.com and it’s associated features and tools with the goal of making our product safer for our customers and the wider community. One of their focus areas surrounds the detection and mitigation of abusive activity on GitLab.com.
What is abuse?
We define abuse as the intentional misuse of GitLab products/services to cause harm or for personal gain which includes the distribution of malware, spam, and prohibited content. This activity is covered under Section 3 of the GitLab website Terms of Use. You can learn more about how we classify abuse in our handbook.
How to report abuse as a GitLab.com user
Users on GitLab.com can report abuse via the Report Abuse button while logged in. Alternately, users can email abuse reports to [email protected]. Be sure to include any relevant information details in the issue or email so we can quickly and accurately understand the problem.
Self-managed customers: preventing, detecting and mitigating spam
GitLab uses Akismet Spam filter to check for spam when users create issues and reCaptcha as an added level of spam and abuse prevention.
This tooling helps respond to the symptoms of abuse, but the root of the problem remains: malicious actors register new accounts, or take over existing accounts and then use the accounts to spam and abuse instances and projects.
So, what more can you self-managed Admins do to prevent and mitigate spam?
2FA
Hosted instances of GitLab can reduce spam by making it more difficult for bots to automate account creation or takeover. Requiring 2FA for all users is one way to prevent legitimate users from having their accounts taken over and used to create spam.
Authentication restrictions
Sign-up restrictions
Sign-up restrictions will allow self-managed Admins to:
- Disable new sign-ups.
- Require Admin approval for new sign-ups.
- Require user email confirmation.
- Denylist or allowlist email addresses belonging to specific domains.
In fact, for customers running public-facing GitLab instances, we highly recommend that you consider disabling new sign-ups if you do not expect or want public users to sign up for an account on your instance.
Sign in restrictions
Sign in restrictions allow self-managed Admins to customize authentication restrictions for web interfaces as well as Git over HTTP(S). These settings will allow you to enforce:
- Mandatory 2FA for new users; this makes it more difficult for bots to surpass and prevents legitimate users from getting pwned via single factor authentication + weak password combinations.
- Email confirmation on sign-up; making it more difficult for bots to register new spam accounts.
We know that spammers are humans (or humans running bots) and these configurations create additional work for illegitimate users with the intent to spam your instance; thus presenting a deterrent and making your instance a more difficult target.
Harden your instance
Also, customizing your instance configuration can go a long way to discourage and reduce spam and abuse. This includes defining how users access your instance and who can have access.
Understand how abuse is reported and managed by self-managed Admins
It’s also key to understand how users can report abuse from other GitLab users to GitLab self-managed Administrators, the actions that self-managed Admins can take against abusers and how abuse reports are managed and resolved by Admins.
Rate limits
Finally, if you’re in the midst of spam abuse you can impose rate limits to help respond to the increased loads. You can also limit rates on issue creation and impose rate limits on user and IPs.
What’s next in spam and abuse prevention and detection
We continue to look for new ways to prevent, detect and mitigate abuse on GitLab.com and within our product. We are exploring alternate options for captcha to improve user experience and options to prevent bots posting URLs followed by crawlers to prevent spam. In addition, our security team is in the process of developing new automation to detect and prevent the creation of spam and are aiming to begin testing a first iteration on GitLab.com within the next 3 months. If successful, this is something we’ll look to incorporate into the product so all customers can benefit. For current, working product improvements to detect and mitigate spam, see our active merge requests.
Suggestions and feature requests
If you have any suggestions or requests to improve abuse prevention on GitLab CE and EE, feel free to create a feature proposal issue from the provided templates in the GitLab Project and add the ~"Abuse Prevention" label. For more information on how to contact our Trust & Safety Team, see our handbook.