compose-lint

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.
https://github.com/tmatens/compose-lint

Every release is identified by a signed, annotated git tag of the form vMAJOR.MINOR.PATCH (e.g. v0.4.0). Tags are pushed to GitHub and drive the publish pipeline (PyPI + Docker Hub + GitHub Release with Sigstore attestations). Tag list: https://github.com/tmatens/compose-lint/tags

Repository on GitHub, which uses git. git is distributed.

Each release has a unique SemVer identifier set in both pyproject.toml and src/compose_lint/init.py and published to PyPI as an immutable version (PyPI rejects re-uploads of the same version). Current release: 0.4.0. Release history: https://pypi.org/project/compose-lint/#history

Every release is identified by a signed annotated git tag of the form vMAJOR.MINOR.PATCH (e.g. v0.4.0, v0.3.7). Tags are created as part of the release process documented in docs/RELEASING.md, pushed to GitHub, and trigger the publish workflow (PyPI via Trusted Publishers, Docker Hub multi-arch image, and GitHub Release with Sigstore attestations). Full tag list: https://github.com/tmatens/compose-lint/tags

Non-trivial release notes file in repository: https://github.com/tmatens/compose-lint/blob/main/CHANGELOG.md.

The project maintains release notes in CHANGELOG.md (Keep a Changelog format), with one section per tagged release. No publicly known runtime vulnerabilities (CVEs or GitHub Security Advisories) have been reported or fixed in compose-lint to date, so there are none to enumerate. The vulnerability disclosure process is documented in SECURITY.md: reports go through GitHub private vulnerability reporting, and any future fix will be published as a GHSA and called out in the corresponding CHANGELOG.md release entry.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/tmatens/compose-lint/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues as its public issue tracker for bug reports and feature requests. The tracker is linked from README.md, CONTRIBUTING.md, and the PyPI project page.

