Towards a Minimum Viable Enumeration of Vulnerabilities
summary
Proposal claims the absolute MVVE is just two fields: a unique public identifier and a product identifier including version/build, enough to initiate discovery and disambiguate instances; without both, vulnerability management halts. Authors map that MVVE to CVE, OSV and other databases, sketch an 11‑phase lifecycle and four stakeholder roles, and publish slides plus a paper. An “MVVE++” adds a required remediation intent field so prioritization and response can proceed.
AI-written summary · about
chapters (10)
- 0:00Welcome to MVVE
- 1:49Origin and purpose
- 5:03Core elements of MVVE
- 8:54Vulnerability phases and roles
- 14:13Real-world complexity
- 17:21Information elements list
- 19:27Identifying vulnerability
- 22:37Minimum required fields
- 23:37MVE plus introduction
- 26:49Future work
related talks
37mThe Vulnerability Identity Crisis
57mA Paradigm Shift in Vulnerability Identity: Why Vulnerability Databases Struggle
45mVulntology - A Methodology to Characterize Vulnerabilities While Providing A Granular & Intuitive...
27mEffective Vulnerability Management for a DevSecOps Pipeline
37mPrioritizing Vulnerability Response with a Stakeholder Specific Vulnerability Categorization
15mA vulnerability database should not be about vulnerabilities!
32mUnderstanding Exploitability with VEX, EPSS, and Other Standard Frameworks
58mWhy Can't We All Just Get Along? Bridging the Gap in Vulnerability Prioritization Standards
