Recently, one of the friends from Konabos (kudos to Wojciech Tokarzewski) shared an interesting article (https://securityaffairs.com/158306/data-breach/mercedes-benz-data-leak.html or https://redhuntlabs.com/blog/mercedes-benz-source-code-at-risk-github-token-mishap-sparks-major-security-concerns/ ) about the security breach that Mercedes-Benz company encountered a few weeks ago. Long story short, Mercedes’ development team added authorization private key in the public GitHub repository and with that key everyone could access data in the internal Mercedes’s GitHub Enterprise Server. It is easy to imagine how much information could be extracted from there.  

Many of you may think that the code review should solve the issue. But what if you work in an enterprise-size company with multiple teams working independently? Teams consist of hundreds of people with different levels of expertise and are not always conscious of security risks.  

Mistakes like that can happen to everyone – so how to avoid a security breach like that?  

GitHub’s secret scanning

 If you are using GitHub, you can also use secret scanning mechanism ( https://docs.github.com/en/code-security/secret-scanning ) that will search for tokens, private keys and other secrets in the code and titles, descriptions, comments of your issues, pull requests, or other discussions.  

As GitHub informs that this mechanism is always enabled for public repositories and npm packages of GitHub’s partners.  

Secret scanning is also available for free on all public repositories.  

If you use GitHub Enterprise Cloud with GitHub Advanced Security license you can also enable secret scanning on the private and internal repositories.  

Secret scanning sounds very serious, but what does it do in fact? To answer that you need to look at the diagram (modified version of the diagram shared by GitHub documentation):  

As you can see when the changes are added to GitHub it triggers the scan which seems to be a regex expression verifying what the changes contain. The mechanism is looking for the tokens that are usually used during the development process and implementing integrations with external services.  

The list of supported by default patterns is here: https://docs.github.com/en/code-security/secret-scanning/secret-scanning-patterns#supported-secrets 

Usually when scan finds a secret that should not be stored in the repository can: 

• Block the push 
• Inform administrators and users via email 
• Show notifications 

You can also customize the security scan by adding there more tokens and rules but this is a material for a separate article. (https://resources.github.com/learn/pathways/security/essentials/application-security-testing-github-advanced-security/) 

This briefly describes what you can do with GitHub but will not help you when you store your repositories within other providers. 

Gitleaks

Gitleaks is an open-source tool that works in a way very similar to GitHub’s security checks. The difference is that you can: 

• Add it as GitHub action 
• Configure it to work as a precommit-hook (locally) 
• Run it with the CLI commands (locally or on the CI/CD servers) 

It opens new configuration options and allows you to become more creative with the way you are going to secure your code base. You are no longer limited to GitHub’s policies.  

Gitleaks also uses regex expressions to verify if code contains secrets. The full list of the default checks is available in the source code:  
https://github.com/gitleaks/gitleaks/blob/master/config/gitleaks.toml 

https://github.com/gitleaks/gitleaks/tree/master/cmd/generate/config/rules 

You can extend the list by adding your custom rules. 

What is good to note at this point is that Gitleaks does not run checks on the comments, discussions, PRs as GitHub does. So, usage of these two tools in parallel seems to be not such a bad idea.  

Gitleaks is free for personal use. It is also free for commercial use. The difference is that when you are planning to use it at your organization, you should request a free license.  

Summary 

No matter which option you select (maybe you decide to use both) or if you find any other interesting option (please add it in the comments section) it is important to be conscious of the risk coming with the leaks of authorization data. In the case of the Mercedes-Benz, it probably finished luckily only with some noise. Other companies did not have so much luck in the past and were losing sensitive data and the trust of the customers. Let’s hope that no one will mention us in the context of problems like that but also let’s do everything possible to be prepared.