Website · Documentation · Architecture · Vyre GPU engine

KeyHog: GPU-accelerated secret scanner for code, cloud, and CI

KeyHog is an open-source secret scanner in Rust that finds and verifies leaked API keys, tokens, passwords, and credentials across source code, Git history, containers, cloud storage, browser assets, collaboration content, and running systems.

Most secret scanners stop at CPU regex matches in a repository checkout. KeyHog combines 926 service-specific detectors, decode-through for concealed credentials, context-aware evidence and suppression, live provider verification, and first-class CUDA, Metal, and WGPU execution through Vyre. Calibration measures every eligible pure-Rust CPU, Hyperscan/SIMD, and GPU backend. Automatic routing then uses the fastest parity-proven route for the exact host and workload class.

cargo install --locked keyhog
keyhog scan .

A secret scanner built around the GPU

KeyHog does not hand a few regular expressions to a generic compute shader. Its GPU path is built on Vyre, a Rust GPU compute substrate developed alongside KeyHog. Detector triggers compile into immutable GPU-resident tables. Bounded source batches produce complete match positions for the same confirmation, suppression, evidence, and reporting pipeline used by CPU and Hyperscan routes.

• Three physical GPU peers. CUDA, native Metal, and portable WGPU are acquired, measured, and reported independently.
• Exact result parity. Calibration rejects a candidate whose finding identity differs from the reference route. A faster wrong answer never enters the routing table.
• Persistent route evidence. KeyHog records the binary, detector corpus, configuration, workload class, host, accelerator, driver, and measured timing evidence. Normal scans do not benchmark in the hot path.
• Resident execution. Daemon workers keep compiled detector and accelerator state warm for repeated file, archive, history, remote, and cloud batches.
• No hidden CPU escape hatch. An explicitly selected accelerator that cannot initialize or dispatch fails visibly instead of returning CPU findings under a GPU label.

The default crates.io install uses the portable pure-Rust CPU route so it works on a clean Rust host. Enable the three GPU peers without acquiring Hyperscan:

cargo install --locked keyhog --no-default-features --features portable,gpu

Run the production backend diagnostic, then inspect the measured route:

keyhog backend --self-test
keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

The backend guide documents the resident tables, bounded dispatch model, parity contract, and reproducible crossover evidence.

Get started

Install and run your first scan

The two commands above install the latest crates.io release and scan the current tree with the portable pure-Rust route.

Pin a CI environment to one exact release with cargo install --locked --version '=0.5.79' keyhog. KeyHog requires Rust 1.89 or newer. See the installation guide for GPU, Hyperscan, CI, portable, and source-build profiles.

KeyHog exits 1 when a finding blocks the active evidence policy. The default policy blocks likely and confirmed findings while keeping review findings visible with exit 0; --evidence-policy paranoid blocks every tier. Review each finding's exact evidence tier, reason code, file, line, detector, and remediation. Other nonzero codes describe input, system, verification, or coverage failures; see the exit-code reference.

The complete process contract is:

Filter, format, gate:

Create a baseline before using it as a filter:

keyhog scan . --create-baseline .keyhog-baseline.json
keyhog scan . --baseline .keyhog-baseline.json --format json-envelope --output keyhog.json

The first command snapshots reviewed findings and exits 0 without printing them. Commit that file, then use the second command to report only new finding identities. A baseline entry matches on the detector and the credential value, never on the file path, so moving a recorded secret does not fail the gate but rotating it does. Changed credentials and incomplete coverage remain visible. The complete path, including monorepo partitions, is Fail only on new secrets.

For the next scan, use the recipes cookbook or the copyable commands in Choose the right workflow. You can scan Git history, container images, cloud buckets, repository collections, URLs, and a whole machine without changing tools.

Guard repositories for fast pre-commit scans

Register a repository with the perpetual KeyHog daemon for fast pre-commit secret detection (requires Unix; on Windows use in-process keyhog scan):

# 1. Start the daemon (accelerated by CUDA, Metal, WGPU, or SIMD)
keyhog guard up

# 2. Guard your repository (indexes baseline and installs pre-commit hook in one step)
keyhog guard add /path/to/repo

# 3. Every staged commit checks only changed blobs against in-memory attestations
keyhog scan --git-staged

# 4. View all active guarded repositories and their states
keyhog guard list

