A standard to

Return lost environment variables to their rightful owners

Your leaked credentials have no return address.

Add SECURITY_TXT to your environment files so researchers can contact you without using your secrets.

Sensitive environment variables leak in countless ways. Committed to public repos. Exposed in CI logs. Shipped in Docker images. Pasted into Slack. Security researchers find them constantly.

Figuring out who to return them to? That's the hard part. Most leaked credentials offer no clue about their owner, and using them to find out is ethically murky, potentially illegal, and puts researchers at risk.

Adopt the Standardanybody can make up a standard on the internet. look at us go!

1

Set up security.txt

Create a security.txt (opens in new tab) file at /.well-known/security.txt on your domain. This is RFC 9116 (opens in new tab), the standard way for researchers to find your security contact.

2

Add SECURITY_TXT to your environment

Include this variable anywhere you store environment configuration: .env files, CI secrets, Docker configs, Kubernetes manifests. Spread it around.

SECURITY_TXT=https://yourdomain.com/.well-known/security.txt
3

Commit to your templates

Add it to .env.example, .env.template, and your documentation so every project and team member adopts it by default.

$ cat .env
DATABASE_URL=postgres://user:pass@host/db
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfi...
STRIPE_SECRET_KEY=sk_live_...
SECURITY_TXT=https://example.com/.well-known/security.txt

While You're At It...

Consider adding canary tokens (opens in new tab) to your environment files. These are fake credentials that alert you when someone tries to use them, giving you early warning that your secrets have leaked.

# Real credentials
AWS_ACCESS_KEY_ID=AKIA...

# Canary token - alerts you if used
AWS_CANARY_KEY=AKIA_CANARY_TOKEN_HERE

SECURITY_TXT helps researchers find you. Canary tokens let you know when someone's already found your secrets.

FAQ

Is this actually useful?

Maybe. If even one leaked credential gets returned to its owner because of this, we'll call it a win.

Why not just use the credentials to find the owner?

Because that's ethically murky at best and illegal at worst. Do you really want to explain to a lawyer why you logged into someone's AWS account "just to be helpful"?

What if someone puts a malicious URL in SECURITY_TXT?

Researchers should treat all URLs with appropriate caution, just like any other data in a leaked file. Don't blindly trust anything in a random .env you found on the internet.