GitHub repositories are treasure troves for attackers searching for credentials. API keys, database passwords, AWS access keys, authentication tokens, and encryption keys regularly get committed to repositories—sometimes visible to the entire public internet, sometimes hidden in commit history that only someone with repository access can see. The scary part is how common this is and how long credentials stay exposed. A developer checks in a configuration file "temporarily," it gets noticed weeks later, and by then an attacker might have already used the exposed credentials to access your systems. This guide walks through how credentials get exposed, what attackers do with them, and how to implement secret scanning to prevent this critical security vulnerability.

How Credentials End Up in GitHub

Developers commit secrets to GitHub through a combination of carelessness, automation, and misunderstanding of what's safe to commit. The most common scenario: a developer creates a configuration file locally with real credentials (database password, API key) for testing, then commits it "temporarily" with a plan to remove it later. That plan gets forgotten, the credentials are now in git history, and weeks or months later someone notices.

Automated tooling makes this worse. CI/CD systems sometimes export credentials as environment variables, logging tools sometimes capture configuration files, and infrastructure-as-code systems sometimes require credentials in config files. A developer might check in a deployment script that includes credentials, a Terraform file with API keys, a Docker Compose file with database passwords, or a package.json file that references a private npm registry with authentication tokens.

The false sense of security for "private" repositories makes it worse. A developer might think "this is a private repository, it's fine to commit credentials here." But private repositories are often accessed by many people—contractors, ex-employees, service integrations, former collaborators. Even if no one accesses it today, there's always a risk: someone's GitHub account gets compromised, a contractor's access never gets revoked, or the repository gets accidentally made public. Credentials in git history are essentially permanent—they can be retrieved even after the file is deleted or the commit is removed.

Once credentials are in GitHub, attackers find them through multiple methods: GitHub search queries for common patterns (AWS, database password, API key), scanning tools that crawl GitHub's API looking for credentials, scraping GitHub repositories for companies they're targeting, monitoring GitHub for new repositories containing credentials, and searching commit history when they gain access to a repository. This all happens automatically and continuously.

What Attackers Do With Exposed Credentials

Exposed AWS access keys give attackers full access to your cloud infrastructure. They can spin up instances, access your database, read files from your storage buckets, and run code in your environment. The AWS bill alone—for resources the attacker spun up—can reach thousands of dollars before you notice. Exposed database passwords let attackers connect directly to your database and copy all customer data. Exposed API keys and authentication tokens let attackers impersonate your application, call your own APIs, and perform actions on behalf of your service.

The most dangerous aspect: you often don't realize credentials were exposed until an attacker has already used them. Attackers don't immediately announce themselves. They might silently exfiltrate your database, harvest API keys for other services, or wait months before using the credentials when you're least expecting it. By the time you detect the breach, significant damage might already be done.

Exposed credentials from one service can cascade into compromises of other services. An exposed GitHub token might give attackers access to your entire codebase, where they'll look for more credentials in config files, environment files, or API integrations. Exposed AWS keys might lead to database access. Exposed database credentials might lead to application compromise. One credential exposure often leads to full infrastructure compromise.

Implementing Secret Scanning to Prevent Exposure

Modern secret scanning tools automatically detect credentials being committed to repositories and prevent the commit from completing. GitHub's built-in secret scanning (available on all public repositories and paid private repositories) scans for known credential patterns: AWS access keys, database connection strings, private keys, and API tokens.

Enable GitHub secret scanning for all your repositories. For public repositories, it's free and automatic. For private repositories, enable it in your repository settings (Settings > Security > Secret scanning > Enable for this repository). When scanning detects a credential, it immediately alerts you and invalidates the credential with the service provider (GitHub works with AWS, Stripe, and others to automatically revoke exposed credentials).

Configure branch protection rules to require all commits to pass security checks before being merged. This prevents commits with detected secrets from reaching your main branch. In your repository settings, go to Branches > Branch protection rules, enable "Require status checks to pass before merging," and select the security scanning checks.

Use pre-commit hooks to block commits containing credentials before they even reach GitHub. Tools like TruffleHog, Detect-Secrets, or git-secrets integrate into your local git workflow and scan commits for credential patterns before allowing them. Developers see an error message: "Commit blocked: potential secret detected" and must fix the commit before proceeding.

Install TruffleHog as a pre-commit hook: pip install trufflehog, then configure .git/hooks/pre-commit to run trufflehog scan git. This scans every commit for credential patterns before the commit is recorded. The first time a developer hits this, they'll be surprised—and they'll stop accidentally committing credentials.

Auditing Existing Repositories for Exposed Credentials

Run secret scanning against your existing repositories immediately. Even if you enable scanning going forward, you likely have committed credentials in historical commits. Use TruffleHog to scan all your GitHub repositories: trufflehog github --org yourorganization. This will find any credentials in commit history across all repositories.

For each credential found: immediately rotate or revoke it. Contact the service provider and request a new credential. If it's an AWS access key, delete the old key. If it's a database password, change it. If it's an API token, generate a new one and revoke the old one. Don't just assume no one found the credential—assume the worst and rotate. If the credential is in commit history going back months or years, there's a high probability an attacker has already found and used it.

After rotating credentials, clean up the git history. Simply deleting the file from the latest commit isn't enough—the credential is still in git history. Use BFG Repo-Cleaner or git-filter-branch to remove the credential from the entire history. After cleaning, force-push to all branches. This is disruptive (every developer will need to re-clone), but necessary if the credential was widely accessible.

Implement a policy: credentials are never committed, ever. For local testing, use .env files and add them to .gitignore. For CI/CD, use environment variables or secrets management. For configuration management, use tools like HashiCorp Vault or AWS Secrets Manager that keep credentials out of code entirely. Train your team that if they see a credential in code, it's an emergency—immediately rotate the credential and clean it from history.

Secrets Management: The Right Way

As you grow, implement a secrets management system to keep credentials out of repositories entirely. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager centralize credential management. Your application retrieves credentials from the secrets manager at runtime rather than reading them from configuration files or environment variables.

For immediate improvement with minimal setup, use environment variables: store credentials in your deployment environment and inject them into your application at runtime. Your code never contains credentials—they're only in your production environment. CI/CD systems can safely store encrypted secrets and inject them during deployment.

GitHub secrets leaked from developer carelessness is entirely preventable. It requires technical controls (secret scanning, pre-commit hooks) and process discipline (no credentials in code, secrets management system). The tools are free or cheap, the implementation is straightforward, and the alternative—a credential exposure leading to infrastructure compromise—is catastrophic.

RedRadar can scan your GitHub repositories for exposed credentials, help you implement secret scanning and pre-commit hooks, and design a secrets management system that keeps credentials out of your codebase entirely.