G4ENV: THE LAZY SECRET HUNTER THAT NEVER LEAVES YOUR LAPTOP

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

g4env is a terminal-native security auditor that hunts for exposed secrets in your .env files, config files, CI/CD pipelines, and codebases, so you don't have to.

Checking a project for leaked credentials by hand means grepping, squinting at YAML, and hoping you remembered to add .env to .gitignore. g4env replaces all of that with one command:

g4env audit .

It doesn't just flag problems. It hands you a remediation plan: what leaked, why it matters, and what to fix first. It's built for the developer who wants to set up a check once (pre-commit or CI) and forget about it until it catches something.

It's also different from GitHub secret scanning. GitHub blocks known provider key formats on their way to GitHub. g4env is a linter for configuration that runs before anything leaves your machine, and it catches things GitHub has no opinion on: your internal Postgres password, a real key pasted into .env.example, a hardcoded Authorization header, a literal secret in a CI workflow, or a .env file that was never added to .gitignore. The strongest setup uses both.

Demo

g4env is a CLI, so the demo is one command. The repo ships fixtures that trigger every rule, so you can see it work with no model, no API key, and no network:

git clone https://github.com/CYBWithFlourish/g4env.git
cd g4env
python -m venv .venv && source .venv/bin/activate
python -m pip install -e ".[dev]"
g4env audit examples

(It isn't on PyPI yet, so you run it from a clone.)

Output:

g4env 1.0.0  |  target: examples
provider: rules (offline)  |  model: -  |  schema: 1.0
files scanned: 10  |  duration: 9 ms
risk score: 100/100

17 finding(s): 1 critical, 11 high, 5 medium.

  [CRITICAL] env.private-key  keys/deploy_key.txt:5
    Private key embedded in configuration
    ...

And here's what a finding looks like on a typical project. Note that secret values are masked in the output:

  [HIGH] env.raw-secret  .env:2
    Raw API token detected
    A plaintext Stripe key was found assigned to STRIPE_API_KEY.
    evidence  STRIPE_API_KEY=sk_live_****
    impact    Exposed credentials can lead to unauthorized service access.
    fix       Move secrets to a secure secret manager or environment store.

Next steps
  1. Rotate every credential that is stored in plaintext; assume it has already leaked through version control history.
  2. Move the values into a secret manager or your platform's encrypted environment store and reference them with a variable.
  3. Add the .env files to .gitignore, remove them from the index and purge them from the git history.
  4. Re-run `g4env audit .` to confirm that the remediation worked.

Code

CYBWithFlourish / g4env

A fast, offline-first CLI tool for auditing .env files, configuration schemas, and codebases for hardcoded credentials, secret leaks, and security anti-patterns using deterministic rules and local Gemma models.

g4env - Gemma 4 Environment Security

Catch exposed secrets before they become security vulnerabilities.

g4env is a local-first, terminal-native security auditing tool designed to help developers identify exposed credentials, hardcoded secrets, and insecure environment configurations before they become a problem.

It scans .env files, configuration files, CI/CD pipeline definitions, and codebases for potential security risks, including API keys, private keys, database credentials, weak passwords, and other sensitive values that should never be exposed or committed to version control.

By combining fast, deterministic rule-based detection with optional AI-powered contextual analysis through locally running Gemma models, g4env helps developers identify security issues while maintaining control over their sensitive configuration data.

Unlike tools that require cloud-based analysis by default, g4env is designed to work offline out of the box. Its default rule-based auditing engine makes no network requests, while its optional Ollama integration enables deeper analysis using models running on your own machine.

…

View on GitHub

Licensed GPL-3.0-or-later. Docs for providers, rules, and CI wiring are in the repo's docs/ folder.

How I Built It

g4env is a Python CLI with a layered design:

1. Deterministic rules first. Nine rules cover raw vendor keys (AWS, GitHub, GitLab, Google, OpenAI, Anthropic, Stripe, Slack and more), embedded private keys, database URLs with passwords, weak passwords, real secrets in template files, high-entropy strings, hardcoded Authorization headers, literal secrets in CI files, and .env files not excluded from version control. These run instantly with zero network requests, on any machine.
2. Optional local Gemma on top. With --provider ollama, g4env sends redacted content to a Gemma model running on your own machine through Ollama (gemma2:2b by default). The model adds contextual findings that regexes can't catch, like an internal bearer token with no recognizable format.

ollama pull gemma2:2b
g4env audit . --provider ollama   # rules + local Gemma reasoning

1. No GPU? No problem. Not every machine can run local inference, so g4env also supports an opt-in hosted provider through the Gemini API:

export GEMINI_API_KEY="your-key"
g4env audit . --provider gemini   # rules + hosted Gemini reasoning

The key is read from the environment and is never accepted as a command-line flag. Only redacted content is sent, and the report records that a network call happened ("offline": false, "network_scope": "remote"). So there are three tiers: rules only (zero network, the default), local Gemma via Ollama (localhost only), and hosted Gemini (remote, explicit opt-in).

A few other design decisions worth calling out:

• Redaction on the way out and on the way in. Secrets are masked in terminal output by default, and redacted again before any content reaches a model, so a screenshot or CI log never becomes a new leak.
• Schema-validated reports. Every report follows a versioned JSON schema and is validated before it's written, so you can diff it, store it, and gate CI on it.
• CI-friendly exit codes. --fail-on high (the default) exits with code 3 when a finding meets the threshold, so g4env works as a pipeline gate.
• Respects your ignore rules. Directory scans honor .gitignore and a .g4envignore file, and skip vendored dependencies, build output, and binaries.
• Measurable quality. g4env bench runs a labelled test set so detection quality can be compared across providers instead of guessed at.

The project also ships with automated tests, linting, type-checking, and a CI workflow.

Why Does Open Innovation Matter?

A secret scanner has an awkward property: the thing it analyzes is your secrets. Sending .env files to a closed API in order to find leaked credentials is a bit like mailing your house key to a locksmith to check whether your lock is weak.

An open-weight model changes that:

• Nothing leaves your machine. With Gemma on Ollama, analysis stays on localhost, and the report says so ("network_scope": "localhost-only").
• It works air-gapped. Auditing proprietary code doesn't require uploading it anywhere.
• It costs nothing per scan, so there's no reason not to run it on every commit.
• It's swappable. The --model flag lets you change models without touching the tool, and you can point --host at any Ollama server you control.

There's a real trade-off, and I'd rather state it than hide it: a small local model reasons less well than a large hosted one, and not everyone has hardware that can run one. That's why the deterministic rules run first and work everywhere, with local Gemma as the private upgrade and hosted Gemini as a clearly labelled opt-in for people who want more reasoning power without a GPU. The open-weight path is what makes the privacy-first default possible, and the hosted path is there when convenience matters more. With open models that choice is yours. With a closed API, it's made for you.

The Lazy Payoff

The goal was to turn a tedious manual audit into a command you run once and trust. Pointed at the bundled demo fixtures, g4env scans 10 files and surfaces 17 findings (1 critical, 11 high, 5 medium) in about 9 milliseconds, each with a severity, the exact file and line, and a concrete fix. The "next steps" list at the end of every report means you never have to work out what to do after a finding. Wire g4env audit into pre-commit or CI and the check runs on every change without you thinking about it again.

Prize Categories

• Best Use of Gemma: g4env runs Gemma locally through Ollama to add contextual secret detection on top of its deterministic rules, keeping sensitive configuration on the user's own machine.