CDK Insights Static Analysis
CDK Insights performs comprehensive static analysis of your CDK stacks, identifying security vulnerabilities, cost optimizations, and best practice violations.
How Static Analysis Works
CDK Insights analyzes your CDK application by:
- Running
cdk synthto generate CloudFormation templates - Parsing the CloudFormation output to understand your infrastructure
- Applying a comprehensive set of rules to identify issues
- Generating detailed reports with actionable recommendations
This approach ensures that we analyze exactly what AWS will deploy, not just your CDK code, giving you the most accurate results.
What Gets Analyzed
Security
Identifies security vulnerabilities and misconfigurations
Cost Optimization
Finds opportunities to reduce AWS costs
Best Practices
Enforces AWS and CDK best practices
Rule Sources
CDK Insights Rules
Custom rules specifically designed for CDK patterns and best practices
CDK Nag Rules
Integration with the popular CDK Nag security analysis tool
CDK Mixin Awareness
CDK Insights understands CDK Mixins — the composable property-mutating API that ships with aws-cdk-lib >= ~2.230. We read the aws:cdk:analytics:mixin manifest stream that aws-cdk-lib writes for every .with() / Mixins.of(scope).apply(...) call, so each finding tells you which mixins (if any) touched the resource and any remediation we suggest accounts for them re-applying at synth.
On top of attribution, two template-level rules detect the specific footguns mixins introduce:
Compliance-Critical Mixin Applied Without Stack Coverage
Fires when a compliance-critical mixin (e.g. BucketEncryption, BucketVersioning, BucketBlockPublicAccess) is applied to some but not all resources of its target type. This is the template-visible signature of Mixins.of(scope).apply(...) silently skipping resources outside its selector. Recommends switching to requireAll() so synth fails when the mixin can't be applied.
Custom Mixin Applied Across Many Resource Types
Fires when a user-defined mixin appears on resources spanning 3+ distinct CFN types in the same stack — the template-visible signature of .with(customMixin) recursing through every descendant because the mixin's supports() filter accepts every construct. Verify your mixin narrows to the intended type.
See the dedicated CDK Mixins page for the full picture, or our note on Aspects vs Mixins.
Missing IAM Permission Detection
Most scanners only flag over-permissioning. CDK Insights also detects under-permissioning: compute wired to a resource whose grant was never made — the classic forgotten table.grantReadWriteData(fn) that synths and deploys cleanly, then fails with AccessDenied at runtime. Because CDK grants materialize as IAM policies in the synthesized template, the absence of a grant is statically provable.
Five template-level rules cover the family. They fire only on provable zero coverage — imported roles, conditional policies, and anything unresolvable are conservatively skipped, so a properly-granted L2 app produces zero findings:
Compute Reference Without IAM Permissions
A Lambda function or ECS task definition references a DynamoDB table, S3 bucket, SQS queue, SNS topic, Kinesis stream, secret, event bus, or state machine through an environment variable, but its execution role grants zero actions in that service's namespace on it. An ECS task with no task role at all is called out explicitly.
Event Source Mapping Missing Required IAM Permissions
An event source mapping polls an SQS queue, Kinesis stream, or DynamoDB stream but the function role lacks the documented required action set. The finding names exactly the missing actions (e.g. sqs:DeleteMessage).
Lambda Trigger Missing Resource-Based Permission
An EventBridge rule, SNS subscription, or S3 bucket notification targets a function with no matching AWS::Lambda::Permission — so the trigger silently never fires. CDK's own notification patterns are excluded.
ECS Container Secrets Without Execution Role Access
A container pulls Secrets[].ValueFrom from a Secrets Manager secret or SSM parameter the task execution role cannot read — the container fails to start with ResourceInitializationError.
Step Functions Integration Without Role Permissions
A state machine definition declares a service integration (lambda:invoke, dynamodb:getItem, sqs:sendMessage, ...) that its role cannot perform, so the task state fails at execution time.
Available from CLI 1.55.0 in the free static tier. Suppress individual rules with ignoreRules: ["TL-PERM-001"] or the whole family with ignoreRules: ["TL-PERM-*"].
Supported AWS Services
CDK Insights analyzes resources across 35 AWS services, with targeted checks for each:
Understanding Severity Levels
Critical
Immediate security or compliance issues that should be fixed immediately
High
Security or configuration issues that should be addressed soon
Medium
Best practice violations or potential optimization opportunities
Low
Minor issues or suggestions for improvement
Example Analysis Output
Here's what a typical static analysis output looks like:
Ready to Run Your First Analysis?
Start with static analysis to identify security and configuration issues in your CDK stacks.