open/llm-security
1
0
Fork 0
Code Issues Releases 2 Activity
llm-security/SECURITY.md
Kjell Tore Guttormsen c14501e99c chore(llm-security): release v8.0.0 - version sync and changelog 
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>
2026-09-18 00:16:19 +02:00

4.2 KiB
Raw Blame History

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).

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). 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 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.

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).

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.