Kjell Tore Guttormsen
f669479777
0.5.0 is the axis separation `de09711` built: `Risk` (assessment) alongside `Disposition` (action), `Policy.action_map` as the supported override, and the fail-closed path pinned to both axes. Additive and measured to be so — 717 passing with no test changed, matrix 128/128 with 6/6 documented gaps, the `PRESET_USER_UPLOAD` grading table unchanged row by row. Plus the field FP measurement (`d1bff60`) and the 0.3.3 behaviour-change correction (`d3d0928`). WHY THIS COMMIT TOUCHES EIGHT FILES AND 0.4.0's TOUCHED THREE 0.4.0's release commit updated CHANGELOG, pyproject.toml and __init__.py, and deferred README deliberately: the install block should not name a tag before a clean-venv install had proven it resolved. Sound reasoning, and the proof step never ran — so tag v0.4.0 permanently advertises v0.3.4. The tag is not moved. The ordering is. Sweeping every tracked file for a version claim, instead of ticking the four surfaces the checklist named, found five more that no release had ever touched: SECURITY.md "pre-1.0 (0.2.x)" — the one with a consequence for an outsider: it named a support window two minor lines behind the code. README.md "**Status:** v0.3" — the front page, stale since 0.4.0. docs/BRIEF.md "v0.2 (alpha)" — stale since 0.3.0. CLAUDE.md "v0.2 (alpha)" and "12 moduler" where src/ has 15. docs/ADOPTION-BRIEF "703 passing" where the suite is at 717. Measurement provenance is deliberately left alone: "New in v0.4.0", "verified identical on 0.2.0 and 0.3.1", "measured against the v0.3.1 tag", every "post-0.4.0 tree" in LIMITATIONS. Bumping those falsifies the record instead of updating it, which is why this cannot be a sed sweep — the surfaces have to be sorted into current-state and provenance before a single edit. Found because llm-ingestion-okf took our report of this defect class as a hypothesis about their own repo, measured it, found a worse instance on their public front page, and sent back the generalization: writing down a trap is not the same as applying it. VERIFIED BEFORE COMMITTING, NOT AFTER 717 passed; coverage 128/128 recall, 6/6 documented gaps hold docs/LIMITATIONS.md: 33 items, README says 33 fp-sweep reproduced all three published numbers exactly on the bumped tree — vendor-harvest 98/185 (53.0%), generated-notes 88/547 (16.1%), reference-corpus 133/389 (34.2%) — and self-docs runs clean, so the untested script survived the bump it imports names from forge description: 178 codepoints, under the 180 cap no tracked file carries a stale current-state version claim Still to prove before the tag: a clean-venv install from this commit's sha, and `git show <sha>` over the README. The install proves the package builds; only the grep proves the text the tag will carry is right. That second check is the one the old ordering could not perform, because by then the tag existed.
62 lines
2.5 KiB
Markdown
62 lines
2.5 KiB
Markdown
# Security policy
|
|
|
|
`llm-ingestion-guard` is a defensive library for LLM ingestion pipelines. Its own
|
|
security posture matters: a flaw here can silently admit a poisoned artifact into a
|
|
downstream corpus. Reports are welcome.
|
|
|
|
## Supported versions
|
|
|
|
The project is pre-1.0 (`0.5.x`, alpha). Only the latest published version receives
|
|
fixes; there are no back-ported security branches yet. Pin a version and watch the
|
|
`CHANGELOG.md` `### Security` entries.
|
|
|
|
## Reporting a vulnerability
|
|
|
|
**Do not open a public issue for a vulnerability.** Public disclosure before a fix
|
|
gives an attacker a window against every downstream consumer.
|
|
|
|
Instead, report it **privately** to the maintainer via the canonical repository on
|
|
Forgejo:
|
|
|
|
- Repository: `git.fromaitochitta.com/open/llm-ingestion-pipeline-security`
|
|
- Contact the maintainer directly through that Forgejo instance (private message /
|
|
maintainer contact) and mark the subject `SECURITY`.
|
|
|
|
Please include:
|
|
|
|
- affected version / commit,
|
|
- a minimal reproduction (input → observed disposition/finding vs. expected),
|
|
- the impact you see (e.g. a poisoned artifact that disposes `WARN` instead of
|
|
`FAIL_SECURE`).
|
|
|
|
Obfuscate any real payloads the same way the test corpus does — build attack strings
|
|
from `chr(0x…)` fragments so the report itself does not ship a live carrier.
|
|
|
|
## What counts as a vulnerability
|
|
|
|
In scope (a real finding):
|
|
|
|
- a bypass of a **stated** control — e.g. an invisible carrier that reaches the
|
|
persist gate without failing secure, a credential that egresses without a
|
|
`decoded:egress:*` / `egress:*` label, a `guard()` path that fails *open*;
|
|
- a `prepare_input` / `screen_output` code path that raises instead of failing
|
|
closed;
|
|
- a ReDoS or unbounded-resource input against the scanner.
|
|
|
|
Out of scope (documented boundaries — see the **Known limitations** section of
|
|
`README.md`, not vulnerabilities):
|
|
|
|
- semantic / factual poisoning invisible to lexicon + entropy;
|
|
- a HIGH finding in *trusted* prose disposing to `WARN` (§4.7 trust-scaling);
|
|
- hex-wrapped (non-base64) secret egress;
|
|
- multimodal / binary-layer carriers (OCR, font stego, VBA/macros, encrypted files);
|
|
- the multilingual homoglyph-mix false positive.
|
|
|
|
If you are unsure whether something is in scope, report it privately anyway.
|
|
|
|
## Disclosure
|
|
|
|
This is a small project without a formal embargo SLA. The maintainer will
|
|
acknowledge a report, agree a fix + disclosure timeline with the reporter, and
|
|
credit the reporter in the `CHANGELOG.md` `### Security` entry unless they prefer to
|
|
remain anonymous.
|