What do security teams get wrong about secrets in SSDLC programmes?

Why This Matters for Security Teams

Security teams often narrow the problem to source code scanning, then miss the real risk: secrets move through design, build, test, release, and runtime, and each handoff creates another opportunity for exposure. A token committed to a repository is only one failure mode. Reuse across environments, weak ownership, and slow revocation are what turn a single leak into persistent access.

This matters because SSDLC controls are supposed to reduce blast radius, not just improve hygiene. If a secret is embedded in application code, CI variables, container images, configuration files, or deployment manifests, the exposure can survive even after the original finding is closed. Current guidance from the OWASP Non-Human Identity Top 10 aligns with a broader point: machine credentials need explicit governance, not just developer awareness.

Teams also underestimate how often valid secrets are discovered by attackers after code review has already passed. In practice, many security teams encounter secret abuse only after a build system, service account, or deployment pipeline has already been used as the entry point, rather than through intentional preventive control.

How It Works in Practice

Effective SSDLC programmes treat secrets as managed identities with a lifecycle, not as static text to detect and delete. That means establishing where secrets are created, where they are stored, who can request them, how they are injected at runtime, and how quickly they are revoked when exposure is suspected. The strongest programmes also separate human credentials from machine credentials and avoid hard-coding long-lived values into repositories or pipeline definitions.

Practically, teams usually need four layers of control:

• Prevent hard-coded secrets by using secret managers, workload identity, and short-lived credentials wherever possible.
• Detect exposure early with repository scanning, CI checks, and pre-merge policy gates.
• Rotate and revoke immediately when a secret is exposed, without waiting for a full incident review.
• Track ownership so every secret has a service owner, an expiry expectation, and a clear recovery path.

For cloud-native delivery, it helps to align this with NIST guidance on microservices security and with OWASP Secrets Management guidance, which both reinforce the value of short-lived credentials and centralized control. The operational question is not whether a secret can be found, but whether the system keeps working safely after that secret is discovered.

That distinction matters in CI/CD because build agents, deployment tools, and test environments often inherit overly broad access. The safer pattern is to issue tightly scoped credentials just in time, log their use, and ensure automated revocation when the pipeline job ends. These controls tend to break down when legacy applications require shared service accounts because rotation becomes operationally risky and teams quietly preserve standing access.

Common Variations and Edge Cases

Tighter secrets control often increases engineering overhead, requiring organisations to balance delivery speed against revocation discipline and credential churn. That tradeoff is real, especially where dozens of services share dependencies or where legacy code cannot easily adopt workload identity. Best practice is evolving, but there is no universal standard for every environment yet.

One common edge case is ephemeral infrastructure. Containers, preview environments, and short-lived test stacks can create false confidence because the environment disappears, but the exposed secret may still be valid elsewhere. Another is secrets stored outside code, such as in environment variables, build logs, artifact registries, or observability platforms. Those locations are often missed by scanner-first programmes because the secret never appears in a committed file.

Another operational issue is ownership drift. A platform team may manage the tooling, but the application team owns the secret’s purpose and rotation cadence. Without that split being explicit, revocation stalls during incidents. Teams should also assume that any secret used by a non-human workload is an access path to be governed alongside other machine identities, not an implementation detail to be left to developers.

Where regulatory or audit pressure is high, the strongest evidence is not just scan coverage but demonstrated control over issuance, usage, and decommissioning. For identity-sensitive environments, the NIST Digital Identity Guidelines can help frame assurance expectations, while the NIST Zero Trust model and the CISA secure software development guidance support a more enforceable approach to software supply chain control.

Related resources from NHI Mgmt Group

• What do security teams get wrong about secrets in third-party code and integrations?
• What do security teams get wrong about risk assessment in identity programmes?
• What do security teams get wrong about access review automation in CMMC programmes?
• What do security teams get wrong about RBAC in IGA programmes?