# 5. Turn the daemon on and off cleanly without losing registrations or durable index
keyhog guard down

See the perpetual guard guide and pre-commit workflow for full configuration, state machine lifecycle, and hook automation.

Add it to GitHub Actions

Create .github/workflows/keyhog.yml:

name: keyhog
on:
  push:
    branches: [main]
  pull_request:
permissions:
  contents: read
  security-events: write
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: santhreal/keyhog@v0
        with:
          path: .
          severity: high

The Action scans the checked-out tree, fails on findings at high or critical, uploads SARIF to Code Scanning, and retains the report as a workflow artifact. Installation, coverage, backend, and report-publication failures also fail the job.

Use the GitHub Action guide for inputs, outputs, baseline adoption, monorepo partitions, verification, and failure behavior. Use the CI guide for GitLab, CircleCI, Jenkins, Buildkite, and generic shell jobs. Use the mass-scanning guide for repository organizations, hosted Git groups, cloud buckets, and partitioned inventories.

Scan surfaces other tools treat as separate products

KeyHog scans bytes at the boundary where they can leak, not only tracked source files. Use one report per boundary so CI retains exact coverage and failure state.

These routes share one detection and reporting contract. A source-specific failure cannot silently turn into a narrower local scan.

Choose the right workflow

Choose the source boundary first. A preset changes detection work, while a backend changes execution. Neither one expands a working-tree scan into Git history, a provider inventory, cloud storage, or a host audit.

There is no honest scan everything shortcut. A complete estate review runs the relevant boundaries below as separate jobs and retains each json-envelope report with its raw exit code.

Scan every supported source boundary

Use one command per boundary. Keep a json-envelope report and the raw exit status for each inventory partition.

A plain directory scan does not read native binaries. Each one becomes a binary (extension or content sniff) coverage gap, the scan still exits 0, and --no-default-excludes does not change it, so pass --binary when compiled artifacts are in scope. That flag needs a build with the binary feature, which the default crates.io install has and the lean ci feature does not.

Native binary extraction reports complete credentials that satisfy a named detector's explicit shape contract. It suppresses short prefix fragments and generic assignment-shaped strings from compiled data sections because those bytes do not retain source context.

Endpoint fetching is bounded and SSRF-screened. It is not a crawler. Private cloud endpoints and credential forwarding require their explicit trust flags. Provider tokens belong in the documented environment variables, not process arguments.

Use the workflow chooser for source and policy details, the GitHub Action guide for the maintained repository gate, the direct CI guide for durable reports and exit handling, and the mass-scanning guide for partitioning and aggregation. The recipes cookbook covers containers, archives, URLs, GitHub collaboration content, and cloud sources.

Speed and concurrency without guesswork

Start with the defaults. The historical verified binary-asset installer runs calibration itself. Cargo cannot execute KeyHog after cargo install, so run the commands below once after installing a multi-backend Cargo build and again after the host, binary, detector corpus, driver, or workload classes change:

keyhog calibrate-autoroute --policy all
keyhog backend --autoroute --json

Inspect the resolved policy with keyhog config --effective. Use --profile to measure fixed scanner stages and the complete operator run before you change reader, batch, or channel-depth controls. The low-overhead report records source, backend, cache, workload, thread, input, state-transition, CPU-time, peak memory, exact binary SHA-256, enabled-feature SHA-256, target triple, build profile, compiler, allocator, linked-backend SHA-256, detector-corpus SHA-256, enabled-detector BLAKE3, compiled-plan BLAKE3, hashed detector-provenance, complete resolved-configuration BLAKE3, performance-policy BLAKE3, preset, applied protection state, source adapters, hashed source-target BLAKE3, hashed source-partition BLAKE3, raw source bytes, source-unit fanout, decode-derived bytes, completed backend-dispatch bytes, and stable size/fanout buckets. Byte domains that their source adapter cannot yet distinguish remain explicitly unavailable instead of becoming measured zeroes. The report does not record source content, credential values, raw paths, raw URLs, or raw configuration values. Use --perf-trace only for expensive per-pattern and backend diagnostic counters. Keep advanced pipeline controls unset unless a reproducible measurement on the target worker shows an improvement.

For a recurring full repository scan:

keyhog scan . --incremental \
  --format json-envelope --output keyhog.json

For a shared runner where the job is allocated four scanner workers and one reader worker:

