Is your feature request related to a problem?
Keywatch currently has 106 built-in detectors and supports scanning files, directories, git history, and stdin with baseline/inline suppression. However, compared to gitleaks (222 rules, TOML config, SARIF, GitHub Action) and its successor betterleaks (CEL validation, BPE tokenization, async secret validation), keywatch lacks several capabilities that would make it production-ready for CI/CD pipelines and enterprise adoption.
Describe the solution you'd like
I'd like to add the following features inspired by gitleaks and betterleaks:
-
User-Configurable TOML Config File (like gitleaks' .gitleaks.toml)
Allow users to define custom rules, overrides, and allowlists in a .keywatch.toml file instead of requiring code changes. Should merge with built-in detectors.toml at runtime.
-
SARIF Output Format (like gitleaks' --report-format sarif)
Enable keywatch to emit SARIF (Static Analysis Results Interchange Format) so findings appear in GitHub's Security tab / Code Scanning alerts.
-
Official GitHub Action
Publish a keywatch/scan GitHub Action for CI/CD pipeline integration.
-
Pre-commit Framework Support
Ship .pre-commit-hooks.yaml so users can add keywatch via the pre-commit framework.
-
Rule-Level Severity & Tags
Allow per-rule severity assignment in config (like gitleaks' [rules.tags] and severity field).
-
Expression-Based Allowlist (inspired by betterleaks' CEL filtering)
Support contextual allowlist expressions that evaluate fragment attributes (git author, commit message, file path) beyond simple regex matching.
-
Secrets Validation / Verification
Optional async HTTP requests to verify if detected credentials are still active (betterleaks' CEL validation model).
-
Docker Image & Homebrew Formula
Publish multi-arch Docker images and a Homebrew tap for easier distribution.
-
Per-Detector Enable/Disable in Config
Allow users to disable noisy detectors via config without removing them from the binary.
Example Implementation
// Example: Config-driven custom rule (loading from .keywatch.toml)
// This would merge with built-in detectors at startup
// .keywatch.toml
// [rules]
// [rules.my-custom-api]
// pattern = 'my-api-key-[A-Za-z0-9]{32}'
// severity = "HIGH"
// keywords = ["my-api"]
// allowlist.paths = ["tests/**"]
// CLI usage:
// key-watch scan . --config .keywatch.toml
// key-watch scan . --format sarif --output report.sarifAdditional context
All features are directly inspired by gitleaks (MIT, 27k+ stars) and its successor betterleaks (MIT, 1.2k+ stars). Gitleaks pioneered user-configurable TOML rules, SARIF output, and GitHub Action support — these are standard expectations for a modern secrets scanner. Betterleaks advances the category with CEL-based validation and expression filtering. Keywatch should match these capabilities while maintaining its Rust performance advantage.
Priority
Important
Is your feature request related to a problem?
Keywatch currently has 106 built-in detectors and supports scanning files, directories, git history, and stdin with baseline/inline suppression. However, compared to gitleaks (222 rules, TOML config, SARIF, GitHub Action) and its successor betterleaks (CEL validation, BPE tokenization, async secret validation), keywatch lacks several capabilities that would make it production-ready for CI/CD pipelines and enterprise adoption.
Describe the solution you'd like
I'd like to add the following features inspired by gitleaks and betterleaks:
User-Configurable TOML Config File (like gitleaks'
.gitleaks.toml)Allow users to define custom rules, overrides, and allowlists in a
.keywatch.tomlfile instead of requiring code changes. Should merge with built-in detectors.toml at runtime.SARIF Output Format (like gitleaks'
--report-format sarif)Enable keywatch to emit SARIF (Static Analysis Results Interchange Format) so findings appear in GitHub's Security tab / Code Scanning alerts.
Official GitHub Action
Publish a
keywatch/scanGitHub Action for CI/CD pipeline integration.Pre-commit Framework Support
Ship
.pre-commit-hooks.yamlso users can add keywatch via the pre-commit framework.Rule-Level Severity & Tags
Allow per-rule severity assignment in config (like gitleaks'
[rules.tags]and severity field).Expression-Based Allowlist (inspired by betterleaks' CEL filtering)
Support contextual allowlist expressions that evaluate fragment attributes (git author, commit message, file path) beyond simple regex matching.
Secrets Validation / Verification
Optional async HTTP requests to verify if detected credentials are still active (betterleaks' CEL validation model).
Docker Image & Homebrew Formula
Publish multi-arch Docker images and a Homebrew tap for easier distribution.
Per-Detector Enable/Disable in Config
Allow users to disable noisy detectors via config without removing them from the binary.
Example Implementation
Additional context
All features are directly inspired by gitleaks (MIT, 27k+ stars) and its successor betterleaks (MIT, 1.2k+ stars). Gitleaks pioneered user-configurable TOML rules, SARIF output, and GitHub Action support — these are standard expectations for a modern secrets scanner. Betterleaks advances the category with CEL-based validation and expression filtering. Keywatch should match these capabilities while maintaining its Rust performance advantage.
Priority
Important