Who should be accountable when a cloud exposure originates in application code?

Why This Matters for Security Teams

When a cloud exposure starts in application code, the security question is not only “what failed?” but “who can actually fix it fastest without losing control?” In practice, the accountable party is usually the code owner, because the flaw lives in a repository, a build pipeline, or a deployment path that security did not author. That is why identity and access failures often become software ownership failures, especially when secrets, permissions, or cloud API calls are hard-coded or overly broad.

This is consistent with NHIMG research showing how quickly non-human access problems become operational problems: the 2024 Non-Human Identity Security Report found that 88.5% of organisations say non-human IAM lags human IAM, while 59.8% see value in dynamic ephemeral credentials. When code is the source of exposure, the alert is only the symptom; the real control point is the development and ownership trail. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that accountability should be tied to defined responsibilities, not just tooling. In practice, many security teams encounter this only after a cloud incident has spread across repos, pipelines, and runtime logs.

How It Works in Practice

Accountability should follow the asset back through the software supply chain. Start with the cloud resource or exposure, identify the application, map it to the repository, and then trace the exact commit, pull request, or configuration change that introduced the risk. That gives security a defensible path from runtime symptom to code owner. For agentic or automated workloads, the same logic applies, but the identity surface is larger because the agent may call tools, mutate infrastructure, or request credentials on demand.

For teams handling non-human identities, the practical model is: source code owns the behavior, platform engineering owns the guardrails, and security owns the policy and verification layer. A mature workflow usually includes:

• Repository-level ownership tags tied to service catalogs and on-call rotation
• Commit and pull request evidence for every cloud-permission change
• Runtime telemetry that links alerts to workload identity, not just IP or account names
• JIT credentials and short-lived secrets for automated services to reduce blast radius
• Policy checks in CI/CD so risky infrastructure changes are blocked before deployment

That approach aligns with the patterns NHIMG documents in the 52 NHI Breaches Analysis and the Guide to the Secret Sprawl Challenge, where exposure is rarely isolated to one layer. External guidance also supports this chain-of-custody approach: NIST control families expect traceable ownership and least privilege, while incident responders increasingly treat code provenance as part of remediation, not an afterthought. These controls tend to break down when application teams can deploy cloud changes without repository linkage, because no one can prove which commit introduced the exposure.

Common Variations and Edge Cases

Tighter accountability often increases process overhead, requiring organisations to balance faster remediation against the friction of tracing every exposure to code history. That tradeoff becomes more visible in microservices, multi-cloud estates, and teams using shared platform modules, where one cloud alert can implicate several owners at once. Current guidance suggests assigning a primary accountable owner, even if multiple teams contribute to the fix, to avoid diffusion of responsibility.

There are also edge cases where the code owner is not the only accountable party. If a platform template, shared library, or infrastructure-as-code module introduced the flaw, the platform team may own the patch while the application team owns the service-level risk acceptance. If an agentic workload made the change autonomously, accountability may extend to the policy that allowed the action, not just the agent itself. The industry has not reached universal consensus on how to split accountability for autonomous changes, but best practice is evolving toward workload identity, policy-as-code, and explicit approval boundaries. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now and the Codefinger AWS S3 ransomware attack show why static ownership alone is not enough when credentials and automation can be reused across environments. In hybrid estates, accountability breaks down when the same codebase is deployed by different teams with different cloud permissions and no shared change record.

Related resources from NHI Mgmt Group

• Who is accountable when a public application flaw leads to secret exposure and code execution?
• Who is accountable when identity teams let high-risk access remain ungoverned in cloud platforms?
• Who is accountable when application identity controls are inconsistent across the enterprise?
• How should security teams build an NHI program when identities are spread across cloud, code, and third-party connections?