keyhog scan . --threads 4 --reader-threads 1 \
  --format json-envelope --output keyhog.json

The second command is a resource budget, not a universal optimum. Measure the target host before choosing explicit worker counts.

For deep recovery and system-wide triage, use their dedicated guides because their coverage and completion rules differ from a normal repository scan.

Secret scanner benchmarks

These panels compare detection policy, CPU and GPU execution requests, incremental cache behavior, and warm daemon requests. Every value is generated from the checked benchmark snapshot. The snapshot binds the scanner version, executable digest, detector digest, corpus, host, and run timestamp. Use the full benchmark evidence for competitor provenance and per-category recall.

Detection accuracy

KeyHog KeyHog v0.5.70 scanned the mirror corpus: 15,000 fixtures, 3,000 labeled positives, and 2,431,242 input bytes. The answer-key manifest was excluded from the scan tree. The row uses the default policy on the explicit Hyperscan/SIMD route on AMD Ryzen 9 9950X 16-Core Processor.

The tracked source tree was clean.

Execution routes, presets, and cache

Measured on AMD Ryzen 9 9950X 16-Core Processor with NVIDIA GeForce RTX 5090, 32 logical cores, 15,000 fixtures, 3,000 labeled positives, and 2,431,242 input bytes. Scanner: KeyHog v0.5.70. The tracked source tree was clean.

Full scan by execution route

All rows use the default detection policy with incremental cache and daemon off. The automatic row records the requested policy, but the benchmark result does not bind the selected persisted route, so it is not routing proof. GPU rows include acquisition and full scanner startup on this small corpus; they are not GPU kernel crossover measurements.

Detection policy on Hyperscan/SIMD

The route, cache, daemon state, corpus, and host remain fixed. Presets change detection work, so compare precision and recall as well as time.

Incremental warm rerun

The benchmark populates the BLAKE3 Merkle index, then times the second identical scan. The small synthetic tree changes little because scanner startup dominates; measure your repository before claiming a speedup.

Warm daemon requests

One deterministic 8 MiB regular file (sha256:afafbe7b6487fd62866f510e7c281a9e7bfeaa8dc585d7b0478c92ee6c4f5ef5) was scanned once in process and once through an owned daemon after one warmup request. Daemon time is the client request; daemon RSS belongs to the resident server.

These rows cover the warm single-file route. The mass route also accepts bounded directory and remote-source batches; its incremental filesystem path is measured separately.

CPU, reader, storage, size, and partition scaling

Generated by make -C benchmarks readme-scaling from benchmarks/reports/readme-scaling.json. The harness ran 3 measured trials after 1 warm-up with explicit simd and daemon routing off. Worker scaling uses a warm client page cache to isolate CPU work. Reader, corpus-size, storage, and partition rows request clean-page eviction with posix_fadvise where the platform supports it; the snapshot records the policy on every row. Every workload is byte-deterministic and finding-free.

Host: AMD Ryzen 9 9950X 16-Core Processor, 32 effective logical cores, 94,140 MiB RAM, Linux 6.17.0-19-generic. Evidence: clean, binary 274b045489c4.

Scan worker scaling

Filesystem reader scaling

Corpus-size scaling

Storage scaling

Concurrent partition scaling

These rows are measurements, not universal tuning constants. Run the generator on the target host and storage. Use the knee where throughput stops improving, then reserve CPU and memory for the CI runner or orchestration layer.

Reproduce all four benchmark groups with make -C benchmarks readme-matrix. The command measures the required matrix and fails if any requested CPU, Hyperscan, CUDA, Metal, WGPU, preset, cache, daemon, thread, reader, storage, corpus size, or partition row is unavailable. Use make -C benchmarks readme-matrix-check to verify that both snapshots, reports, and README agree.

Choose a scan configuration

Start with the default policy and calibrated automatic routing. Change one axis only when the workflow requires it:

--fast, --deep, and --precision are mutually exclusive detection presets. --lockdown is a fail-closed execution mode, not a fourth preset. Explicit --backend values are diagnostics and benchmark overrides. They do not replace the persisted fastest-correct evidence used by automatic routing. See Configuration, autoroute calibration, daemon and warm scans, and hardening for the full contracts.

How KeyHog works

