FlashAudit Core.

// the problem

A client's Gitleaks pre-commit hook took 4 minutes on their monorepo. Engineers disabled it. Secrets shipped.

// overview

Secret scanning sits in the hottest part of a CI pipeline — every push, every PR, every merge. If it blocks for 4 minutes, engineers will find a way to skip it. That's how secrets ship. FlashAudit is what happens when you treat the scanner like a systems problem, not a regex problem.

// how it works

• 01Memory-mapped file I/O — the scanner never allocates a per-file buffer; it views the bytes directly.
• 02Rayon work-stealing parallelism — a thread idle on small files pulls work from a thread stuck on a large one.
• 03Pattern engine compiled once, shared across threads — the regex set is a static Aho-Corasick DFA, not a per-file recompile.
• 04SARIF output — drops into GitHub Advanced Security, Azure DevOps, and any SARIF-aware dashboard with zero glue code.

// measured impact

// what I'd change

The pattern set lives in a static array today — fine for the built-in rules, painful the moment a client wants custom patterns at runtime. Next iteration: a RON/TOML rule file loaded at startup with the DFA compiled lazily. Also want to experiment with Hyperscan as an optional backend for the overlapping-match case. Full methodology and raw hyperfine output on the /benchmarks page.