Notifications
Clear all
Topic starter
08/07/2026 6:52 pm
TL;DR: SST’s built-in secret handling keeps early-stage deployments simple, but its stage-bound, CLI-first model leaves visibility, rotation, audit, and hierarchy gaps as teams scale, according to Infisical. The governance problem is not storage alone, but the lack of lifecycle control around secrets across environments.
NHIMG editorial — based on content published by Infisical: SST Secrets Management: A Technical Guide
Questions worth separating out
Q: How should teams govern secrets in code-first infrastructure environments?
A: Teams should treat code-first secret handling as an implementation layer, not the governance model.
Q: When does stage-based secret management become a liability?
A: It becomes a liability when multiple environments, teams, or compliance obligations require layered control.
Q: What breaks when secrets are not rotated automatically?
A: Without automatic rotation, credentials remain valid far longer than their operational need, which expands the attack window if they are exposed.
Practitioner guidance
- Map secrets by stage, owner, and business criticality Create an inventory that distinguishes development, staging, production, and shared fallback values, then assign an owner and review cadence to each secret.
- Separate workload identity from secret storage decisions Review which function roles or deployment identities can decrypt each secret and remove broad permissions that make runtime injection a hidden privilege path.
- Introduce rotation for production credentials first Start with database passwords, payment keys, and service credentials that would materially increase blast radius if exposed, then automate renewal and propagation.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- CLI examples for setting stage-specific secrets and fallback values in SST workflows
- Implementation guidance for moving production credentials from local secret handling into centralized governance
- Rotation and dynamic credential patterns for databases, API keys, and CI/CD pipelines
- Developer workflow details for runtime secret retrieval and environment-by-environment access control
👉 Read Infisical's analysis of SST secrets management limits and enterprise controls →
SST secrets management: where code-first workflows break down?
Explore further
08/07/2026 7:13 pm
Code-first secret management works until governance becomes the real requirement. SST is effective for early-stage infrastructure, but stage-local secrets and CLI-driven updates do not answer lifecycle questions at production scale. The moment teams need visibility across environments, the model shifts from convenience to control. Practitioners should recognise that storage is not governance.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Why do workload roles matter as much as the secret value itself?
A: Because the role or execution identity is usually the path that decrypts or retrieves the secret. If that identity is over-permissioned, the credential can be abused even when storage is encrypted. Secret governance therefore depends on least privilege for the workload, not just protection of the stored value.
👉 Read our full editorial: SST secrets management exposes the limits of code-first controls
