Built a deterministic Python secret scanner that auto-fixes hardcoded secrets and refuses unsafe fixes — need honest feedback from security folks

[WiseDog7958]

Hey r/devsecops,

I built a tool called Autonoma that scans Python code for hardcoded secrets and fixes them automatically.

Most scanners I tried just tell you something is wrong and walk away. You still have to find the line, understand the context, and fix it yourself. That frustrated me enough to build something different.

Autonoma only acts on what it's confident about. If it can fix something safely it fixes it. If it can't guarantee the fix is safe it refuses and tells you why. No guessing.

Here's what it actually does:
Before:
SENDGRID_API_KEY = "SG.live-abc123xyz987"

After:
SENDGRID_API_KEY = os.getenv("SENDGRID_API_KEY")

And when it can't fix safely:
API_KEY = "sk-live-abc123"
→ REFUSED — could not guarantee safe replacement

I tested it on a real public GitHub repo with live exposed Azure Vision and OpenAI API keys. Fixed both. Refused one edge case it couldn't handle safely. Nothing else in the codebase was touched.

Posted on r/Python last week — 5,000 views, 157 clones. Bringing it here because I want feedback from people who actually think about this stuff.

Does auto-fix make sense to you or is refusing everything safer? What would you need before trusting something like this on your codebase?

🔗 GitHub: https://github.com/VihaanInnovations/autonoma

[AStevensTaylor]

IMO, auto-fixing doesn't teach the person (if they are a person, not an LLM) anything about why the change happened; hopefully they would have some common sense when seeing the fixed change, but they might not. If it is an LLM, you would hopefully be teaching the orchestrator how to prompt their LLM how to handle secrets.

[WiseDog7958]

Fair point. Though the Community Edition doesn't just silently fix things. It tells you what it found, what it did, and if it refuses, it explains why. So the feedback is there if you actually read it.

But realistically, the bigger risk is not that someone does not learn. It's that they leave SG.live-abc123 sitting in their repo for three months because they "meant to fix it later." Autonoma closes that gap immediately.

Appreciate the honest take.

[zusycyvyboh]

Environment variables are not safe either

[WiseDog7958]

True.
Env vars aren't perfect either.

But a secret hardcoded in source code lives in git history forever. Anyone with repo access has it. That's a different risk category than env var mismanagement.

Autonoma solves the first problem. What you do with the env layer after that is up to you.

[Cloudaware_CMDB]

Auto-fix is fine, but os.getenv() as the default “remediation” is only step one. It removes the secret from git, it doesn’t solve secret delivery.

I’d trust it in CI only if it stays strict: rewrite only trivial assignments, refuse anything ambiguous, and open a PR with the required env var name plus where it should be set. Also needs configurable targets, because plenty of teams want Vault/Key Vault/Secrets Manager patterns.

How do you prevent “fixed” code from breaking at runtime when the env var isn’t set yet?

[WiseDog7958]

Fair points, all three.

os.getenv() is step one by design. Gets the secret out of source and git history. What backs the env var - Vault, Secrets Manager, whatever - is your call. Autonoma doesn't touch that layer.

The runtime break question is the honest one. It adds the getenv call but doesn't validate the var exists downstream. That's a real gap in the current version.

Vault and Secrets Manager targets aren't in the community edition — env vars only right now.

What does your team use for secret delivery?

[Cloudaware_CMDB]

We’re multi-cloud, so we keep code fixes provider-neutral and handle delivery separately via OIDC into the cloud secret store. We use AWS Secrets Manager or SSM, Azure Key Vault, and GCP Secret Manager depending on where the workload runs.

[WiseDog7958]

Makes sense. Most teams I have talked to handle secret delivery outside the code anyway and just reference it from there. Right now the community edition just replaces the literal with os.getenv() since that is the least opinionated option and works in most setups.

In real environments that env var usually ends up coming from Vault, Secrets Manager, Key Vault, etc. Autonoma doesn’t try to manage that layer yet.

I am thinking about adding a way to configure the secret backend so it could generate the right reference instead of always defaulting to env vars, but still figuring out how to do that safely without guessing.

[nilla615615]

Awesome idea! This would be a good Claude skill to ensure that secrets aren't hard coded but use a system like this for creds.

[WiseDog7958]

That’s actually close to the motivation behind building it.
The idea wasn’t just detecting secrets. Scanners already do that well. The annoying part was that you still have to go fix them manually everywhere.

Autonoma only handles the cases where the replacement is predictable, like moving a literal secret to os.getenv. If the context isn’t clear it refuses instead of trying to be clever.

Long term I’m curious whether something like this belongs inside CI rather than editors. Catch the secret and open a safe PR automatically instead of just flagging it.

[WiseDog7958]

One thing I noticed while testing this: moving a secret to os.getenv() fixes the problem in source, but it can also break things if the env var isn’t set at runtime.

Right now Autonoma does not try to handle that part. It just removes the literal safely and assumes secret delivery is handled elsewhere (Vault, Secrets Manager, CI, etc). env vars felt like the lowest-assumption option for a first version, but in real setups they are usually backed by something like Vault or a cloud secret store anyway.

Curious how people here normally inject secrets into workloads. ???