open/llm-security
1
0
Fork 0
Code Issues Releases 6 Activity
llm-security/SECURITY.md
Kjell Tore Guttormsen f92ad3f7b3
 docs(readme): shorter, concrete value proposition, antivirus alerts for organizations 
README goes from 825 to 227 lines. The value proposition comes first
(three concrete outcomes), then install, a first-five-minutes table,
compact hook and command tables, and one section for teams and CI.

New section "Antivirus and EDR alerts": a warning at the top tells
organizations that products such as Microsoft Defender can raise
alerts, what v8.1.0 did about it (and that v8.1.1/v8.1.2 did not touch
it), that nothing has been measured on Windows, what still sits on
disk as readable text, how to report to Microsoft (managed devices via
the Defender portal, single machines via wdsi), and to email
security@fromaitochitta.com so the file can be fixed in a patch.

Corrected claims found by an independent fact-check: the standalone
CLI is not offline (npm audit, pip-audit, DNS, OSV.dev), the secrets
hook has 19 patterns not 30+, /security deep-scan takes no CI flags,
look-alike package names warn rather than block, the Linux bwrap
caveat, and the demo's 85 findings need the LLM half too. Moved to
links: scanner tables, knowledge list, playground, version history.

SECURITY.md: 8.1.x is the active line; antivirus alerts are in scope,
also on knowledge files; the dead README section references fixed.
CLAUDE.md: README section name updated.

repo-standard 22/22, doc-consistency + av-surface 51/0, full suite
2328 / 2322 pass / 0 fail / 6 skipped. Self-scan: README 1 -> 0
findings.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-23 09:42:41 +02:00

4.6 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.1.x Active. Bug + security fixes. Stabilization line.
8.0.x Best-effort security fixes only. Upgrade to 8.1.x recommended.
7.0.x – 7.8.x Best-effort security fixes only. Upgrade to 8.1.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 "Known limitations" in the README and docs/defense-philosophy.md — 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)
  • Antivirus or EDR alerts on any tracked file, including knowledge files and examples (see "Antivirus and EDR alerts" in the README). Include the file path, the detection name, the plugin version or commit, and the product and its signature version.

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), except antivirus or EDR alerts on it, which are in scope above
  • 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.