GitHub - puck-security/geiger: Detection tells you a key is real; geiger tells you whether it's dangerous.

Is it still live, what does it reach, and how bad? Read-only blast-radius triage for leaked credentials.

Your secret scanner found the key — it won't tell you if it's still live or what it unlocks. geiger does: pipe any credential-bearing text at it and it recognizes the credentials inside, runs read-only recon with each, and ranks what they actually reach by blast radius.

Dual-use triage: an incident responder's "how bad is this?" and a pentester's "what does this key reach?". Read-only by construction, dry-run by default.

Install

Binary — grab the archive for your OS/arch from Releases:

tar xzf geiger_*_linux_amd64.tar.gz && sudo mv geiger /usr/local/bin/

Source (Go 1.25+):

git clone https://github.com/puck-security/geiger && cd geiger
go build -o geiger ./cmd/geiger

Tutorial

geiger doesn't touch anything on the network until you say so. Dry-run first (default): it recognizes the credential and prints the read-only calls it would make. Try it on AWS's well-known example keys — no real secret needed:

printf 'AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE\nAWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\n' | geiger

That prints the read-only calls it would run (sts:GetCallerIdentity, …). Add --live with a real credential to actually run them and get the impact note:

echo 'GITHUB_TOKEN=ghp_...' | geiger --live

How-to

# a file, stdin, or a cloud CLI's output
geiger --live .env
cat sso-cache.json | geiger --live
aws configure export-credentials | geiger --live

# the current environment
geiger --env --live

# a whole repo / dir (walked; results sorted by impact)
geiger --live ./leaked-repo

# a scanner's report — e.g. a TruffleHog sweep of a compromised laptop,
# exactly what supply-chain worms (Shai-Hulud) run; triage which creds reach prod
geiger --live --from-trufflehog trufflehog.json
geiger --live --from-gitleaks gitleaks-report.json

# rank by YOUR crown jewels (boost anything touching these to HIGH+)
geiger --live --context '1234567890,acme-prod,billing-service' ./repo

# self-hosted services need a host
echo 'VAULT_TOKEN=hvs....' | geiger --live --endpoint https://vault.internal:8200

# only what matters; save a clean artifact
geiger --live --min-severity high -o case-1234.txt ./repo

# OPSEC: identity call only; route egress through a proxy
geiger --live --min-footprint --proxy socks5://127.0.0.1:9050 .env

# machine-readable
geiger --live --json ./repo | jq .

