🔧 Feature Request: Baseline support to suppress existing violations

[leinardi]

Is this feature request related to a new rule or cfn-lint capabilities?

New capability

Describe the feature you'd like to request

It would be really useful if cfn-lint supported a baseline feature to suppress existing warnings and errors. This would allow teams to focus on newly introduced issues during development, rather than being overwhelmed by legacy violations.

The baseline would be recorded in a file (e.g., cfn-lint-baseline.json), capturing the current set of known violations. These would be excluded from future linting results unless they change.

This approach is common in other linters and tools like ESLint, flake8, Checkstyle and Android Lint.

Describe the solution you'd like

I propose extending cfn-lint with two main capabilities:

1. A --generate-baseline flag (or similar) that stores all current violations in a JSON file.
2. A --baseline-file <path> option that tells cfn-lint to suppress any violations found in the baseline file (unless the finding has changed).

To identify whether a violation is already known, a deduplicated key can be generated based on:

• File path
• Path in the CloudFormation structure
• Rule ID

This way, violations are still detected even if the file lines shift but the issue remains.

Additional context

This would enable:

• ✅ Gradual adoption of cfn-lint in large or legacy codebases.
• 🚫 Prevention of new issues without being blocked by legacy ones.
• 🧹 Incremental cleanup of technical debt over time.

I have already implemented this in CI via a standalone Python script that:

• Generates a cfn-lint-baseline.json file by running cfn-lint -f json --output-file cfn-lint-baseline.json
• Filters current findings by comparing them to the baseline

cfn-lint-baseline.py

The current limitation is that it doesn't integrate cleanly with pre-commit hooks, since it requires manually invoking cfn-lint, bypassing the configured hook logic. Native support in cfn-lint would make this workflow much more flexible and robust.

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request

Would this feature include a breaking change?

• ⚠️ This feature might incur a breaking change