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.”
- cdk-nag - CDK-specific. Runs against the CDK construct tree; no direct equivalent outside a CDK project.
- cfn-lint - works anywhere you synthesise a CloudFormation template.
- SonarQube, OWASP - work with any CI/CD pipeline: GitHub Actions, Jenkins, GitLab CI, or anything else.
The examples use CDK Pipelines but the tools are portable.
The series
Chapter 1 - Policy Checks with cdk-nag (coming soon)
cdk-nag runs NagPacks (AwsSolutions, HIPAA, NIST, PCI DSS) against the synthesised CDK app at synth time - violations block the build before any CloudFormation changeset is created.
Chapter 2 - Template Linting with cfn-lint (coming soon)
cfn-lint validates the synthesised CloudFormation template for invalid properties, deprecated fields, and best practice violations.
Chapter 3 - Static Analysis with SonarQube (coming soon)
SonarQube runs static analysis on the application code and gates the pipeline on quality thresholds - bugs, security hotspots, code smells.
Chapter 4 - Dependency Scanning with OWASP (coming soon)
OWASP Dependency-Check scans Python and Node dependencies against the CVE database and fails the build on any HIGH or above finding.
Notes
- The series assumes CDK familiarity. The Infrastructure as Code with AWS CDK series covers project setup, constructs, configuration, testing, and CI/CD pipelines.
- Each guardrail is independent - add cdk-nag without cfn-lint, wire in OWASP without SonarQube. No requirement to implement all four at once.