TL;DR: DevSecOps tools are most effective when they secure code, pipelines, containers, and infrastructure together, but the source article argues that access control is the layer that determines whether the rest of the stack can be trusted, according to StrongDM. That makes Zero Trust, least privilege, and auditability the operational baseline rather than optional hardening.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on StrongDM's blog post: In DevSecOps, the access layer determines whether other security tools can be trusted.
Why it matters: It matters because IAM, PAM, and NHI programmes fail if developers, services, and infrastructure can still be reached through shared credentials or poorly governed access paths.
Context
DevSecOps security is often discussed as a stack of scanners, policies, and runtime protections, but access control is the layer that decides whether those controls can be relied on. In this article, the central issue is not just what tools detect, but who can reach infrastructure and under what conditions.
The identity governance question is straightforward: if teams still depend on shared credentials, VPNs, or unmanaged SSH keys, then the rest of the programme inherits those weak trust assumptions. That makes least privilege and Zero Trust access control a foundation problem for both human IAM and NHI governance.
Key questions
Q: What breaks when infrastructure access is still managed manually in fast-moving DevOps environments?
A: Manual access management breaks down when resources are created and removed quickly, because permissions lag behind the infrastructure lifecycle. Teams spend more time chasing access requests, users wait longer for credentials, and revoked access is easier to miss. That creates avoidable operational friction, higher error rates, and weaker auditability.
Q: Why does least privilege matter more in DevSecOps than in traditional operations?
A: DevSecOps mixes rapid delivery with high-value infrastructure access, so broad permissions quickly turn into standing exposure across databases, clusters, and internal apps. Least privilege limits how far a routine account compromise can move and keeps access aligned to a specific task rather than permanent operational convenience. That is why it is a governance control, not just an efficiency preference.
Q: How can teams tell whether access governance is actually working?
A: Look for short revocation times, low rates of stale entitlements, and repeatable access review outcomes across systems. If accounts remain active after role changes or offboarding, governance is not effective. Good measurement focuses on whether access is removed when it stops being justified.
Q: What is the difference between Security as Code and DevSecOps?
A: DevSecOps is the broader operating model that embeds security across development and operations. Security as Code is a specific way to do that by expressing security requirements, checks, and controls in code and automated workflows. SaC is therefore one implementation pattern within DevSecOps, focused on making security rules repeatable, testable, and easier to enforce.
Technical breakdown
Zero Trust access control for DevSecOps infrastructure
Zero Trust access control in DevSecOps means no implicit trust based on network location, device posture, or prior authentication. Access is issued from policy, evaluated at request time, and scoped to the minimum resource and duration needed. In this article’s context, that applies to servers, databases, Kubernetes clusters, and internal applications that often sit behind fragile legacy access paths. The important design point is that security shifts from perimeter trust to transaction-level authorisation, so a valid login does not become blanket infrastructure reach.
Practical implication: model infrastructure access as policy decisions at the moment of use, not as durable reach granted once and reused indefinitely.
Least privilege for humans and services
Least privilege in DevSecOps is not just a role design principle. It is the discipline of ensuring that developers, operators, and services receive only the specific access needed for the current task, then lose it when the task ends. That matters because modern delivery environments mix human users, automation, and machine identities across hybrid estates. When permissions are broad or permanent, compromise of one account becomes compromise of the environment. The article’s core claim is that this access minimisation is what makes the rest of the stack trustworthy, not the other way around.
Practical implication: review both human and service access scopes for persistent overreach, especially where access was granted to accelerate delivery.
Immutable session recording and auditability
Immutable session recording creates a trustworthy evidence layer for infrastructure access. Instead of relying on scattered logs, the control captures who accessed what, when, and what happened in session, in a form that is harder to tamper with after the fact. For DevSecOps teams, that matters because compliance, incident review, and privileged troubleshooting all depend on reconstructing access paths across fast-moving environments. The article ties this directly to audit readiness, but the deeper value is that visibility becomes continuous rather than retrospective.
Practical implication: require session-level evidence for privileged infrastructure access so investigations are not limited by missing or alterable logs.
Threat narrative
Attacker objective: The objective is to turn one exposed access path into broader infrastructure control and persistent operational visibility loss.
- Entry begins when infrastructure is reachable through static credentials, VPN paths, or reused SSH keys rather than tightly scoped access controls.
- Escalation follows when broad permissions let a compromised user or service move from one system to databases, clusters, or internal applications.
- Impact occurs when the attacker can operate across the environment without strong session visibility, making containment and attribution harder.
Breaches seen in the wild
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Access control is the trust boundary DevSecOps keeps underestimating: Scanners can find defects, but they cannot compensate for infrastructure that is still reachable through static credentials, reused keys, or overly broad roles. The article’s real insight is that the access layer determines whether code, pipeline, and runtime security can be meaningfully enforced. Practitioners should treat access control as the control plane that makes every other DevSecOps control trustworthy.
Least privilege is no longer just a permissions principle, it is a delivery constraint: Fast-moving engineering teams often accumulate access to avoid blocking work, then keep it far longer than required. That creates standing exposure across human and service identities and turns routine compromise into environment-wide reach. The governance implication is that access scope must be designed around task boundaries, not organisational convenience.
Immutable session records change the evidentiary model for privileged infrastructure access: In DevSecOps, auditability is not a compliance afterthought because troubleshooting, incident response, and segregation of duties all depend on proving what happened inside sensitive systems. When session records are continuous and tamper-resistant, security teams can validate behaviour instead of reconstructing it from partial logs. The practitioner conclusion is that access governance without reliable session evidence is incomplete.
DevSecOps access governance is really lifecycle governance for identities and entitlements: The same lifecycle problem appears across engineers, service accounts, and infrastructure workflows. Onboarding, offboarding, and role change all need to shrink access quickly enough that delivery speed does not translate into privilege creep. The field should stop treating infrastructure access as a separate DevOps concern and recognise it as part of the broader identity lifecycle problem.
Identity blast radius is the right concept for modern delivery stacks: The article describes a world where one credential can reach many systems, which means the real security question is how far a single identity can move if it is misused. That blast radius is shaped by privilege scope, session duration, and whether access is centrally governed. Practitioners should measure access by containment potential, not by how quickly users can connect.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
Identity blast radius becomes the practical metric for DevSecOps governance: When one account can reach databases, clusters, and internal applications, the question is not just whether access is authenticated but how far misuse can travel. Teams should evaluate whether their current access model shrinks or amplifies that blast radius across human and non-human identities.
The strongest programmes will treat access governance as part of the delivery pipeline itself, not as a post-deployment wrapper. That means aligning entitlement design, offboarding speed, and session evidence with the same urgency normally reserved for code quality and vulnerability response.
For practitioners
- Define task-scoped access boundaries Map the infrastructure resources each role, service, and pipeline actually needs, then remove any standing reach that is not required for the current task.
- Replace shared credentials and static keys Eliminate VPN-dependent shared access paths, reusable SSH keys, and long-lived passwords for infrastructure entry points.
- Centralize privileged session recording Record infrastructure sessions in an immutable format so investigations and compliance reviews can reconstruct who accessed what and when.
- Automate offboarding and role changes Revoke access immediately when users move teams or leave, and reduce residual permissions whenever a role changes.
Key takeaways
- DevSecOps tools do not compensate for weak infrastructure access, because the access layer determines whether other controls can be trusted.
- Standing credentials and broad permissions expand the blast radius of a single compromise across infrastructure, services, and audit processes.
- Teams should focus on short-lived access, immediate revocation, and immutable session evidence to make DevSecOps governance operational.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on limiting excessive infrastructure access across human and service identities. |
| NHI-01 — Improper Offboarding | The article explicitly discusses automatic revocation when people leave or change roles. | |
| Recommendation — Reduce standing infrastructure access to the minimum permissions each identity actually needs. Remove infrastructure access immediately when roles change or users leave. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing entitlements and authorizations for sensitive infrastructure. |
| Recommendation — Review entitlements so infrastructure access matches approved business and operational need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses replacing static credentials and SSH keys with governed access. |
| Recommendation — Manage authenticators to avoid reusable infrastructure credentials and stale access material. | ||
| CIS Controls v8 | CIS-5 — Account Management | Onboarding, offboarding, and role changes are central to the article's access-control model. |
| Recommendation — Tighten account lifecycle processes so infrastructure access is revoked as soon as it is no longer required. | ||
Key terms
- Zero Trust Access Management: Zero Trust access management is the practice of making every access decision explicit, contextual, and continuously reassessed. It replaces blanket trust in a network zone with identity, device, and risk-based policy that can change during a session. In mature programmes, it governs both human and non-human actors.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
- Immutable session recording: A tamper-resistant record of what happened during a privileged access session. It preserves activity context for investigation, audit, and accountability, which is especially important when humans and automated identities can both make changes to infrastructure.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org