A secret that reaches git is already compromised

The moment that matters

The moment that matters isn't when someone finds a hardcoded API key in a repository. It's git commit, the instant a literal secret value gets written into a commit object. Everything after that, a teammate cloning the repo, a CI runner checking it out, a public fork, is a different way of discovering damage already done. This course is about catching the problem at the one moment it's still preventable, before that commit.

What this app already gets right

Two entries in this project's .gitignore exist to keep secrets out of that first commit:

/.env*

# Ignore master key for decrypting credentials and more.
/config/master.key

config/master.key decrypts config/credentials.yml.enc, this app's encrypted store for secrets; without the key file, the encrypted file is useless to anyone who clones the repo. .env* covers any local environment file a developer uses for per-machine values. Checked against this repository's tracked files (git ls-files), neither config/master.key nor any .env* file is tracked, so the rule has held in practice.

Why a .gitignore line isn't the whole story

A .gitignore entry only stops a file someone named in advance as sensitive. It does nothing about a secret typed into a line of Ruby, JavaScript or YAML in some other file, a value like API_KEY = "sk-live-abc123..." sitting in an ordinary, trackable file. That kind of secret has no filename to block, because the file it lives in is supposed to be tracked. Catching it takes something that reads a file's content as well as its name. That's the gap a secret detector, human or automated, exists to fill.

Where AI fits into this

An AI coding assistant reviewing a diff before it's committed can be asked one narrow question: does anything in this diff look like a credential typed in as a literal value? That's a more mechanical task than "review this code for bugs", closer to a pattern check than a judgment call. "AI prompting: zero-shot Ruby" showed that a narrow, well-specified question gets a more reliable answer than a vague one.

What this course covers

1. What a hardcoded secret looks like to a detector: name signals and value shape together.
2. Where a secret should live instead, using this app's two idiomatic patterns.
3. Why false positives are the hardest part of building a detector worth trusting.
4. Asking an AI to review a diff for secrets, a narrower question than a general code review.
5. What has to happen once a secret is already committed, since deleting it later isn't enough.
6. A small regex-based detector, built and checked by hand.

By the end, "does this line hardcode a secret" becomes a specific, checkable question with a mechanical answer, instead of a hopeful guess made after the fact.