At Number Three of the Open Source Intelligence Top Ten (aka OSINT Top Ten) is Sensitive Code Exposure.

Online code repositories such as GitHub have grown to become standard solutions for version control and source code management. These solutions have proven to be easy-to-use but also prone to misconfigurations leading to the exposure of sensitive information (specifically sensitive code).

Many of these online code repository solutions provide the capability to secure private and public repositories.  Do your public repositories have sensitive information in them? 

Do you know what kind of information is obtainable within the code? Is the information that is available aligned with your organization’s expectations and policies? 

It is vital to take an inventory of both Public and Private repositories associated with your organization. With Public repositories being out in the open, it is even more important to see if what code your organization has committed is considered sensitive (i.e., Passwords, configuration files, keys, etc.).

As mentioned earlier, it is straightforward to deploy code to a sharing repository. Anyone can do it and even impersonate your organization in some way. Claiming your organization’s ‘sanctioned’ repository will help shield your image/brand from incorrect code commits/styles/exposures.

Private repositories should also be combed through for secrets and other sensitive files before being pushed to any public-facing environment.

Proper training for secure coding (what not to push to public repositories), monitoring public repositories for the company, vendors, and employees is critical. It is also essential to invest in adequately monitoring and securing these repositories (training, people, security monitoring). Data leaks on this front (or any front) can lead to a security breach/incident, leading to even more costs.