open/llm-security-commons
1
0
Fork 0
Code Issues Releases 1 Activity

docs(security): the attack surface here is data, so the report route had to say where a wrong entry gets fixed

Browse source 
org-ops recorded SECURITY.md as missing against the org standard (coord,
2026-08-11) and this repository owed it for a sharper reason than "given what
the repo is about": nothing here runs, so a report is never a crash — it is a
detection entry that looks like it works and is not looking.

SECURITY.md therefore answers what an ordinary policy does not have to: how to
report that a detection-table entry is WRONG, and why a confirmed defect in
extracted data is decided in the runtime it was extracted from before it is
changed here. Correcting it here would make the copy disagree with the
implementation it was taken from — two runtimes, two answers on one input, the
exact failure this repository exists to prevent. Two classes skip that routing:
a real secret in the history, and data authored here rather than extracted.
Fix latency is stated plainly as bounded by the owning runtime's schedule and
the consumer's pull, not by ours.

secret-egress 0.1.0 -> 0.2.0 is a staleness DISCLOSURE, not a data change: all
18 patterns byte-identical, one evidence_limits entry added. llm-security
reports the source table at 19 entries now; recorded as their report and not
reproduced, because the commit carrying it is not on their public remote —
measured at b1ba1fb today. What was measured here: none of the 18 patterns
matches a legacy sk-...T3BlbkFJ... shape. A consumer vendoring this file
under-matches the seed hook by one entry, and now reads that in the file.

manifest 0.3.0 -> 0.3.1 corrects the secret-egress blocker. Through 0.3.0 it
named gcp-service-account-json and openai-api-key-legacy together as ids
"absent here". Measured against the guard at e671edb by running this file's own
18 patterns over a service-account document: a COMPLETE service-account key
file is matched here at order 11, since the PEM entry's prefix group is
optional and the bare PKCS#8 header matches; the same document with private_key
removed matches nothing here while the guard's marker still fires. That is a
cut-point difference, which is what the blocker is about, not a missing entry.
openai-api-key-legacy IS a real hole and is now recorded as one. Folded into
the existing blocker string rather than a sibling key, because blockers is a
map from table path to text.

Verified: all JSON well-formed; every non-fixture JSON has a top-level version;
charter clean (no executable code); patterns[] and count byte-identical to HEAD
for secret-egress; manifest key set unchanged and count still 90; 90 case
directories untouched; every spec still carries its normative marker.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T85QqeiWBEoBMjWaMiBnxD
This commit is contained in:
Kjell Tore Guttormsen 2026-08-11 14:03:24 +02:00
commit c28d8c7a29
5 changed files with 201 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

56
CHANGELOG.md
View file

@ -11,8 +11,64 @@ case ids, disposition semantics). Each JSON file additionally carries its own
## [Unreleased]
## [0.3.1] — 2026-08-11
**No pattern changed value. One shipped table is disclosed as stale, and the repository gains
the reporting route it did not have.** Nothing in `patterns`, `expected.json` or any id moved,
so a runtime that passes `0.3.0` passes `0.3.1` unchanged. Read the first entry anyway if you
vendor `signatures/secret-egress.json`: it now says, in the file, that it under-matches its own
source by one entry.
### Added
- `SECURITY.md` — the reporting route for a repository whose attack surface is **data**. It
answers the question an ordinary security policy does not have to: how to report that a
*detection-table entry is wrong*, and why a confirmed defect in extracted data is decided in
the runtime it was extracted from before it is changed here. Names what is in scope (a silent
false negative, a fixture that sanctions a miss, an unsafe normative clause, a secret in the
history, data gone stale against its source), what is a documented boundary rather than a
vulnerability, and the two classes that skip the routing — a real secret, and data authored
here rather than extracted. States plainly that fix latency is bounded by the owning runtime's
schedule and the consumer's pull, not by this repository's.
Written because `org-ops` recorded the file as missing against the org standard on
2026-08-11, and because four files here are detection data where a mistake is a detector that
looks like it works. `CONVENTIONS.md`, recorded in the same message, is not in this release.
- `README.md` — a short **Reporting a wrong entry** section pointing at it. Without it the
policy is a file nobody looking at the front page would know to open.
### Changed
- `signatures/secret-egress.json` `0.1.0` → `0.2.0` — **a staleness disclosure, not a data
change.** All 18 patterns are byte-identical to `0.1.0`; one entry is added to
`provenance.evidence_limits`. `llm-security` reports having taken the source `SECRET_PATTERNS`
from 18 to 19 by adding `OpenAI Legacy API Key`. That is recorded as their report and
explicitly **not** reproduced here — the commit carrying it is not on their public remote,
which was measured at `b1ba1fb` on 2026-08-11. What *was* measured here: none of the 18
patterns matches a legacy `sk-…T3BlbkFJ…` key shape. So a consumer vendoring this file
under-matches the seed hook by one entry, on a live credential shape, and now reads that in the
file rather than inferring it. It will be closed by re-extraction from a pinned public commit,
never by authoring the entry here from a message.
- `conformance/manifest.json` `0.3.0` → `0.3.1` — the `scope_planned.blockers` text for
`signatures/secret-egress.json` is corrected. Through `0.3.0` it ended by naming
`gcp-service-account-json` and `openai-api-key-legacy` together as ids "absent here". They are
two different kinds of fact, and one of them was misleading.
Measured 2026-08-11, by running this file's own 18 patterns in `order` over a service-account
document, against the guard at commit `e671edb`: a **complete** GCP service-account key file
*is* matched here, at order 11 (`Private Key PEM Block` — its `(?:RSA |EC |DSA |OPENSSH )?`
prefix group is optional, so the bare PKCS#8 header such a file carries matches). The same
document with `private_key` removed matches nothing here while the guard's marker pattern still
fires. That is a **cut-point** difference — the guard detects the document marker, this table
detects the key material — which is what the blocker is about, and not a missing entry.
`openai-api-key-legacy`, by contrast, is a real hole here today, and is now recorded as one.
The correction is folded into the existing blocker string rather than added as a sibling key:
`blockers` is a map from table path to text, and a second key under a table path would read as
a second table to anything iterating it.
- `docs/lexicon-port-divergence.md` (informative) — the residual `[^>]` vs `[^><]` row gains a
fuller witness set. `llm-security` measured the three forms as **totally ordered** by what they
match, each a strict superset of the next, and named two input classes the guard's narrower

7
README.md
View file

@ -150,6 +150,13 @@ so the gap is visible rather than inferred.
- **The homoglyph map is finite.** Confusable coverage is a long tail; absence from the map
is not evidence a character is safe.
## Reporting a wrong entry
A wrong code point or a mis-escaped regex here is a silent false negative in every runtime
that reads it, so it is a security report even though nothing runs. Send it privately — see
[SECURITY.md](SECURITY.md), which also explains why a confirmed defect in extracted data is
decided in the runtime it came from before it is changed here.
## Changelog
See [CHANGELOG.md](CHANGELOG.md).

133
SECURITY.md Normal file
View file

@ -0,0 +1,133 @@
# Security policy
This repository ships **no runnable code** — no package, no build, no dependency tree,
nothing that executes on your machine. So the usual question, *can this be exploited*,
has an unusual answer here: the attack surface is the **data**.
Seven data files here carry the detection material — pattern tables, code-point carriers,
calibration thresholds, an OWASP mapping — and several independent runtimes read them at the
same time. A wrong code point, a mis-escaped regex, a fixture that expects a miss: none of that
crashes anything. It produces a detector that looks like it works and is not looking. That
is the vulnerability class this policy is about, and a report of one is welcome even though
no code changes as a result.
## Reporting
**Do not open a public issue.** A report here usually names an input that gets *past* a
detector, and that is a working bypass against every consumer until it is closed.
Report privately by email:
- **hello@fromaitochitta.com**, with `SECURITY` at the start of the subject.
Pull requests are not the channel either — they are switched off on the canonical
repository, and not as an oversight. This repository is vendored into independent runtimes
that pin a tag; a change to detection data changes what those runtimes *find*. Such a change
has to be coordinated with each consumer before it exists, which a merge button does not do.
Fork-and-own is the supported path.
Please include:
- the file and the entry — its `name`, `order` or `id`, whichever that file uses;
- the tag you read (`v0.3.0`, not "main");
- the input that should have matched and does not, or the input that matches and should not;
- what a consuming runtime actually does today, if you have measured it.
**Obfuscate live payloads.** Do not send a working credential or a live carrier. Spell
invisible characters as code points the way the tables do (`"U+200B"`), and use placeholder
key material — a report should not itself be a delivery mechanism.
## What counts as a vulnerability here
In scope — all of these are real reports:
1. **A detection entry that is a silent false negative.** A wrong code point, a regex whose
escaping is wrong for the declared dialect, missing or wrong flags, a pattern that fails
to compile in a documented engine and gets skipped rather than reported.
2. **A conformance fixture that sanctions a miss.** `expected.json` is ground truth: a
runtime that disagrees with it is deemed wrong. A fixture that expects too little makes
every conforming runtime wrong identically, and the corpus will not catch it.
3. **A normative clause that mandates unsafe behaviour.** The `spec/` files bind the
implementations that consume them, so a weak rule propagates to all of them.
4. **A real secret or personal data in the repository or its history.** The history is
public in full.
5. **Data that has gone stale against its declared source in a way that under-detects.**
Each data file names its source in a `provenance` block. If that source has since added
or corrected an entry, the copy here under-matches, and a consumer vendoring it is less
protected than the runtime it was taken from.
Out of scope — documented boundaries, not vulnerabilities. See **Known limitations** and
**Non-goals** in [README.md](README.md):
- a detection class absent from the tables entirely (coverage is the union of what the seed
implementations detected, not of what exists);
- a table implemented by only one runtime, and cases marked `not-applicable` for the others;
- disagreement about a `calibration.json` threshold — the thresholds are published, the
policy built on them belongs to the consumer;
- a divergence already recorded in [`docs/lexicon-port-divergence.md`](docs/lexicon-port-divergence.md);
- the five data files no fixture constrains, and the finite homoglyph map.
If you are unsure which side something falls on, report it privately anyway.
## Why a confirmed defect is usually not fixed here first
This is the part that differs from an ordinary repository, and it is worth reading before
you conclude that a fix is being stalled.
Most data here is an **extraction**: a copy of a table that lives in a runtime, kept
behaviour-identical to it on purpose. Correcting an entry here — even a genuinely wrong one
— would make the copy disagree with the implementation it was taken from. Two implementations
answering differently on the same input is precisely the failure this repository exists to
prevent, so producing one as a *fix* would be self-defeating.
A confirmed defect in extracted data therefore travels:
1. the report reaches the maintainer here, privately;
2. the owning runtime is identified — every data file names it in `provenance.source_repo`
— and the report is routed there;
3. the decision is taken **there**, where the pattern is under test against a real suite;
4. once the source has moved, this repository **re-extracts** from a pinned public commit
and tags a release;
5. consumers pull that tag on their own schedule.
Stated plainly, because it affects you: fix latency is bounded by the owning runtime's
schedule and by each consumer's pull, not by this repository's. If you need protection
sooner than that, the fix belongs in your own runtime; this repository is where it becomes
shared, not where it becomes real.
Two things do **not** take that route:
- **A real secret in the repository or its history** (class 4) is handled here, immediately.
- **Data authored in this repository** rather than extracted — it is flagged as such where
it occurs, for example `authored_payloads` in `conformance/manifest.json` — is this
repository's own to correct.
The precedent is on the record. In `v0.3.0` a detection pattern changed value here for the
first time, and it changed because the owning runtime had changed its own and this
repository re-read the source — not because a reviewer here judged the old value wrong.
`docs/lexicon-port-divergence.md` records a row where two runtimes still disagree and this
repository deliberately did *not* pick a winner. Provenance is the ground for moving a
value. Merit is not, and the day it becomes the ground, the guarantee is gone.
## Supported versions
Pre-1.0. Only the latest tag is fixed; there are no back-ported branches.
Consumers vendor this repository (`git subtree`, or a pinned copy) rather than installing
it, so a fix reaches a consumer only when that consumer pulls the new tag. There is no CI in
this organisation and nothing polls for updates. When a fix changes detection data, the
maintainer notifies the known consumers directly — but their upgrade is their own action, on
their own schedule.
Read the `CHANGELOG.md` entry before upgrading rather than the version number: in 0.x, a
change to what a conforming runtime *finds* is still a minor bump.
## Disclosure
There is no formal embargo SLA here. The maintainer will acknowledge the report, agree a fix
and disclosure timeline with the reporter, and credit the reporter in the `CHANGELOG.md`
entry unless they prefer to remain anonymous.
If the report is a false negative in a table that has already shipped, the changelog entry
will say what slipped through, in enough detail that a consumer still pinned to the older
tag can judge whether it is exposed. Naming it is the point of fixing it.

4
conformance/manifest.json
View file

@ -1,5 +1,5 @@
{
"version": "0.3.0",
"version": "0.3.1",
"id": "llm-security-commons/conformance",
"description": "Enumeration and measurement header for the conformance corpus. Every case directory holds input.txt (the exact bytes to scan) and expected.json (the findings a conforming runtime must produce). The normative reading of those files is spec/conformance-corpus.md; this file records where the cases came from and what was measured.",
"$comment": "Fixture files carry no individual version field. The corpus is versioned as a whole, here — a case is added, removed or corrected by bumping this version, and a case-id change is a MAJOR bump because consumers name cases.",
@ -29,7 +29,7 @@
"signatures/secret-egress.json": 1,
"blockers": {
"codepoints/carriers.json": "No adoptable id space, and a second problem underneath it. The guard emits TWO stage-coupled labels for the same carrier depending on pipeline position — `sanitize:zero-width` (input) versus `output:zero-width-present` (output), and the same split for bidi and unicode-tag; llm-security emits prose titles (unicode-scanner.mjs:191,236). A commons id would therefore have to be invented stage-neutral, which no other id space here required. And because `exact-within-scope` compares a finding SET, a commons id aliasing both guard labels would make the verdict depend on which entry point the runtime was measured through — an entry-point dependence the lexicon cases do not have, since this manifest pins entry point as a measurement fact rather than as contract.",
"signatures/secret-egress.json": "Not an id-naming question at all. The two runtimes carry DIFFERENT TABLES, not two namings of one: this file holds 18 entries from llm-security, the guard's `_SECRET_PATTERNS` (output.py) holds 25 at different cut points — this file's single `GitHub Token` is four ids there, `Private Key PEM Block` is three, `Database connection string` is four — and membership diverges both ways (the guard has `gcp-service-account-json` and `openai-api-key-legacy`, which are absent here; this file has `Slack/Discord Webhook URL` and `Azure AI Services Key`, which are absent there). `aws-access-key-id` is the one clean one-to-one, which is why exactly one egress case was ever offered. A shared id space presupposes a table reconciliation that has not happened."
"signatures/secret-egress.json": "Not an id-naming question at all. The two runtimes carry DIFFERENT TABLES, not two namings of one: this file holds 18 entries from llm-security, the guard's `_SECRET_PATTERNS` (output.py) holds 25 at different cut points — this file's single `GitHub Token` is four ids there, `Private Key PEM Block` is three, `Database connection string` is four. `aws-access-key-id` is the one clean one-to-one, which is why exactly one egress case was ever offered. A shared id space presupposes a table reconciliation that has not happened. Membership diverges both ways, and `Slack/Discord Webhook URL` (order 13) and `Azure AI Services Key` (order 4) are here and absent from the guard. CORRECTED IN 0.3.1: through 0.3.0 this text ended '(the guard has `gcp-service-account-json` and `openai-api-key-legacy`, which are absent here; ...)'. Two entries were named as one kind of fact, and they are two different kinds. Measured here on 2026-08-11 by running this file's own 18 patterns, in `order`, over a service-account document, against the guard at commit `e671edb`. (1) `gcp-service-account-json` is NOT a coverage hole here. A complete service-account key file matches this table at order 11, `Private Key PEM Block`: that pattern's prefix group `(?:RSA |EC |DSA |OPENSSH )?` is optional, so the bare PKCS#8 header `-----BEGIN PRIVATE KEY-----` such a file carries is matched. What differs is the CUT POINT: the same document with its `private_key` field removed matches nothing here, while the guard's `\"type\"\\s*:\\s*\"service_account\"` still fires — the guard detects the document MARKER, this table detects the KEY MATERIAL. Both fire on a real key file; only the guard fires on a stripped one. That is exactly the cut-point divergence this blocker is about, and it is not a missing entry. (2) `openai-api-key-legacy` IS a real hole here as of this version: no pattern in this file matches a legacy `sk-…T3BlbkFJ…` key, measured the same way. llm-security reports (coord, 2026-08-11) having added `OpenAI Legacy API Key` to `SECRET_PATTERNS`, 18 -> 19 — their claim, not reproduced here, because the commit carrying it is not on their public remote yet. This file is therefore knowingly STALE against its own declared source until it can be re-extracted from a pinned commit, and this note stays until that re-extraction lands."
}
},
"omitted_payloads": [

5
signatures/secret-egress.json
View file

@ -1,5 +1,5 @@
{
"version": "0.1.0",
"version": "0.2.0",
"id": "secret-egress",
"description": "Credential and token shapes that must never leave a machine: the fixed pattern table a pre-write guard matches against content before it is persisted. Detection data only - what to DO when one matches (block, warn, redact) is the consumer's policy and is not described here.",
"owasp": "LLM02",
@ -19,7 +19,8 @@
"evidence_limits": [
"The dump is a transcription of the source module, not the module file itself. The checks recorded for this file prove that this JSON agrees with the DUMP; dump-to-module fidelity is llm-security's assertion, not a result reproduced here.",
"No severity, and no per-entry disposition, was supplied. The source table carries a name and a pattern and nothing else, so neither is invented here.",
"The runtime-injected custom patterns (entries 19+) are policy, not data, and are out of scope. A consumer that matches only this table matches LESS than the seed hook does when a policy is loaded."
"The runtime-injected custom patterns (entries 19+) are policy, not data, and are out of scope. A consumer that matches only this table matches LESS than the seed hook does when a policy is loaded.",
"STALE AGAINST ITS SOURCE, disclosed 2026-08-11 in version 0.2.0. llm-security reports having taken the source `SECRET_PATTERNS` from 18 to 19 fixed entries by adding `OpenAI Legacy API Key`. That is their report, NOT reproduced here: the commit carrying it is not on their public remote, which stood at `b1ba1fb` when this was checked. Measured here against the 18 patterns below: no legacy `sk-…T3BlbkFJ…` key shape matches any of them. So a consumer vendoring this file today under-matches the seed hook by one entry, on a live credential shape, and that is a false negative rather than a difference of opinion. It will be closed by RE-EXTRACTION from a pinned public commit — never by authoring the entry here from a coord message, which is what the behaviour-preservation rule in CLAUDE.md forbids."
]
},
"ordering": {