AWS CDK

Deltz does not parse CDK programs. It gates what your CDK app synthesises — which is CloudFormation, and CloudFormation is a first-class input.

There is no special flag. cdk synth writes templates, and the gate reads templates.

What works

cdk synth                 # writes cdk.out/*.template.json
garboard gate cdk.out

That is the whole integration. cdk synth needs no cloud credentials — it evaluates your app locally — so unlike the Pulumi path there is no credential boundary to think about at all.

On a small demo app (an S3 bucket, a VPC, an RDS instance) the gate reports:

✗ [critical]  S3 bucket has no encryption configuration    DeltzCdkDemo.template.json:3
✗ [critical]  RDS instance is publicly accessible          DeltzCdkDemo.template.json:330
✗ [critical]  RDS instance is not encrypted at rest        DeltzCdkDemo.template.json:330
· [warn]      Database has no backup retention configured  DeltzCdkDemo.template.json:330

4 finding(s) · 3 blocking · 1 advisory

Roughly twelve of the seventeen built-in rules reach CloudFormation, along with the compliance tags and the custom-rule ABI. The intrinsics — Ref, Fn::Sub, Fn::GetAtt, Fn::If — are treated as unknown, so a rule never fires on a value the template does not actually pin down.

The evidence is in the synthesised template, not your code

Findings cite cdk.out/DeltzCdkDemo.template.json:330, not lib/database-stack.ts:42.

This is the main thing to weigh before adopting it. A reviewer reading the finding sees the resource CDK produced, and has to map that back to the construct that produced it themselves. CDK writes a aws:cdk:path into each resource’s metadata, which usually makes that mapping obvious, but Deltz does not currently follow it and the link is not made for you.

Do not trust the conventions

The gate works. Convention derivation on synthesised output does not, and this is not a gap we intend to close by trying harder.

Run garboard scan over cdk.out and it will happily derive something. On the demo app above it derived “tags carry keys: Name” with high confidence — from tags CDK generated automatically, that nobody on the team decided. That is derivation measuring the framework’s behaviour and reporting it as your team’s rule.

The same inversion applies as for Pulumi: derivation reads what a repository does to infer the rule it keeps, and evaluated output shows the convention’s effect rather than the convention.

So: gate your synthesised templates, and ignore the RCD. If learning your conventions is why you are evaluating Deltz, CDK is not served today.

If you also commit your templates

Nothing changes — the gate reads them wherever they are. Teams that commit cdk.out get the review on the diff without a synth step in CI; teams that do not should synth first, as above.

In GitHub Actions

- run: npx cdk synth
  # no cloud credentials needed — synth evaluates locally

- uses: garboardai/garboard-action@v1
  with:
    path: cdk.out

Why there is no CDK frontend

For the same reason there is no Pulumi one, and one more.

Supporting CDK properly means TypeScript, Python, Java, Go and C# — and CDK’s construct model means the interesting rules live in constructs, not in the resources they emit. A parser that read the program would still have to evaluate it to know what a construct produces, at which point it is synth with extra steps.

CloudFormation was the last frontend that fit Deltz’s existing facts model without bringing its own. CDK does not, and synth already gives us its output.