Secrets Management Technical Due Diligence

Credential Storage, Access Patterns, and Rotation Hygiene

Secrets management maturity is one of the clearest indicators of security culture. We assess three dimensions: how secrets are stored (properly encrypted vs. plaintext in code), how they’re accessed (centralized with audit logging vs. copied into .env files), and how they’re maintained (regular rotation vs. set-and-forget).

Exposure scanning covers all repositories, including git history. We’ve found production database passwords, API keys with billing access, and OAuth secrets in repositories that passed code review - the secrets were in early commits that predated security awareness. Each exposed secret is assessed for current risk: is it still active? What can it access?

Access control evaluation maps who can access which secrets. In mature organizations, application secrets are separate from developer access. In immature organizations, every developer has production database credentials on their laptop.

Exposed Keys, Stale Credentials, and Blast Radius Analysis

The highest risk: active secrets in public or widely-accessible repositories. This is an immediate security incident requiring rotation before diligence continues. We’ve found this in a meaningful percentage of companies we evaluate - AI-generated code commits with .env files are common.

Rotation practices indicate ongoing security hygiene. Secrets that haven’t been rotated in years mean the blast radius of any historical compromise extends to the present. If a credential was exposed at any point in the past, and it hasn’t been rotated since, it’s still compromised.

Compliance implications are assessed against target frameworks. SOC2 requires documented credential management. GDPR requires access controls for personal data. If the company claims compliance but lacks credential management procedures, the compliance claim is suspect.

Vault, Secrets Operators, and Runtime Injection Practices

Beyond policy, we evaluate the technical implementation of secrets management tooling. Organizations using HashiCorp Vault, AWS Secrets Manager, or similar platforms are assessed for configuration correctness - dynamic secrets generation, lease TTLs, audit logging enablement, and access policy granularity. A Vault deployment with a single root token and no audit backend enabled is barely better than plaintext configuration files. We check whether secrets are injected via environment variables at runtime or baked into container images at build time - the latter means every image registry becomes a secrets store. For Kubernetes-based deployments, we review whether secrets are stored as native Kubernetes Secrets (base64-encoded, not encrypted at rest by default) or managed through External Secrets Operator or Sealed Secrets with proper encryption. Service mesh configurations are examined for mTLS certificate rotation and whether certificate authorities are properly scoped rather than sharing a single CA across all environments.

Secrets Posture Report and 30-Day Remediation Priority List

The report provides a secrets management maturity score with specific findings and risk quantification. Exposed secrets are flagged with severity based on access scope. Missing rotation procedures are flagged with the window of potential compromise. The remediation roadmap prioritizes by risk, providing clear actions for the first 30 days post-acquisition.