ACM.427 Reviewing code before it enters your GitHub repositories
⚙️ Part of my series on Automation of cybersecurity measures. THE Coded.
🔒 Related Stories: GitHub and code commit security | Application security
💻 Free content on Cybersecurity Jobs | ✉️ Register for Broadcast list
In the last article in this series, I explained where your TLS certificates end up at the time of this writing when using a “trusted enclave” on AWS.
It’s a new year and I’m doing random tasks, so you’re going to have a bunch of random stories before I get back to what I was doing. I need to clean up the code and repositories as I embark on new adventures for the year. I kept promising to save my code and finally get there. Before I do this, I’d like to make sure there are no secrets in my code.
One thing I can do to globally check values in files in a directory on a Linux machine would be to use grep like this:
grep -r 'mysecret' .
It works to some extent. If I want to replace all instances of this value in files in a directory, I can use this command:
find . -type f -exec sed -i 's/mysecret/xxxxxxx/g' {} +
This is fine, but you have to remember to do this every time before you check in and test out any variations of secrets you might want to replace. The other thing is that you may have saved a secret in your git history and then deleted it later. This value will always be in your git history.
One way to check secrets every time you check in your code, and according to the documentation, check your git history, is to use git-secrets. This is a tool from AWS Labs that tries to help you keep secrets and sensitive data out of GitHub. It adds pre-commit hooks to prevent certain data from reaching GitHub as configured in default templates or custom rules you create.