14 Secret Scanning

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