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 describes this as Security of the Cloud and Security in the Cloud.

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 Cloud Development Kit (AWS CDK) follows the shared responsibility model through the specific Amazon Web Services (AWS) services it supports. For AWS service security information, see the AWS service security documentation page and AWS services that are in scope of AWS compliance efforts by compliance program.

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 external parties (meaning unauthenticated identities or identities from different AWS Accounts; 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.

Run CDK code in a trusted execution 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.

Similarly, you should not deploy cloud assemblies from sources that you do not trust. Synthesizing a CDK app produces a cloud assembly (the cdk.out directory by default). It’s possible to deploy a previously synthesized cloud assembly from a different source; for example, cdk deploy --app /downloaded/file/path/cdk.out. Only deploy a cloud assembly that you produced yourself or that comes from a trusted source.

Deploy to a trusted environment

(Your responsibility) CDK treats the AWS Account as the security boundary. This is consistent with the AWS Well-Architected Framework. CDK cannot guarantee that all synthesized infrastructure is secure against actors with permissions in the same Account. Some examples of scenarios that CDK cannot guard against include, but are not limited to, the following:

You should not use CDK in an environment where untrusted identities might perform AWS CloudFormation deployments, or where untrusted identities have AWS Identity and Access Management (IAM) permissions that might interact with resources created by CDK.

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.