Avoiding API keys in source code and repositories

Lesson 1 of this unit established why an API key must be treated as a high-value credential. This lesson focuses on the single most common way keys actually leak in practice: they end up committed to a source code repository. This is not a rare mistake — automated scanners run continuously against public GitHub repositories specifically looking for strings that match API key formats, and a key pushed to a public repo can be found and abused within minutes.

Why source code is a bad home for secrets

A hardcoded key looks convenient in the moment:

# DO NOT DO THIS
from openai import OpenAI

client = OpenAI(api_key="sk-proj-abc123examplekeydonotusethisformat")

This line works, and that is exactly the problem — it works well enough that it is tempting to leave in place "temporarily." But source code is designed to be shared, copied, and preserved:

• It is committed to version control, which keeps a permanent record of every version of every file, including ones you later "fix."
• It is often pushed to a remote host (GitHub, GitLab, Bitbucket), where it may be cloned, forked, mirrored, or indexed by search engines and bots.
• It is copied into new environments constantly — every git clone, every CI checkout, every teammate's laptop.

None of these are things you want a secret to inherit. A .env file or a secret manager entry (Lesson 3) is scoped to one machine or one deployment; a line in main.py is scoped to everywhere that repository ever goes.

The .gitignore pattern

The first line of defense is keeping secret-bearing files out of version control entirely. The standard pattern is:

1. Store secrets in a file that is not tracked by git — conventionally .env.
2. List that file in .gitignore so git refuses to track it even if someone runs git add ..
3. Commit a .env.example (or .env.sample) file that documents which variables are needed, with placeholder values, so teammates know what to create locally without ever seeing a real secret.

# .gitignore
.env
.env.*
!.env.example

# .env.example  (safe to commit)
OPENAI_API_KEY=your-api-key-here
OPENAI_PROJECT_ID=your-project-id-here

# .env  (never committed — this is the real one, local only)
OPENAI_API_KEY=sk-proj-REALVALUEHERE

The !.env.example line in .gitignore is a negation pattern: it says "even though .env.* is ignored, make an exception for .env.example." This lets you version-control the shape of your configuration without ever version-controlling the values.

Your Python code then loads the real file at runtime (see Lesson 3 for the full python-dotenv pattern), while git never sees its contents.

Detecting secrets before they are committed

.gitignore only protects files that are never staged in the first place. It does nothing if a key is pasted directly into a tracked .py, .json, or .yaml file. For that, use a pre-commit secret scanner — a tool that inspects staged changes and blocks the commit if something that looks like a credential is found.

A minimal version of the idea, implemented as a standalone check you could wire into a pre-commit hook or CI step, looks like this:

import re

# Patterns that plausibly match common secret formats.
SECRET_PATTERNS = [
    re.compile(r"sk-[A-Za-z0-9]{20,}"),          # OpenAI-style API keys
    re.compile(r"AKIA[0-9A-Z]{16}"),              # AWS access key IDs
    re.compile(r"-----BEGIN (RSA|EC|DSA)? ?PRIVATE KEY-----"),
]


def find_suspected_secrets(file_content: str) -> list[str]:
    """Return any substrings in file_content that look like secrets."""
    findings = []
    for pattern in SECRET_PATTERNS:
        findings.extend(match.group(0) for match in pattern.finditer(file_content))
    return findings


def check_files_for_secrets(files: dict[str, str]) -> dict[str, list[str]]:
    """
    files: mapping of filename -> file content (as would be staged for commit).
    Returns a mapping of filename -> list of suspected secrets found, for
    files where at least one match was found.
    """
    problems = {}
    for filename, content in files.items():
        findings = find_suspected_secrets(content)
        if findings:
            problems[filename] = findings
    return problems

This is intentionally simplified — production tools like detect-secrets, gitleaks, or truffleHog use a much larger and better-maintained set of patterns, entropy analysis (flagging high-randomness strings even without a known prefix), and historical scanning across the whole git log. But the shape of the check is the same: pattern-match staged content against known secret formats and refuse the commit if something matches.

A dependency-injected test, with no real files or real secrets touched:

def test_detects_openai_style_key():
    files = {
        "config.py": 'API_KEY = "sk-proj-abcdefghijklmnopqrstuvwxyz123456"',
        "readme.md": "This project uses the OpenAI SDK.",
    }
    problems = check_files_for_secrets(files)
    assert "config.py" in problems
    assert "readme.md" not in problems
    print("PASS: secret scanner flags the file containing a key-like string")


def test_clean_files_pass():
    files = {"app.py": "import os\napi_key = os.environ['OPENAI_API_KEY']"}
    problems = check_files_for_secrets(files)
    assert problems == {}
    print("PASS: scanner does not flag code that reads from the environment")


test_detects_openai_style_key()
test_clean_files_pass()

The second test matters as much as the first: a scanner that also flags legitimate, secret-free code (reading from os.environ) is not useful, because developers will learn to ignore or bypass it.

If a key is already committed: revoke first, scrub second

This is the point most teams get wrong. When a key is discovered in a repository's history, the instinct is to remove it from the code and rewrite git history to erase it. History rewriting is useful, but it is not the fix — it is cleanup.

The only action that actually stops the exposure is revoking the key in the OpenAI dashboard and issuing a new one. Once a secret has been pushed to a remote repository — especially a public one, or even a private one with more than a couple of collaborators — you must assume it has been seen, cloned, cached, or indexed somewhere outside your control. Rewriting history on your own copy of the repository does not reach any of those other copies.

The practical order of operations is:

1. Revoke the exposed key immediately in the OpenAI dashboard and generate a replacement.
2. Update every environment (local .env files, CI secrets, production secret manager) with the new key.
3. Remove the secret from the current code so the mistake isn't repeated in the next commit.
4. Optionally, scrub git history with a tool like git filter-repo (the modern replacement for the older BFG Repo-Cleaner / git filter-branch approaches) if you want the string gone from the repository's history for hygiene or compliance reasons.

Note on history scrubbing: Rewriting history changes every commit hash after the rewritten commit. Anyone with an existing clone will need to re-clone or carefully re-base their work, and any open pull requests referencing the old commits will likely need to be recreated. Coordinate with your team before doing this, and never treat it as a substitute for revocation — a scrubbed-but-not-revoked key is still a valid, working credential.

Common Mistakes

• Believing that deleting a file in a later commit removes the secret. Git preserves every prior version in its history by default; the key is still retrievable with git log -p or by checking out the earlier commit, even after a "fix" commit removes it from the latest version.
• Committing to a private repository and assuming that makes it safe. Private repositories are still cloned by teammates, mirrored by CI systems, and sometimes accidentally made public later. Treat every repository, private or not, as a place secrets do not belong.
• Scrubbing history without rotating the key. As covered above, this leaves a fully functional credential in place while giving a false sense of resolution.

Best Practices

• Add secret-bearing filenames to .gitignore before creating the files, not after, so there is never a window where the real file could be accidentally staged.
• Run an automated secret scanner as a pre-commit hook and in CI, so a leak is caught before it reaches the remote repository, not after.
• Commit an .env.example file so new contributors know what configuration is required without ever needing to see or copy a real secret.
• Treat any leaked key as compromised the moment it is pushed, and revoke it immediately rather than waiting to assess whether anyone actually saw it.