Security, Infrastructure & OperationsApplication Security
Secret Management
Secrets exclusively in Heroku config vars; 2FA mandatory; rotation upon compromise
Principle
No secret is embedded in the source code. All credentials, API keys, and configuration secrets are stored exclusively in Heroku config vars and are injected into the application as environment variables at runtime.
Categories of Managed Secrets
| Category | Content |
|---|---|
| Databases | Postgres and Redis connection URL (per environment) |
| Transactional email | Postmark server token (per environment) |
| Electronic signature | Electronic signature provider credentials (mTLS client certificate or API token) |
| Observability | New Relic account key, Sentry DSN |
| AWS | IAM credentials for S3 and CloudWatch access (least-privilege) |
| Application session | Session cryptographic key (per environment) |
Secret Access Controls
- Mandatory 2FA on accounts with access to administrative consoles: GitHub, Heroku, AWS, and other consoles
- Access to Heroku config vars is restricted to team members with an administrative role
- Secrets are separated per environment — production and staging have completely distinct sets
- Credentials are separated per provider: each external service has its own token/key — there are no shared credentials
Protection Against Accidental Exposure
- GitHub branch protection: mandatory PR review on main — reduces the risk of a secret being accidentally committed
- Secrets are not logged in application or CI/CD output
- Heroku logs do not contain config var values
- Static SAST analysis scans the code for hardcoded secrets in the source
Least-Privilege Principle
AWS credentials adhere to least-privilege IAM:
- S3 access is restricted to the application's buckets
- CloudWatch write-only (the application cannot read its own logs through these credentials)
- No key has administrator access
Secret Rotation
Upon a compromise event or at planned intervals:
- Generate new credentials in the provider's service
- Update the config var in Heroku (production + staging separately)
- Verify the application works with the new credentials
- Revoke the old credentials
- Document in the incident log (if the rotation is caused by a compromise)
In the event of a security incident, rotation covers all secrets simultaneously: Heroku config vars, AWS keys, Postmark/electronic signature provider tokens.
Signing Secrets
Electronic signing keys are managed separately — see the Cryptographic Key Management page.