Don’t Let Hardcoded Secrets Compromise Your Security: 4 Effective Remediation Techniques

Hardcoded secrets in your code are a security risk. If these secrets are accidentally made public, malicious actors could exploit them and gain unauthorized access to your system. In this blog post, we discuss how to remediate hardcoded secrets at different stages of development, from pre-commit to remote code base.

1. Remediation at the Pre-Commit Stage

A pre-commit hook is a tool that automatically checks code before it is committed to version control. It helps catch errors early in the development process and ensures consistent code formatting and style.

When hardcoded secrets are detected at the pre-commit stage, it means that they were found locally and have not been committed yet. In this case, remediate the issue by using the following steps:

1. Remove the secret from the code.
2. Try to commit the code again.
   

2. Remediation at the Pre-Receive Stage

1. Use git log to determine which commit surfaced by the push error that came first in history. Most of the time, you will get the commit id in the pre-receive response (attach screen-shot)
2. Start an interactive rebase with git rebase -i <commit-id>~1. This is the id of the commit from step 1.
3. Identify your commit to edit by changing pick to edit on the first line of the text that appears in the editor.
4. Remove the secret from your code.
5. Commit the change with git commit --amend.
6. Run git rebase --continue to finish the rebase.

Reference: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

After following the above commands, you can push your code again (hopefully this time without any secrets).A pre-receive hook is a script that runs on the server. It performs checks on the content of the push. It helps catch errors before the commits are saved in the remote repository.

If the hardcoded secret is detected at the pre-receive stage, it means that it was blocked before it was committed to the remote repository. However, you still need to rewrite your history to push your code. Here are the steps to remediate the issue: 

1. Remove the secret from your code.
2. Commit the changes by using git commit --amend.
3. Push your changes with git push.

You can also remove the secret if the secret appears in an earlier commit in the Git history.

3. Remediation at the Pull Request Stage

Pull requests are a standard development procedure where other team members review changes made to a codebase by one developer before being merged into the main branches.

If the hardcoded secret is committed to a pull request of your remote repository, it means that it is visible to everyone who has access to the repository. 

The good news is that the secret is probably inactive in a production environment, and you can revoke it.

The best way to remediate the issue is to revoke the secret, but it’s not always possible. Here are the steps:

1. Make sure that no other modules or services are using the same secret before revoking it. Because once the secret is revoked, there is no way back
2. If the secret is being used already, you either need to rotate it in all the places where the secret is being used or rewrite your commit history.
3. Delete the secret from your code and commit the changes 

You have 2 options:

1. Squash and merge –  Squash and merge is a feature in version control systems such as Git that allows multiple commits to be combined into a single commit before being merged into the main branch. This can help to remove the secret from the commit history. Don’t forget to delete your branch after removing all the evidence.
2. Rewrite your commit history – Choose this way if you want to keep your commit history. Here’s an example of how to rewrite your commit history in Git:

• If the secret is in the last commit, you can delete it from your code and use git amend to remove the secret from your git history – git add [FILENAME] && git commit --amend
• If the secret is deeper in your commit history:
  • And you don’t care about your local commit tree:
    • Run git reset --soft HEAD^N (when N is the number of commits to reset)
    • Remove the secret and commit your changes
  • You do care about your local git commit history:
    • If the secret is an entire file that you want to remove, git filter-repo --use-base-name --path [FILENAME] --invert-paths
    • If the secret is a text within a file, use the following git filter-repo --replace-text ../replacements.txt [--force]

Reference: https://github.com/newren/git-filter-repo/blob/main/Documentation/git-filter-repo.txt 

4. Remediation for a Secret That Has Already Been Recorded in Your Remote Repository History

If the hardcoded secret is found during monitoring, it means that it’s probably being used in a production environment. Here are the steps to remediate the issue:

1. Find all the places where the secret is being used.
2. Rotate the secret in all these places.
3. If it’s impossible to rotate the secret, rewrite the commit history to remove it and reduce exposure.

Important: If a secret is detected in a public repository, you must revoke it immediately.

Conclusion

Hardcoded secrets in your code can be a serious security risk. However, by following the steps outlined above, you can remediate these issues at different stages of development, from pre-commit to monitoring. By being proactive and diligent, you can keep your code secure and your systems safe from unauthorized access.