Policy Validation

chant emits standard CloudFormation JSON: chant build writes exactly what aws cloudformation deploy accepts. cfn-guard, OPA/conftest, Checkov and cfn-lint all validate template.json unchanged, the same way they validate a template written by hand or emitted by CDK’s CfnInclude escape hatch.

An org’s existing .guard files, Rego policies, or Checkov custom checks run against a chant project as they are.

CloudFormation Guard

cfn-guard validates a template against .guard rule files, the same engine behind CDK’s CfnGuardValidator.

chant build src -o t.json
cfn-guard validate -r rules.guard -d t.json

rules.guard is an ordinary cfn-guard rules file (or directory of them) with nothing chant-specific in it. A named compliance pack (NIST 800-53, PCI DSS, CIS) distributed as .guard files works unchanged.

OPA / conftest

conftest runs Open Policy Agent Rego policies against structured data, CloudFormation JSON included:

chant build src -o t.json
conftest test t.json --policy policy/

Checkov and cfn-lint

Checkov and cfn-lint both accept a template path directly, with the flags you’d pass for a hand-written or CDK-synthesized template:

chant build src -o t.json
checkov -f t.json
cfn-lint t.json

Running it as a chant Op step

The recipes above run standalone in any CI job. To run the check as a step in a chant Op that gates an apply the way policyGate does, use guardValidate:

import { Op, phase, build, guardValidate } from "@intentius/chant/op";
import { awsApply } from "@intentius/chant-lexicon-aws";

export default Op({
  name: "deploy",
  phases: [
    // The project's own `npm run build` script writes `template.json`
    // (`chant build src --lexicon aws -o template.json`).
    phase("Build", [build(".")]),
    // Runs `cfn-guard validate -r rules.guard -d template.json`.
    // A violation fails the run here, so nothing is applied.
    phase("Policy", [guardValidate("rules.guard")]),
    phase("Apply", [awsApply("template.json", { stackName: "prod" })]),
  ],
});

guardValidate(rules, opts?) shells cfn-guard through the same runtime-adapter spawn seam every other Op activity uses. It never runs inside chant build, which stays dependency-free and offline. template defaults to <path>/template.json, the convention chant build -o template.json writes to; pass an explicit template if your project writes elsewhere. A non-compliant rule throws (non-retryable), so:

• chant run deploy on the local executor exits non-zero and fails the CI job.
• Placed before an apply phase, the same violation blocks the apply.

Only report mode ships today; it prints a summary of every violation and fails the run. issue/pull-request finding-modes (opening a tracking issue or PR comment instead of just failing) are a follow-up.

Where this fits next to lint.policies

This page is about reusing an external engine against the finished artifact. For project-authored rules written in TypeScript (“no public buckets in prod,” “every bucket must be encrypted”), see Organizational Policy: the same PostSynthCheck shape lexicons ship as domain lint, authored by your org and run inside chant build with no subprocess at all. The two compose: lint.policies catches what’s cheap to express as a resolved-resource check, an external engine’s named compliance pack catches everything else, and both gate the same way.

Limitations

Like CDK’s own synthesis-time Validations, this is advisory build/CI-time validation against the declared template; it never touches a live stack. It catches drift between your source and the compliance pack before a deploy, not after one; runtime enforcement (a resource changed outside chant, or drifted after deploy) is chant lifecycle, AWS Config, or CloudFormation hooks.