How to Detect Secret Credentials in your GitHub Repository?

How to Detect Secret Credentials in your GitHub Repository?

All of us have, at some point, accidentally committed a password or API key that should not have been pushed. Once that is done, we all know what GitHub has to say about it.

Warning: Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised. If you committed a password, change it! If you committed a key, generate a new one.

If your repository was private you are somewhat secure from the general public. But if it was public, your premium Shutterstock account is being used by some student for his graduation project. You better hope he gets an A. At least, for searching “Shutterstock auth token” in GitHub search. You can try it out and see for yourself how many premium keys are out there for free and this is just the tip of the iceberg. What if some dummy had committed his AWS_SECRET_KEY or RDS access URLs?

The Solution

Of course, none of us want to be in this position. So there are mainly two tiny steps I take to ensure that my repository…

  1. Stays free of any sensitive credentials (Even in commit history)

  2. Prevents commits containing sensitive credentials.

For this I use GitGuardian. An easy-to-setup and flexible service (with a good dashboard!) to keep all my repositories in check.

Why GitGuardian?

I needed a one-stop solution that clears my past mistakes as well as future-proofs me. That too, easily! So I expected these 4 features to be present which they did.

  • CLI support

  • Historical scans

  • Pre-commit hooks

  • GitHub actions

Setting Up

Integrating GitGuardian is pretty simple. You can log in using GitHub OAuth which will allow you to select repositories for monitoring. You can read more about this on their official docs.

Historical Scans

After selecting your repositories, you can initiate Historical scans on them to check what credentials you have committed in the past.

Now, if you did find sensitive creds in your repository (which is highly likely), I would suggest reading GitHub’s official solution to this. It suggests truncating your repository’s history after removing/recycling all your secrets but I feel it still does not hide previous commits. The cleanest solution I found is to clone and push your repository under a different name.

Future Proofing

Pre-commit hook

There could always be someone who will accidentally commit changes with some sensitive credentials. For this, we should always integrate GitGuardian as a pre-commit hook so that such data is never committed in the first place. This is what you should have in your .git/hooks/pre-commit file.

#!/bin/bash
ggshield scan pre-commit

GitHub action

Even after a pre-commit hook, someone will use the -n flag during commit which again puts us in a tight spot if that commit did contain something sensitive. To counter this, we have to set up a GitGuardian action on our repository, so that we can at least catch these during pull request checks. This is what a simple GitGuardian action check looks like. You can put this in .github/workflows/gitguardian.yml

name: GitGuardian scan

on: [push, pull_request]

jobs:
  scanning:
    name: GitGuardian scan
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: GitGuardian scan
        uses: GitGuardian/gg-shield-action@master
        env:
          GITHUB_PUSH_BEFORE_SHA: ${{ github.event.before }}
          GITHUB_PUSH_BASE_SHA: ${{ github.event.base }}
          GITHUB_PULL_BASE_SHA: ${{ github.event.pull_request.base.sha }}
          GITHUB_DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
          GITGUARDIAN_API_KEY: ${{ secrets.GITGUARDIAN_API_KEY }}

Make sure to add GITGUARDIAN_API_KEY in your repository secrets.

GitGuardian Dashboard

GitGuardian also provides a neat dashboard where you can check all your commits and pull requests. You can assign, resolve, ignore issues, and even re-initiate Historical scans. Take some time to explore it!

Conclusion

I feel, all these steps are the bare minimum if want basic protection for your team against committing sensitive info to your repositories. After all, it takes only 5 minutes, so it feels silly not doing it.

Thanks for reading ✨

Originally published at arrayofcode.com. Revised for accuracy and brevity.

Did you find this article valuable?

Support Aditya Krishnan's Blog by becoming a sponsor. Any amount is appreciated!