Gitorii Logo Gitorii
← Back to blog
Security · 6 min read

Built-in Secret Scanning

Gitorii scans for tokens, API keys, and credentials before every commit so you never push secrets again.

Every leaked-credential postmortem ends the same way. The key gets rotated. Someone force-pushes a clean history. A security review gets written. Everybody is a little more tired than they were yesterday. The root cause is almost never the rotation or the review — it is that the secret made it into a commit at all. Prevention is orders of magnitude cheaper than remediation.

Gitorii bakes a scanner into the commit path. Every torii save runs the staged diff through a fast detector before anything writes to the object store. If something matches, the commit is blocked with a precise pointer to the line.

What it catches

  • Cloud providers — AWS access keys and secret keys, GCP service account JSON, Azure storage keys.
  • Forges — GitHub personal access tokens (ghp_, gho_, ghs_), GitLab PATs (glpat-), Gitea/Forgejo tokens.
  • Payments and comms — Stripe live keys (sk_live_), Slack webhooks, SendGrid, Twilio.
  • Infrastructure — Docker Hub tokens, NPM tokens, private PEM keys, SSH private keys.
  • Generic — high-entropy strings near variable names like TOKEN, SECRET, API_KEY, PASSWORD.
⚠ Secret detected in src/config.rs:12
GITHUB_TOKEN = "ghp_xxxxxxxxxxxxxxxxxxxx"
 
⚠ Secret detected in .env.example:7
STRIPE_SECRET_KEY = "sk_live_51Hxxxxxxxxxxxx"
 
# commit aborted (2 findings)
# override with --allow-secret if the finding is a false positive

False positives and overrides

  • A .toriignore file with glob patterns for files the scanner should skip (like your fixtures/ directory).
  • An inline comment — // torii:allow-secret on the offending line marks it as vetted.
  • The --allow-secret flag on torii save. Use when you are in a hurry and plan to fix the root cause later.

Scanning the past

If you are adopting Gitorii on an existing repo, the blocker is not today's commit — it is the secret that someone leaked in 2022 and never fully purged. Gitorii can audit the full history too:

torii history scan --history
 
# found 3 potential secrets across 18,432 commits
# abc1234 · src/config.rs:12 · github-token
# def5678 · .env · stripe-key
# 9012345 · docs/deploy.md:44 · aws-access-key

For the files you want completely gone — not just from HEAD, from every commit that ever touched them — there is torii history remove-file.

Agent-proof by design

One of the quietly concerning failure modes of the agent era is a model reading your .env file to "understand context" and pasting fragments into a commit. A pre-commit scanner does not care who wrote the diff — human or model, both get stopped the same way.

Performance

Scans run against the staged diff, not the working tree, and on a typical commit complete in under 50ms. For the --history scan on a 20k-commit repo, expect around 30 seconds on modern hardware. Secret scanning is on by default; turn it off with torii config set security.scan_on_save false if you really must.