AVE is a standard, not software. Its “architecture” is the structure of the standard: the record schema, the record/rule/fixture validation triangle, the contract between a static record and a runtime finding, the framework mappings, and the SARIF emission convention. None of this describes any one product’s internals — it describes what every implementer must honor.
The standard at a glance
Conventional standards stop at the package: CVE identifies a flaw, OSV maps it to a version range. Agent component threats have no package and no version — the danger is behavioral. AVE assigns a stable id to each distinct behavioral vulnerability class, scores it with OWASP AIVSS v0.8, and maps it to the frameworks the field already uses. One record catches many textual variants of the same underlying attack.
If two scanners read the same record and produce divergent results, the standard has failed at its one job. The architecture below exists so any implementation agrees with any other.
How a record works
Anatomy
A record has two halves. The static definition describes the vulnerability class and never changes per scan: ave_id (immutable), attack_class, behavioral_fingerprint, severity, aivss, and the framework mappings. The evidence declarations (added in v1.1) are optional and declare the defaults a scanner uses to assign per-finding metadata.
Validation — the record/rule/fixture triangle
Every record requires a detection rule (pattern, YARA, or Semgrep) that references the ave_id, a positive fixture that must trigger it, and a negative fixture — a benign lookalike that must not. A rule without a negative fixture is an incomplete false-positive guard.
Consumption — the record declares, the scanner assigns
This is the most important rule for implementers. A record is static; a finding is a runtime instance. Confidence belongs to the finding, never the record — the same class in a docs folder and in a live skill file deserves different confidence. So the record declares a confidence_baseline and the scanner does the per-detection math.
| Record declares (static) | Scanner assigns to finding (runtime) |
|---|---|
| confidence_baseline | confidence (then FP-adjusted) |
| evidence_kind_default | evidence_kind |
| detection_stage | evidence_stage (floor) |
| evidence_basis_engines | evidence_basis |
| derivable_into | ToxicFlow.derived_from_findings |
In any finding, confidence and aivss_score are separate fields and are never merged. AIVSS answers “how bad would this be”; confidence answers “how sure are we.” Putting baselines in the standard rather than in scanner code is what keeps two implementations consistent.
Output — how AVE travels
A scanner emits findings as SARIF with the ave_id in ruleId and under taxonomies, plus aivss_score, confidence, owasp_mcp, and mitre_atlas in the properties bag. Because SARIF is already consumed by the GitHub Security tab and CI, AVE ids reach those surfaces for free. The open record set can be consumed by any tool, and crosswalks let other scanners’ finding types resolve to AVE ids.
The schema, records, rules, and fixtures are all open under Apache 2.0. Honor the declares-vs-assigns contract and the SARIF convention, and your tool’s findings will interoperate with every other AVE implementation. See the schema reference and the repository.