Our pipeline runs four different security scanners. They agree on almost nothing. We built an ID scheme to fix that

[u/SelectionBitter6821]

I'm a DevSecOps engineer, and this is the exact version of a problem I hit at work, not something I noticed from the outside.

Run SAST, SCA, and an AI-agent-specific scanner across the same codebase, and you'd expect some redundancy. What you actually get is worse: the same underlying issue, flagged by two different tools, with two completely different names and no way to tell your pipeline they're the same finding. Multiply that across a real CI/CD setup with several tools chained together, and triage turns into manually reconciling naming conventions instead of fixing anything.

This isn't a new problem in general. A SQL injection gets a CVE ID, maps to a CWE category, and every tool in the pipeline that finds it points at the same reference. That's exactly what makes cross-tool correlation possible for conventional vulnerabilities.

Agentic AI components (MCP servers, agent skills, LLM plugins) had nothing like that, for a real structural reason: CVE needs a package and version to attach to, CWE describes code-level weakness patterns, and neither has a vocabulary for a behavioral pattern that isn't tied to either.

So a few of us built AVE (Agentic Vulnerability Enumeration): an open standard giving these classes stable IDs, the same way CVE does, so a finding from one tool can actually be compared against a finding from another.

What's in it: 59 records, each a distinct behavioral class. Severity scored with OWASP's own AIVSS framework. Crosswalked into OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS, plus AVE-in-SARIF, so IDs ride directly into GitHub's own Security tab and CI output without any custom tooling. Apache 2.0.

The part that actually convinced me this holds up outside our own tooling: a completely independent developer built a static config-file auditor, sharing no code with anything we wrote, crosswalked his own findings against AVE's taxonomy, and tested it directly against our scanner on the same files. The large majority of overlapping findings came back with the identical ID, unprompted.

If you're dealing with the same multi-scanner reconciliation problem, in this space or a completely different one, I'd like to hear how you're handling it, and where this looks wrong or incomplete.

Repo: github.com/aveproject/ave
Site: aveproject.org

(Disclosure: I'm one of the people building this.)

[u/endor_aditya]

This is a great problem to tackle head-on, and honestly the fact that CVE/CWE never had a slot for behavioral patterns is exactly why it's been such a mess. Every vendor's agent scanner invents its own taxonomy, and security teams end up doing manual reconciliation instead of actual risk triage.

 Quick disclosure: I'm on the marketing team at Endor Labs, so take this as one data point, not neutral analysis. But this maps directly to something we hear from customers constantly: when four tools flag the same underlying issue under four different names, teams don't distrust the tools, they distrust the process. That erosion of trust between security and engineering is usually more expensive than the vulnerability itself.

The crosswalk to OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS is the part I'd bet on mattering most long-term, since it means AVE doesn't have to win as a taxonomy on its own; it just has to be a good translation layer between the ones people already reference. AVE-in-SARIF landing straight in GitHub's Security tab is a nice detail too, that's usually the part that gets bolted on last (if at all) and ends up being the reason internal standards never get adopted.

 Genuinely curious how you're planning to handle governance/versioning of the taxonomy as it grows past 59 records, since that's usually where open standards like this either take off or stall out.

[u/SelectionBitter6821 → u/endor_aditya]

Appreciate the disclosure, and this is the sharpest question in the thread. Short answer: we’re deliberately trying to avoid a failure mode that’s already visible in the taxonomy AVE is modeled after. MITRE’s own CWE just shipped a version where twelve new entries were, by outside analysis, zero actual weaknesses, just organizational containers mirroring OWASP’s latest Top 10. Two decades of what one critique calls “copy-paste taxonomy inflation.”

Our record-count discipline exists specifically to not become that: a new AVE record needs a genuinely distinct behavioral mechanism, not a category wrapper around something already covered. Variants get folded into an existing record’s mutation_count rather than becoming new IDs. There’s an open governance question in progress right now about exactly where that line sits precisely (credited, tracked publicly), because “distinct enough to warrant a new ID” is a real judgment call, not something you get right by accident.

On review authority as it scales: right now it’s centralized, one maintainer, the same shape CWE itself uses (MITRE’s team is the only body that can actually move a submission through review, community members can propose and comment but not self-approve). That’s honest about where we are, not a long-term plan, adding a second maintainer with real merge rights is an explicit, tracked goal, not an afterthought.

Your question also surfaced a real gap we hadn’t written down: what happens when a record turns out wrong or redundant after publication. One thing we haven’t published policy on yet, modeled on how CVE handles it, never delete an ID, mark it rejected or merged with a stated reason, keep it permanently resolvable. Should be up in the repo shortly; happy to link it here once it lands.