compose-lint 0.28.0__tar.gz

compose_lint-0.28.0/.githooks/pre-push

@@ -0,0 +1,37 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+while read local_ref local_sha remote_ref remote_sha; do
+  if [ "$local_sha" = "0000000000000000000000000000000000000000" ]; then
+    continue  # branch deletion, skip
+  fi
+
+  # Only check commits unique to this branch — not commits already on main
+  # (including GitHub squash-merge commits which carry GitHub's own key).
+  base=$(git merge-base "$local_sha" origin/main 2>/dev/null \
+    || git rev-list --max-parents=0 HEAD)
+
+  while IFS= read -r line; do
+    sha="${line%% *}"
+    status="${line##* }"
+    if [ "$status" != "G" ]; then
+      echo "error: commit ${sha} is unsigned or unverified — sign your commits before pushing"
+      exit 1
+    fi
+  done < <(git log --format="%H %G?" "${base}..${local_sha}")
+
+  # DCO. Separate from the signature above: signing proves who committed, the
+  # trailer asserts the right to contribute. No git config adds it to every
+  # commit (format.signOff only affects format-patch), so without this check a
+  # missing trailer surfaces in CI — and on a first-time contributor's fork PR,
+  # not until a maintainer approves the run.
+  while IFS=$'\t' read -r sha author_name author_email; do
+    expected="Signed-off-by: ${author_name} <${author_email}>"
+    if ! git log -1 --format='%B' "${sha}" | grep -qiF "${expected}"; then
+      echo "error: commit ${sha} is missing '${expected}'"
+      echo "       add it with 'git commit --amend --signoff', or"
+      echo "       'git rebase --signoff ${base}' for a whole branch"
+      exit 1
+    fi
+  done < <(git log --format='%H%x09%an%x09%ae' "${base}..${local_sha}")
+done

compose_lint-0.28.0/.github/CODEOWNERS

@@ -0,0 +1,8 @@
+# Every file in this repo is owned by @tmatens. This is a single-maintainer
+# project today; CODEOWNERS makes ownership explicit and gives us the hook
+# to hand off specific directories to co-maintainers later without rewriting
+# history.
+#
+# See https://docs.github.com/en/repositories/managing-your-repositories-settings-and-security/customizing-your-repository/about-code-owners
+
+* @tmatens

