Skip to content

SECURITY.md

Latest commit

 

History

History
97 lines (82 loc) · 4.29 KB

SECURITY.md

File metadata and controls

97 lines (82 loc) · 4.29 KB

Security Policy

Supported versions

claude-memory-lint ships fixes only on the latest minor line. Older minor releases receive no security backports — upgrade to the latest release to get fixes.

Version Supported
0.3.x ✅
0.2.x ❌ — please upgrade
< 0.2 ❌ — please upgrade

Reporting a vulnerability

Please do not open a public GitHub issue for security problems. Instead, file a private report through GitHub Security Advisories:

  1. Open the repository Security tab.
  2. Click "Report a vulnerability" and describe what you found — reproduction steps, the affected version, and the impact you can demonstrate.
  3. Maintainers acknowledge new advisories within 7 days, and aim to ship a fix within 30 days of acknowledgement when the report is reproducible. Reports that turn out to be wider issues (e.g. upstream Python or runner bugs) are co-disclosed with the relevant project on a coordinated timeline.

If GitHub Security Advisories is unavailable for any reason, you may fall back to opening an issue titled "security: please contact me privately" without reproduction details, and a maintainer will reach out off-platform.

In scope

We treat the following as security-relevant and welcome reports on them:

  • Secret leakage by the linter itself — any path through which a matched secret literal reaches stdout, stderr, the JSON / SARIF output, the .bak file, log files, or any error message. R009 has defence-in-depth tests asserting the matched substring is never written to user-facing output; a regression there is the most serious class of bug this project can ship.
  • Path-handling weaknesses — any way to make cml fix write outside the directory it was pointed at, follow symlinks into unrelated trees, or overwrite files under a malicious target name.
  • Backup-file leakage — .bak files written by cml fix are created with mode 600. A regression that widens those permissions, or that writes .bak files outside the corpus directory, is in scope.
  • Atomic-write regressions — cml fix writes through tmpfile + rename to avoid leaving a truncated file on SIGKILL. Any change that observably leaves a half-written .md is in scope.
  • Privacy regressions — the stats command and JSON output deliberately print only filenames, rule IDs, and counts. A change that leaks body content into any non-text reporter is in scope.
  • Supply-chain integrity of releases — issues with the OIDC-based PyPI publish workflow (see .github/workflows/publish.yml), including any change that lets a non-main branch produce a PyPI release, or that bypasses the test / lint / privacy-scan gates that run before publication.

Out of scope

  • Dependency advisories on transitively-installed packages that are development-only (e.g. pytest, ruff, build, twine). Report those upstream; we will follow when a fix is released.
  • Lint findings that you disagree with. Open a regular issue for rule-design feedback.
  • Theoretical attacks against secret patterns the linter does not claim to detect. R009 enumerates the supported pattern set; expanding it is enhancement work, not a security report.

Hardening posture

Some defences are already in place and are exercised by the test suite or CI:

  • No LLM API calls. The linter is heuristic-only; matched content never leaves the local machine.
  • Atomic writes for cml fix (tmpfile + os.replace).
  • Mode 600 on .bak files and on the temp file used for atomic replacement.
  • realpath confinement in path resolution for cml fix so symlinks cannot redirect a write to an arbitrary tree (see src/cml/cli.py and the corresponding unit tests).
  • Privacy-scan workflow runs on every PR; see .github/workflows/test.yml. Catches token literals committed alongside unrelated changes.
  • Pre-commit secret scan (pre-commit-security hook) runs on the maintainer side as the last write-time gate before a commit lands on this repository.
  • OIDC-based PyPI publishing with attestations: true (PEP 740) starting at 0.3.1 — downstream installers can verify artifact provenance without long-lived API tokens.