Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: AWS Shared Responsibility in DevSecOps breaks down when teams assume managed services remove their obligations, leaving application, data, identity, and configuration risk outside the provider boundary, according to Arnica. The operational gap is not cloud coverage but responsibility mapping, continuous visibility, and policy enforcement across code, pipelines, and runtime.
NHIMG editorial — based on content published by Arnica: AWS Shared Responsibility: A DevSecOps Guide (May 2026)
Questions worth separating out
Q: How should security teams implement shared responsibility in AWS environments?
A: They should map every AWS service to the specific security controls the organisation owns, then enforce those controls in code review, CI, and runtime.
Q: Why do managed cloud services still create application security risk?
A: Managed services reduce infrastructure burden, but they do not remove responsibility for code, access policy, identity, or data handling.
Q: What do teams get wrong about cloud identity security?
A: Teams often assume that strong application security controls automatically neutralise the risk created by shared infrastructure.
Practitioner guidance
- Build a service-by-service responsibility matrix Map EC2, Lambda, containers, managed databases, S3, and third-party integrations to the exact controls your team owns, including patching, access policy, code security, and configuration.
- Embed security checks into pull requests and pipelines Fail builds or block merges when unresolved risks meet your policy threshold, and route findings to the people who own the code rather than to a generic security queue.
- Continuously govern machine identities and secrets Track service accounts, API keys, tokens, and certificates as first-class assets in the shared responsibility model, with ownership, expiry, and revocation paths defined for each workload.
What's in the full article
Arnica's full blog post covers the operational detail this post intentionally leaves for the source:
- Service-by-service examples for EC2, Lambda, S3, and container workloads so teams can translate responsibility into specific controls.
- Developer workflow details for pull request enforcement, ChatOps, and CI integration that show how policy becomes operational.
- Prioritisation logic using CVSS, EPSS, and KEV to decide what should fail builds versus what should be tracked.
- Examples of continuous feedback loops that spot recurring vulnerabilities and risky developer behaviour across the SDLC.
👉 Read Arnica's guide to AWS shared responsibility in DevSecOps →
AWS shared responsibility in DevSecOps environments: are controls keeping up?
Explore further
19/08/2026 4:17 pm
Shared responsibility fails when AWS boundaries are treated as governance boundaries. The cloud provider boundary is real, but it does not define ownership for applications, data, identity, or configuration. In DevSecOps, that distinction matters because the highest-risk controls sit above the infrastructure layer. Organisations that treat managed services as a transfer of security responsibility end up with unowned risk in the exact places attackers target. The practitioner conclusion is simple: ownership must be mapped to service and control, not to the cloud brand.
A question worth separating out:
Q: Who is accountable when AWS access is misconfigured or overexposed?
A: Accountability sits with the organisation that owns the identities, policies, and workloads, not with AWS infrastructure security. Under the shared responsibility model, the provider secures the underlying platform while the customer governs access, permissions, and secret handling. That means IAM ownership, policy review, and incident response must be clearly assigned inside the enterprise.
👉 Read our full editorial: AWS shared responsibility in DevSecOps: where security still fails
