What do you keep in your Git repos? Source code for your production applications certainly, but you probably also keep a fair amount of experimental and “hackathon” code. Maybe you keep your documentation in Git. Maybe, like the District of Columbia does, you even keep legal documents there. So which of these are the most important to protect?
From the perspectives of access control and change management, clearly, they’re all vital. You might not want prying eyes seeing your internal documentation, and you certainly wouldn’t want them tampering with it. But what about from an application security perspective? There’s no source code in legal documents to analyze with static application security testing (SAST) tools. There are no supply chain dependencies in documentation to analyze with static code analysis (SCA). You might even be tempted to skip analyzing your hackathon repos on the notion that these never actually get deployed to customers. But there’s one critical vulnerability that undeniably affects all these repos: exposed secrets.
Secrets can get exposed anywhere. Production repos, hackathon repos, documentation repos, anywhere. There’s no guarantee that production secrets only get exposed in production repos. It’s just as easy to expose a production secret in a documentation repo as it is in your production main.
A great way to keep secrets out of all your repos is to use GitHub Advanced Security (to protect your GitHub repos) and GitHub Advanced Security for Azure DevOps (to protect your Azure DevOps Git repos). These solutions are natively built directly into GitHub and Azure DevOps, with nothing to install or maintain, and work in two ways to protect secrets:
- Automatic scans for secrets across all existing code in your repos–all historical commits across all branches, not just tip of main–and raise any findings in a Security Alert pane inside GitHub or Azure DevOps.
- Advanced Security also prevents committers from exposing secrets in the first place by analyzing incoming Git pushes, checking for exposed secrets, and rejecting the push if any secret is found so that no new secrets are added to the repo.
With repo-wide scanning of all branches, secret exposures can be easily and quickly remediated. And with push-time secret detection rejection, mitigating secret exposure requires only removing the secret from the commits and re-pushing, rather than revoking a newly-exposed credential that often involves tedious and fragile efforts.
Earlier this year, GitHub made Advanced Security secret scanning available for free for all public GitHub repos, which has prevented over 17,000 potential secret exposures. If you’re interested in learning more about how you can use GitHub Advanced Security to protect your own most important private repos–that is, all of them–please visit the GitHub Advanced Security page or sign up for the public preview of GitHub Advanced Security for Azure DevOps.
0 comments