Kjell Tore Guttormsen
342acda5bc
D4-C, order 20260821T091412Z-1428311869-from-.claude. Measured by .claude
against the org 21.08: this repo has the org's most mature deprecation
PRACTICE and no stated policy. An adopter cannot read a CHANGELOG row and know
it applies next time -- what D4 measures is what can be EXPECTED, not what
happened last time.
Form copied from open/portfolio-optimiser SECURITY.md "Deprecation Notice
Period"; the numbers are this repo's own. Both floors are kept because the
release count alone is toothless here: measured from the README release table,
7.5.0 and 7.6.0 shipped a day apart (2026-05-05 -> 2026-05-06), so "at least
one minor release" without a day floor would permit a next-day removal. 30 days
is comfortably holdable -- the one precedent ran 112 days (v7.3.0 released
2026-05-01 per commit 4637139; v8.0.0 still unreleased at 2026-08-21).
The precedent is worded as staged, not shipped: git describe reports
v7.8.3-43-ge97c232 and the removal sits under CHANGELOG [Unreleased], so
claiming v8.0.0 "removed" them would have been a claim about an untagged
release. Only the four env-vars are cited; CHANGELOG dates riskScoreV1's
@deprecated to v7.0.0 while README says v7.3.0, and that disagreement should
not be load-bearing in a policy.
No promise the project cannot hold: it is stated as a notice period and not an
SLA, with no backporting, and the one exception for security-critical removal
is named explicitly. README's Project scope now points at the section so an
adopter arriving from the deprecation bullet lands on the rule.
Docs only; the Iron Law does not fire. doc-consistency gate 45/45 pass, exit 0.
Full suite unchanged vs HEAD: 2253 tests / 2247 pass / fail 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y7TAHJfxBoCm9YwhMWm6y5
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 |
|
||
|---------------|------------------------------------------------|
|
||
| 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.
|