You ever notice how the last line of defense is always the most neglected? Like how people will install a fancy security system but leave the back door propped open with a rock.
That is an extremely specific analogy.
I spent three hours once watching a guy install biometric locks on his shed while his wallet was sitting on a folding chair next to him, unguarded.
Is this a real story?
It is now. Today's prompt from Daniel is about Git pre-commit hooks, specifically for solo developers thinking about security and PII scanning. And honestly, given how much code AI assistants are spitting out these days, this topic could not be timelier. Fun fact, this episode's script is being generated by MiniMax M2.7, so if it goes off the rails, take it up with them.
I will note that MiniMax M2.7 has been remarkably well-behaved so far.
Don't jinx it. So look, most developers treat git commit as a formality. You run your tests, you write some code, you type git commit, and you assume whatever you've done is fine. The commit is your last chance to catch something before it enters the permanent record. And yet most solo devs I know have zero hooks configured. Zero. It's like being a doctor who doesn't wash their hands because, you know, they trust themselves.
The thing is, git hooks are not new. They've been around since the early days of Git. But the tooling has gotten so much better in recent years that there's really no excuse anymore. The pre-commit framework alone has over two hundred ready-made hooks covering fifty plus languages. We're not talking about writing shell scripts in the dark anymore.
Right, but here's the thing most people don't realize. Git hooks are actually dead simple at their core. You go into your .git directory, there's a hooks folder, and Git ships with sample scripts for every hook point. Pre-commit, pre-push, commit-msg, post-commit. All you have to do is remove the .sample extension and make them executable.
And that's exactly where most tutorials stop. They tell you to write a bash script and call it a day. And that's fine for one-off stuff, but what happens when you want to share those hooks across multiple projects? Or when your hook gets complex enough that debugging it becomes its own nightmare?
Which is where the pre-commit framework comes in. Instead of writing custom shell scripts, you write a YAML file that defines your hooks, and the framework handles the execution, the environment, all of it.
And the beauty is that you can pin specific versions of hooks so you're not at the mercy of whatever breaking change lands in a new release. You want commit number forty-seven of the detect-secrets hook? Done. Your CI pipeline will thank you.
Okay, but let's get concrete. What does this actually prevent? Because I think people hear security hooks and they imagine some hyper-specific enterprise scenario that doesn't apply to them.
The most common failure mode is API keys. You paste a curl command from your terminal into a test file to debug something. That curl command has your API key embedded in it. You commit the file, push to GitHub, and thirty seconds later someone's already scraping your key. This happens constantly. GitHub's secret scanning now blocks over one hundred thousand secrets per day from being pushed to public repos. And that's just the public repos they catch.
That's a hundred thousand in a single day.
In a single day. The vast majority of those are probably individual developers who just made a mistake. They didn't mean to expose their AWS credentials or their Stripe API key. They were moving fast, testing something, and forgot to clean up.
And AI coding assistants have made this worse, right? Because now you've got a system that's generating entire files of code at the speed of thought, and if you're not careful, it'll happily include your environment variables in the output because you had them loaded in your terminal session.
That is a real phenomenon. The context window includes your environment. So if you're debugging something and you dump your .env file into a prompt, the next piece of code that model generates might reference those variables. And if you copy-paste without reviewing, boom, you've committed your secrets.
I had this happen just last week, actually. I was testing something with the AWS CLI and I had my credentials loaded. I asked an AI to write me a quick script to list some S3 buckets, and it output the credentials directly in the script because they were in the context. I almost copy-pasted the whole thing into a file before I caught it.
See, that's exactly the scenario. You're coding at midnight, you're tired, you just want to get something working. The model gives you working code, you trust it, you paste it in. If you didn't have a hook, you'd be shipping credentials to your production AWS account.
And the scary part is how fast this moves once it's out there. I've talked to security researchers who run automated scrapers on GitHub all day long. They have systems that detect newly pushed API keys within minutes, sometimes seconds. It's not some hacker manually browsing repos. It's bots crawling everything.
The economics of credential theft have made it a volume business. They don't care whose key it is or what it accesses. They just grab it and either use it directly or sell it on dark web marketplaces. AWS credentials can go for anywhere from five to fifty dollars depending on what permissions they have.
That's less than a movie ticket.
And potentially worth thousands in compute resources run up on your dime. So yeah, the stakes are real.
This is why the pre-commit hook approach is so valuable for solo devs. You're not relying on discipline. You're building a system that catches this automatically before it becomes a crisis.
The mechanism itself is straightforward. When you run git commit, Git pauses after gathering your changes but before creating the commit object. It looks for an executable file at .git/hooks/pre-commit and runs it. If the script exits with a zero, the commit proceeds. If it exits with any other code, the commit is aborted.
So your hook gets the staged files via stdin or by reading them from the working directory. It can inspect whatever it wants, and then it just decides yes or no.
And that's powerful because you can do anything. Scan for patterns, run external tools, call out to APIs. Most of the popular security hooks work by running grep-like pattern matching against your staged files. They look for things like aws-access-key-id, sk-live, the string API-KEY with actual values nearby.
What about false positives? Because I imagine if you're scanning for things like password equals, you're going to catch a lot of legitimate code that just happens to use those variable names.
This is where the mature hooks get smart. The detect-secrets tool, for example, uses entropy analysis in addition to regex patterns. It can identify high-entropy strings that look like actual keys versus just the word password in a comment. It also maintains a baseline file so you can whitelist known secrets that you've already dealt with.
So you can say, yeah, I know there's a fake test API key in my codebase for development, I've already rotated the real one, stop yelling at me about it.
And you can also configure hooks to only scan certain file types or certain directories. You probably don't need your security hook running against your markdown files.
Unless your markdown files contain API keys, which I have absolutely seen happen.
Fair point. Now let's talk about the PII angle because this is the part that gets overlooked. Beyond API keys, you can configure hooks to scan for personally identifiable information. Emails, phone numbers, Social Security numbers, credit card numbers.
Which sounds almost paranoid until you remember that developers paste things into code all the time. Test data. Debug output. Sample user records. And if that ends up in a commit, you've potentially exposed real customer information.
There was a case a few years back where a developer committed a spreadsheet of beta tester emails to a public repository. Nothing malicious, they were just trying to track something. But those emails were now indexed by search engines and they got spammed into oblivion.
The lesson being that PII in your repo is a liability even if it's not a credential.
The GDPR implications alone should make solo devs think twice. If you're storing European user data in your code and that repo gets compromised or made public, you're potentially on the hook for regulatory violations. We're talking fines up to four percent of annual revenue or twenty million euros, whichever is higher.
And most solo devs don't even know if their code is handling European user data. They might be processing analytics events that include email addresses without realizing it.
PII scanning hooks can catch things you didn't even realize were in your codebase. But here's the thing about PII scanning that's different from secret scanning. It's harder to detect programmatically. An API key has a specific format. An email address could be legitimate test data or it could be real. A phone number in a test file might be completely fabricated or it might be someone's actual number.
So there's more nuance, which means more false positives.
Right. Which is why most PII scanning hooks let you configure what counts as a violation. You can set thresholds. Maybe you allow one email address in a file for testing purposes, but flag files with dozens of them. It's about finding the balance between catching real issues and screaming wolf.
What about real names? Because that's technically PII too.
It is, but scanning for names is much harder. Names are ambiguous. A string like "John Smith" could be a variable name, a test fixture, or actual user data. Hooks generally don't try to detect names because the false positive rate would be through the roof.
So the practical advice is focus on structured PII. Emails, phone numbers, Social Security numbers, credit card numbers. Those have formats you can match reliably.
And dates of birth, passport numbers, driver's license numbers. Anything with a predictable format that isn't likely to appear naturally in code.
Okay, so we've covered the what and the why. Let's get into implementation. Walk me through setting up a basic pre-commit framework from scratch.
It's three commands. First, you pip install pre-commit. Second, you create a file called .pre-commit-config.yaml in your repository root. Third, you run pre-commit install, which sets up the git hook symlinks for you.
That's it?
That's it. The framework handles the rest. Your YAML file defines which hooks you want and where to find them. Most popular hooks are available from the pre-commit default repository, which is basically a curated collection maintained by the community.
So give me a practical example. I want hooks that scan for secrets and also enforce that I don't have trailing whitespace or debug console.log statements.
Your YAML would look something like this. You specify repo, the hook ID, and any args. For detect-secrets, you'd use the official Yelp hook. For whitespace and console.log, you'd use the check-added-trailing-whitespace and no-commit-to-branch hooks from the default repo. The framework downloads the hook scripts on first run and caches them.
And this runs every time I commit?
It runs on the staged files. Git gives hooks access to the diff, so the hook only scans what you've actually changed. For a large codebase, this is important because you don't want to re-scan your entire history on every commit. The hook is smart enough to know what is new.
What's the performance hit? Because I can imagine someone saying this sounds great but I don't want to add thirty seconds to every commit.
For a typical solo developer project, you're looking at five to fifteen seconds extra on a commit. Most of that is the first run when the hook downloads. After that, it's cached. And you're only scanning the files that changed, not the whole repo.
That's nothing. I spend more time than that staring at my terminal waiting for npm install.
Right. If fifteen seconds is breaking your workflow, you might be committing too frequently. Most developers benefit from committing more often, not less.
That's fair. Now let's talk about the pre-commit configuration for teams because even solo devs sometimes collaborate.
The pre-commit framework supports local hooks, which are hooks you define within your own repository. But it also supports remote repositories, which means you can have an organization-level hook configuration that everyone references. You can have a shared repository of hooks that your team pulls from.
So if I'm a solo dev working with a couple freelancers on a client project, I can define my hooks once and they pull them in without me having to manually configure their environments.
You commit your .pre-commit-config.yaml to the repo, and when they run pre-commit install, they get the same hooks you have. Consistency without manual coordination.
What about the edge cases? Because every system has them. When do hooks fail in ways that are annoying versus genuinely problematic?
The most common annoyance is false positives. You're trying to commit legitimate code that triggers a hook. Maybe you have a test string that looks like an API key. The solution is to add a noqa comment or to update your baseline file. The pre-commit framework supports both.
And when you absolutely, positively need to commit something that fails a hook?
Git provides the --no-verify flag for exactly this scenario. You can bypass your hooks. The framework also supports skipping specific hooks or running in audit mode where violations are reported but don't block commits.
I feel like --no-verify is the git equivalent of asking your firewall to just trust the exe file.
It should be used sparingly and with full awareness of what you're doing. The hooks exist for a reason. Bypassing them should require a conscious decision, not just lazy habits.
Though there are legitimate use cases. Sometimes you need to commit something that will be cleaned up in the next commit. Sometimes you're in the middle of a rebase and you need to power through. Sometimes you're dealing with generated files that legitimately contain patterns that look like secrets.
All valid reasons. The key is intentionality. If you find yourself using --no-verify every day, your hooks are probably misconfigured. If you're using it once a month for specific scenarios, that's probably fine.
What about pre-push hooks? Because commit hooks run before every commit, but push hooks run before you push to a remote.
Pre-push is useful for things that are expensive to run on every commit. Maybe you want to run your full test suite before pushing. Or run a comprehensive security scan that takes a few minutes. The trade-off is that push hooks run less frequently but catch problems later, after you've potentially made multiple commits.
So the workflow is usually commit hooks for fast checks, push hooks for thorough checks. You catch the obvious stuff immediately and the expensive stuff before it leaves your machine.
Though I should note that pre-push hooks don't run if someone clones your repo and pushes directly. They're local only. So you still need CI checks for things that absolutely must pass.
Okay, now here's something I don't think enough developers consider. Hooks aren't just for security. You can automate all kinds of quality checks. Formatting, linting, running tests on changed files.
This is where pre-commit becomes genuinely transformative for solo dev workflows. You can configure hooks that run Black or Prettier to auto-format your code. You can run ESLint or Pylint. You can execute your test suite on only the files that changed.
The test thing is interesting. Because traditionally you'd run your full test suite in CI, which might take twenty minutes. But a pre-commit hook that runs just the tests for files you touched? That's fast.
And it catches issues before they enter the repository. You're not waiting for CI to fail and then having to fix commits that are already part of your history. Though I'll say, if your tests take more than thirty seconds to run on changed files, you might have a test suite architecture problem.
Tests should be fast. If they're not, that's a separate issue to address.
Now let's talk about preventing direct commits to main. Because that's a common best practice. You want all changes to come through pull requests.
There's a pre-commit hook for that. The no-commit-to-branch hook can block commits directly to protected branches. You set it up, you try to git commit directly to main, and it refuses. Your change has to go through a feature branch.
Unless you use --no-verify.
Unless you use --no-verify. Which, again, you should only do deliberately.
The no-commit-to-branch hook is one of those things that seems annoying until you realize how many times it's saved you from accidentally committing directly to main. And for solo devs working on personal projects, it still enforces good habits.
What about commit message validation? Because commit-msg is a hook point too.
You can validate that commit messages follow a certain format. Conventional commits, for example. You can require that messages have a ticket number, or that they're under a certain length. Though honestly, most solo devs don't need that level of rigor.
Though if you're generating changelogs automatically from commit messages, conventional commits become more valuable.
True. That's more of a project management thing than a security thing, but it's still useful.
Now let's talk about writing custom hooks, because the YAML configuration is great for existing tools, but at some point you might need something specific to your project.
You can write a hook in any language. Python, Node, Ruby, Bash. The only requirement is that the script exits with zero for success or non-zero for failure. You point to it in your YAML config as a local repo, and the framework handles execution.
Walk me through what a simple custom hook looks like.
You create a hooks directory in your repo, write a Python script that receives file paths from stdin, inspects them however you want, and exits appropriately. Then in your YAML you specify entry, the command to run, and types, which tells the framework what file types to pass to your hook.
So if I wanted a hook that checks for TODO comments without authors, or enforce a maximum line length?
You could do all of those. The pre-commit framework doesn't care what your hook does. It just runs it and respects the exit code.
What about hooks that call external APIs? Like what if I want to scan URLs in my code against a database of known malicious domains?
That's possible, but you need to be careful about performance. If your hook makes network requests, it adds latency to every commit. And if the API is down, your hook fails. For something like that, a pre-push hook might be more appropriate than pre-commit.
Good point. You don't want your commit workflow dependent on external services being available.
Though many API-based security tools handle this by caching results locally and only checking new or changed URLs. It's all about finding the right balance.
Okay, practical takeaways time. I'm a solo developer, I've heard this episode, I want to set this up. What are the concrete steps?
First, install the pre-commit framework. pip install pre-commit. Second, create a .pre-commit-config.yaml file. Start with two hooks, detect-secrets and trailing-whitespace. Third, run pre-commit install to activate the hooks in your repository. Fourth, test it by intentionally committing a fake secret and making sure the hook catches it.
That's a good test. You want to verify your safety net actually works before you need it.
And once you've confirmed it works, gradually add more hooks. Whatever makes sense for your stack. Linters, formatters, custom checks. But start simple.
What about existing repositories? If I've got a codebase that's been around for years, do you need to scan your entire history for secrets?
The pre-commit framework has a detect-secrets baseline command that scans your repo and creates a baseline file of known secrets. You then configure the hook to ignore those. It's a one-time operation.
So you're not expected to clean up years of git history, you just start from now and lock the door going forward.
Though if you do have secrets in your history, you should rotate them regardless. Assume they've been seen even if they haven't been exploited.
Always assume the worst case and work backward from there.
Security mindset. Now here's the thing about AI coding assistants that brings this all together. These tools generate code at a rate we've never seen before. And a lot of that code is boilerplate that developers copy-paste without reviewing thoroughly.
Which means the surface area for accidentally committing secrets or PII has increased dramatically.
You used to have to manually type out a curl command with your API key. Now the model generates it for you and you paste it into a file without thinking. The hook catches it before it becomes a problem.
The pre-commit hook is your automated review layer that never gets tired and never misses something because it was three in the morning.
As these tools get more powerful, I think automated safety nets become less optional and more infrastructure.
The cost of a single leaked credential versus thirty seconds of hook setup time. I know which one I'd rather pay.
One hundred thousand dollars in AWS bills versus thirty minutes of configuration. It's not even close.
For those playing along at home, the pre-commit framework documentation is at pre-commit.com. There's a getting started guide, a hook list with over two hundred entries, and everything you need to implement this in your workflow.
Episode 1549 covered phishing attacks targeting developers, which touches on the security side of this. Both address security blind spots in developer workflows, but this episode focuses on prevention rather than detection.
All right, let's wrap this up. What's the open question you want listeners thinking about?
If you had to pick one type of hook to implement today, security or quality, which would it be and why? Most developers would say quality, because it's visible. But security hooks are invisible until they're not. The value of a security hook is measured by incidents that never happened.
And incidents that never happened are notoriously hard to put on your resume.
They are. Though if you're reading this in the future and that AWS bill showed up on your credit card, you might wish you'd listened to this episode.
Fair point.
Big thanks to Modal for providing the GPU credits that power this show. This has been My Weird Prompts. Find us at myweirdprompts dot com for RSS and all the ways to subscribe. If you're enjoying the show, a quick review on your podcast app helps us reach new listeners. We'll see you next time.