KeyHog compiles its 926 detectors into a shared trigger and extraction plan, decodes nested encodings before matching, and applies per-detector scoring, evidence, and suppression. Pure-Rust CPU (cpu-fallback) is always available. The Hyperscan route (simd-regex) uses Hyperscan when that feature is present; portable builds use the CPU route. CUDA (gpu-cuda-region-presence), Metal (gpu-metal-region-presence), and WGPU (gpu-wgpu-region-presence) are peers in a proof-backed autoroute selector, not a fallback chain. Calibration measures every eligible peer and persists the fastest route whose complete findings match the reference route for the exact binary, detector and configuration state, host, accelerator, and workload class. A missing, stale, invalid, or incomplete decision stops an automatic scan before execution and reports how to recalibrate. It never silently substitutes another backend.

See Architecture for the repository map, dependency direction, bytes-to-finding pipeline, and profiling entrypoints. See Backends and routing for execution contracts and Autoroute calibration for parity, workload identity, cache lifecycle, and repair procedures.

Full documentation: santhreal.github.io/keyhog - install, first scan, output formats, detection internals, suppressions, verification, pre-commit + CI integration, CLI reference, autoroute, exit codes, env vars, and contributing. Source under docs/.

Install KeyHog

Install the current crates.io release:

cargo install keyhog --locked

Build the repository checkout when you need an unreleased change:

cargo install --path crates/cli --locked

Confirm the installed build:

keyhog --version --full
keyhog doctor

Use the install guide for Rust toolchain requirements, feature profiles, and platform-specific runtime dependencies.

What it catches

926 embedded detectors with detector-owned offline validation and companions:

• Cloud providers: AWS (access key + secret + STS verification), Azure (subscription key, storage account key, SAS), GCP (service account, API key), Cloudflare, Heroku, Vercel, Supabase.
• Payment processors: Stripe, Braintree, Razorpay, Paddle, Plaid, Square, and PayPal, with detector-owned checks and optional or required companions. A Razorpay key secret requires its nearby key ID.
• Source forges: GitHub PATs (with CRC32 checksum), GitLab tokens, Bitbucket app passwords, npm tokens (with checksum), Gitea / Forgejo / Codeberg.
• Auth / SSO: Okta, Auth0, Clerk, JumpCloud, Kinde.
• Comms: Slack, Discord, Twilio, SendGrid, Postmark, Mailgun, Resend, Loops.
• AI / ML: OpenAI (sk-/sk-proj-), Anthropic, Google AI Studio, Cohere, Mistral, HuggingFace, Replicate. HuggingFace organization credentials include both the current hf_ form and legacy api_org_ tokens.
• Password managers: 1Password account secret keys (A3- followed by five or six segmented uppercase alpha-numeric components).
• Databases: Postgres connection strings, MongoDB Atlas, Supabase service-role, PlanetScale, Neon, Turso, MySQL, Redis URLs.
• Generic + entropy discovery: API_KEY=<high-entropy-blob> catches credentials with no named detector, gated by per-context entropy thresholds + ML scoring.
• Cryptographic material: RSA / EC / SSH private keys, PGP private blocks, JWT signing secrets.

Each detector ships as a TOML file (data, not code): service metadata, regex patterns, keywords, offline validators, entropy and ML policy, companion fields, and verification handler. Adding a new detector is a single reviewable TOML change; the contributor guide walks through it.

keyhog explain <id> dumps any detector's full spec: patterns, keywords, verification endpoint, plus a service-keyed rotation and step-by-step remediation guide, so a finding is never a black box:

Browse detector authoring and inspection in the detector reference, or query the installed corpus with keyhog detectors --search <term> --verbose.

Why higher recall, fewer false positives

