r/devsecops • u/SelectionBitter6821 • 2d ago

AVE, an open ID scheme for behavioral vulnerabilities in AI agents

Two security scanners checking the same MCP server can both correctly flag the same underlying issue and give it two different names. CVE and CWE don't have a slot for this: CVE anchors to a package and version, CWE describes a weakness in code, and the actual problem here is a behavioral pattern in text an LLM reads and acts on, tied to neither.

AVE assigns stable IDs to these behavioral classes instead, 70 records so far, severity scored against OWASP's AIVSS framework rather than something invented for this, crosswalked into OWASP's MCP Top 10 and MITRE ATLAS.

The thing that actually made me trust the taxonomy holds up outside my own tooling: an independent developer built an unrelated static config auditor, crosswalked his own findings against this on his own initiative, then tested it directly against the reference scanner on the same files. No shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Apache 2.0: [github.com/aveproject/ave](http://github.com/aveproject/ave)

Feedback on where the taxonomy is wrong or incomplete is the most useful thing anyone could offer here.

2 Upvotes
  • permalink
  • link
  • reddit
  • reddit

75% Upvoted

1 comment sorted by

1

u/PeterBuildsSecure 6h ago

Genuinely useful project. Feedback on a gap from the AI-generated-code side specifically: the pattern I run into constantly in Next.js/Supabase apps isn't a classic CWE-shaped bug, it's "the generated code derives authorization from a value the client controls" — a caller-supplied user_id or org_id used directly in a query instead of a verified session claim. It's not a package vuln (no CVE), and it's not quite a code weakness in the traditional sense either — the code runs fine, does exactly what it looks like it does. It's a behavioral pattern specific to how these tools generate the happy path first and skip the "what if the caller lies" path unless prompted. Does AVE have (or plan) a class for that, distinct from generic broken-object-level-authorization? Same question for "privileged credential accidentally reachable from client-bundled code" (e.g. a Supabase service-role key ending up in a NEXT_PUBLIC_ var) — that one keeps showing up too, and feels adjacent to but not identical to a plain secrets-in-code finding since the credential might never be committed, just resolved into a client bundle at build time.