As part of the ongoing effort to secure TuneIn's GitHub repos to prevent another occurrence similar to what happened with CodeCov, we will be implementing a scan that runs on PRs opened to the primary branch of each repo. The code for the PR will be checked out and the cli tool gitleaks will be run against it. If there are findings, the failed check will show on the "Conversation" tab of the PR. In order for all checks against an open PR to succeed, the PR must not contain sensitive keys.
What do I do if my PR check fails?
If you have mistakenly checked in a secret to git as part of your PR, you should remove it promptly.
Git reset to the commit prior to the secret being added to source control
Edit the file(s) containing secrets to remove them
Author a new commit containing the fix as well as your other work
Force-push the new commit history to git
The force push is essential to ensure that the secret is not only removed from the most recent commit but from the history as well. After performing this sequence of steps, the automated scan on your PR will pass.
Help! The scan says I have checked in secrets but it's a false positive.
Every repo's scanning rules are customizable. Refer to the Custom Rules section below for en explanation of the syntax to add the path containing a false positive to the allowlist. Exercise caution when findings are added to the allowlist to ensure that the findings are not genuine. Entries in the allowlist will not appear on subsequent scans.
What about tokens that my team regularly works with that are not picked up by the default scan rules?
You can add custom rules to your config that meet the needs of your team. Rules are picked up by scanning files with a list of regular expressions. Write a regex for the types of tokens that your app interacts with and add it to your custom config file.
Custom Rules
Custom rules for your repo should live in the file .github/gitleaks.toml. See examples below for some available customizations or, refer to the documentation for gitleaks for more complete examples.
If your team is already using a strategy to prevent checking secrets into source control, continue to utilize that going forward. If you are in search of a solution, the strategies below are being utilized in teams at TuneIn already. Reach out to #devops if you need assistance with getting one of these solutions in place.
Automated Scanning of Pull Requests for API Keys
As part of the ongoing effort to secure TuneIn's GitHub repos to prevent another occurrence similar to what happened with CodeCov, we will be implementing a scan that runs on PRs opened to the primary branch of each repo. The code for the PR will be checked out and the cli tool
gitleakswill be run against it. If there are findings, the failed check will show on the "Conversation" tab of the PR. In order for all checks against an open PR to succeed, the PR must not contain sensitive keys.What do I do if my PR check fails?
If you have mistakenly checked in a secret to git as part of your PR, you should remove it promptly.
The force push is essential to ensure that the secret is not only removed from the most recent commit but from the history as well. After performing this sequence of steps, the automated scan on your PR will pass.
Help! The scan says I have checked in secrets but it's a false positive.
Every repo's scanning rules are customizable. Refer to the Custom Rules section below for en explanation of the syntax to add the path containing a false positive to the
allowlist. Exercise caution when findings are added to theallowlistto ensure that the findings are not genuine. Entries in theallowlistwill not appear on subsequent scans.What about tokens that my team regularly works with that are not picked up by the default scan rules?
You can add custom rules to your config that meet the needs of your team. Rules are picked up by scanning files with a list of regular expressions. Write a regex for the types of tokens that your app interacts with and add it to your custom config file.
Custom Rules
Custom rules for your repo should live in the file
.github/gitleaks.toml. See examples below for some available customizations or, refer to the documentation forgitleaksfor more complete examples.Adding a path to the
allowlistAdding a custom rule
Alternatives to Secrets in Git
If your team is already using a strategy to prevent checking secrets into source control, continue to utilize that going forward. If you are in search of a solution, the strategies below are being utilized in teams at TuneIn already. Reach out to #devops if you need assistance with getting one of these solutions in place.