How a B2B SaaS Team Eliminated Plaintext Secrets and Cut Credential Exposure Risk by 94%
A 120-engineer SaaS company replaced .env files and static DB passwords with HashiCorp Vault dynamic credentials, cutting secret sprawl from 340 hardcoded values to under 20 long-lived secrets.
Security · intermediate · 12 min read · 2368 words · By Sandip Das · Published
Composite scenario: built from common industry patterns; the figures are illustrative.
What this covers
- The Situation
- The Problem
- Constraints
- Options Considered
- The Solution
- Implementation
- Results
- What Went Wrong Along the Way
- Lessons Learned
- Apply It Yourself
Key numbers
| Metric | Before | After |
|---|---|---|
| Static or hardcoded secret values in production | 340 | 18 |
| Database credential TTL | Never rotated (months to years) | 1 hour |
| Time to revoke all credentials for a compromised service | 2–4 hours (manual) | 12 seconds |
| Secret read audit coverage | 0% | 100% |
| Open SOC 2 CC6 findings | 4 | 0 |
Key components
- HashiCorp Vault Database Secrets Engine — Generates ephemeral, per-service PostgreSQL credentials with a 1-hour TTL, eliminating shared database accounts.
- Vault Agent Sidecar Injector — Runs as an init and sidecar container in every pod, fetching and renewing secrets without requiring application code changes.
- Kubernetes Auth Method — Validates pod ServiceAccount JWTs against the EKS API server to issue scoped Vault tokens, giving every workload a cryptographic identity.
- Vault Raft Integrated Storage — Provides a three-node HA cluster without an external Consul dependency, reducing operational surface area.
- Vault Audit Log to Splunk — Streams every secret read and token event to Splunk, providing the 100% audit coverage required for SOC 2 CC6 evidence.
- AWS KMS Auto-Unseal — Automatically unseals Vault nodes on restart using a KMS CMK, preventing manual intervention during node replacements.
The Situation
This is a composite scenario built from patterns observed across multiple mid-sized SaaS organisations; the team structure, timelines, and figures are illustrative but internally consistent.
The organisation is a 120-engineer B2B SaaS company building a workflow-automation platform. Their backend runs on roughly 40 microservices deployed to a self-managed Kubernetes cluster (EKS, three availability zones, us-east-1). The data layer is PostgreSQL 15 on RDS, Redis 7 on ElastiCache, and a handful of third-party integrations (Stripe, SendGrid, Datadog). The team uses GitHub Actions for CI/CD, Helm for deployments, and Terraform for infrastructure. Security and compliance work is owned by a two-person platform-security team embedded in a larger 12-person platform engineering group.
The company had recently signed its first enterprise contracts and was heading into a SOC 2 Type II audit. That audit was the forcing function for everything that followed.
The rest of this case study — the trade-offs, the scaling numbers and the build prompt — is available to LearnXops members. Create an account or see membership.
Topics: security, vault, secrets-management, devops, postgresql, kubernetes
Related case studies
- AWS Keys Leaked to GitHub: The First 60 Minutes and the Clean-Up
- How a 120-Engineer SaaS Company Replaced Its Corporate VPN with Zero-Trust Access
- How a B2B SaaS Team Contained Prompt Injection Across an AI Agent With Live Tool Access
- How a B2B SaaS Team Cut Supply-Chain Risk by Enforcing SBOMs, Sigstore Signing, and OPA Admission Policies