Env & Secrets Manager
Tier: POWERFUL
Category: Engineering
Domain: Security / DevOps / Configuration Management
Overview
Manage environment-variable hygiene and secrets safety across local development and production workflows. This skill focuses on practical auditing, drift awareness, and rotation readiness.
Core Capabilities
.env and .env.example lifecycle guidance
- Secret leak detection for repository working trees
- Severity-based findings for likely credentials
- Operational pointers for rotation and containment
- Integration-ready outputs for CI checks
When to Use
- Before pushing commits that touched env/config files
- During security audits and incident triage
- When onboarding contributors who need safe env conventions
- When validating that no obvious secrets are hardcoded
Quick Start
# Scan a repository for likely secret leaks
python3 scripts/env_auditor.py /path/to/repo
# JSON output for CI pipelines
python3 scripts/env_auditor.py /path/to/repo --json
Recommended Workflow
- Run
scripts/env_auditor.py on the repository root.
- Prioritize
critical and high findings first.
- Rotate real credentials and remove exposed values.
- Update
.env.example and .gitignore as needed.
- Add or tighten pre-commit/CI secret scanning gates.
Reference Docs
references/validation-detection-rotation.md
references/secret-patterns.md
Common Pitfalls
- Committing real values in
.env.example
- Rotating one system but missing downstream consumers
- Logging secrets during debugging or incident response
- Treating suspected leaks as low urgency without validation
Best Practices
- Use a secret manager as the production source of truth.
- Keep dev env files local and gitignored.
- Enforce detection in CI before merge.
- Re-test application paths immediately after credential rotation.
Cloud Secret Store Integration
Production applications should never read secrets from .env files or environment variables baked into container images. Use a dedicated secret store instead.
Provider Comparison
| Provider |
Best For |
Key Feature |
| HashiCorp Vault |
Multi-cloud / hybrid |
Dynamic secrets, policy engine, pluggable backends |
| AWS Secrets Manager |
AWS-native workloads |
Native Lambda/ECS/EKS integration, automatic RDS rotation |
| Azure Key Vault |
Azure-native workloads |
Managed HSM, Azure AD RBAC, certificate management |
| GCP Secret Manager |
GCP-native workloads |
IAM-based access, automatic replication, versioning |
Selection Guidance
- Single cloud provider — use the cloud-native secret manager. It integrates tightly with IAM, reduces operational overhead, and costs less than self-hosting.
- Multi-cloud or hybrid — use HashiCorp Vault. It provides a uniform API across environments and supports dynamic secret generation (database credentials, cloud IAM keys) that expire automatically.
- Kubernetes-heavy — combine External Secrets Operator with any backend above to sync secrets into K8s
Secret objects without hardcoding.
Application Access Patterns
- SDK/API pull — application fetches secret at startup or on-demand via provider SDK.
- Sidecar injection — a sidecar container (e.g., Vault Agent) writes secrets to a shared volume or injects them as environment variables.
- Init container — a Kubernetes init container fetches secrets before the main container starts.
- CSI driver — secrets mount as a filesystem volume via the Secrets Store CSI Driver.
Cross-reference: See engineering/secrets-vault-manager for production vault infrastructure patterns, HA deployment, and disaster recovery procedures.
Secret Rotation Workflow
Stale secrets are a liability. Rotation ensures that even if a credential leaks, its useful lifetime is bounded.
Phase 1: Detection
- Track secret creation and expiry dates in your secret store metadata.
- Set alerts at 30, 14, and 7 days before expiry.
- Use
scripts/env_auditor.py to flag secrets with no recorded rotation date.
Phase 2: Rotation
- Generate a new credential (API key, database password, certificate).
- Deploy the new credential to all consumers (apps, services, pipelines) in parallel.
- Verify each consumer can authenticate using the new credential.
- Revoke the old credential only after all consumers are confirmed healthy.
- Update metadata with the new rotation timestamp and next rotation date.
Phase 3: Automation
- AWS Secrets Manager — use built-in Lambda-based rotation for RDS, Redshift, and DocumentDB.
- HashiCorp Vault — configure dynamic secrets with TTLs; credentials are generated on-demand and auto-expire.
- Azure Key Vault — use Event Grid notifications to trigger rotation functions.
- GCP Secret Manager — use Pub/Sub notifications tied to Cloud Functions for rotation logic.
Emergency Rotation Checklist
When a secret is confirmed leaked:
- Immediately revoke the compromised credential at the provider level.
- Generate and deploy a replacement credential to all consumers.
- Audit access logs for unauthorized usage during the exposure window.
- Scan git history, CI logs, and artifact registries for the leaked value.
- File an incident report documenting scope, timeline, and remediation steps.
- Review and tighten detection controls to prevent recurrence.
CI/CD Secret Injection
Secrets in CI/CD pipelines require careful handling to avoid exposure in logs, artifacts, or pull request contexts.
GitHub Actions
- Use repository secrets or environment secrets via
${{ secrets.SECRET_NAME }}.
- Prefer OIDC federation (
aws-actions/configure-aws-credentials with role-to-assume) over long-lived access keys.
- Environment secrets with required reviewers add approval gates for production deployments.
- GitHub automatically masks secrets in logs, but avoid
echo or toJSON() on secret values.
GitLab CI
- Store secrets as CI/CD variables with the
masked and protected flags enabled.
- Use HashiCorp Vault integration (
secrets:vault) for dynamic secret injection without storing values in GitLab.
- Scope variables to specific environments (
production, staging) to enforce least privilege.
Universal Patterns
- Never echo or print secret values in pipeline output, even for debugging.
- Use short-lived tokens (OIDC, STS AssumeRole) instead of static credentials wherever possible.
- Restrict PR access — do not expose secrets to pipelines triggered by forks or untrusted branches.
- Rotate CI secrets on the same schedule as application secrets; pipeline credentials are attack vectors too.
- Audit pipeline logs periodically for accidental secret exposure that masking may have missed.
Pre-Commit Secret Detection
Catching secrets before they reach version control is the most cost-effective defense. Two leading tools cover this space.
gitleaks
# .gitleaks.toml — minimal configuration
[extend]
useDefault = true
[[rules]]
id = "custom-internal-token"
description = "Internal service token pattern"
regex = '''INTERNAL_TOKEN_[A-Za-z0-9]{32}'''
secretGroup = 0
- Install:
brew install gitleaks or download from GitHub releases.
- Pre-commit hook:
gitleaks git --pre-commit --staged
- Baseline scanning:
gitleaks detect --source . --report-path gitleaks-report.json
- Manage false positives in
.gitleaksignore (one fingerprint per line).
detect-secrets
# Generate baseline
detect-secrets scan --all-files > .secrets.baseline
# Pre-commit hook (via pre-commit framework)
# .pre-commit-config.yaml
repos:
- repo: https://github.com/Yelp/detect-secrets
rev: v1.5.0
hooks:
- id: detect-secrets
args: ['--baseline', '.secrets.baseline']
- Supports custom plugins for organization-specific patterns.
- Audit workflow:
detect-secrets audit .secrets.baseline interactively marks true/false positives.
False Positive Management
- Maintain
.gitleaksignore or .secrets.baseline in version control so the whole team shares exclusions.
- Review false positive lists during security audits — patterns may mask real leaks over time.
- Prefer tightening regex patterns over broadly ignoring files.
Audit Logging
Knowing who accessed which secret and when is critical for incident investigation and compliance.
Cloud-Native Audit Trails
| Provider |
Service |
What It Captures |
| AWS |
CloudTrail |
Every GetSecretValue, DescribeSecret, RotateSecret API call |
| Azure |
Activity Log + Diagnostic Logs |
Key Vault access events, including caller identity and IP |
| GCP |
Cloud Audit Logs |
Data access logs for Secret Manager with principal and timestamp |
| Vault |
Audit Backend |
Full request/response logging (file, syslog, or socket backend) |
Alerting Strategy
- Alert on access from unknown IP ranges or service accounts outside the expected set.
- Alert on bulk secret reads (more than N secrets accessed within a time window).
- Alert on access outside deployment windows when no CI/CD pipeline is running.
- Feed audit logs into your SIEM (Splunk, Datadog, Elastic) for correlation with other security events.
- Review audit logs quarterly as part of access recertification.
Cross-References
This skill covers env hygiene and secret detection. For deeper coverage of related domains, see:
| Skill |
Path |
Relationship |
| Secrets Vault Manager |
engineering/secrets-vault-manager |
Production vault infrastructure, HA deployment, DR |
| Senior SecOps |
engineering/senior-secops |
Security operations perspective, incident response |
| CI/CD Pipeline Builder |
engineering/ci-cd-pipeline-builder |
Pipeline architecture, secret injection patterns |
| Infrastructure as Code |
engineering/infrastructure-as-code |
Terraform/Pulumi secret backend configuration |
| Container Orchestration |
engineering/container-orchestration |
Kubernetes secret mounting, sealed secrets |
1---2name: env-secrets-manager3description: Manage environment-variable hygiene and secrets safety across local development and production. Practical auditing, drift awareness, rotation readiness. Use when auditing .env files for committed secrets, planning a credential rotation, debugging ...4license: MIT5---6
7# Env & Secrets Manager
8
9**Tier:** POWERFUL
10**Category:** Engineering
11**Domain:** Security / DevOps / Configuration Management
12
13---
14
15## Overview
16
17Manage environment-variable hygiene and secrets safety across local development and production workflows. This skill focuses on practical auditing, drift awareness, and rotation readiness.
18
19## Core Capabilities
20
21- `.env` and `.env.example` lifecycle guidance
22- Secret leak detection for repository working trees
23- Severity-based findings for likely credentials
24- Operational pointers for rotation and containment
25- Integration-ready outputs for CI checks
26
27---
28
29## When to Use
30
31- Before pushing commits that touched env/config files
32- During security audits and incident triage
33- When onboarding contributors who need safe env conventions
34- When validating that no obvious secrets are hardcoded
35
36---
37
38## Quick Start
39
40```bash
41# Scan a repository for likely secret leaks
42python3 scripts/env_auditor.py /path/to/repo
43
44# JSON output for CI pipelines
45python3 scripts/env_auditor.py /path/to/repo --json
46```
47
48---
49
50## Recommended Workflow
51
521. Run `scripts/env_auditor.py` on the repository root.
532. Prioritize `critical` and `high` findings first.
543. Rotate real credentials and remove exposed values.
554. Update `.env.example` and `.gitignore` as needed.
565. Add or tighten pre-commit/CI secret scanning gates.
57
58---
59
60## Reference Docs
61
62- `references/validation-detection-rotation.md`
63- `references/secret-patterns.md`
64
65---
66
67## Common Pitfalls
68
69- Committing real values in `.env.example`
70- Rotating one system but missing downstream consumers
71- Logging secrets during debugging or incident response
72- Treating suspected leaks as low urgency without validation
73
74## Best Practices
75
761. Use a secret manager as the production source of truth.
772. Keep dev env files local and gitignored.
783. Enforce detection in CI before merge.
794. Re-test application paths immediately after credential rotation.
80
81---
82
83## Cloud Secret Store Integration
84
85Production applications should never read secrets from `.env` files or environment variables baked into container images. Use a dedicated secret store instead.
86
87### Provider Comparison
88
89| Provider | Best For | Key Feature |
90|----------|----------|-------------|
91| **HashiCorp Vault** | Multi-cloud / hybrid | Dynamic secrets, policy engine, pluggable backends |
92| **AWS Secrets Manager** | AWS-native workloads | Native Lambda/ECS/EKS integration, automatic RDS rotation |
93| **Azure Key Vault** | Azure-native workloads | Managed HSM, Azure AD RBAC, certificate management |
94| **GCP Secret Manager** | GCP-native workloads | IAM-based access, automatic replication, versioning |
95
96### Selection Guidance
97
98- **Single cloud provider** — use the cloud-native secret manager. It integrates tightly with IAM, reduces operational overhead, and costs less than self-hosting.
99- **Multi-cloud or hybrid** — use HashiCorp Vault. It provides a uniform API across environments and supports dynamic secret generation (database credentials, cloud IAM keys) that expire automatically.
100- **Kubernetes-heavy** — combine External Secrets Operator with any backend above to sync secrets into K8s `Secret` objects without hardcoding.
101
102### Application Access Patterns
103
1041. **SDK/API pull** — application fetches secret at startup or on-demand via provider SDK.
1052. **Sidecar injection** — a sidecar container (e.g., Vault Agent) writes secrets to a shared volume or injects them as environment variables.
1063. **Init container** — a Kubernetes init container fetches secrets before the main container starts.
1074. **CSI driver** — secrets mount as a filesystem volume via the Secrets Store CSI Driver.
108
109> **Cross-reference:** See `engineering/secrets-vault-manager` for production vault infrastructure patterns, HA deployment, and disaster recovery procedures.
110
111---
112
113## Secret Rotation Workflow
114
115Stale secrets are a liability. Rotation ensures that even if a credential leaks, its useful lifetime is bounded.
116
117### Phase 1: Detection
118
119- Track secret creation and expiry dates in your secret store metadata.
120- Set alerts at 30, 14, and 7 days before expiry.
121- Use `scripts/env_auditor.py` to flag secrets with no recorded rotation date.
122
123### Phase 2: Rotation
124
1251. **Generate** a new credential (API key, database password, certificate).
1262. **Deploy** the new credential to all consumers (apps, services, pipelines) in parallel.
1273. **Verify** each consumer can authenticate using the new credential.
1284. **Revoke** the old credential only after all consumers are confirmed healthy.
1295. **Update** metadata with the new rotation timestamp and next rotation date.
130
131### Phase 3: Automation
132
133- **AWS Secrets Manager** — use built-in Lambda-based rotation for RDS, Redshift, and DocumentDB.
134- **HashiCorp Vault** — configure dynamic secrets with TTLs; credentials are generated on-demand and auto-expire.
135- **Azure Key Vault** — use Event Grid notifications to trigger rotation functions.
136- **GCP Secret Manager** — use Pub/Sub notifications tied to Cloud Functions for rotation logic.
137
138### Emergency Rotation Checklist
139
140When a secret is confirmed leaked:
141
1421. **Immediately revoke** the compromised credential at the provider level.
1432. Generate and deploy a replacement credential to all consumers.
1443. Audit access logs for unauthorized usage during the exposure window.
1454. Scan git history, CI logs, and artifact registries for the leaked value.
1465. File an incident report documenting scope, timeline, and remediation steps.
1476. Review and tighten detection controls to prevent recurrence.
148
149---
150
151## CI/CD Secret Injection
152
153Secrets in CI/CD pipelines require careful handling to avoid exposure in logs, artifacts, or pull request contexts.
154
155### GitHub Actions
156
157- Use **repository secrets** or **environment secrets** via `${{ secrets.SECRET_NAME }}`.
158- Prefer **OIDC federation** (`aws-actions/configure-aws-credentials` with `role-to-assume`) over long-lived access keys.
159- Environment secrets with required reviewers add approval gates for production deployments.
160- GitHub automatically masks secrets in logs, but avoid `echo` or `toJSON()` on secret values.
161
162### GitLab CI
163
164- Store secrets as **CI/CD variables** with the `masked` and `protected` flags enabled.
165- Use **HashiCorp Vault integration** (`secrets:vault`) for dynamic secret injection without storing values in GitLab.
166- Scope variables to specific environments (`production`, `staging`) to enforce least privilege.
167
168### Universal Patterns
169
170- **Never echo or print** secret values in pipeline output, even for debugging.
171- **Use short-lived tokens** (OIDC, STS AssumeRole) instead of static credentials wherever possible.
172- **Restrict PR access** — do not expose secrets to pipelines triggered by forks or untrusted branches.
173- **Rotate CI secrets** on the same schedule as application secrets; pipeline credentials are attack vectors too.
174- **Audit pipeline logs** periodically for accidental secret exposure that masking may have missed.
175
176---
177
178## Pre-Commit Secret Detection
179
180Catching secrets before they reach version control is the most cost-effective defense. Two leading tools cover this space.
181
182### gitleaks
183
184```toml
185# .gitleaks.toml — minimal configuration
186[extend]
187useDefault = true
188
189[[rules]]
190id = "custom-internal-token"
191description = "Internal service token pattern"
192regex = '''INTERNAL_TOKEN_[A-Za-z0-9]{32}'''
193secretGroup = 0
194```
195
196- Install: `brew install gitleaks` or download from GitHub releases.
197- Pre-commit hook: `gitleaks git --pre-commit --staged`
198- Baseline scanning: `gitleaks detect --source . --report-path gitleaks-report.json`
199- Manage false positives in `.gitleaksignore` (one fingerprint per line).
200
201### detect-secrets
202
203```bash
204# Generate baseline
205detect-secrets scan --all-files > .secrets.baseline
206
207# Pre-commit hook (via pre-commit framework)
208# .pre-commit-config.yaml
209repos:
210 - repo: https://github.com/Yelp/detect-secrets
211 rev: v1.5.0
212 hooks:
213 - id: detect-secrets
214 args: ['--baseline', '.secrets.baseline']
215```
216
217- Supports **custom plugins** for organization-specific patterns.
218- Audit workflow: `detect-secrets audit .secrets.baseline` interactively marks true/false positives.
219
220### False Positive Management
221
222- Maintain `.gitleaksignore` or `.secrets.baseline` in version control so the whole team shares exclusions.
223- Review false positive lists during security audits — patterns may mask real leaks over time.
224- Prefer tightening regex patterns over broadly ignoring files.
225
226---
227
228## Audit Logging
229
230Knowing who accessed which secret and when is critical for incident investigation and compliance.
231
232### Cloud-Native Audit Trails
233
234| Provider | Service | What It Captures |
235|----------|---------|-----------------|
236| **AWS** | CloudTrail | Every `GetSecretValue`, `DescribeSecret`, `RotateSecret` API call |
237| **Azure** | Activity Log + Diagnostic Logs | Key Vault access events, including caller identity and IP |
238| **GCP** | Cloud Audit Logs | Data access logs for Secret Manager with principal and timestamp |
239| **Vault** | Audit Backend | Full request/response logging (file, syslog, or socket backend) |
240
241### Alerting Strategy
242
243- Alert on **access from unknown IP ranges** or service accounts outside the expected set.
244- Alert on **bulk secret reads** (more than N secrets accessed within a time window).
245- Alert on **access outside deployment windows** when no CI/CD pipeline is running.
246- Feed audit logs into your SIEM (Splunk, Datadog, Elastic) for correlation with other security events.
247- Review audit logs quarterly as part of access recertification.
248
249---
250
251## Cross-References
252
253This skill covers env hygiene and secret detection. For deeper coverage of related domains, see:
254
255| Skill | Path | Relationship |
256|-------|------|-------------|
257| **Secrets Vault Manager** | `engineering/secrets-vault-manager` | Production vault infrastructure, HA deployment, DR |
258| **Senior SecOps** | `engineering/senior-secops` | Security operations perspective, incident response |
259| **CI/CD Pipeline Builder** | `engineering/ci-cd-pipeline-builder` | Pipeline architecture, secret injection patterns |
260| **Infrastructure as Code** | `engineering/infrastructure-as-code` | Terraform/Pulumi secret backend configuration |
261| **Container Orchestration** | `engineering/container-orchestration` | Kubernetes secret mounting, sealed secrets |