Blog How GitLab uses Third Party Security Rating to Build Customer Confidence
December 18, 2020
4 min read

How GitLab uses Third Party Security Rating to Build Customer Confidence

This blog is about how GitLab manages Third Party Security Rating platforms, why we chose to partner with BitSight, and how we are using BitSight’s external validation to increase customer confidence.

Blog fallback hero

In today’s security world, it isn’t enough to say your product is secure, Customers and Prospects want you to prove it. GitLab understands how critical security is when making purchasing decisions and recognizes that many utilize results from Third Party Security Ratings platforms as a deciding factor. While these services can be extremely helpful, there is also the potential for inaccurate information to be presented as evidence on a company’s behalf, especially for a company like GitLab. That’s why GitLab aligned with BitSight, a leading provider of Third Party Security ratings and loyal GitLab customer, with a mutual goal of removing misappropriated information, improving GitLab’s security rating, and building confidence in our security posture for our Customers and Prospects. Here’s how we did it.

The Downside to Third Party Ratings

Third Party Security ratings are a great way to independently validate a company’s security. However, without proper diligence and review, ratings can be presented inaccurately. This was especially true in GitLab’s case. GitLab maintains multiple environments to properly segment our development and testing activities from our production environment. Within these non-production environments it is common to have older infrastructure or operating systems for backwards compatibility testing. However, with many Third Party Security Rating platforms, non-production environments are lumped together with production. Additionally, due to GitLabs dynamic nature, our team members often create infrastructure for testing, register the IP address, and then remove the infrastructure within a short period of time. This can lead to IP addresses that are no longer utilized by GitLab to be included in the ratings. Both of these resulted in a deceptively lower score on multiple Third Party Security Ratings platforms that were not accurately reflecting GitLab’s security posture.

Improving GitLab’s BitSight Rating

Third Party Ratings Workflow

In August 2020, GitLab's BitSight rating was 530 (on a scale of 250-900) with documented vulnerabilities related to Compromised Systems and Application Security.

We began by validating our Digital Footprint - a list of IP addresses and domains that public DNS records associated with GitLab. By reviewing this list first, we were able to identify IPs that were no longer associated with GitLab and request they be removed. This increased our score.

Next, we created Environment tags and created 3 custom ratings for Production, Pre-Production, and User Managed IPs. This allowed us to “remove” findings associated with non-production (non-customer impacting) IPs. This increased our score significantly.

With a narrowed down list of targeted findings, we reviewed the findings and associated infrastructure and took action. By the end of September 2020 GitLab's BitSight rating was a 780 (on a scale of 250-900).

A critical step in our success was the implementation of a Third Party Security Rating process for identifying new findings, managing our score, and tracking observations through remediation. This included utilizing BitSight’s built in functionality for score monitoring and alerting as well as regular auditing of the Digital Footprint and Observation Management procedures to track resolution of identified findings. To see our Monthly Summary Report, visit our Customer Assurance Package.

Partnering with BitSight

We began this process by conducting research into some of the most common Third Party Security Ratings platforms and understanding how each sourced their information, validated their information, and assigned ratings to identified findings. This allowed us to identify the platform that best suited our needs and focus on improving that rating specifically.

For GitLab, it was critical that the platform has:

  • Alerting and visibility when our rating changes
  • Re-scan options for remediated findings
  • Ability to remove IPs/Domains that aren’t ours
  • Individual reports or ratings for different environments (ie- production vs non-production)
  • Integrations/APIs for ingestion of data into our monitoring tools
  • Alerting and Visibility when our third parties or competitor’s ratings changes
  • Simple and clear factors and scoring
  • Sufficient detail about the finding to validate and remediate

In the end we decided we would move forward with BitSight due to their simple and transparent factors and scoring, the ability to segment out different environments, and their ability to support multiple GitLab use cases. And while we recognize that there are many other ratings platforms out there, GitLab is committing to a collaborative partnership with BitSight to maintain a simple and transparent security rating that we all can be proud of. You can read more about our Third Party Security rating process and view our latest ratings reports in GitLab’s Customer Assurance Package.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert