open/llm-ingestion-pipeline-security
1
0
Fork 0
Code Issues Pull requests Releases Activity
llm-ingestion-pipeline-secu.../SECURITY.md
Kjell Tore Guttormsen 1625f3893b docs: version-sync + SECURITY/CONTRIBUTING + honest-limits (Session E) 
- 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).
2026-07-15 10:08:24 +02:00

2.5 KiB
Raw Permalink Blame History

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.