Kjell Tore Guttormsen
c14501e99c
Phase 6 of the approved v8.0.0 plan. HEAD was 45 commits past v7.8.3 with every version-bearing file still reading 7.8.3 and no v8 tag anywhere. Version sync: plugin.json, package.json, README badge, CLAUDE.md header. CHANGELOG: [Unreleased] becomes [8.0.0] - 2026-09-18. It covered 3 of the user-visible commits since v7.8.3; the other 18 fix/feat/refactor commits are now recorded from their commit bodies - the commons extraction (five tables, scanners/commons/ subtree, knowledge/signatures.json removed), conformance spec 1.1, the golden-gate coverage relabel, and eight fixes (script-tag recall, whole-table ReDoS gate and its own 8-of-45 blind spot, Berry and nested lockfile-v1 misses, per-occurrence strip attribution, legacy OpenAI keys, compileRules coercion, SIG self-flag, SARIF tags). Counts verified against the loaded modules: 83 injection patterns, 19 secret shapes, 7 SIG rules. SECURITY.md supported-versions table said 7.3.x Active; now 8.0.x Active, 7.0.x - 7.8.x best-effort. README gets the 8.0.0 row; CLAUDE.md gets the v8.0.0 highlights and the test floor moves 2045+ to 2250+. Tests: 2253 / 2247 pass / 0 fail / 6 skipped, exit 0, measured on HEAD before the edits. The post-edit full run had 3 red, all timing ceilings, under load average 60 from unrelated jobs on the machine; each passes alone (460 ms of 1000, 370 ms of 2000, 2127 ms) and doc-consistency is 45/45 alone. The diff is docs and version strings only. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
96 lines
4.2 KiB
Markdown
96 lines
4.2 KiB
Markdown
# 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 |
|
||
|---------------|------------------------------------------------|
|
||
| 8.0.x | **Active.** Bug + security fixes. Stabilization line. |
|
||
| 7.0.x – 7.8.x | Best-effort security fixes only. Upgrade to 8.0.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.
|