compose_lint-0.28.0/.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,83 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at tmatens@gmail.com. All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at [https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

compose_lint-0.28.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,98 @@
+name: Bug report
+description: Report incorrect behavior in compose-lint (false positive, false negative, crash, wrong output).
+title: "[bug] "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to file a bug report. Please include a **minimal** Compose file that reproduces the problem — the smaller, the better.
+
+        Security vulnerabilities should go through [private vulnerability reporting](https://github.com/tmatens/compose-lint/security/advisories/new), not this form.
+
+        Docs, code quality, tooling, or a question? Use the "Other" template instead. It doesn't ask for a Compose file.
+
+  - type: textarea
+    id: compose-file
+    attributes:
+      label: Minimal Compose file
+      description: The smallest `docker-compose.yml` that reproduces the issue. Strip anything unrelated.
+      render: yaml
+      placeholder: |
+        services:
+          web:
+            image: nginx:1.27
+            privileged: true
+    validations:
+      required: true
+
+  - type: textarea
+    id: command
+    attributes:
+      label: Command you ran
+      description: The exact `compose-lint` invocation.
+      render: shell
+      placeholder: compose-lint docker-compose.yml
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+      description: What did you expect to happen?
+    validations:
+      required: true
+
+  - type: textarea
+    id: actual
+    attributes:
+      label: Actual behavior
+      description: What actually happened?
+    validations:
+      required: true
+
+  - type: textarea
+    id: output
+    attributes:
+      label: Output
+      description: The full `compose-lint` output, if there is any.
+      render: shell
+    validations:
+      required: false
+
+  - type: input
+    id: version
+    attributes:
+      label: compose-lint version
+      description: Output of `compose-lint --version`.
+      placeholder: "x.y.z"
+    validations:
+      required: true
+
+  - type: input
+    id: python-version
+    attributes:
+      label: Python version
+      description: Output of `python --version`.
+      placeholder: "3.12.3"
+    validations:
+      required: true
+
+  - type: input
+    id: os
+    attributes:
+      label: Operating system
+      placeholder: "Ubuntu 24.04, macOS 14.5, Windows 11, ..."
+    validations:
+      required: false
+
+  - type: checkboxes
+    id: checks
+    attributes:
+      label: Before submitting
+      options:
+        - label: I searched existing issues and this is not a duplicate.
+          required: true
+        - label: I am running the latest released version, or I have confirmed the bug still reproduces on `main`.
+          required: true

compose_lint-0.28.0/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: false

compose_lint-0.28.0/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,45 @@
+name: Feature request
+description: Suggest a non-rule feature (CLI flag, output format, config option, tooling integration, etc.). For new rules, use the "Rule proposal" template instead.
+title: "[feature] "
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        compose-lint's scope is deliberately narrow: static security analysis of Compose files. Features that push it toward being a general-purpose Compose linter, a runtime scanner, or a replacement for KICS/Checkov are out of scope. See [AGENTS.md](https://github.com/tmatens/compose-lint/blob/main/AGENTS.md#project-overview) for the full scope statement.
+
+        **Proposing a new security rule? Use the "Rule proposal" template instead.**
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: What problem does this solve?
+      description: Describe the use case. What can't you do today that you want to do?
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposed-solution
+    attributes:
+      label: Proposed solution
+      description: What should compose-lint do? Show the CLI invocation, config key, or output format you have in mind.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+      description: What workarounds exist today? What other approaches did you consider, and why is this the right one?
+    validations:
+      required: false
+
+  - type: checkboxes
+    id: scope-check
+    attributes:
+      label: Scope check
+      options:
+        - label: This is not a new security rule (those use the "Rule proposal" template).
+          required: true
+        - label: This fits compose-lint's scope as a zero-config security linter, not a general Compose linter or runtime scanner.
+          required: true

compose_lint-0.28.0/.github/ISSUE_TEMPLATE/other.yml

@@ -0,0 +1,27 @@
+name: Other
+description: Anything that isn't a linter bug or a feature — docs, code quality, tooling, CI, or a question.
+title: "[other] "
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use this for anything the other templates don't fit: documentation, code quality, project tooling, CI, or a question about compose-lint.
+
+        Security vulnerabilities should go through [private vulnerability reporting](https://github.com/tmatens/compose-lint/security/advisories/new), not this form.
+
+  - type: textarea
+    id: details
+    attributes:
+      label: What's on your mind?
+      description: Describe the issue or question. Link to the file, doc, or line if there is one.
+    validations:
+      required: true
+
+  - type: input
+    id: version
+    attributes:
+      label: compose-lint version
+      description: Only if it matters for this issue.
+      placeholder: "x.y.z"
+    validations:
+      required: false

compose_lint-0.28.0/.github/ISSUE_TEMPLATE/rule_proposal.yml

@@ -0,0 +1,101 @@
+name: Rule proposal
+description: Propose a new CL-XXXX rule. Rules must be grounded in an authoritative source — opinion-only rules are not accepted.
+title: "[rule] "
+labels: ["rule-proposal"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for proposing a new rule. Every rule in compose-lint must be traceable to OWASP, CIS, or Docker's official documentation. If you can't point to an authoritative source, the rule probably isn't a fit for this tool.
+
+        Please read [AGENTS.md — Rule Design Philosophy](https://github.com/tmatens/compose-lint/blob/main/AGENTS.md#rule-design-philosophy) and [docs/severity.md](https://github.com/tmatens/compose-lint/blob/main/docs/severity.md) before filing.
+
+  - type: textarea
+    id: risk
+    attributes:
+      label: What is the risk?
+      description: Describe the real-world consequence of the misconfiguration. What can an attacker do? What's the blast radius?
+    validations:
+      required: true
+
+  - type: textarea
+    id: authoritative-source
+    attributes:
+      label: Authoritative source
+      description: |
+        Direct link to the OWASP Docker Security Cheat Sheet, CIS Docker Benchmark, or Docker official documentation section that supports this rule. Quote the relevant text.
+      placeholder: |
+        https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-1-...
+
+        "Do not use the --privileged flag..."
+    validations:
+      required: true
+
+  - type: textarea
+    id: insecure-example
+    attributes:
+      label: Example insecure YAML
+      description: A Compose snippet the rule should flag.
+      render: yaml
+      placeholder: |
+        services:
+          web:
+            image: nginx:1.27
+            privileged: true
+    validations:
+      required: true
+
+  - type: textarea
+    id: fixed-example
+    attributes:
+      label: Example fixed YAML
+      description: The same snippet, remediated. This becomes the fix guidance shown to users.
+      render: yaml
+      placeholder: |
+        services:
+          web:
+            image: nginx:1.27
+            # privileged removed; add specific capabilities instead if needed
+            cap_add:
+              - NET_BIND_SERVICE
+    validations:
+      required: true
+
+  - type: dropdown
+    id: proposed-severity
+    attributes:
+      label: Proposed severity
+      description: See [docs/severity.md](https://github.com/tmatens/compose-lint/blob/main/docs/severity.md) for the scoring matrix.
+      options:
+        - CRITICAL — direct path to host compromise
+        - HIGH — exposed attack surface or requires chaining for cross-container/host impact
+        - MEDIUM — requires chaining for single-container impact, or hardening gap with cross-container scope
+        - LOW — hardening gap contained within a single container
+    validations:
+      required: true
+
+  - type: textarea
+    id: severity-reasoning
+    attributes:
+      label: Severity reasoning
+      description: Walk through the two axes — exploitability and impact scope — that justify your proposed severity.
+    validations:
+      required: true
+
+  - type: textarea
+    id: false-positives
+    attributes:
+      label: Known false positives or edge cases
+      description: Are there legitimate reasons to configure it this way? How should the rule handle them?
+    validations:
+      required: false
+
+  - type: checkboxes
+    id: checks
+    attributes:
+      label: Before submitting
+      options:
+        - label: I searched existing rules (`docs/rules/`) and issues to confirm this rule does not already exist and has not already been proposed.
+          required: true
+        - label: My authoritative source is OWASP, CIS, or Docker official documentation — not a blog post or personal opinion.
+          required: true

compose_lint-0.28.0/.github/SECURITY.md

@@ -0,0 +1,49 @@
+# Security Policy
+
+For what compose-lint will and will not protect you against, see
+[docs/SECURITY-EXPECTATIONS.md](../docs/SECURITY-EXPECTATIONS.md). For
+the full assurance case (threat model, trust boundaries, mitigations),
+see [docs/ASSURANCE.md](../docs/ASSURANCE.md).
+
+## Supported Versions
+
+compose-lint follows semantic versioning. Only the latest minor release
+receives security fixes.
+
+## Reporting a Vulnerability
+
+**Please do not report security vulnerabilities through public GitHub issues.**
+
+Use GitHub's private vulnerability reporting:
+
+1. Go to <https://github.com/tmatens/compose-lint/security/advisories/new>
+2. Submit a report with reproduction steps and impact
+
+You should receive an acknowledgement within 7 days. If the report is valid, a fix
+will be coordinated and released, and the advisory will be published with credit
+unless you request otherwise.
+
+## Scope
+
+In scope:
+
+- Code execution or information disclosure via crafted Compose files
+- Tampering with the published PyPI package or GitHub Action
+- Vulnerabilities in dependencies that are exploitable via compose-lint
+
+Out of scope:
+
+- False positives or false negatives in security rules — file these as normal
+  issues
+- Findings against vulnerable Compose files in `tests/compose_files/` (these are
+  intentionally insecure fixtures)
+
+## Supply Chain
+
+- PyPI releases use [Trusted Publishing](https://docs.pypi.org/trusted-publishers/)
+  via GitHub Actions OIDC. No long-lived API tokens exist.
+- Releases include [Sigstore build attestations](https://docs.pypi.org/attestations/).
+  Verify with `pip install compose-lint --require-hashes` plus the published
+  attestation.
+- Dependencies are kept current by Renovate. CodeQL and OpenSSF Scorecard run
+  on every push and weekly.

compose_lint-0.28.0/.github/actions/update-dockerhub-description/action.yml

@@ -0,0 +1,47 @@
+name: 'Update Docker Hub description'
+description: >
+  Sync a Docker Hub repository's overview (long description) and short
+  description from a local markdown file (default: the trimmed
+  docs/dockerhub-overview.md, kept under Docker Hub's 25000-byte cap —
+  NOT README.md, which is uncapped). First-party replacement for
+  peter-evans/dockerhub-description — no third-party Node bundle holds the
+  delete-capable Docker Hub PAT. Implementation is a single bash script
+  invoking the Docker Hub v2 API; review diff before bumping.
+
+inputs:
+  username:
+    description: >
+      Docker Hub username of the account that owns the PAT. Not the
+      organization name, even if the repository lives under an org.
+    required: true
+  token:
+    description: >
+      Docker Hub Personal Access Token with "Read, Write, Delete" scope.
+      The description PATCH endpoint rejects narrower scopes with HTTP 403.
+    required: true
+  repository:
+    description: Docker Hub repository in `<namespace>/<name>` form.
+    required: true
+  readme-filepath:
+    description: Path to the markdown file whose contents become the overview.
+    required: false
+    default: './docs/dockerhub-overview.md'
+  short-description:
+    description: One-line short description shown under the repo title.
+    required: false
+    default: 'Security-focused linter for Docker Compose files'
+
+runs:
+  using: 'composite'
+  steps:
+    - name: Sync Docker Hub description
+      shell: bash
+      env:
+        DOCKERHUB_USERNAME: ${{ inputs.username }}
+        DOCKERHUB_TOKEN: ${{ inputs.token }}
+        DOCKERHUB_REPO: ${{ inputs.repository }}
+        README_PATH: ${{ inputs.readme-filepath }}
+        SHORT_DESCRIPTION: ${{ inputs.short-description }}
+      run: |
+        "${GITHUB_WORKSPACE}/scripts/update-dockerhub-description.sh" \
+          "${DOCKERHUB_REPO}" "${README_PATH}"

compose_lint-0.28.0/.github/allowed_signers

@@ -0,0 +1,30 @@
+# SSH allowed-signers file for verifying compose-lint release tags.
+#
+# Format: <principal> [namespaces=...] <key-type> <base64-key> [comment]
+# See `man ssh-keygen` SSH ALLOWED-SIGNERS FILE FORMAT for the full spec.
+#
+# `namespaces="git"` scopes the key to git-context signatures so it cannot
+# be reused for arbitrary SSH signing if leaked.
+#
+# This file is consumed by the `verify-tag` job in .github/workflows/publish.yml,
+# which runs `git verify-tag` against every release tag before any publish step.
+# Adding a key here grants release-signing authority — treat changes like a
+# maintainer promotion (see GOVERNANCE.md §"Adding a maintainer").
+#
+# To add or rotate a key:
+#   1. Add a line below with the new public key.
+#   2. Open a PR titled "Add release signing key for <name>" or "Rotate release signing key".
+#   3. After merge, sign the next release tag with the new key. publish.yml
+#      will refuse to publish if it cannot verify against this file.
+#
+# Removing a key revokes release-signing authority and is a maintainer-removal
+# action (see GOVERNANCE.md §"Removing a maintainer").
+
+# Todd Matens — release signing key (used to sign vX.Y.Z annotated tags
+# from v0.3.7 onward). Verified against tag v0.7.0 (commit 23da963).
+tmatens@gmail.com namespaces="git" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINz74LQz7YwG5+9fSmqshOfarZt53sBYgFMTGMKJoBY+
+
+# Todd Matens — release signing key for the remote/automated release path (added 2026-06-13).
+# Same principal as the key above; signs vX.Y.Z annotated tags cut from the remote release
+# flow rather than from a workstation. Grants release-signing authority (see GOVERNANCE.md).
+tmatens@gmail.com namespaces="git" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDrB4X76XPEJmLX70W/hdIky3KvboFvWJJKCpL5RE1pT

compose_lint-0.28.0/.github/pull_request_template.md

@@ -0,0 +1,95 @@
+<!--
+Thanks for contributing! Fill in the sections below. Delete any that don't
+apply. See CONTRIBUTING.md for the full workflow, commit conventions, and
+signing requirements.
+-->
+
+## Summary
+
+<!-- What does this PR change? One or two sentences. -->
+
+## Why
+
+<!-- Why is this change needed? Link to the issue, bug report, OWASP/CIS
+     reference, or incident that motivated it. -->
+
+Closes #
+
+## Type of change
+
+- [ ] New rule (`CL-XXXX`)
+- [ ] Bug fix
+- [ ] Refactor (no behavior change)
+- [ ] Documentation
+- [ ] Build / CI / release tooling
+- [ ] Other:
+
+## Origin
+
+<!-- Tick everything that applies. This helps a reviewer decide where to spend
+     attention; it does not affect whether the PR is accepted. -->
+
+- [ ] Personal contribution
+- [ ] Contributed on behalf of an employer or client
+- [ ] Produced primarily by an automated agent
+
+## Evidence
+
+<!-- The questions no check can answer for you. A line each is plenty, and
+     "n/a" is a fine answer where it doesn't apply — a blank one is not.
+     A question you find you can't answer is the finding. -->
+
+**Which tests cover this change, and what do they assert?**
+
+<!-- Name them, e.g. `tests/test_CL0031.py::test_flags_privileged`. CI
+     already requires 90% of the lines you touched to be covered, so "a test
+     executes this line" is proven before a reviewer arrives. This asks the
+     part coverage cannot see: whether the assertion would actually fail if
+     the behavior regressed. For a rule, that means a case that triggers and
+     a case that must not. -->
+
+**What does this change make wrong elsewhere?**
+
+<!-- README, docs/, examples, a rule page, a message quoted in a test. "It
+     doesn't" is a fine answer, but say it deliberately rather than by
+     leaving this empty. -->
+
+## Checklist
+
+<!-- Short on purpose. CI checks sign-off, the four local gates, AI
+     attribution, the rule surfaces and the severity matrix, and a reviewer
+     reads those off the checks tab — repeating them here only asks you to
+     agree with a check that has already run. What's left is what CI cannot
+     see for itself. -->
+
+- [ ] Commits are **signed** — GitHub shows a `Verified` badge on the commits
+      tab (proves *who committed*; not the same as signing off, which the
+      `dco` check enforces separately — see CONTRIBUTING.md)
+- [ ] One logical change per commit; no unrelated changes bundled in
+- [ ] `tests/corpus_snapshot.json.gz` is **not** in this PR (a maintainer regenerates it)
+
+## New rule only
+
+<!-- Delete this section if this PR is not a new rule. -->
+
+**Which source grounds this rule, and where does it demonstrate the need in a
+container context?**
+
+<!-- Link it and quote the line. OWASP, CIS or Docker docs. Generic
+     host/Linux hardening that a container's defaults already neutralize is
+     not enough — see CL-0022 and CL-0023, which were removed for exactly
+     that. If the container-context evidence is thin, the rule's premise
+     needs a runtime check in `scripts/validate_rule_premises.py` instead. -->
+
+**Paste the before / after YAML a user would apply.**
+
+<!-- Copy-pasteable, not a description of what to do. If you can't write the
+     "after" without knowing something the finding doesn't tell the user,
+     the fix guidance isn't specific enough yet. -->
+
+## Breaking changes
+
+<!-- Does this change the CLI, config format, rule IDs, or exit code contract?
+     If yes, describe the migration path. If no, write "None". -->
+
+None