All five user-filed issues opened to date have been triaged by the maintainer. Four are closed with fixes shipped (#1, #2, #3, #5 — the latter shipped in v0.4.0 via ADR-010); #4 is an open enhancement still in the backlog. Issue #51 is the Renovate dependency dashboard, not a user report. Response rate on bug reports is 100%. See https://github.com/tmatens/compose-lint/issues?q=is%3Aissue

Three enhancement requests have been filed (#1, #4, #5). Two are closed with the feature shipped (#1 in early releases; #5 in v0.4.0). #4 is acknowledged and tracked in the backlog. Response rate >50%. See https://github.com/tmatens/compose-lint/issues?q=is%3Aissue+label%3Aenhancement,OR-equivalently the full issue list above.

All bug reports, enhancement requests, and maintainer responses are filed as GitHub Issues on the public repository. The full history (open and closed, including every comment) is permanently archived and searchable at the URL above. Pull request discussions are likewise archived at https://github.com/tmatens/compose-lint/pulls?q=is%3Apr .

SECURITY.md documents the CVD process: private reporting via GitHub Security Advisories, acknowledgement within 7 days, coordinated fix and advisory publication with credit. See https://github.com/tmatens/compose-lint/blob/main/SECURITY.md [osps_vm_01_01]

GitHub private vulnerability reporting is enabled and documented in SECURITY.md: https://github.com/tmatens/compose-lint/security/advisories/new [osps_vm_03_01]

The full issue history (open and closed, with all comments) is publicly searchable at https://github.com/tmatens/compose-lint/issues?q=is%3Aissue . PR discussions are likewise archived at https://github.com/tmatens/compose-lint/pulls?q=is%3Apr .

Python package built via PEP 517 with hatchling as configured in pyproject.toml. Standard invocation: python -m build (sdist + wheel) or pip install .. The same build is exercised on every PR by the build-wheel job in .github/workflows/ci.yml and by .github/workflows/publish.yml for releases.

Build backend is hatchling (the default Python PEP 517 backend), invoked via build (PyPA) and pip. All three are the standard Python packaging toolchain.

The entire build toolchain is FLOSS: hatchling (MIT), build (MIT), pip (MIT), and CPython (PSF). No proprietary tools are required.

CI runs the full pytest suite across Python 3.10–3.14 on every PR via .github/workflows/ci.yml; the aggregate ci-ok check is required by the main branch ruleset, blocking merge unless tests pass. [osps_qa_06_01]

Invoked the standard Python way: pytest at the repo root. Configured under [tool.pytest.ini_options] in pyproject.toml with testpaths = ["tests"]. Documented in CONTRIBUTING.md under "Development setup".

Every rule in src/compose_lint/rules/ has a dedicated tests/test_CL{NNNN}.py file with both positive (rule triggers) and negative (clean compose file) fixtures, per the checklist in CONTRIBUTING.md. Parser, engine, config, and each output formatter (text/JSON/SARIF) also have dedicated test modules.

CI runs the full pytest suite across Python 3.10–3.14 on every PR via .github/workflows/ci.yml; the aggregate ci-ok check is required by the main branch ruleset, blocking merge unless tests pass. [osps_qa_06_01]

CONTRIBUTING.md §"Adding a new rule" step 5 requires a tests/test_CL{NNNN}.py with positive and negative cases for every new rule. §"PR expectations" states: "New rules need positive and negative tests. Bug fixes need a regression test."

Every CL-XXXX rule file in src/compose_lint/rules/ has a matching tests/test_CL{NNNN}.py. Recent examples: git log --diff-filter=A --name-only -- 'src/compose_lint/rules/CL-.py' pairs 1:1 with adds under tests/test_CL.py in the same commit.

Documented in CONTRIBUTING.md §"Adding a new rule" (test file is step 5 of the checklist) and §"PR expectations" ("Update tests. New rules need positive and negative tests. Bug fixes need a regression test."). The PR template links back to CONTRIBUTING.md.

Three FLOSS linters gate every PR in .github/workflows/ci.yml: ruff check (selects E,W,F,I,UP,B,SIM,TCH per [tool.ruff.lint] in pyproject.toml), ruff format --check, and mypy src/ in strict mode ([tool.mypy] strict = true). Additionally actionlint lints GitHub Actions workflows, bandit scans for Python security issues, and pip-audit scans dependencies.

ruff check, ruff format --check, and mypy src/ are required checks on main via the branch ruleset; any warning fails the PR and blocks merge. Maintainers fix — never suppress — findings unless there's a documented reason.

mypy runs with strict = true (the maximum setting: enables all optional strict flags). ruff selects broad rule families including B (bugbear correctness checks) and UP (pyupgrade modernization) in addition to the defaults. Formatting drift is also an error (ruff format --check).

The project is a security-focused linter authored by maintainers with working knowledge of secure-design principles (least privilege, defense in depth, input validation, minimal attack surface). Evidence in-repo: every rule in docs/rules/ cites an authoritative source (OWASP, CIS Docker Benchmark, Docker docs); docs/severity.md applies a real-world exploitability rubric; SECURITY.md defines scope, private vulnerability reporting, and supply-chain guarantees; the release pipeline uses Trusted Publishers (OIDC, no long-lived tokens) and Sigstore attestations.

Maintainers are familiar with common error classes and their mitigations. In-repo evidence: the rule catalogue (src/compose_lint/rules/, docs/rules/) enumerates and mitigates common Compose-file misconfigurations (privileged containers, host namespace sharing, writable root filesystems, ${VAR} secret leakage, port exposure, missing healthchecks, etc.), each with a documented fix. For the tool's own code, bandit scans for common Python vulnerability patterns (injection, insecure temp files, weak crypto APIs) on every PR, and pip-audit / CodeQL / Docker Scout guard the supply chain.

All ten cryptography criteria — N/A. compose-lint is a static analyzer for Docker Compose YAML files; the software it produces contains no cryptographic functionality (no protocols, algorithms, password storage, key/nonce generation, or security mechanisms depending on crypto). Its only runtime dependency is PyYAML. Cryptography is used only in the release pipeline (Sigstore signing, GitHub OIDC), not in the shipped code.

N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.

N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.

N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.

N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.

N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.

N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.

N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Release artifacts are signed, not just hashed. PyPI wheels and sdists are published via PyPI Trusted Publishing (GitHub Actions OIDC, no long-lived tokens) with Sigstore build attestations — see SECURITY.md §"Supply Chain" and .github/workflows/publish.yml. GitHub Releases attach Sigstore bundles (verified post-release by the publish.yml canary job using sigstore verify). Consumers can verify provenance with pip install --require-hashes against the lockfile or sigstore verify against the release bundle.

No known unpatched vulnerabilities of medium or higher severity. Continuous scanning gates every PR and runs on schedule: pip-audit (dependency CVEs), bandit (Python source), CodeQL (.github/workflows/codeql.yml), Docker Scout (scout-scan.yml), OpenSSF Scorecard (scorecard.yml), and ClusterFuzzLite fuzzing (cflite-batch.yml, cflite-pr.yml). Private vulnerability reporting is enabled per SECURITY.md.

SECURITY.md commits to acknowledgement within 7 days and coordinated fix + advisory for valid reports. Only the latest minor release receives security fixes (documented supported-versions policy). Renovate / Dependabot auto-open PRs for vulnerable dependency bumps, so critical upstream CVEs are patched as soon as an upstream fix lands.

GitHub secret scanning and push protection are both enabled, blocking pushes that contain detected credentials. PyPI publishing uses Trusted Publishing (OIDC), so no long-lived PyPI tokens exist in the repo or secrets store. Remaining workflow credentials are held in GitHub encrypted Secrets and referenced only via ${{ secrets.* }} at runtime. .gitignore excludes .env and similar files. See https://github.com/tmatens/compose-lint/blob/main/SECURITY.md [osps_br_07_01]

Multiple FLOSS static analyzers are applied before every release: bandit (Python security linter) in .github/workflows/ci.yml, GitHub CodeQL (.github/workflows/codeql.yml) on every PR and weekly schedule, and ruff + mypy --strict as quality gates. All are required checks on main, so no release ships without a green run.

Bandit and CodeQL both implement vulnerability-pattern rules. Bandit scans for the Python-specific common-weakness patterns (B-series: shell injection, insecure deserialization, weak crypto calls, hardcoded secrets, etc.). CodeQL's default query suite covers OWASP/CWE categories (injection, path traversal, SSRF, XSS).

Bandit and CodeQL are required status checks on main; any finding they report blocks merge until fixed, so no medium+ finding can reach a release. The scheduled CodeQL run (.github/workflows/codeql.yml, weekly) catches newly-added queries against existing code and files an issue on failure.

Static analysis runs on every PR (CI fires on pull_request) and on pushes to main. CodeQL also runs on a weekly cron (27 4 * * 1); Scorecard runs weekly (13 5 * * 1).

The project runs continuous fuzzing via ClusterFuzzLite: .github/workflows/cflite-pr.yml fuzzes every PR, .github/workflows/cflite-batch.yml runs a batch fuzzing campaign daily (17 4 * * *). The harness is fuzz/fuzz_compose.py, an Atheris harness that exercises the full parser + engine pipeline end-to-end. A scheduled failure auto-files a tracking issue.

compose-lint is written in pure Python (a memory-safe language) with PyYAML as the sole runtime dependency. No C/C++/unsafe-Rust code is produced or shipped.

The Atheris fuzz harness (fuzz/fuzz_compose.py) treats any unexpected exception as a crash — i.e., the whole lint pipeline is run under an implicit assertion that only the documented error set may escape. The pytest suite additionally relies on Python's built-in assert (not stripped at runtime) throughout tests/.

ClusterFuzzLite's PR job blocks merge on new crashes; the daily batch job opens an issue on failure so regressions are triaged promptly. No open medium+ fuzz findings exist.