This is the AWS CDK v2 Developer Guide. The older CDK v1 entered maintenance on June 1, 2022 and ended support on June 1, 2023.
Security for the AWS Cloud Development Kit (AWS CDK)
The AWS Shared Responsibility Model
Cloud security at Amazon Web Services (AWS) is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The Shared Responsibility Model
Security of the Cloud – AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud and providing you with services that you can use securely. Our security responsibility is the highest priority at AWS, and the effectiveness of our security is regularly tested and verified by third-party auditors as part of the AWS Compliance Programs
Security in the Cloud – Your responsibility is determined by the AWS service you are using, and other factors including the sensitivity of your data, your organization’s requirements, and applicable laws and regulations.
The AWS CDK follows the shared responsibility model
Security of the AWS CDK
Given a program written in a general purpose programming language that describes the shape of your desired infrastructure, the AWS CDK generates a set of deployable artifacts that will create that infrastructure.
Security of default generated infrastructure
(AWS' responsibility) Constructs in the AWS Construct Library are designed to generate
infrastructure that does not allow data disclosure, data manipulation, elevation
of privilege or other tampering by unauthorized third parties (unless explicitly
configured otherwise, which is in line with the
shared
responsibility model
Any violation of this expectation can be reported through the company-wide vulnerability reporting mechanisms
Execution in a trusted environment
(Your responsibility) CDK is designed to run in a trusted environment with trusted inputs. It is your responsibility to ensure user code, any libraries loaded into memory (including those downloaded from the Internet via a package manager like NPM or pip), or inputs into the CDK construct libraries are trustworthy. The CDK cannot protect you from malicious intent.
You should not use CDK in an environment where untrusted authors write parts of the code that drives a CDK application, or where untrusted parties control inputs to CDK constructs without validation.
Compliance verification is an external process
(Your responsibility) Because of the unlimited expressivity afforded by a general purpose programming language, custom CDK constructs cannot guarantee an unbypassable compliance with security policies. CDK has mechanisms to shift left compliance checks, and mechanisms that can help developers meet compliance requirements with minimal effort; but a determined enough developer will always be able to bypass the output of the specially designed constructs.
If you need compliance guarantees, impose them via a process external to the CDK application like CloudFormation Hooks, or a separate CloudFormation template validation step in the CI Pipeline.
