Running CDK in production, one thing becomes clear: a passing cdk synth is not the same as a safe deploy. There are four categories of risk that a standard CI/CD pipeline leaves unchecked: IaC policy violations, CloudFormation template errors, application code quality issues, and vulnerable dependencies. Each one has a tool that catches it at build time - and together they form a pipeline where “it deployed” also means “it deployed safely.” ...
This is Chapter 1 of the DevSecOps Guardrails series. cdk-nag runs against the CDK construct tree at synth time and blocks the build on any rule violation - before a changeset is created, before any AWS API call is made. I wired it in as the first guardrail because it is CDK-native: it sees the construct level, not just the synthesised template, which means it can catch things cfn-lint cannot. Adding it is a five-line change to app.py. The part that matters more than setup is suppressions: knowing when to suppress versus fix, and writing a reason string that makes the decision visible in a code review. A synth failure maps directly to a blocked pipeline stage in Jenkins, GitHub Actions, and Azure DevOps with no extra configuration needed. ...