# 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

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

Or enable it permanently in `.nitpik.toml`:

```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:

```bash
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](https://github.com/gitleaks/gitleaks#configuration):

```toml
[[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:

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

```toml
# .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](12-Threat-Scanning) — malicious pattern detection (complementary to secret scanning)
- [How Reviews Work](09-How-Reviews-Work) — where secret scanning fits in the pipeline
- [Configuration](14-Configuration) — secrets config section
- [CI/CD Integration](15-CI-Integration) — enabling secret scanning in pipelines
