Detector Coverage Atlas

Secret-scanning tools name, categorize, detect, and verify the same credentials differently — so coverage questions stay tribal.

Teams cannot answer which providers are covered, whether two detectors are equivalent, whether a finding can be verified, or what changed, without overstating the evidence.

Without this: Competitive slides invent gaps. Unreviewed cells get treated as “unsupported.” Onboarding depends on whoever last read the detector source.

Primary: Security researcher / AppSec engineer who needs evidence-backed coverage and verification status

Secondary: PM, SA, AE, and CS who must explain coverage without overstating it

Job: Answer a detector-coverage question with provenance, confidence, and a path to the source.

Independent research against public TruffleHog: a source parser observed 910 detector records (Sept 2026), with 14 fully enriched and ready to render. Nested folders (github/v1, aws/access_keys) were being dropped until that bug was fixed. Validity-check detection is heuristic — GitHub and GitLab verification delegated to helpers are known false negatives. This is a public research catalog, not an official Truffle Security product.

Goals

• Preserve source names and pin every import to a commit SHA.
• Normalize to canonical secret types without deleting source terminology.
• Label cells documented, observed, unknown, not evaluated, or needs review — never treat gray as a confirmed gap.
• Keep detection (`detectors`) separate from credential-capability analysis (`analyzer`).

Non-goals

• A production scanner or continuous customer-monitoring product.
• CodeQL, dependency scanning, or general vuln scanning.
• Real secrets, live credential verification, or internal Truffle code/data.
• Filling Betterleaks or Kingfisher columns before their public rule files are reviewed.
• Treating how-to-rotate docs as detector-coverage evidence.

Catalog foundation: schema, TruffleHog ingestion, 14 reviewed starter detectors, searchable comparison with explicit uncertainty.

Question the MVP tests: Can fragmented public detector information become a reliable, evidence-backed product before we add more sources or automation?

1. Ingest public repos and docs at a pinned commit
2. →Normalize without overwriting source names
3. →Enrich with evidence level and review status
4. →Compare across tools
5. →Queue parser uncertainty for human review

Plain language

1. Public GitHub + provider docs
2. →Ingestion
3. →Normalization
4. →Evidence + confidence
5. →Searchable UI
6. →Scheduled change detection
7. →Human review queue

Technical

1. Octokit (commit-pinned reads)
2. →Provider-specific parsers
3. →Postgres + Drizzle (next)
4. →Vercel Cron snapshots (next)
5. →shadcn data table
6. →Comparison matrix

• DetectorRecord
• DetectorEquivalenceGroup
• CoverageMatrixCell
• IngestionRun
• Verification profile
• ValueNarrative
• RotationGuide
• Review item

Operational

• 910 TruffleHog records parsed; 14 enriched
• Normalization rate and evidence completeness
• Stale-record and parser false-negative rate

Behavioral

• Review-queue resolution
• Reuse in onboarding and competitive prep

Business

• Hypothesis: fewer unsupported product claims and faster coverage answers than manual repo research

If coverage is evidence-based and reviewable, product and field decisions get faster and claims get safer. No invented revenue. Missing public docs is not a confirmed gap.

• Parser complexity vs. a human review queue for ~30 “no verifier” flags.
• Breadth of providers vs. depth of evidence — TruffleHog first.
• Scheduled snapshots vs. real-time crawling.
• Computed comparison views vs. stored matrix rows.

Phase 1 in progress: parser tested on the real public TruffleHog repo; 14 enriched detectors ready for the Next.js table. Independent/unofficial. Separate from Truffle Camp (secretsafari) and from any company-owned Atlas.

Intended value

• Faster technical research
• More accurate competitive analysis
• Fewer unsupported product claims
• Quicker onboarding
• Stronger product and field decisions

• Detector detail with verification profiles and conditional risk language.
• Betterleaks and Kingfisher only after rule-file review; GitGuardian and GitHub Secret Scanning stay manual-doc.
• Commit snapshots, diffs, and a review queue.
• Five to ten representative questions against the UI to pick the next phase — not every planned screen.