# Security Policy

## Supported versions

This is a solo-maintained open-source project. "Supported" here means the
maintainer will look at security reports — not that there is an SLA, paid
support, or backporting policy. Forks are encouraged for organizations that
need stronger guarantees (see [`CONTRIBUTING.md`](CONTRIBUTING.md)).

| Version       | Status                                         |
|---------------|------------------------------------------------|
| 7.3.x         | **Active.** Bug + security fixes. Stabilization line. |
| 7.0.x – 7.2.x | Best-effort security fixes only. Upgrade to 7.3.x recommended. |
| < 7.0         | End of life. No fixes. |

The project is in **stabilization mode** as of 2026-05-01. New features are
out of scope (see "Project scope" in [`README.md`](README.md)). Security and
correctness fixes continue.

## Deprecation notice period

When a supported surface is removed — an env-var, an exported helper, a policy
key, a command, or a documented output field:

- The deprecation is announced in [`CHANGELOG.md`](CHANGELOG.md) under the
  release that introduces it, and where the code can warn, it warns on use.
- **At least one minor release — and no fewer than 30 days — passes between that
  announcement and the removal.** Both floors are required: minor releases here
  have shipped as little as a day apart, so the release count alone would not
  give anyone time to read the changelog.
- **Removals themselves land in a major release**, never in a minor or a patch.
- **The one stated exception is a security-critical removal.** If leaving a
  surface in place is itself the risk, it goes in the next release and the
  changelog says plainly why the notice period was not used. This has not
  happened so far.

Precedent: the four `LLM_SECURITY_*` configuration env-vars were announced as
deprecated in v7.3.0 (2026-05-01) and warned on every use. Their removal is
staged for v8.0.0 — five minor releases (7.4.0 through 7.8.0) and more than
three months later — with a migration table in [`README.md`](README.md).

This is a notice period, not an SLA. It says when a break will be *announced*,
not when a release will happen. There is no backporting, and a fork that needs
stronger guarantees should set its own (see [`CONTRIBUTING.md`](CONTRIBUTING.md)).

## Reporting a vulnerability

If you discover a security vulnerability in this plugin, please report it
responsibly.

**Do NOT open a public issue.** Instead:

1. Email: **security@fromaitochitta.com**
2. Include:
   - Description of the vulnerability
   - Steps to reproduce
   - Affected component (scanner, hook, agent, command, knowledge file)
   - Potential impact
   - Whether you have a proof-of-concept (encrypted attachment is fine)

**Response timeline (best-effort, solo project):**

- Acknowledgment within 7 days
- Triage and severity classification within 14 days
- Fix or documented mitigation within 30 days for confirmed High/Critical findings; Medium and Low scheduled into the next regular release

If the report touches a vulnerability the project explicitly cannot defend
against (see "Defense philosophy" and "What this plugin does NOT cover" in
the README — e.g., adaptive ML-based prompt injection bypass), the response
will explain why it is out of scope rather than leaving the report open.

## Scope

This policy covers:

- Hook scripts (`hooks/scripts/*.mjs`)
- Deterministic scanners (`scanners/*.mjs`)
- Scanner shared library (`scanners/lib/*.mjs`)
- Agent definitions (`agents/*.md`)
- Command definitions (`commands/*.md`)
- CLI entry point (`bin/llm-security.mjs`)

Out of scope:

- The malicious-skill-demo fixture (`examples/malicious-skill-demo/`) — intentionally vulnerable for testing
- Knowledge base content (derived from published OWASP standards and cited research)
- Template files (output formatting only, not part of the security boundary)
- Forks under other names — please report there, not here

## Disclosure

Confirmed vulnerabilities will be disclosed in the CHANGELOG after a fix is
available, with credit to the reporter unless anonymity is requested.

For coordinated disclosure with downstream forks: include the maintainer
email above and the maintainer of the fork in the same thread.