• Decode-through scanning. Kubernetes Secret manifests, Jupyter notebooks, JWT payloads, base64-wrapped envs, Helm values, and docker-config auth: blobs. The structured preprocessor treats balanced Helm actions as inert render-time values and closes missing Jupyter delimiters at end of file, so literal bytes and complete code cells remain covered. It decodes structured values in place and feeds every downstream detector the plaintext. Detectors do not each need to re-implement decoding. Decode-enabled scans also recover side-effect-free JavaScript byte-array XOR and AES-256-CBC expressions when all recovery material is embedded, including strict CryptoJS/OpenSSL salted passphrase wrappers. KeyHog never executes the source.
• Multiline reassembly. "sk-proj-" + \ continuation in JavaScript, YAML multi-line strings, Makefile backslash-continuation, Helm / Jinja templated outputs, all reassembled before regex matching.
• Companion validation. Required companions gate high-noise detectors. A Twilio API key without its API secret is skipped. Optional companions enrich evidence scoring or verification. AWS access-key detection does not require its secret, but the secret is needed for live verification.
• Cross-detector resolution. Detector TOML can require, reject, or subsume bounded findings from another detector. Resolution stays deterministic across input order, and invalid targets, contradictions, or dependency cycles fail corpus compilation.
• Evidence verdicts. Every finding carries an exact review, likely, or confirmed tier plus a canonical reason code. Intrinsic checksum or grammar proof, required companions, and live verification produce confirmed evidence; strong vendor-specific shape in a credential-bearing role produces likely evidence; weak anchors, generic assignments, entropy-only candidates, and test, documentation, rule, or identifier contexts remain review evidence. An optional supplements the verdict when measured. Default threshold controls the scanner's internal confidence floor and remains configurable with .

Performance

Use the reproducible harness in benchmarks/ to compare KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog, and Titus under one scoring contract. The harness excludes the ground-truth manifest from every scan tree. The generated tables remain empty until current-schema runs exist. Run make -C benchmarks report after measurement. Do not edit generated tables by hand.

Detection leaderboard

Corpus: mirror - 15000 fixtures, 3000 labeled positives. Every scanner scored identically (SecretBench overlap rule); the answer-key manifest is excluded from the scan tree.

Result provenance

Speed & memory

Per-category recall comparison

Diagnostic recall slice only. Overall precision and F1 remain the comparison contract; false positives are counted in their scored categories.

Bounded static recovery telemetry

Selected run: scanner KeyHog KeyHog v0.5.70<br>Commit: d1eb2e09eb2c289181d93d719ce3f62411aeaf2c<br>Detector Set: 926 (926-4168e2c6c93a16ca)<br>Build Target: x86_64-linux<br>ML Model Version: moe-v1-246a05b92bec9aa3<br>ML Model Card: recorded 2026-07-15; features 55; synthetic F1 0.971 / P 0.945 / R 0.999; real F1 0.832 / P 0.753 / R 0.931 / [email protected] 0.938; zero-recall detectors 2/32; six-scanner differential unavailable; corpus mirror (15,000 fixtures, 2,431,242 bytes); generated 2026-08-11T01:29:39Z; artifact mirror-keyhog-simd-nocache-nodaemon-full.json.

Telemetry schema: static-recovery-v1.

Bigram Bloom evidence

Evidence schema: bloom-evidence-v1.

Finding identity binds detector, file, line, byte span, and credential SHA-256; plaintext credentials are never recorded.

Reproduce: make -C benchmarks canonical KEYHOG_BIN=/absolute/path/to/keyhog reruns the exact KeyHog, Betterleaks, Kingfisher, Nosey Parker, TruffleHog, and Titus mirror run set, including the executable-bound CredData Bloom differential, make -C benchmarks report regenerates the tables above and benchmarks/reports/. See benchmarks/README.md for the corpora (mirror, competitor home-turf, Samsung/CredData) and the backend/cache/daemon/OS/GPU matrix.

GPU-backed mass daemon workers

The optional Unix mass daemon keeps one compiled scanner and its calibrated backend state warm. Local filesystem scans send only canonical root and source-policy metadata; the daemon reads and batches the files in its own process. Git, binary, remote, and cloud sources that require client-side credentials use protected bounded chunk frames.

# Terminal 1
keyhog calibrate-autoroute --policy default
keyhog daemon start --mass

# Terminal 2, after the daemon prints its ready line
keyhog scan --daemon=mass /srv/inventory/team-a \
  --format json-envelope --output team-a.json
keyhog daemon stop

--daemon=mass is a required route. It never retries in process. Each batch is bounded to 8 MiB and 1,024 chunks, independent of total input size. Preserve the coverage envelope, exit status, and terminal execution receipt for every inventory partition.

See daemon lifecycle, routing, and receipts and inventory partitioning.

System-wide credential triage

sudo keyhog scan-system --space 50G
sudo keyhog scan-system --include-network --output system-findings.json

