Kjell Tore Guttormsen
1625f3893b
- README: tests badge 275->357; status v0.1->v0.2 (repo is 0.2.0; the v1.0 bump belongs to the Session G freeze, not this docs pass); add three honest-limits — lone-HIGH-in-trusted-prose->WARN, vacuous quarantine-floor, Cyrillic/Latin homoglyph-mix false positive. - docs/BRIEF.md: drop "No code yet" pre-implementation framing -> implemented v0.2. - docs/OKF-INGESTION-BRIEF.md 4: correct cross-link control language — absolute https / references/ targets are spec-permitted, not rejected. - Add SECURITY.md (private Forgejo disclosure) + CONTRIBUTING.md (stdlib-only core, Iron-Law TDD, no trailers, Forgejo-only invariants).
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.2.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 **Honest 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.
|