Levn Ln 761 Secret Scanner

---
name: ln-761-secret-scanner
description: Scans codebase for hardcoded secrets. Returns normalized findings with severity and remediation guidance. Pre-commit hook integration.
---

# Secret Scanner

Scans codebase for hardcoded secrets and credentials, returning structured findings for remediation.

## Purpose & Scope

- Detect hardcoded secrets using available tools (gitleaks, trufflehog) or manual patterns
- Classify findings by severity (Critical/High/Medium/Low)
- Filter false positives via baseline and allowlists
- Provide remediation guidance per finding type
- Return normalized report to parent orchestrator (ln-760)

## When to Use

- During project bootstrap (via ln-760-security-setup)
- Pre-commit hook validation
- CI/CD security pipeline
- Manual security audit

---

## Workflow

### Phase 1: Tool Detection

**Step 1: Check Available Scanners**
- Check if gitleaks is installed (preferred)
- Check if trufflehog is installed (alternative)
- If neither available: use manual pattern matching as fallback

**Step 2: Load Configuration**
- Load project `.gitleaks.toml` if exists (custom rules)
- Load `.gitleaksbaseline` if exists (known false positives)
- If no config: use default patterns from `references/detection_patterns.md`

### Phase 2: Scan Execution

**Step 1: Run Available Scanner**
- Execute scanner against project root
- Capture output in structured format (JSON/SARIF preferred)
- If tool unavailable: run manual grep patterns for high-confidence secrets

**Step 2: Parse Results**
- Normalize output to common format: file, line, pattern, raw_match
- Preserve original severity if provided by tool

### Phase 3: Report Generation

**Step 1: Severity Classification**
- Map findings to severity levels per `references/detection_patterns.md`
- Critical: AWS keys, private keys, JWT secrets
- High: Generic passwords, connection strings
- Medium: API keys (may be test data)
- Low: Potential secrets requiring manual review

**Step 2: False Positive Filtering**
- Apply baseline exclusions
- Apply allowlist patterns (placeholders, test data, docs)
- Mark filtered items as "excluded" with reason

**Step 3: Build Report**
- Group findings by severity
- Include file path, line number, pattern matched
- Do NOT include actual secret values in report

### Phase 4: Remediation Guidance

**Step 1: Attach Remediation Actions**
- For each finding, attach remediation steps from `references/remediation_guide.md`
- For Critical findings: emphasize immediate rotation requirement

**Step 2: Return Results**
- Return structured findings list to orchestrator
- Include summary: total scanned, total found, by severity

---

## Critical Rules

1. **Never log actual secret values** - redact in all outputs
2. **Treat any found secret as compromised** - rotation required for Critical
3. **Preserve baseline** - do not remove existing baseline entries
4. **Pre-commit priority** - recommend pre-commit hook if not configured
5. **Git history awareness** - warn if secret may exist in history (requires git-filter-repo)

---

## Definition of Done

- [ ] Scan completed using available tool or manual patterns
- [ ] Findings classified by severity
- [ ] False positives filtered via baseline/allowlist
- [ ] Remediation guidance attached to each finding
- [ ] Report returned in normalized format (no raw secret values)
- [ ] Critical findings flagged with rotation requirement

---

## Reference Files

| File | Purpose |
|------|---------|
| `references/detection_patterns.md` | Secret patterns by confidence level |
| `references/gitleaks_config_template.toml` | Template for project gitleaks config |
| `references/remediation_guide.md` | Rotation procedures by secret type |

---

**Version:** 2.0.0
**Last Updated:** 2026-01-10