Go deeper — --intrusive (doesn't modify resources, but leaves a trail): connects to databases (Postgres, MySQL, MongoDB, Redis, SQL Server, Oracle, ClickHouse, Cassandra — fixed catalog queries, read-only session), reads local SQLite/IDE stores in place, hits cluster APIs, redeems cached user refresh tokens (Azure / GCP sessions) to map their reach — an active sign-in that shows in the tenant's audit log — and follows secrets-store reads, draining Vault/Doppler/1Password/cloud secret managers (AWS SM, GCP SM, Azure Key Vault) and recursively triaging each extracted secret. The same fan-out a worm performs, so you see the real blast radius. Plain --live stays read-only: it uses a still-valid cached token but never redeems a refresh token.

geiger --live --intrusive .env

SSH keys — point it at a directory; it fingerprints each key (encrypted keys are locked, not dead). --ssh-correlate lists candidate target hosts from ~/.ssh/config, known_hosts, and shell history.

geiger --ssh-correlate ~/.ssh

Where geiger fits

geiger is not a scanner — it starts where they stop. Detection finds the secret; geiger triages it. Point gitleaks or TruffleHog at the haystack, then pipe the report in (--from-gitleaks / --from-trufflehog) to learn which hits actually reach prod.

¹ TruffleHog's analyze enumerates permissions for ~a dozen providers — the closest peer; geiger generalizes that to ~163 credential types with blast-radius scoring and downstream harvest. ² GitGuardian assigns validity/severity inside its platform.

Detection is their job and they're good at it — geiger doesn't replace them, it answers the question they leave open: now that you found it, how bad is it?

Reference

Flags

Tiers

CRITICAL · HIGH · MEDIUM · LOW · INFO · DEAD — a composite blast-radius score (capability × reach × sensitivity), relative not absolute. --context matches and force-multiplier capabilities force at least HIGH.

What geiger reads — and what it can't

geiger triages a credential you were handed, or one sitting on disk.

• In scope — on-disk / offline-readable. API tokens, connection strings, cloud CLI caches (~/.aws, gcloud, MSAL), SSH keys, kubeconfigs, secrets-manager creds, MCP configs, AI-IDE plaintext token stores, password-manager recovery material (KeePass, encrypted Bitwarden — offline-crackable with the master password), plaintext exports, and Firefox saved logins (logins.json + key4.db), which decrypt offline when no primary password is set.
• Out of scope — in-process / OS-bound. Chromium passwords & cookies (wrapped by DPAPI / macOS Keychain / Secret Service), raw DPAPI blobs, the macOS Keychain, LSASS. Reading those means decrypting against a live OS session — credential extraction from a host, not triage of one. Not always a black and white line.

Coverage

Recognition rides on gitleaks (shape/checksum) plus geiger's own shape/env-name recognizers; an unrecognized type is reported unknown, not characterized. Triage keys on capability — a key that runs code, wipes devices, restores backups, or reads other secrets is a force multiplier; a billed-usage API key is a warning.

Output

A block per credential: a tier, a redacted title with the source location, never the raw secret, labeled findings (⚠ notable, ⚠⚠ force multiplier, ? can't-determine-read-only), and a one-line takeaway.

For IR, each finding leads with where and when: an exposure line classifies the source — a crash dump (in-memory, persisted to disk, often auto-uploaded — may have left the host), a VS Code local-history snapshot, an IDE secret store, shell history, a log — and source modified / validated live carry the file mtime and live-check timestamp. When a secret turns up in several files, also exposed in groups them by class (8 local-history snapshots; 7 crash dumps) instead of listing paths (the full list expands under -v and in --json).

With -v each planned call prints as a copy-pasteable curl. Triaging more than one credential prints a closing summary — tier breakdown, rotate-first queue, and follow-ups (secrets-store reach, what couldn't be characterized, anything hidden by --min-severity). GitHub write/admin and org-admin are read from each repo's permissions and /user/memberships/orgs, so they're reported even for fine-grained PATs that expose no scopes.

Drift resilience. Beyond declared field paths, every response is scanned heuristically (admin/owner indicators → force multiplier; a fallback identity + count when the API shape changed), so a module stays useful as providers rename fields. --trace shows the raw request/response (secrets masked).

How it works

Pipeline: recognize → (authenticate) → recon → note. Recon runs the identity/whoami call first, then a couple of count calls to size reach.

Safety model

• Read-only by construction. One client allows only GET/HEAD plus a short allowlist of read-only POSTs (STS GetCallerIdentity, k8s SelfSubjectRulesReview, the single OAuth token exchange). DB recon uses a read-only session and a fixed query allowlist. Local stores (SQLite, IDE state.vscdb, Firefox key4.db) open read-only. A guard test enforces this across every module.
• Dry-run by default. --live is required and always prints the destinations it hits (real provider APIs, and their audit logs).
• Attribution. Recon identifies itself as geiger/<version> — dual use beware, no detection evasion; defenders can attribute the calls.
• Secrets are not printed or stored. Redacted everywhere; scrubbed from URLs, headers, and errors.
• Untrusted-input hardening. Refuses cloud-metadata targets (SSRF), sanitizes hostile API responses, strips file-referencing DSN options

Principle: likely impact, not perfect impact. geiger is triage, not deep cloud-privesc graphing (use PMapper/CloudFox/ScoutSuite/etc for that).

Authorized use only. geiger exercises live credentials — run it only on creds you are entitled to triage.

Contributing a module

Most providers are a few lines of declarative recipe:

add("digitalocean-pat", recipe.HTTP{
    ModuleName: "digitalocean", Base: "https://api.digitalocean.com",
    Auth:   recipe.AuthSpec{Kind: recipe.Bearer},
    Whoami: recipe.GET("/v2/account").Field("email", "account.email"),
    Calls:  []recipe.Call{recipe.GET("/v2/droplets").CountFrom("meta.total", "droplets")},
}.Module())

Add an httptest-backed test, then go run ./tools/coverage to refresh the coverage table above. Exotic signing (SigV4, RS256-JWT, Digest) implements the module.Module interface directly with the internal/sign + internal/auth helpers — see internal/modules/ for examples.