2 Commits

Include renames

Author	SHA1	Message	Date
Marius CiepluchandClaude Opus 5	d15985f695	fix(model): a guard discharges the obligation it is a guard of ... contributor-scan 2.6. Access control entailed 7 of 9 VAmPI handlers, including three that do authorize and three the OpenAPI spec declares public. Five separate defects, each invisible to a corpus of one-function excerpts and each found by asking the query what it actually matched. **A trailing segment is not a match.** `query.get` was matched by its last segment, so every `.get(` in the repository became a protected database operation -- `request.headers.get('Authorization')` and `request_data.get('username')` included. Four of the seven false positives came from this, and so did the apparent detection of the known BOLA: it was entailed because fetching the Authorization header had no dominating guard, not because of the defect. A qualified token now requires its qualifier. **Configuration is not authorization.** dominance_specs took every obligation fact. `security_setting` operations are discharged by a VALUE, which config_specs already claims them for; pooled in here they made `app.run(...)` an operation requiring an authorization guard and put thirteen tokens in BOTH lists -- an obligation that is its own discharge, the same shape as the taint sink that used to sanitize itself. **Input validation is not authorization.** `jsonschema.validate` was counted as a guard, so handlers with no authorization check at all read as guarded. No operation in the table requires validated_input. **A guard discharges the obligation it is a guard of.** The largest one. `orm-read` requires an identity_constraint or an ownership_check; `token_validator` is a path_guard. Flattened into one list, authenticating the caller discharged an object-level obligation -- a handler that authenticates and then looks the record up by a PATH parameter read as fully guarded. The facts state that relation and the spec was discarding it; it is now carried and the engine asks per operation. **A word boundary needs a word.** Found while fixing the above. Guard matching wrapped every token in `(?<![A-Za-z0-9_])...(?![A-Za-z0-9_])`. The identity token `['sub']` begins with `[`, and the character before it in `resp['sub']` is `p` -- so the assertion could never hold. Every identity token starting with punctuation was unmatchable, and the identity constraint that separates a correct lookup from an IDOR was invisible. Also: dominance rows were repository-wide, so the model's unguarded `delete_user` was attributed to the API handler of the same name. Rows are scoped to the region's file, which is what the rung's own justification says -- the evidence is a file contradicting itself. Measured against VAmPI's OpenAPI `security` blocks, which declare per operation whether auth is required, and agree with the code: vampi precision 28.6% (2/7) -> 50.0% (2/4) known found 3 of 3, all model_entailed And on the labelled access-control pairs, which nobody tuned this against: all 9 pairs pair_correct 3 -> 3, leak 44.4% -> 11.1% 7 non-VAmPI pair_correct 2 -> 2, leak 42.9% -> 0.0% Every detection lost was on a pair whose FIXED side was flagged too, which scores nothing. No correct detection was traded for the precision. get_by_title was flagged before it was in the recipe: its code carries the comment "# Broken Object Level Authorization" and the README lists it, so a real finding was being scored as a false positive. It is now the recipe's third known vulnerability. Both remaining false positives are endpoints the spec declares public. Recorded as 2.8, with the reason the mapper's access_level cannot simply be trusted: for decorator frameworks "public" means "no decorator found", which is the bug itself. Gates byte-identical. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01T7XD7x5KonMdmGRkp63EQG	2026-09-09 11:02:48 +02:00
Marius CiepluchandClaude Opus 5	8c387306be	feat(repos): pinned known-vulnerable checkouts, offline by default ... The pair corpus scores excerpts: a vulnerable function and its fixed twin, handed to the engine with the answer already narrowed down. Nothing in it exercises a repository -- region ranking, the budget, one CPG over thousands of files, or whether a verdict that holds on fifteen lines still holds when the source, the sink and the guard live in three modules. benchmarks/repos/<name>.toml names a real checkout: url, a full 40-char commit SHA, licence, and every known vulnerability with its file, function and line. `ousast repos` lists them; `--fetch` materialises one; CI does neither, and conftest clears the switch and redirects the cache so a developer with warm checkouts cannot read them by accident. Three rules the loader enforces rather than documents: - A branch or tag is rejected. Either would make the same recipe mean different code next month while the baseline it produced kept the old numbers. - `in_scope` must be stated per vulnerability, never defaulted. It decides whether "not found" is a miss or a non-question, which is the most important thing about the result. - A recipe that declares `detection` must name something in scope to detect. `ousast repos` does not trust a recipe either: against a materialised checkout it checks HEAD against the pin, that the licence file is there, and that each declared function appears above its declared line. That earned its place immediately -- the first libpng recipe named LICENSE.md, which is the filename at HEAD today and not at the pinned commit, where it is still LICENSE. Two checkouts, verified against the real repositories: - vampi (MIT, 520 lines) is the DETECTION checkout. Excerpts of it are already in the pair corpus, including the update_password miss diagnosed earlier, so a whole-repository run says directly whether a verdict survives the move off the excerpt. Its routes register through an OpenAPI operationId, so it exercises registration-based entry-point mapping rather than the decorator path. - libpng (libpng-2.0, 91k lines of C) is the ENVELOPE checkout, pinned at the parent of the commit that added the missing clamp. Its CVE is marked out of scope: an out-of-bounds read is not a family this engine arbitrates, and recording "not found" against it as a miss is the easiest way to make a measurement lie. Nothing is vendored; the recipe records the licence so an artifact can say what it ran against. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01T7XD7x5KonMdmGRkp63EQG	2026-09-09 08:10:59 +02:00