Hi!
AVE (Agentic Vulnerability Enumeration) is an open, vendor-neutral behavioral classification standard for agentic AI components — skill files, MCP servers, system prompts, agent plugins — currently 80 published records, each scored with OWASP AIVSS and already mapped to OWASP MCP Top 10, MITRE ATLAS, and NIST AI RMF.
This is a deliberately small first batch, not the whole corpus
Rather than submitting all 80 records at once, attached are 3 pilot mappings — the strongest, most unambiguous correspondences to existing CWE-linked CREs already in OpenCRE — with a request for feedback on approach and format before mapping more. If this looks right, a follow-up batch is already researched and ready (2 more records, one of which involves a multi-CRE correspondence worth a second pair of eyes before submitting).
Verification approach
Each of the 3 was checked at the mechanism level against OpenCRE's own live data (www.opencre.org/rest/v1/...), not by CWE-label adjacency alone — read each candidate CRE's full linked-standards list before treating a mapping as correct, since several CWEs here link to multiple CREs covering genuinely different failure modes under one shared CWE number.
One thing worth flagging explicitly, since your own CONTRIBUTING.md calls it out directly ("We do not recommend to use an existing mapping from the standard to another standard that is already in OpenCRE (e.g. CWE). Typically, details get lost that way"): the first draft of this batch found candidate CREs by relaying through AVE's own existing CWE citations, exactly the shortcut you warn against. Went back and re-derived each one independently via text_search against the AVE record's own language instead, before comparing. Two of the three held up unchanged; it's the third record (now held back for the follow-up batch, not included here) where the independent method actually found a better, more precise CRE that the CWE-routed approach had structurally missed. Wanted to mention it since it's a concrete instance of exactly the risk your own docs name.
The 3 mappings
| AVE record |
CRE |
Correspondence |
| AVE-2026-00047 — Hardcoded credentials in agent component |
774-888 "Do not store secrets in the code" |
Direct — AVE's own behavioral fingerprint is a detection-shaped restatement of this CRE |
| AVE-2026-00061 — TLS certificate verification disabled |
430-636 "Verify TLS certificates and trust chain" |
Direct — picked out of 8 CWE-295-linked CREs (most about OTP/MFA) as the one actually matching cert-validation bypass specifically |
| AVE-2026-00053 — MCP resource path traversal |
675-168 "Sanitize filename metadata from untrusted origin if processing is required" |
Direct, strongest independent corroboration found in this batch |
Attachments
Mapping-template spreadsheet (CSV, using your own CRE 0–CRE 4 + <standard>|name/id/hyperlink/description column convention, full CRE hierarchy paths included): https://raw.githubusercontent.com/aveproject/ave/main/crosswalks/ave-to-opencre-pilot-mapping.csv
Same 3 rows as a readable table, for review without opening the CSV: https://github.com/aveproject/ave/blob/main/crosswalks/ave-to-opencre-pilot-mapping-READABLE.md
Happy to answer anything, and no rush — would appreciate a maintainer's read on whether this is the right shape before there's more of it. (cc @ottosulin, whose AISVS mapping work in #1016 was a genuinely useful reference for understanding the real template conventions while putting this together.)
Hi!
AVE (Agentic Vulnerability Enumeration) is an open, vendor-neutral behavioral classification standard for agentic AI components — skill files, MCP servers, system prompts, agent plugins — currently 80 published records, each scored with OWASP AIVSS and already mapped to OWASP MCP Top 10, MITRE ATLAS, and NIST AI RMF.
This is a deliberately small first batch, not the whole corpus
Rather than submitting all 80 records at once, attached are 3 pilot mappings — the strongest, most unambiguous correspondences to existing CWE-linked CREs already in OpenCRE — with a request for feedback on approach and format before mapping more. If this looks right, a follow-up batch is already researched and ready (2 more records, one of which involves a multi-CRE correspondence worth a second pair of eyes before submitting).
Verification approach
Each of the 3 was checked at the mechanism level against OpenCRE's own live data (
www.opencre.org/rest/v1/...), not by CWE-label adjacency alone — read each candidate CRE's full linked-standards list before treating a mapping as correct, since several CWEs here link to multiple CREs covering genuinely different failure modes under one shared CWE number.One thing worth flagging explicitly, since your own CONTRIBUTING.md calls it out directly ("We do not recommend to use an existing mapping from the standard to another standard that is already in OpenCRE (e.g. CWE). Typically, details get lost that way"): the first draft of this batch found candidate CREs by relaying through AVE's own existing CWE citations, exactly the shortcut you warn against. Went back and re-derived each one independently via
text_searchagainst the AVE record's own language instead, before comparing. Two of the three held up unchanged; it's the third record (now held back for the follow-up batch, not included here) where the independent method actually found a better, more precise CRE that the CWE-routed approach had structurally missed. Wanted to mention it since it's a concrete instance of exactly the risk your own docs name.The 3 mappings
Attachments
Mapping-template spreadsheet (CSV, using your own
CRE 0–CRE 4+<standard>|name/id/hyperlink/descriptioncolumn convention, full CRE hierarchy paths included): https://raw.githubusercontent.com/aveproject/ave/main/crosswalks/ave-to-opencre-pilot-mapping.csvSame 3 rows as a readable table, for review without opening the CSV: https://github.com/aveproject/ave/blob/main/crosswalks/ave-to-opencre-pilot-mapping-READABLE.md
Happy to answer anything, and no rush — would appreciate a maintainer's read on whether this is the right shape before there's more of it. (cc @ottosulin, whose AISVS mapping work in #1016 was a genuinely useful reference for understanding the real template conventions while putting this together.)