In this post we’ll be talking about an explanation to a previous post regarding exposed repositories via version control platforms. This will be related to use of self-hosted product of the cloud-hosted platform.

First, let’s do a quick recap. The use of public repositories is good, which is a good way to collaborate. However, there must be some verification before there is a commit made, as the code getting committed could potentially contain information which may have been needed in development but wasn’t meant to be included within the commit. This information could be easily searchable via the platform search function.

Ultimately, this situation can happen even on a cloud platform, which requires no maintenance from the company hosting their code on it. GitLab, another version control platform, provides a self-host version of their product for usage internally. Being self-hosted, this requires the implementation and configuration needed to ensure it is setup and accessible for any authorised users.

The use of this internally and not public facing could slightly decrease the risk of an issue occurring but could be reversed if this was publicly accessible. The self-host version control is chosen for the protection of Intellectual Property (IP), as this is usually a company’s most precious asset (data-wise). However, having repositories publicly accessible and misconfigured could have far more consequences.

An example of this is when a security researcher discovered some exposed files via a development lab used by Samsung engineers. The reason for this was due to an exposed GitLab instance which wasn’t adequately protected.

Although the reason around the use of self-hosted products can be debated, their use will allow the code to stay within the company itself. However, not ensuring that all checks and balances have been carried out and have been set up correctly could lead to potential issues.