This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed devops secure -

GitLab Secret Detection ADR 002: Store the Secret Detection Gem in the same repository


During Phase 1, we opted for using the Ruby-based push check approach to block secrets from being committed to a repository, and as such the scanning of secrets was performed by a library (or a Ruby gem) developed internally within GitLab for this specific purpose.

Part of the process to create this library and make it available for use within the Rails monolith, we had to make a decision on the best way to distribute the library.


We evaluated two possible approaches:

  1. Store the library in the same repository as the monolith.
  2. Store the library in an external repository.

Each approach came with some advantages and disadvantages, mostly around distribution, consistency, maintainability, and the overhead of having to set up review and release workflows and similar processes. See below for more information.

Within the same repository as the monolith

Having the gem developed and stored in the same repository meant having it packaged within GitLab monolith itself, and with that ensuring it does not have to be installed as a dependency. This would also reduce maintainability overhead in terms of defining workflows and processes from scratch. On the other hand, the library would have less visibility as it is not exposed or published to the wider community.

In an external repository

Storing the library in an external repository meant having more visibility especially as the gem would be published on, which would have garnered more interest and possibly contributions from the community into the feature. Additionally, the gem would be available to be used in other projects and applications. However, in doing so, the maintainability overhead would have increased signficantly for various reasons such as:

  • Changes would need to be coordinated between multiple repositories when a new version is released.
  • Review and release workflows, and similar processes would need to be defined separately.


The decision was made to store the library in the same repository during the first phase to ensure easier distribution since it’s packaged within GitLab and will be available immediately without having to install external dependencies.

With that said, we still followed the process to reserve the gem on to avoid name-squatters from taking over the name and providing malicious code to 3rd-parties.

We have no plans to publish the gem externally at least until Phase 2 as we begin to consider building a standalone service to perform secret detection.