Why Credential Workflow Matters
Every modern app depends on secrets: API keys, database passwords, tokens, and cloud credentials. A secure credential workflow helps teams ship faster without leaking access to critical systems. This guide explains a practical, end-to-end process from local development to production.
What Counts as a Credential?
- Source control tokens: GitHub/GitLab access and automation tokens
- Database secrets: Per-environment connection strings and passwords
- API keys: Payment, email, analytics, and messaging providers
- Cloud IAM credentials: AWS, Azure, GCP service access
- SSH keys/certificates: Infrastructure and deployment access
Core Principles (Use These Everywhere)
- Least privilege: Grant only the minimum required permissions
- Environment isolation: Never reuse production secrets in dev/test
- Short-lived access: Prefer expiring tokens over long-lived credentials
- Centralized secret storage: Keep one source of truth, not scattered notes/files
- Auditability: Track who accessed what, and when
Local Development: Safe by Default
Recommended Setup
- Commit only a template:
.env.example - Store real values in
.env.local(ignored by git) - Load secrets from a trusted vault/secret manager
- Use separate credentials for each developer when possible
Git Safety Checklist
- Add
.env*exceptions carefully in.gitignore - Enable pre-commit secret scanning (e.g., gitleaks, git-secrets)
- Enable repository-level secret scanning alerts
- Block pushes that contain high-risk secret patterns
Testing and Staging: Treat as Production-Like
Staging should mirror production behavior, but access should still be controlled. Use dedicated staging credentials and avoid sharing credentials in chat or email.
- Use sandbox/test API keys first, live keys only when required
- Document scope, owner, and expiry date for each secret
- Prefer read-only staging DB access for most developers
CI/CD: Secure Automation
- Store pipeline secrets in CI/CD secret stores, not in workflow files
- Use separate credentials per pipeline/environment
- Prefer OIDC/workload identity over static cloud keys where possible
- Rotate automation credentials on a fixed schedule
For deeper implementation patterns, see CI/CD credential security.
Production Access Protocol
- Just-in-time access: Grant temporary credentials for specific tasks
- Approval workflow: Require reviewer/manager sign-off for elevated access
- Role tiers: Read-only by default, write/admin only when necessary
- Full audit trail: Log access and review regularly
Rotation and Revocation Policy
Suggested Baseline
- High-risk tokens (CI/CD, production): every 60–90 days
- Developer personal tokens: every 90–180 days
- Immediate revocation on role change, incident, or suspected leak
If a Credential Is Leaked
- Revoke/disable immediately
- Issue replacement credential with reduced scope
- Search logs for misuse window
- Document incident and prevention updates
Onboarding and Offboarding
Onboarding (Day 1)
- Provision minimum required project access
- Set up local environment using approved secret workflow
- Verify scanning tools and branch protections are enabled
Offboarding (Immediate)
- Remove vault/project access
- Revoke personal tokens and SSH keys
- Rotate shared secrets they could access
Where LockPulse Fits (Without Vendor Lock-In)
If your team uses LockPulse, treat it as the shared source of truth for credential storage, access control, and audit logs. The same workflow in this guide also applies to other vault tools: the key is consistency, least privilege, and regular rotation.
Related reading: GitHub token security and managing multiple environments.
Final Developer Checklist
- ✅ No hardcoded secrets in code or configs committed to git
- ✅ Separate secrets for dev, test, staging, and production
- ✅ CI/CD uses secure secret injection (not plaintext files)
- ✅ Access is role-based, time-limited, and auditable
- ✅ Rotation and incident response playbooks are documented