Secrets management for small SaaS teams is one of those jobs everyone agrees is important and nobody wants to do properly. I have lost count of the codebases I have opened where a database password, a Stripe key or a storage connection string was sitting in plain text in a config file, and often in the git history too. It is rarely malice or laziness. It is just that the quick way works today and the tidy way takes an afternoon nobody has.
The good news is that for a small team, doing this properly really is about an afternoon. You do not need a security department or a HashiCorp cluster. You need a handful of habits and one decent tool.
What Counts as a Secret
People tend to think of passwords, but the list is longer than that. API keys, connection strings, signing keys for tokens, webhook secrets, SMTP credentials, certificates and OAuth client secrets all belong on it. If leaking a value would let someone read your data, spend your money or pretend to be you, it is a secret.
A useful test is to ask whether you would be comfortable pasting the value into a public GitHub issue. If the answer is no, it should not be in your repository, your Slack history or your wiki.
Where They Usually Leak
The classic is the committed appsettings.json or .env file. Someone adds it in a hurry, the repository goes private to public, or a contractor gets access, and suddenly the key is out. Deleting it in a later commit does nothing, because the history still has it.
The second is the shared message. A key gets pasted into Teams or Slack to unblock a colleague, and it lives there forever, searchable by anyone who joins the workspace later. The third is build logs, where a careless debug line prints the whole environment for anyone with pipeline access to read.
A Sensible Setup for a Small Team
Here is what I actually put in place on the products I build, and what I recommend when a client asks. It is boring on purpose.
Use a Proper Vault, Not Environment Variables Alone
If you are on Azure, Key Vault is the obvious answer and it is cheap enough that cost should not enter the conversation. Your application authenticates to it using a managed identity, which means there is no secret needed to fetch your secrets. That single detail removes the chicken and egg problem that trips up most home made schemes.
In .NET the configuration provider for Key Vault is a few lines in your startup code. Your app reads its settings exactly as it did before, but the values now come from the vault rather than from a file. Nothing sensitive is left in the repository at all.
Give Each Environment Its Own Vault
Development, staging and production should never share secrets. Use a separate vault for each, with production locked down so that only the running application and a very small number of people can read it. Your developers should be working against dev credentials that cannot hurt anyone if they leak.
This ties in neatly with how you structure your deployments, which I covered in my post on CI/CD pipelines for small teams. The pipeline should pull what it needs at deploy time and never store production values in plain pipeline variables that half the team can view.
Keep Local Development Painless
If the secure way is annoying, people will route around it. For local work, use the user secrets feature in .NET or a git ignored local settings file that points at dev resources only. Make sure your .gitignore covers it from day one, and add a sample file with fake values so a new starter can get running in ten minutes.
Rotation, Access and Scanning
Storing secrets safely is half the job. The other half is being able to change them without a panic.
Rotate Secrets on a Schedule
Pick a rotation period you can actually keep, whether that is every ninety days or every six months. The real test is whether you could rotate a key today, in an hour, without an outage. If the answer is no, that is the thing to fix first, because when a leak does happen you will not have time to work out how.
Where a provider supports two active keys at once, use both. Switch your app to the new one, confirm everything works, then retire the old one. Stripe and most cloud storage providers make this easy.
Limit Who Can See What
Most small teams give everyone access to everything because it is simpler. I understand it, but it does not scale past about five people. Give developers read access to dev secrets, give production access to two or three trusted people, and turn on audit logging so you know who read what and when.
Scan Before You Push
Turn on secret scanning in GitHub or Azure DevOps. It is free or nearly free and it catches the mistakes that slip through on a Friday afternoon. Add a pre commit hook if you want to catch things even earlier. It will find a live key in a commit far faster than any human reviewer will.
What To Do When One Leaks
It will happen eventually. Do not spend the first hour working out whose fault it was. Revoke the key straight away, issue a new one, check the provider logs for any use you do not recognise, and only then look at how it escaped.
Write down what happened and what you changed. It takes ten minutes and it is exactly the sort of evidence a customer or an insurer will ask for later. I go into the wider picture in my post on securing a SaaS application without a security team, and secrets are near the top of that list for good reason.
Start With the Riskiest One
Do not try to fix everything at once. Find the single most dangerous secret you have, probably your production database connection string or your payment provider key, and move that into a vault this week. Then rotate it, because the old one has almost certainly been seen by more people than you think.
Once that is done, the rest is just repetition. If you would like a second pair of eyes on how your product handles credentials, that is a job I regularly do through my consulting work.
