How should organisations combine shift-left and shift-right for secrets security?

Why This Matters for Security Teams

Secrets security fails most often when organisations treat release-time scanning and production monitoring as separate problems. Shift-left catches obvious leaks in code, configs, and CI variables before deployment; shift-right catches the cases that emerge later, such as duplicated tokens, forgotten API keys, and secret reuse across services. Current guidance suggests the real objective is not point-in-time detection but continuous control over the secret lifecycle.

The risk is amplified by modern delivery pipelines, where a single leaked credential can be copied into build logs, container layers, tickets, or chat systems before anyone notices. NHI Management Group’s Guide to the Secret Sprawl Challenge shows how quickly secrets spread once they leave a controlled vault, and the issue is reinforced by OWASP Non-Human Identity Top 10 guidance on overexposure and weak lifecycle management. In practice, many security teams encounter secret abuse only after a production token has already been reused, exfiltrated, or left active long after the original change was made.

How It Works in Practice

A balanced model combines prevention, detection, and response. Shift-left starts before merge: developers should use secret scanning in IDEs, pre-commit hooks, repository scanning, and CI gates to block hardcoded credentials and insecure handling patterns. Shift-right continues after deployment: runtime telemetry, cloud audit logs, vault access events, and anomaly detection should be used to identify secret use outside normal paths, unexpected source IPs, unusual rotation failures, or credentials that appear in places they should never reach.

The practical control loop usually looks like this:

• Prevent obvious leaks with repository and pipeline scanning.
• Issue short-lived secrets where possible, not long-lived static tokens.
• Rotate exposed or high-risk credentials automatically.
• Correlate secret use with workload, user, and environment context.
• Revoke unused, duplicated, or stale credentials as soon as they are discovered.

That lifecycle view aligns with the operational lessons in NHI Management Group’s 52 NHI Breaches Analysis and is consistent with how secrets exposure is described in CISA guidance on securing secrets. For teams using cloud-native delivery, the strongest pattern is to pair scanning with vault-backed issuance and policy checks at deploy time, rather than relying on developers to manually avoid mistakes. These controls tend to break down when secrets are duplicated across code, tickets, chat tools, and multiple vaults because revocation and attribution become ambiguous.

Common Variations and Edge Cases

Tighter secrets control often increases engineering and operational overhead, requiring organisations to balance faster delivery against stronger verification and rotation discipline. That tradeoff becomes sharper in legacy estates, polyglot toolchains, and fast-moving DevOps environments where teams still depend on static secrets for compatibility.

There is no universal standard for this yet, but best practice is evolving toward layered controls. Some environments can enforce full shift-left gating because the build system is mature and centrally governed. Others need a lighter front-door control set and stronger shift-right detection because third-party integrations, embedded devices, or long-lived service accounts make immediate elimination unrealistic. The key is not choosing one side of the lifecycle. It is ensuring that every secret is discoverable, attributable, monitored, and revocable. That is especially important when secrets travel through collaboration systems, where GitGuardian research in The State of Secrets Sprawl 2025 found that 38% of incidents in tools like Slack, Jira, and Confluence are highly critical or urgent. Organisations should also map this work to the NIST Cybersecurity Framework and treat exceptions as temporary, not accepted state.

Related resources from NHI Mgmt Group

• When does shift left create more risk than it reduces?
• How do organisations decide when DNS belongs in security architecture reviews?
• How should security teams automate certificate management without exposing privileged secrets?
• How should security teams combine RBAC and ABAC in a Zero Trust programme?