SST secrets management exposes the limits of code-first controls

At a glance

What this is: This is an analysis of SST secrets management and where its native approach stops meeting production secrets governance needs.

Why it matters: It matters because IAM and security teams need consistent control over NHI secrets, workload credentials, and developer access as infrastructure scales beyond prototypes.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Infisical's analysis of SST secrets management limits and enterprise controls

Context

SST secrets management is a practical example of a broader NHI problem: development-friendly credential handling often breaks down when teams need hierarchy, auditability, and rotation at scale. In code-first infrastructure, the secret may be encrypted, but the governance model is still thin.

The primary issue is not whether SST can store a secret. It is whether the surrounding IAM, lifecycle, and access-control model can answer who can modify it, who can consume it, when it changes, and how it is retired. That is where production secrets programmes usually separate from prototype workflows.

Key questions

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. The key controls are ownership, environment separation, rotation, access logging, and expiry. If those controls are missing, the secret may be encrypted, but its lifecycle is still unmanaged and the operational risk remains high.

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. A flat stage model encourages duplication, manual updates, and hidden fallback values. That increases drift and makes it harder to prove who can access a credential, when it changed, and whether it still needs to exist.

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. It also creates compliance and accountability gaps because the organisation cannot show that credential lifespan is being actively governed across critical environments.

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.

Technical breakdown

Stage-bound secrets and the limits of flat inheritance

SST’s native model treats secrets as stage-specific values with a simple fallback layer. That works when there are only a few environments, but it does not create real hierarchy, approval boundaries, or policy inheritance across a growing estate. The result is duplicated values, manual propagation, and weak separation between development, staging, and production. In identity terms, the secret is governed per stage, not as a lifecycle-managed credential with ownership, review, and retirement controls.

Practical implication: treat stage-specific secret storage as a starting point, not a control plane for production governance.

Runtime secret injection and encrypted storage

SST stores secrets encrypted in the customer AWS account and injects them into function configuration, where the runtime decrypts them using the function role. This reduces plaintext exposure in infrastructure state, but it does not eliminate the dependency on IAM correctness. If the role is over-permissioned, the secret becomes reachable through the same trust path that protects the workload. The security boundary is therefore the execution identity and its access path, not just the storage bucket.

Practical implication: review the workload role and decrypt path as carefully as the secret value itself.

Rotation, audit, and dynamic credentials as governance controls

The biggest gap in native secret handling is lifecycle control. Rotation, expiration, access logging, and dynamic credential issuance are governance mechanisms, not storage features. Static secrets remain valid until a human updates them, which creates long exposure windows and weak accountability when environments multiply. Dynamic secrets change the model by turning credentials into short-lived, bounded artefacts with revocation semantics. That is the difference between holding a secret and governing its lifespan.

Practical implication: move high-value credentials to systems that enforce rotation and revocation, not just encryption at rest.

NHI Mgmt Group analysis

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.

Flat secret inheritance creates hidden duplication and operational drift. A single fallback value can reduce setup friction, but it does not provide layered inheritance or central oversight. That means secrets are copied manually across stages, which increases configuration drift and makes consistency dependent on human discipline. Practitioners should treat this as an environment sprawl problem, not a tooling quirk.

Runtime decryption does not remove IAM risk, it relocates it. When a function role decrypts a secret on demand, the real security boundary becomes the execution identity and its permissions. That is a useful pattern, but only if the role is tightly scoped and separately reviewed. Practitioners should evaluate secret access as part of workload identity governance, not as an isolated secret-store decision.

Lifecycle control is the named gap this model exposes. Static secrets without automated rotation, secret-level audit trails, or expiry enforcement create a lifecycle gap that is easy to miss during development and hard to unwind later. The issue is not secret storage at rest. The issue is that access outlives operational need. Practitioners should redesign around secret lifecycle, not just secret location.

Dynamic credentials are the correct direction for high-risk workloads because they collapse exposure windows. Short-lived credentials reduce the time an attacker can abuse a leaked value and improve traceability when access is issued per use. That matters across NHI governance, workload identity, and compliance controls. Practitioners should reserve static secrets for low-risk cases and move critical paths to bounded credentials.

From our research:

• 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.
• For a broader lifecycle lens, read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside this analysis.

What this signals

Secret sprawl is becoming a governance problem, not just an engineering inconvenience. When a programme uses multiple secret managers, fallback values, and per-stage overrides, the result is usually inconsistent ownership and uneven control coverage. Teams should expect secret governance to be judged increasingly by auditability and lifecycle evidence, not by whether values are encrypted at rest.

The practical signal is that workload identity and secrets management can no longer be separated in mature IAM programmes. A secret is only as secure as the identity that can retrieve it, which is why least privilege, rotation, and offboarding need to be handled as one lifecycle flow.

As the estate grows, the question changes from how secrets are stored to how they are governed across build, deploy, and runtime. That shift favours programmes that can connect operational controls to identity evidence, especially when secrets support production workloads and privileged access.

For practitioners

• 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.
• Replace long-lived values with dynamic credentials where possible Use short-lived leases for supported backends so that access expires automatically and leaked credentials have a much smaller window of usefulness.
• Build secret-level auditability before compliance demands it Log who changed each credential, what changed, and when, so production access reviews are based on evidence rather than assumption.

Key takeaways

• SST’s native secret model is useful for early development, but it does not provide the lifecycle governance production teams need.
• The main risk is not plaintext storage alone, but fragmented ownership, weak rotation, and limited visibility across stages.
• Mature programmes should move critical credentials toward dynamic, auditable, least-privilege controls that are governed as part of workload identity.

Key terms

• Static Secret: A static secret is a credential value that stays valid until a person or system changes it. In practice, this means a password, token, or key can outlive the original need for access unless rotation, expiry, and ownership are actively managed.
• Dynamic Credential: A dynamic credential is a short-lived secret issued on demand and revoked automatically at the end of its lease. It reduces exposure because the value is temporary, scoped, and easier to trace than a long-lived shared credential.
• Workload Identity: Workload identity is the non-human identity used by an application, function, or service to authenticate and retrieve resources. For secrets governance, it matters because the identity that fetches the secret is often the real control boundary, not the secret store itself.
• Secret Lifecycle: Secret lifecycle is the full path of a credential from creation through use, rotation, review, and retirement. A mature lifecycle model focuses on who owns the secret, how long it exists, where it is used, and what evidence proves it was retired on time.

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

👉 Infisical's full post covers stage-specific handling, runtime injection, and rotation patterns in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.