Why is it bad to store keys and logins into my code?
A common problem in developing and deploying applications is that developers often unintentionally commit secrets and credentials into their remote repositories. If other programmers have access to the code, or if the project is available publicly, the sensitive information will be exposed. Malicious users can leverage such information to gain access to resources such as third-party accounts or deployment environments.
As such, developers must never store secret keys and logins in their codes. Fortunately, secret scanning capabilities can detect secret keys and credentials and inform you before anyone accesses them.
What is Secret Detection?
If your application communicates with an external service, a popular way to enable the connection is to use a private key or token for authentication. These credentials are examples of secrets issued by service providers.
Secret detection is a technique used to prevent leakage of sensitive information (called secrets), including login credentials, authentication tokens, and private keys. Secret detection works by scanning the entire source code for known patterns of secrets or credentials and reports the findings to the programmer.
To ensure compatibility across multiple languages, secret detection works by looking for regex patterns of common credentials like AWS tokens, API keys, and more [1]. Therefore, you can easily implement Secret Detection in virtually every language.
How to set up secret detection in GitLab
GitLab 11.9 includes a Static Application Security Testing (SAST) for secret detection. SAST scans for vulnerabilities such as Secret detection, SQL Injection, and Cross-site scripting [2]. The default rule set provided by Gitleaks includes the following key types: Cloud services, encryption key (SSH, DSA, PKCS8), social media APIs Keys, Cloud SaaS vendor API Keys, and password and Social Security numbers [3].
Another notable feature is that once secret information is detected, information such as the type of information and the location will be displayed. In cases where a project is shared among many developers, SAST enables the setting of approvers to verify and dismiss a vulnerability intentionally.
Secret Detection analyzer automatically ignores any password in the URL vulnerabilities if the password is preceded by a dollar sign ($) because it assumes that the password is an environment variable. For example, https://username:$password@example.com will not be detected, while https://username:password@example.com will raise be captured.
Setting up SAST in GitLab is relatively simple.
To enable Secret Detection for GitLab, you must
Copy the Security folder from the Gitlab template into your repository.
Add the following lines to your .gitlab-ci.yml file.
include:
- template: Security/Secret-Detection.gitlab-ci.yml
- template: Security/SAST.gitlab-ci.yml
secret_detection:
variables:
GIT_DEPTH: 100
SECRET_DETECTION_HISTORIC_SCAN: "true"
If you want to run Secret Detection jobs by default, you will require a GitLab Runner with a docker or Kubernetes executor. Luckily, if you are using shared runners on GitLab, that option is enabled by default.
How to set up secret detection in GitHub
Just like GitLab, GitHub also scans repositories for known secret formats. Secret scanning is performed by default on public repositories and can still be enabled by organization owners and repository administrators in private repositories. Service providers can also partner with GitHub and submit their secret formats to include in secret scanning.
With that, here is the step by step guide on setting up secret scanning in GitHub;
1. On your GitHub account, navigate to the repository's main page to activate secret scanning.
2. On the repository’s main page, click setting.
3. Click on security and analysis on the left bar.
4. If the GitHub Advanced Security option is disabled, click enable.
5. Click Enable GitHub Advanced Security for this repository.
6. By enabling GitHub Advanced Security, it may automatically enable secret scanning. However, if secret scanning is still disabled, click on enable.
Final Thoughts
It is common for programmers to store sensitive information such as API tokens and login credentials in source code. This practice can be very dangerous, especially in collaborated projects. If secrets land in the wrong hands, the consequences can be dire. Therefore, programmers must always be careful not to store any sensitive information in their code.
For additional security, it is recommended to enable secret detection. However, enabling secret detection is just as important as addressing them. In terms of the threat, a discovered secret is just as dangerous as an undiscovered one.
Want to Learn More about our Cybersecurity API?
HacWare makes it stupid easy for software developers to launch next generation cybersecurity education programs to combat phishing attacks with a few lines of code. To learn more about our powerful security awareness API and developer program, click here to apply .
Learn more about HacWare at hacware.com. If you are a Managed Security Service provider (MSSP) or IT professional, we would love to automate your security education services, click here to learn more about our partner program.