Secrets Management

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 30 — secrets management. Last episode was about cryptographic keys. This time we're talking about all the other credentials — the API keys, database passwords, and tokens your application needs to function. Alice, how big is this problem really?

Alice: Bigger than most people realise. GitGuardian's 2025 report found that 23.8 million secrets were leaked on public GitHub repositories in a single year. And here's the part that keeps me up at night — 70% of secrets that leaked in 2022 were still active two years later. Nobody revoked them. Nobody rotated them. They're just sitting there, working, waiting for someone to find them.

Dan: Twenty-three million. And when you say "secrets," you mean more than just passwords?

Alice: Much more. A secret is anything that grants access to a system. For a legal SaaS platform, that's your database connection string — which gives access to every client's case data. It's your LLM API key — which someone could use to run up thousands of dollars in charges and potentially expose client documents in prompts. It's your OAuth client secret for your Okta or Azure AD integration, your SMTP credentials for sending e-filing confirmations, your webhook signing keys for verifying court API callbacks. Each one is a skeleton key to a different room in your building.

Dan: Right. So where do people go wrong? What's the most common mistake?

Alice: <sigh> Putting secrets in source code. Or in a .env file that gets committed to git. Here's what developers often don't realise: removing a file from the current branch does not remove it from git history. Git is an append-only ledger — every commit ever made is preserved. So when you commit a .env file with your database password, realise the mistake, and delete it in the next commit — the password is still in the repository's history. Every clone of that repo, every developer's laptop, every CI runner that ever checked it out — they all have it. It's like shredding a document after you've already photocopied it and mailed copies to fifty people.

Dan: Hmm. That's a pretty sobering analogy. So where should secrets live?

Alice: In a dedicated secrets manager. Think of it as a specialised vault — separate from your code, separate from your database, with its own access controls and audit logging. The big names are HashiCorp Vault, AWS Secrets Manager, and for smaller teams, Doppler. The idea is the same as key management from last episode — your application authenticates to the secrets manager at startup, pulls the credentials it needs, and uses them. The secrets never appear in your codebase, never get written to a config file on disk, never show up in a deployment manifest.

Dan: Yeah. And how does the application prove it's allowed to access the secrets?

Alice: Good question. The most secure pattern is cloud-native identity. On AWS, your application runs with an IAM role — an identity assigned by the cloud platform itself. The application doesn't carry any credential to authenticate to the secrets manager; the cloud platform vouches for it based on where it's running. It's like a building with badge access — you don't need a key because the building already knows who you are based on your badge. No credential to steal.

Dan: Mm-hmm. Now, you mentioned rotation. How does that work with secrets that aren't encryption keys — like database passwords?

Alice: The gold standard is dynamic secrets. Instead of creating a database password and using it for months, your secrets manager generates a fresh credential on demand every time your application starts or every few hours. HashiCorp Vault is especially good at this. Your app says "I need database access," Vault creates a temporary user with just the permissions the app needs, and that credential automatically expires after a configured time — maybe an hour, maybe a day. If an attacker somehow steals that credential, it's already dead by the time they try to use it.

Dan: That's clever. What about scanning for secrets that have already leaked?

Alice: Prevention and detection. For prevention, you install a pre-commit hook — a check that runs automatically before any code is committed to the repository. Tools like Gitleaks, GitGuardian, and TruffleHog scan your staged changes for patterns that look like API keys, database URLs, or tokens. If they find one, they block the commit before it ever reaches the repository. GitHub also has a built-in feature called Push Protection that does this at the server level.

Dan: And for secrets that are already out there?

Alice: You run a full-history scan — TruffleHog can crawl every commit in a repository's history and even verify whether the detected secrets are still active. The realistic response to finding a leaked secret is: revoke it immediately, generate a new one, and update whatever system uses it. Don't just delete the file and hope nobody noticed. Assume it's been scraped.

Dan: Mm. There's an AI angle here too, isn't there? A lot of legal SaaS tools are integrating LLMs now.

Alice: Yes, and LLM API keys deserve special attention. Three reasons. First, financial exposure — a leaked key can generate thousands of dollars in model usage within hours, and you're paying the bill. Second, data exposure — if an attacker uses your API key to send prompts, those prompts might contain your clients' legal documents, and they may be logged by the model provider. Third, the AI coding tools themselves are part of the problem. GitGuardian found that repositories using GitHub Copilot had a 6.4% secret leakage rate. The AI suggests code patterns that include credentials matching real formats.

Dan: Yeah, that's an ironic twist — AI tools creating AI security problems. What about the Twelve-Factor App methodology? I've heard that mentioned in the context of configuration.

Alice: The Twelve-Factor App says "store config in the environment" — meaning secrets should come from environment variables, not from files in your codebase. That's the right starting point. But environment variables have their own risks. They show up in process listings, in crash dumps, and in logging frameworks that capture the full environment. So the refinement is: use environment variables as pointers to your secrets manager, not as the secrets themselves. Instead of putting the actual database password in an environment variable, you put the reference — like an AWS Secrets Manager ARN — and the application resolves it at runtime.

Dan: Mm. So the environment variable says "go look in this vault," not "here's the combination."

Alice: Exactly. The variable is a map to the treasure. Not the treasure itself. And that distinction — between holding a reference and holding the actual secret — is the core principle of every good secrets management architecture.

Dan: Next episode — PII Handling and Anonymisation. How to classify and protect personally identifiable information, especially when that PII is also legally privileged.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.