Secret Scanning

nitpik detects and redacts secrets in your code before anything is sent to the LLM. When enabled, API keys, tokens, passwords, and other sensitive values are replaced with [REDACTED] in both the diff and file content.

---

Enabling Secret Scanning

nitpik review --diff-base main --scan-secrets

Or enable it permanently in .nitpik.toml:

[secrets]
enabled = true

Tip: Always enable --scan-secrets in CI pipelines. Locally, enable it when reviewing code that may contain credentials.

What Gets Detected

nitpik ships with 200+ gitleaks-compatible rules covering:

• Cloud provider keys (AWS, GCP, Azure)
• API tokens (GitHub, GitLab, Slack, Stripe, Twilio, etc.)
• Database connection strings
• Private keys (RSA, SSH, PGP)
• JWT tokens and bearer tokens
• Generic passwords and secrets in config files
• High-entropy strings (via Shannon entropy checks)

Secrets are detected in both the diff hunks and the full file content included in the prompt. Redaction happens before the LLM call — the provider never sees the secret values.

Custom Rules

Add your own gitleaks-format rules:

nitpik review --diff-base main --scan-secrets --secrets-rules ./custom-rules.toml

Custom rules are loaded in addition to the built-in rules. The format follows the gitleaks rule specification:

[[rules]]
id = "internal-api-key"
description = "Internal API key pattern"
regex = '''INTERNAL_KEY_[A-Za-z0-9]{32}'''

Finding Severity

Detected secrets are reported as findings alongside your review results. By default, each finding has warning severity. Override this with the --secrets-severity flag or the severity config key:

# Treat detected secrets as blocking errors
nitpik review --diff-base main --scan-secrets --secrets-severity error

# .nitpik.toml
[secrets]
enabled = true
severity = "error"   # "error", "warning", or "info"

Set error when secrets should block merges. Set info for legacy codebases where known secrets exist and you don't want them to gate CI.

Performance

Compiling the 200+ built-in regex rules adds roughly 3–5 seconds of startup time on the first invocation (rules are compiled in parallel). This cost is:

• Paid once per run, not per file
• Only incurred when --scan-secrets is enabled
• Unaffected by the number of files in the review

Normal reviews without --scan-secrets have no extra startup cost.

Limitations

Secret scanning is a best-effort safety net, not a guarantee. The built-in rules cover 200+ common patterns, but custom or unusual secret formats may not be detected.

• nitpik does not guarantee detection of all secrets. Unusual credential formats, dynamically constructed secrets, or secrets split across multiple lines may evade detection.
• Always treat --scan-secrets as a safety layer, not a substitute for proper secret management — use environment variables, vault services, and .gitignore to keep secrets out of your repository in the first place.

Related Pages

• Threat Scanning — malicious pattern detection (complementary to secret scanning)
• How Reviews Work — where secret scanning fits in the pipeline
• Configuration — secrets config section
• CI/CD Integration — enabling secret scanning in pipelines