GitGuard

Scan feature without --fix flag
Scan with --fix flag utilizing Claude to fix vulnerabilties
Scan with --vulns for max detection

Inspiration

Almost every developer has done it: hardcoded an API key "just to test something," then accidentally committed it. We've watched friends get surprise AWS bills and revoked tokens because a secret slipped into a public repo. The scary part is that most scanners only catch known key formats — they happily miss a DB_PASSWORD = "admin123" or a random token sitting in a config file. And even when a tool flags something, you're still left to figure out how to fix it. We wanted a scanner that catches the stuff other tools miss, never phones home with your secrets, and hands you a fix — not just a warning.

What it does

GitGuard is a fully offline CLI that scans a single file, a folder, a .zip, or a GitHub repo (including its git history) for exposed credentials and risky code patterns.

Five layered detection systems: vendor-specific rules (AWS, GitHub/GitLab, Stripe, OpenAI, Slack, Discord, Twilio, SendGrid, and more), generic structural patterns (private keys, JWTs, DB/Redis/SMTP connection URLs), an assignment engine that flags secrets by variable name across JS/TS/Python/JSON/YAML/TOML/INI/.env, Shannon-entropy detection for random-looking strings, and a correlation pass that de-duplicates overlapping hits into one strongest finding. Vulnerability mode (--vulns): finds SQL injection, XSS, command injection, SSRF, unsafe eval, weak crypto, IDOR, prototype pollution, and more. AI-ready fixes (--ai): exports a Markdown remediation brief that an agent like Claude Code can act on directly — every finding with its file, line, why it matters, and concrete fix steps. Built for real use: a 0–100 risk score, redaction by default, a detection-coverage breakdown, JSON/CSV/Markdown output, and a --fail-on HIGH flag for CI gates. Nothing ever leaves your machine. Fix with optimal context (--fix): A custom Claude Sonnet harness allows security vulnerabilities to be detected, redacted, and removed without violating security standards.

How we built it

GitGuard is a Python CLI built with Typer and a Rich terminal UI, with zero network calls unless you want it to. We designed the detection engine as independent, composable layers. Regex rules, an assignment parser, entropy analysis, a vulnerability scanner, a correlation/dedup stage, and a reporting layer are used so each can be tested and extended on its own. Adding a new secret rule or vulnerability pattern takes only a few lines. We backed the whole thing with a suite of 111 automated tests and a one-command installer that auto-detects a compatible Python version.

Challenges we ran into

Recall vs. noise: flagging credentials by variable name is powerful but easy to overdo — API_KEY should fire, primaryKey shouldn't. We built a tokenizer that splits camelCase/snake_case and only treats names as sensitive when the right keyword is present. Duplicate findings: a DATABASE_URL would trip both the connection-URL rule and the generic-assignment rule for the same value. We solved it with a span-overlap correlation pass that keeps the single strongest finding (provider > generic > context > entropy). Entropy without false positives: UUIDs and hashes look random too, so we had to filter them out while still promoting genuinely high-entropy secrets in config/production contexts. Testing a secrets scanner safely: we couldn't commit a fixture full of real-looking secrets, so we generate the demo input from runtime-assembled fragments — no literal credential ever lives on disk. Accomplishments that we're proud of On an intentionally vulnerable demo file, GitGuard surfaces 29 secret findings (41 with vulnerability mode on) — far more than pure regex matching catches. The --ai remediation brief turns a scan straight into an actionable to-do list for an AI agent, closing the loop from detect to fix. It's genuinely offline and safe: secrets are redacted, temp clones are auto-deleted, and ZIP extraction is hardened against path traversal. A clean, layered architecture with 111 passing tests — production-quality, not just a hackathon prototype.

What we learned

Good security tooling is as much about precision and developer experience as raw detection — a noisy scanner gets ignored. Combining multiple weak signals (name + value + entropy + context) catches far more than any single technique, if you correlate them well. Writing detection rules makes you think like an attacker, and writing the fix guidance makes you think like the developer who has to clean it up.