DEV Community

Cover image for Ensor, censorship for your codebase
PRATYAY MUSTAFI
PRATYAY MUSTAFI

Posted on AI-assisted

Ensor, censorship for your codebase

Ensor: Censorship for Your Codebase

Detect it. Redact it. Keep the code readable.

Hardcoded secrets are one of those problems that looks simple until you're dealing with a real codebase.

API keys end up in HTTP collections. Tokens get copied into YAML files. Credentials sneak into examples, configuration files, test fixtures, or snippets that eventually find their way into Git.

Secret scanners are excellent at telling us that a secret exists.

Secret managers are excellent at telling us where secrets should live.

But there is an awkward step in between:

What do you actually do with the secret that is already sitting inside your code?

That's the problem I built Ensor to solve.

What is Ensor?

Ensor is a fast, interactive CLI for detecting and redacting secrets from your codebase, while also providing tools for managing environment-variable formats.

It is designed around a simple workflow:

Codebase
   ↓
Scan for secrets
   ↓
Identify the value
   ↓
Map it to a variable
   ↓
Replace the hardcoded secret
   ↓
Keep the code readable
Enter fullscreen mode Exit fullscreen mode

By default, Ensor extracts discovered secrets into an environment file and replaces the values in your project with configurable placeholders.

So instead of this:

headers:
  Authorization: Bearer sk_live_xxxxxxxxxxxxxxxxx
Enter fullscreen mode Exit fullscreen mode

you can end up with something like:

headers:
  Authorization: Bearer ${STRIPE_SECRET_KEY}
Enter fullscreen mode Exit fullscreen mode

The important part is that the surrounding file remains readable.


The Missing Step in Secret Management

There are already excellent tools for different parts of the secret-management lifecycle.

Tools such as Gitleaks, TruffleHog, and betterleaks can help detect secrets.

Then there are tools and systems for actually managing secrets:

  • SOPS
  • Vault / OpenBao
  • Infisical
  • Bitwarden Secrets Manager
  • cloud secret managers
  • GitOps-oriented secret workflows

These solve different problems.

But detection often leaves you with a very manual task:

"Okay, we found the secret. Now go through the project and replace it everywhere."

That's the part Ensor focuses on.

It sits between secret detection and secret management.


The Problem That Started It

I wanted to keep my API requests and development configuration in Git.

For example, Bruno stores requests as .bru files, while many other API clients and development tools use YAML, JSON, TOML, or similar formats.

I wanted those files to remain useful when I wasn't sitting at my main machine.

That created an annoying choice.

Option 1: Encrypt everything

Using something like SOPS is great when you need encrypted files.

But encryption also means the file is no longer immediately readable.

Instead of opening a request and seeing:

method: GET
url: https://api.example.com/users
headers:
  Authorization: Bearer ...
Enter fullscreen mode Exit fullscreen mode

you might first have to decrypt it.

Option 2: Manually remove the secrets

This works.

It is also exactly the kind of repetitive task people eventually forget to do.

And secrets don't only live in .env files.

They can appear inside:

  • API request collections
  • YAML configuration
  • JSON files
  • example code
  • shell scripts
  • test fixtures
  • documentation
  • generated files
  • random configuration files

That is where automation becomes useful.


How Ensor Works

Ensor is built around three main capabilities.

1. Scan and redact secrets

Run:

ensor
Enter fullscreen mode Exit fullscreen mode

Ensor scans the current project for potential secrets and helps redact them.

The scanner is powered by the betterleaks detection engine.

Rather than simply reporting:

SECRET FOUND
Enter fullscreen mode Exit fullscreen mode

Ensor turns the finding into an actionable workflow.

You can associate the detected value with a meaningful environment-variable name and replace the hardcoded value in the codebase.


2. Map existing environment variables

Suppose you already have:

STRIPE_SECRET_KEY=sk_live_xxxxxxxxx
DATABASE_URL=postgres://...
GITHUB_TOKEN=ghp_xxxxxxxxx
Enter fullscreen mode Exit fullscreen mode

Ensor can use those values as a source of truth and find where they appear in your project.

Instead of manually searching for the raw values, Ensor can replace them with their corresponding variable names.

So this:

const token = "ghp_xxxxxxxxx";
Enter fullscreen mode Exit fullscreen mode

can become:

const token = process.env.GITHUB_TOKEN;
Enter fullscreen mode Exit fullscreen mode

The exact replacement depends on the file and workflow, but the goal is the same:

remove the secret while keeping the code useful.


3. Convert environment files

Ensor is not only a redaction tool.

It also includes:

ensor convert
Enter fullscreen mode Exit fullscreen mode

for converting environment configurations between common formats.

For example:

.env
 ↓
JSON
 ↓
YAML
 ↓
TOML
Enter fullscreen mode Exit fullscreen mode

This is useful when different tools expect different configuration formats.

You can keep one set of environment values and translate it when needed rather than manually rewriting the same configuration.


Why an Interactive CLI?

I deliberately didn't want Ensor to behave like another silent black-box scanner.

Secret remediation can be destructive.

A tool replacing values throughout a project should make it obvious what is happening.

That's why Ensor uses an interactive terminal interface.

It is built with Huh, Bubble Tea, and Lip Gloss.

The result is a workflow that lives in the terminal but still provides enough interaction to review what the tool is doing.


A Practical Workflow

A typical workflow might look like this:

cd my-project

ensor
Enter fullscreen mode Exit fullscreen mode

Ensor scans the project and identifies potential secrets.

You can then map the discovered values to environment-variable names and let Ensor replace them in the relevant files.

Your Git diff becomes something closer to:

- Authorization: Bearer sk_live_xxxxxxxxx
+ Authorization: Bearer ${STRIPE_SECRET_KEY}
Enter fullscreen mode Exit fullscreen mode

The important thing isn't the exact placeholder syntax.

It's that the source code remains understandable without embedding the credential itself.


Install Ensor

Using mise

mise use github:pratyay360/ensor@latest
Enter fullscreen mode Exit fullscreen mode

Using Go

go install github.com/Pratyay360/ensor@latest
Enter fullscreen mode Exit fullscreen mode

Using the install script

curl -sSL https://raw.githubusercontent.com/Pratyay360/ensor/main/install.sh | sh
Enter fullscreen mode Exit fullscreen mode

Prebuilt binaries and packages are also available for Linux, macOS, Windows, and FreeBSD in the GitHub Releases.


See It in Action

Here's a short video demonstrating the CLI:

There are also interactive terminal demos:

And for environment conversion:


asciicast

What Ensor Is — and Isn't

Ensor isn't intended to replace a proper secrets manager.

It also isn't a substitute for secret rotation after a credential has been exposed.

If a real credential has already been committed to a repository, the correct response is still to treat that credential as compromised and rotate or revoke it as appropriate.

Ensor addresses a different part of the workflow:

How do I remove secrets from the codebase without turning the code itself into an unreadable mess?

That's the gap I'm trying to fill.


What's Next?

Ensor is still evolving.

There are plenty of places where secret redaction can become smarter: better mappings, more file formats, improved replacement strategies, stronger integrations, and tighter development workflows.

The project is open source, so contributions, issues, and ideas are welcome.

Links

GitHub:
https://github.com/Pratyay360/ensor

License: Apache-2.0


Final Thought

Secret management is often presented as a binary problem:

secret or no secret.

In practice, there is a whole workflow around that secret.

You need to detect it.

You need to identify what it belongs to.

You need to remove it from the code.

And you need to keep the code usable afterwards.

Ensor is built for that middle step.

Censorship for your codebase.

Top comments (0)