scan-system is a bounded local-host audit, not a replacement for repository or cloud inventory partitioning. It bounds itself by total bytes scanned rather than by path: --space is the ceiling, and network-mounted filesystems are skipped unless you pass --include-network. Review mount, network-filesystem, space-ceiling, and privilege behavior before running it. See system-wide triage.

Lock down sensitive local scans

Linux --lockdown is a fail-closed process-protection mode:

keyhog scan . --daemon=off --lockdown

It locks current and future memory, disables core dumps and the incremental cache, remains in process, and refuses verification, plaintext output, fast mode, and completeness-reducing switches. It fails on unsupported platforms or insufficient locked-memory capacity. See hardening and data handling.

Use KeyHog as a Rust library

use keyhog_core::{Chunk, ChunkMetadata, RawMatch};
use keyhog_scanner::CompiledScanner;

let detectors = keyhog_core::load_embedded_detectors_or_fail()?;
let scanner = CompiledScanner::compile(detectors)?;
let findings = scanner.scan(&Chunk {
    data: "TOKEN=sk_live_EXAMPLE…".into(),
    metadata: ChunkMetadata::default(),
})?;
let report_safe: Vec<_> = findings.iter().map(RawMatch::to_redacted).collect();

The default library methods are deterministic portable CPU references. Explicit backend methods return typed errors instead of terminating the process or silently substituting another engine. Raw chunks and matches can contain plaintext. Convert them with RawMatch::to_redacted, or use final VerifiedFinding values, before JSON, logs, disk, or network boundaries.

The architecture guide defines crate ownership, backend contracts, recovery receipts, source helpers, and safe reporting boundaries. Crate-level Rust documentation owns the complete API.

Configure policy with explicit precedence

Repository policy lives in .keyhog.toml:

verify = false

[scan]
severity = "high"
incremental = true

[system]
gpu = "auto"

Resolution order is built-in defaults, user configuration, repository configuration, environment where documented, then explicit CLI overrides. Unknown keys and invalid combinations fail before scanning. Run keyhog config --effective to inspect the resolved policy without exposing proxy credentials. Entries past expires fail allowlist load before scanning.

See configuration and precedence for every key and environment variables for credential and runtime inputs.

Architecture

KeyHog keeps orchestration at the edge and domain behavior in libraries:

sources -> scanner -> suppression/evidence -> reporting
                 \-> optional verifier
CLI and Action own process, transport, and exit semantics.

Detector definitions remain data under detectors/. keyhog-core owns detector and finding types, keyhog-scanner owns matching and execution backends, keyhog-sources owns input acquisition, keyhog-verifier owns live checks, and keyhog-cli owns operator workflows.

Start with the architecture guide for the repository map, dependency direction, bytes-to-finding pipeline, routing ownership, and profiling entrypoints.

Inspect and extend the installation

keyhog detectors --search aws --verbose
keyhog explain aws-access-key
keyhog backend --autoroute --json
keyhog completion zsh

The CLI reference lists every command, flag, generated default, and exit status. Use keyhog --help and keyhog <command> --help for the exact installed version.

Contributing

• New detector? Drop a TOML in detectors/, open a PR. The contributor guide (CONTRIBUTING.md) has the schema and a worked example.
• Bug / missed secret / false positive? File an issue with the redacted credential shape and detector id; each report becomes a permanent test fixture under crates/scanner/tests/contracts/.
• Release behavior? Every successful main CI run increments the patch version, generates changelogs, and publishes all six crates to crates.io. Add an optional fragment under changes/ for a precise note. The release guide covers the automatic transaction and failed-upload recovery.
• Security issue in KeyHog itself? Don't open a public issue; use GitHub private vulnerability reporting. If that form is unavailable, email [email protected]; PGP is not required.

Changelog. Open issues.

Credits

KeyHog stands on prior secret-scanning work. Ideas borrowed from:

• TruffleHog: detector breadth and verification semantics
• Betterleaks: token-efficiency and false-positive suppression
• Titus: scanning ergonomics and severity calibration

Thanks to these projects and their contributors.

License

License: MIT OR Apache-2.0.

Terms: MIT and Apache-2.0. This dual license covers the code and detector TOMLs. Commercial use, embedding, forks, and hosted services are permitted under either license.

Star history

_{Generated from UTC observations of GitHub's public star count. The repository stores the first point and each later count transition. Same-day reruns replace that day's point, and unchanged counts create no commit.}