CVE Consumer Working Group DQAF
draft — open for review

CVE DQAF: Role Inventory

This document is the supporting role and task family inventory for the CVE Data Quality Assessment Framework project. It records the roles, task families, and practitioner questions identified during Phase 1. The consolidated task list derived from this document is in tasks.md.

The hierarchy (Sector → Role → Task Family) exists to ensure systematic coverage — that we don’t miss a role or a task family because we didn’t think to look. Once tasks are identified under each task family, they are promoted to the flat task list in tasks.md with role/sector attribution as metadata.

See also: Task List.

How to Read This Document

Sector — the broad functional context in which CVE data is used. Role — a function (not a job title) within that sector whose work has a direct or traceable dependency on CVE data. Task Family — a cluster of related tasks performed by that role. Task — a practitioner question: what the practitioner is trying to determine or accomplish. Stated without presupposing what CVE data contributes.

A role qualifies if a CVE record or CVE ID is a direct input to at least one task it performs. A task qualifies if CVE data is a traceable input and significant degradation in CVE record quality would produce worse outcomes.

Tasks marked [thin] need additional work before Phase 2 promotion.

Sector: Enterprise

Organizations that consume CVE data to manage vulnerability risk across a technology estate.

Role: Enterprise:Vulnerability Analyst

The primary direct consumer of CVE records in the enterprise. Operates scanner-mediated workflows at scale. Heavy dependency on both CVE ID and record content.

Task Family: Enterprise:Vulnerability Analyst:Detection

Identifying which vulnerabilities exist in the environment. Scanner output references CVE IDs. Includes forward lookup, reverse lookup, and full-coverage questions.

Supporting references:

Task Family: Enterprise:Vulnerability Analyst:Triage and Validation

Confirming scanner findings are real and applicable to the specific deployment.

Supporting references:

Task Family: Enterprise:Vulnerability Analyst:Risk Assessment

Scoring confirmed findings to understand exposure. Uses CVE record content supplemented by external signals. Distinct from prioritization — this is about the inherent risk of the vulnerability, not the order in which it gets fixed.

Supporting references:

Task Family: Enterprise:Vulnerability Analyst:Prioritization

Ordering the remediation queue given all constraints: risk score, asset criticality, business impact, resource availability, and regulatory deadlines. Both the Vulnerability Analyst and the Remediation Coordinator contribute to prioritization from different perspectives: the analyst brings risk scoring, the coordinator brings operational and business constraints.

Supporting references:

Task Family: Enterprise:Vulnerability Analyst:Reporting and Metrics

Producing dashboards, executive summaries, KPI reports, and trend analyses. [thin]

Supporting references: Pending. This task family needs targeted research before Phase 2 promotion.

Role: Enterprise:Remediation Coordinator

Translates prioritized CVE findings into executable remediation plans and drives them to closure. The function that goes from “this CVE” to “here are the steps we take during the patch window.”

Task Family: Enterprise:Remediation Coordinator:Prioritization

This task family is shared with Enterprise:Vulnerability Analyst. The Remediation Coordinator’s contribution is operational and business context: downtime cost, resource constraints, patch window scheduling, and regulatory deadlines.

Supporting references:

Task Family: Enterprise:Remediation Coordinator:Fix Identification

Determining what resolves the vulnerability and how to obtain it.

Supporting references:

Task Family: Enterprise:Remediation Coordinator:Patch Planning and Execution

Building and executing the patch plan. [thin]

Supporting references: Pending. This task family needs targeted research before Phase 2 promotion.

Task Family: Enterprise:Remediation Coordinator:Remediation Verification

Confirming vulnerabilities are actually closed, not just administratively closed.

Supporting references:

Role: Enterprise:GRC / Compliance Analyst

Maps CVE data to regulatory obligations, tracks SLA compliance, and generates audit evidence. The question this role answers is not “how bad is this” but “can we prove we addressed it within the required timeframe.”

Task Family: Enterprise:GRC / Compliance Analyst:Regulatory Mapping

Identifying which CVEs carry mandatory remediation obligations.

Supporting references:

Task Family: Enterprise:GRC / Compliance Analyst:SLA Tracking and Compliance Monitoring

Monitoring whether the VM program is meeting its commitments.

Supporting references:

Task Family: Enterprise:GRC / Compliance Analyst:Audit Evidence Generation

Producing documentation that proves the vulnerability management program operated as required.

Supporting references:

Task Family: Enterprise:GRC / Compliance Analyst:Risk Acceptance and Exception Management

Documenting decisions to defer or not patch a CVE.

Supporting references:

Role: Enterprise:Application Security Engineer

Manages the application security testing program within the enterprise software development lifecycle. Runs and interprets SAST, DAST, and SCA tooling, triages findings, provides remediation guidance to developers, and tracks the application vulnerability backlog. CVE data dependency is strong for SCA (dependency vulnerabilities) and weak to indirect for SAST/DAST (first-party code weaknesses, which are primarily described by CWE rather than CVE).

Task Family: Enterprise:Application Security Engineer:Dependency Vulnerability Detection

Identifying known vulnerabilities in third-party and open-source components used by the application. SCA tooling produces findings keyed to CVE IDs. Strong direct CVE data dependency.

Supporting references:

Task Family: Enterprise:Application Security Engineer:Dependency Vulnerability Triage

Determining whether a CVE present in a dependency is actually exploitable in the application’s specific usage. The dominant false positive problem in SCA: a CVE counts as “present” if the package is installed, but the vulnerable code path may never be called. Research consistently shows 60–80% of SCA alerts are unreachable in practice.

Supporting references:

Task Family: Enterprise:Application Security Engineer:Dependency Vulnerability Remediation

Resolving confirmed dependency vulnerabilities. The primary action is upgrading to a fixed version, but this introduces its own risk — breaking changes, incompatible APIs, cascading upgrades through the dependency tree.

Supporting references:

Task Family: Enterprise:Application Security Engineer:First-Party Vulnerability Management

Managing security weaknesses found in code the organization wrote itself, through SAST, DAST, code review, or external reports. Note: findings here are primarily described by CWE (weakness type), not CVE. CVE enters this workflow when an external party discovers and reports a vulnerability and a CVE ID is assigned, or when the engineer researches how similar vulnerabilities have been exploited elsewhere. [thin — CVE dependency indirect]

Supporting references:

Role: Enterprise:Developer

Writes application code and receives security findings from AppSec tooling via IDE alerts, pull request checks, and CI/CD pipeline failures. Primarily acts on findings rather than discovering them. CVE data dependency is strong when remediating dependency alerts, weak when fixing first-party code weaknesses (which arrive as CWE-keyed findings).

Task Family: Enterprise:Developer:Dependency Alert Response

Responding to a security alert on a third-party package. The developer’s starting point is a CVE ID and a package name surfaced by a scanner or bot (Dependabot, Snyk, npm audit). Their job is to understand the finding and take action.

Supporting references:

Task Family: Enterprise:Developer:First-Party Vulnerability Remediation

Fixing a security weakness identified in the developer’s own code by SAST, DAST, code review, or a reported CVE. CVE data dependency here is indirect — the primary reference is CWE and OWASP category, but a CVE may be cited when the finding came from an external report or when the developer researches exploitation patterns. [thin — CVE dependency indirect]

Supporting references:

Sector: Threat Intelligence and Detection Engineering

Roles that consume CVE data to understand, track, and detect exploitation activity. Distinct from the Enterprise sector in that the primary question is not “are we affected?” but “is this being exploited, by whom, and can we detect it?”

Role: Threat Intelligence and Detection Engineering:Cyber Threat Intelligence Analyst

Tracks threat actors and campaigns, correlates CVEs to adversary activity, monitors exploitation status, and enriches the VM prioritization process with real-world threat context. Answers the question the CVE record cannot: who is actively using this vulnerability and against whom.

Task Family: Threat Intelligence and Detection Engineering:Cyber Threat Intelligence Analyst:Vulnerability Intelligence Monitoring

Continuously tracking the CVE landscape for newly disclosed vulnerabilities relevant to the organization, before the formal VM scanning cycle catches up.

Supporting references:

Task Family: Threat Intelligence and Detection Engineering:Cyber Threat Intelligence Analyst:Threat Actor and Campaign Correlation

Linking CVE identifiers to known threat actor behavior, campaign activity, and adversary infrastructure. Answers who is using a vulnerability, not just whether it is being used.

Supporting references:

Task Family: Threat Intelligence and Detection Engineering:Cyber Threat Intelligence Analyst:Exploitation Status Assessment

Determining the real-world exploitation status of a CVE beyond what the CVE record itself states.

Supporting references:

Task Family: Threat Intelligence and Detection Engineering:Cyber Threat Intelligence Analyst:Intelligence Production [thin]

Translating CVE-based threat intelligence into actionable products for internal consumers — VM teams, SOC, and leadership.

Supporting references:

Role: Threat Intelligence and Detection Engineering:SOC Analyst

Reactive, alert-driven. Encounters CVE IDs in SIEM and EDR alerts and looks them up to understand what an alert means and how to respond. CVE dependency is real but relatively narrow — they need rapid characterization, not deep research.

Task Family: Threat Intelligence and Detection Engineering:SOC Analyst:Alert Triage

An alert has fired referencing a CVE. The SOC analyst needs to understand what the vulnerability is, whether the alert represents a real exploitation attempt, and how serious it is.

Supporting references:

Task Family: Threat Intelligence and Detection Engineering:SOC Analyst:Exploitation Investigation

A confirmed or suspected exploitation attempt is being investigated. The CVE record informs what artifacts and behaviors to look for.

Supporting references:

Role: Threat Intelligence and Detection Engineering:Detection Engineer

Builds and maintains detection rules — Sigma, Snort/Suricata, YARA, EDR behavioral rules — that enable the SOC analyst’s work. Has the most demanding CVE record content requirements of any role in the scaffold.

Critical finding: The standard detection engineering workflow for a new CVE is: (1) locate proof-of-concept exploit code, (2) study the attack mechanism from the PoC, (3) write detection logic, (4) validate. The CVE record is not the primary input to step 2 — the PoC or researcher write-up is. CVE records rarely provide the protocol-level behavioral specifics needed to write a network signature: what request pattern triggers the vulnerability, what the exploit payload looks like, what observable artifacts successful exploitation produces. CVSS vectors give coarse indicators but nothing close to rule-writing specificity. This is a structural data quality failure for this role.

Task Family: Threat Intelligence and Detection Engineering:Detection Engineer:Detection Coverage Assessment

Determining whether current detection rules cover a given CVE and identifying gaps.

Supporting references:

Task Family: Threat Intelligence and Detection Engineering:Detection Engineer:Detection Rule Development

Writing new detection rules for a CVE. The CVE record is the starting point but frequently insufficient — detection engineers must supplement it with PoC code, vendor advisories, and researcher write-ups to get behavioral specifics.

Supporting references:

Task Family: Threat Intelligence and Detection Engineering:Detection Engineer:Rule Validation and Tuning

Ensuring detection rules work correctly without generating excessive false positives.

Supporting references:

Sector: Generalist IT

IT practitioners who manage vulnerability response without dedicated security specialization. They encounter CVE records directly — often reading cve.org or NVD cold — without the tooling, context, or expertise that enterprise VM roles bring. The CVE record is their primary or only data source. Poor record quality has the highest impact here because there is no analyst expertise or toolchain to fill gaps.

Two variants: the internal IT generalist managing a single organization, and the MSP technician managing multiple SMB client environments simultaneously.

Role: Generalist IT:IT Generalist

The de facto vulnerability program in organizations without dedicated security staff. Receives CVE IDs from vendor emails, news headlines, basic scanner alerts, or tickets from a manager. Reads the CVE record directly and must determine what it means, whether the organization is affected, and what to do — without a VM platform, security toolchain, or specialized expertise.

Task Family: Generalist IT:IT Generalist:CVE Comprehension

Reading a CVE record and understanding it well enough to make a decision. The primary failure mode for this role is a record that requires expertise the generalist doesn’t have to interpret — CVSS vector strings, CPE URIs, jargon-heavy descriptions, or descriptions that assume familiarity with the affected technology.

Supporting references:

Task Family: Generalist IT:IT Generalist:Applicability Determination

Determining whether the organization is affected, without a VM platform to automate the matching.

Supporting references:

Task Family: Generalist IT:IT Generalist:Fix Identification and Action

Finding out what to do and doing it.

Supporting references:

Role: Generalist IT:MSP Technician

Manages vulnerability response across multiple SMB client environments simultaneously. Same core tasks as the IT Generalist, multiplied across a client book of business, with the additional requirement to communicate CVE risk to non-technical business owners. Also faces the MSP-as-target problem: the MSP’s own tooling (RMM platforms, remote access tools) can itself be the CVE target, with client environments as downstream victims.

Task Family: Generalist IT:MSP Technician:Multi-Client Exposure Assessment

Determining which clients are affected by a given CVE across a heterogeneous client estate.

Supporting references:

Task Family: Generalist IT:MSP Technician:Client Communication

Translating CVE technical content into client-appropriate language for non-technical business owners.

Supporting references:

Task Family: Generalist IT:MSP Technician:Remediation Coordination

Scheduling and executing patching across multiple client environments. Similar to Enterprise:Remediation Coordinator but without the organizational infrastructure of a formal change management process. [thin]

Supporting references:

Sector: Software Producers

Organizations and individuals who produce software and bear responsibility for publishing CVE records when vulnerabilities are found in their products. This sector is the source of CVE data — the decisions made here directly determine the quality of data all other sectors consume.

CVE records are primarily an output for this sector. However, CVE data is also an input in two specific tasks: checking for duplicate CVEs before publishing a new one, and assessing whether a known CVE in a third-party dependency affects their own product.

Critical structural finding: The CVE schema’s affected array — the field that specifies which product versions are vulnerable — is explicitly documented as a quality problem at the source. CVEProject/cve-schema issue #364 states: “the format is very flexible… data consumers may have trouble… we don’t have detailed guidance on how to define and use products and versions.” The product identification and version matching failures experienced by downstream consumers are rooted in decisions made in this sector.

Update volume finding: In 2024, CVE records received 108,933 updates against 40,274 new publications — a 2.7:1 ratio. Updates represent advancing knowledge: better characterization, corrected version ranges, updated exploitation status, and improved references. The update volume is a sign the ecosystem is maturing. The quality concern is downstream: whether consumer pipelines reliably detect and propagate those updates.

Role: Software Producers:PSIRT / Security Response Coordinator

Manages the full lifecycle of vulnerability response at a software vendor: receives inbound reports, triages, coordinates with engineering teams, manages disclosure timelines and embargoes, notifies downstream parties, assigns or reserves CVE IDs, and publishes CVE records and customer advisories. For large vendors this is a dedicated team; for smaller organizations it may be a single person or shared responsibility.

Task Family: Software Producers:PSIRT / Security Response Coordinator:Vulnerability Intake and Triage

Receiving a vulnerability report and determining what it is: whether it is real, whether it is in scope, whether it duplicates an existing CVE, and how serious it is.

Supporting references:

Task Family: Software Producers:PSIRT / Security Response Coordinator:Vulnerability Characterization

Reproducing and fully characterizing the vulnerability: what it is, how it works, what the affected scope is, and what the fix needs to address. This is the analytical work that feeds everything downstream — the CVE record, the advisory, and the fix.

Supporting references:

Task Family: Software Producers:PSIRT / Security Response Coordinator:CVE ID Management

Reserving, assigning, and managing CVE IDs throughout the disclosure lifecycle.

Supporting references:

Task Family: Software Producers:PSIRT / Security Response Coordinator:Disclosure Coordination

Managing the timeline and communication of the disclosure: coordinating with the reporter, managing embargoes, notifying downstream OEM partners and integrators before public disclosure, and synchronizing patch availability with public knowledge.

Supporting references:

Task Family: Software Producers:PSIRT / Security Response Coordinator:Third-Party Dependency Vulnerability Response

When a CVE is published in a third-party library or component that the vendor ships as part of their product, the vendor must assess whether their product is affected, determine the fix, and notify customers. This task has CVE data as a direct input — the vendor is consuming a third-party CVE to assess their own product’s exposure.

Supporting references:

Role: Software Producers:CNA Record Author

Writes the actual CVE record fields: description, affected product and version ranges, CVSS vector, CWE assignment, and references. May be the PSIRT coordinator or a dedicated role. This is the function whose output quality directly determines what every other sector in this framework receives. Decisions made here — about how to describe the vulnerability, how to express the affected version range, whether to include exploitation conditions — propagate through the entire ecosystem.

Task Family: Software Producers:CNA Record Author:CVE Record Authoring

Writing a CVE record that is accurate, complete, and useful to downstream consumers. The CVE schema specifies required fields but provides limited guidance on how to populate them well — particularly the affected product/version array.

Supporting references:

Task Family: Software Producers:CNA Record Author:CVE Record Maintenance

Updating a published CVE record when new information becomes available — additional affected versions, corrected CVSS, updated fix reference, dispute resolution, or new references. In 2024, CVE records received 2.7 updates per new publication, indicating that maintenance is a substantial ongoing function.

Supporting references:

Role: Software Producers:Open Source Maintainer

An individual or small team that maintains open source software used by others, without a formal security function. Receives vulnerability reports through GitHub security advisories, email, or public disclosure, and must triage, fix, coordinate, and publish — often with no dedicated security staff, limited time, and volunteer capacity. The GitHub blog published a full step-by-step guide for this role because it is so frequently underprepared.

Task Family: Software Producers:Open Source Maintainer:Vulnerability Report Handling

Receiving a report and deciding what to do with it. The open source maintainer often lacks the security expertise to immediately evaluate severity or determine scope, and may be the first time they have encountered a formal vulnerability disclosure.

Supporting references:

Task Family: Software Producers:Open Source Maintainer:CVE Assignment and Advisory Publication

Requesting a CVE ID, writing the advisory, and publishing. For open source projects that are CNAs, this is done directly; for others, the maintainer works through a platform (GitHub, HackerOne) or MITRE.

Supporting references:

Sector: Tool and Data Ecosystem Builders

Organizations that build the infrastructure through which CVE data is transformed, normalized, enriched, and delivered to end consumers. This sector sits between the Software Producers who create CVE records and the consuming sectors who act on them. Data quality failures in CVE records are amplified here: a bad record ingested by a tool reaches every user of that tool.

The NVD enrichment collapse (NVD formally reduced to a triage queue as of April 2026, enriching only ~15-20% of new CVEs) has made this sector’s function critical and contested. Tools that relied on NVD CPE data for matching are now blind to the majority of the CVE corpus. Large vendors have built independent enrichment pipelines; smaller ones have not.

Role: Tool and Data Ecosystem Builders:Vulnerability Scanner and VM Platform Developer

Builds the scanning tools and vulnerability management platforms that enterprise consumers use to identify vulnerabilities in their environments. CVE data drives two core platform functions: detection coverage (what vulnerabilities the scanner knows how to find) and product identification (matching what the scanner finds to CVE records for a specific product and version).

The CPE coverage collapse is the most operationally significant current problem: NVD provided CPE identifiers for only 41.35% of 2024 CVEs. Scanners that rely on CPE-based matching are structurally blind to more than half the CVE population.

Task Family: Tool and Data Ecosystem Builders:Vulnerability Scanner and VM Platform Developer:CVE Data Ingestion and Coverage

Maintaining a current and complete CVE dataset as the foundation for scanning. This is not a one-time task — new CVEs appear continuously, records are updated frequently, and enrichment sources change.

Supporting references:

Task Family: Tool and Data Ecosystem Builders:Vulnerability Scanner and VM Platform Developer:Product Identification and Matching

Mapping CVE product identifiers to the software and assets present in a customer’s environment. This is the matching problem that produces false positives and false negatives in scanner output — the engineering manifestation of the identification quality failures documented throughout this scaffold.

Supporting references:

Task Family: Tool and Data Ecosystem Builders:Vulnerability Scanner and VM Platform Developer:SBOM and Package-Native Matching

For scanners and SBOM tools that match CVE records against software manifests and bills of materials, the product identification challenge requires ecosystem-native identifiers (purl, package coordinates) rather than CPE strings. CVE records that lack these identifiers are structurally unmatchable in this workflow regardless of their accuracy in other respects.

Supporting references:

Role: Tool and Data Ecosystem Builders:Vulnerability Database and Feed Aggregator

Builds and operates data infrastructure that aggregates CVE data from multiple sources, normalizes it, resolves cross-source identity, enriches it with additional signals, and redistributes it to downstream consumers. This includes databases like VulnCheck NVD++, OpenCVE, CVEFeed.io, OSV, GHSA, and commercial threat intelligence platforms.

This role is the most structurally exposed to CVE data quality failures: every gap, inconsistency, and naming irregularity in the raw data must be detected, corrected, or worked around before distribution. What is invisible to the database operator passes through uncorrected to every consumer downstream.

Task Family: Tool and Data Ecosystem Builders:Vulnerability Database and Feed Aggregator:Multi-Source Normalization

Raw CVE records arrive with inconsistent vendor names, product names, and version expressions. Normalization converts these into a consistent internal representation that enables reliable matching and deduplication.

Supporting references:

Task Family: Tool and Data Ecosystem Builders:Vulnerability Database and Feed Aggregator:Cross-Source Identity Resolution

Determining when records from different sources — CVE, GHSA, OSV, JVN, NVD, vendor advisories, GCVE — describe the same underlying vulnerability, and producing authoritative cross-reference mappings.

Supporting references:

Task Family: Tool and Data Ecosystem Builders:Vulnerability Database and Feed Aggregator:Enrichment and Signal Aggregation

Adding structured signals not present in the raw CVE record: CVSS scores where absent, CPE identifiers, exploit availability, KEV status, EPSS scores, threat actor attribution. This is the function that the NVD collapse has pushed onto commercial and community operators.

Supporting references:

Role: Tool and Data Ecosystem Builders:ADP / Enrichment Operator

Organizations authorized as Authorized Data Providers (ADPs) that add structured data directly to CVE records on cve.org, making that enrichment part of the authoritative record rather than a separate database. CISA Vulnrichment is the canonical example, adding CVSS, CWE, CPE, and SSVC assessments directly to CVE records. The ADP model was the CVE program’s response to the NVD enrichment collapse.

Task Family: Tool and Data Ecosystem Builders:ADP / Enrichment Operator:Record Enrichment

Adding structured fields to CVE records that CNAs did not include or included incorrectly. Each enrichment decision is a quality judgment with downstream consequences.

Supporting references:

Task Family: Tool and Data Ecosystem Builders:ADP / Enrichment Operator:Coverage Prioritization

Deciding which CVEs to enrich first given that complete coverage is not achievable. Prioritization decisions here directly determine which CVEs downstream tools can act on and which remain invisible.

Supporting references:

Sector: Independent

Individuals who discover vulnerabilities in software they did not write and do not own, operating outside organizational security programs. CVE data functions as both an input (duplicate checking, target research) and an output (CVE ID as credential and coordination mechanism).

Two sub-populations with meaningfully different CVE data relationships: independent security researchers whose primary function is finding and disclosing vulnerabilities, and bug bounty hunters who work within organized programs and use CVE data more as a research input.

Role: Independent:Security Researcher

Finds vulnerabilities through independent research in software they don’t own — not through a formal bounty program scope. Responsible for coordinating disclosure with the vendor, managing disclosure timelines, and obtaining and publishing a CVE ID. The CVE ID serves both as a professional credential and as the coordination mechanism that ensures defenders can act on the finding.

Task Family: Independent:Security Researcher:Prior Art Research

Checking whether a vulnerability is already known and CVE-assigned before investing in disclosure. A zero-day is not a zero-day if it has already been identified. The quality of this check depends directly on CVE record searchability and description clarity. Poor descriptions make duplicate detection unreliable — researchers may unknowingly re-discover and re-disclose already-known vulnerabilities, wasting effort and creating duplicate CVEs.

Supporting references:

Task Family: Independent:Security Researcher:Vendor Reporting and Disclosure Coordination

Reporting the vulnerability to the vendor and managing the disclosure timeline. This is the most conflict-prone part of the researcher workflow — vendors control the disclosure process, and researchers must navigate unresponsive or hostile vendors, disputed severity assessments, and deadline negotiations.

Supporting references:

Task Family: Independent:Security Researcher:CVE ID Acquisition

Obtaining a CVE ID assigned to the finding. The CVE ID must be requested from the appropriate CNA — determining which CNA is responsible is itself a task, and the process can be blocked by vendor non-cooperation, CNA response time, or disputes about whether the issue qualifies as a vulnerability.

Supporting references:

Task Family: Independent:Security Researcher:Public Disclosure and Attribution

Publishing the finding after the patch is available, verifying the CVE record is accurate, and receiving credit for the discovery.

Supporting references:

Role: Independent:Bug Bounty Hunter

Finds vulnerabilities through organized programs on platforms like HackerOne, Bugcrowd, and Intigriti. CVE data is primarily an input — used to understand a target’s vulnerability history, find unpatched instances of known vulnerabilities, and verify that a finding is not a duplicate before submitting. Platform reputation scores matter more than CVE count for this role; CVE IDs are a secondary concern.

Task Family: Independent:Bug Bounty Hunter:Target Research Using CVE Data

Using the CVE corpus to understand a target’s technology stack vulnerabilities, identify recently published CVEs that the target may not have patched, and find related attack patterns to guide research.

Supporting references:

Task Family: Independent:Bug Bounty Hunter:Duplicate Check Before Submission

Verifying that a finding is not a duplicate before investing time in writing up and submitting a report. Submitting a duplicate is wasted effort and can damage platform reputation.

Supporting references:

Role: Independent:Open Source Developer

Discovers vulnerabilities while contributing to, auditing, or using open source software — not as a formal security researcher and not through a bounty program. May find a security issue while doing unrelated development work (the XZ Utils backdoor, discovered by Andres Freund while investigating performance anomalies, is the canonical case). Often lacks security disclosure training and must navigate the open source ecosystem’s specific reporting infrastructure: project SECURITY.md files, GitHub Private Vulnerability Reporting, GHSA, and OSV.

Distinct from Software Producers:Open Source Maintainer: that role receives vulnerability reports about their own project. This role discovers vulnerabilities in someone else’s project and must figure out how to report them. Distinct from Independent:Security Researcher: less formal, typically not seeking a CVE as a credential, and operating within open source community norms rather than professional disclosure frameworks.

Task Family: Independent:Open Source Developer:Vulnerability Discovery and Scoping

Determining that what they found is actually a security vulnerability, understanding its scope, and deciding whether and how to report it.

Supporting references:

Task Family: Independent:Open Source Developer:Upstream Disclosure

Reporting the vulnerability to the affected project. The open source ecosystem has its own reporting conventions — GitHub Private Vulnerability Reporting, project security contact emails, security policies in SECURITY.md — that differ from the formal CNA process.

Supporting references:

Task Family: Independent:Open Source Developer:CVE and Advisory Navigation

Understanding whether a CVE will be assigned, how the advisory process works in the open source ecosystem, and what the published record should contain. Many open source developers have no prior experience with CVE assignment and are navigating this for the first time.

Supporting references:

Sector: Research and Policy

Individuals and organizations that consume CVE data at corpus scale to produce research outputs, policy instruments, or risk models. Distinct from all other sectors: the primary artifact is not a remediation action or a detection rule — it is a finding, a mandate, or a model derived from the vulnerability population. CVE data quality failures here propagate into research conclusions, policy rationales, and quantitative risk frameworks rather than into individual remediation decisions.

Two roles with distinct data dependencies and distinct quality sensitivities:

Role: Research and Policy:Academic Researcher

Builds models, conducts empirical studies, and analyzes trends using the CVE corpus as a primary dataset. Uses CVE records both as labeled training data (for ML approaches) and as a population from which to draw statistical inferences. Produces outputs that are used by practitioners, tool builders, policymakers, and other researchers. The academic literature on vulnerability management — EPSS, vulnerability discovery models, severity prediction, exploitation likelihood prediction, NLP-based description analysis — depends almost entirely on CVE/NVD data as its empirical substrate.

Critical structural finding: CVE data quality errors propagate into research conclusions. Nguyen and Massacci (2013) verified NVD’s affected-version data against ground truth for Chrome and found systematic errors that produced different conclusions depending on whether the clean or dirty data was used. They note: “Vulnerability data sources are used by academics to build models, and by industry and government to assess compliance. Errors in such data sources therefore not only are threats to validity in scientific studies, but also might cause organizations…” This is the academic research version of the quality problem: the downstream harm is a wrong finding published in a peer-reviewed venue, not a missed patch.

Second structural finding: The CVE corpus is not a representative sample of the software vulnerability population. Coverage is a function of CNA participation, disclosure incentives, and ecosystem biases — open source and enterprise software are over-represented; embedded systems, proprietary firmware, and ICS/OT software are under-represented. ML models trained on this corpus inherit those biases. A researcher building an exploitation prediction model must decide whether their corpus is the population of interest or a biased sample of it, and CVE record fields provide no direct signal on this question.

Task Family: Research and Policy:Academic Researcher:Corpus Construction and Validation

Building a research-grade dataset from CVE records and validating that it is suitable for the intended analysis. The researcher must understand what the corpus contains, what it excludes, and where its quality is sufficient to support valid inferences.

Supporting references:

Task Family: Research and Policy:Academic Researcher:Vulnerability Trend Analysis

Studying how the vulnerability population changes over time — counts by category, severity distributions, weakness type prevalence, disclosure rates, patch latency. CVE corpus completeness and field consistency are prerequisites; if coverage changes over the study period (new CNAs added, NVD enrichment practices changed), trend analyses confound real signal with data collection artifacts.

Supporting references:

Task Family: Research and Policy:Academic Researcher:Predictive Model Development

Building ML models that use CVE record fields as features: severity prediction, exploitation likelihood prediction (EPSS), CWE classification, vulnerability discovery rate modeling. CVE description text, CVSS vectors, CWE assignments, publication dates, and affected product metadata are the primary feature sources. Model validity depends on label quality (are the CVSS and CWE assignments accurate?), description consistency (do descriptions from different CNAs use comparable language?), and corpus representativeness.

Supporting references:

Task Family: Research and Policy:Academic Researcher:Data Quality and Validity Assessment

Studying the CVE corpus itself as a research object — assessing field completeness, accuracy, consistency, and coverage properties. This task family directly produces knowledge that feeds the DQAF project. The researcher’s output is an empirical characterization of where the data fails and what the downstream consequences are.

Supporting references:

Task Family: Research and Policy:Academic Researcher:Cross-Source Harmonization for Research [thin]

Reconciling CVE records with other vulnerability databases (GHSA, OSV, JVN, vendor advisories) to build a more complete research corpus or to study cross-source agreement and disagreement. Distinct from the operational cross-source identity resolution done by database aggregators: the research question here is about what the differences reveal about data quality and coverage, not just resolving them for operational use.

Supporting references:

Role: Research and Policy:Policy Analyst

Uses CVE corpus data to characterize the vulnerability landscape, justify regulatory interventions, measure policy effectiveness, and develop mandates. The CVE ID is a gatekeeping condition for several formal policy mechanisms (KEV requires a CVE ID as a necessary condition for entry). CVE record field content — CWE assignments, CVSS scores, publication dates — feeds the statistics that justify policy arguments. Distinct from the Academic Researcher: the output is an instrument with legal or regulatory force, not a finding that can be subsequently revised.

Critical structural finding: The KEV catalog’s three inclusion criteria are: (1) a CVE ID must exist, (2) reliable evidence of active exploitation, (3) clear remediation guidance. Criterion 1 means that exploited vulnerabilities without CVE IDs are ineligible for KEV inclusion regardless of exploitation evidence or remediation clarity. CVE program coverage gaps are therefore directly and mechanically translated into policy coverage gaps.

Second structural finding: Policy arguments about vulnerability classes depend on CWE assignments in CVE records. The memory-safety policy rationale used by CISA and ONCD — that 70% of vulnerabilities reported to Microsoft and Google are due to memory safety issues — is derived from CWE corpus analysis. If CWE assignments are systematically wrong or incomplete, the empirical basis for that policy argument is wrong.

Task Family: Research and Policy:Policy Analyst:Vulnerability Landscape Characterization

Describing the aggregate vulnerability population to justify a policy intervention. Answers questions about what fraction of vulnerabilities belong to a given class, how rapidly the population is growing, how much exploitation activity is associated with which types of vulnerabilities, and whether the current disclosure ecosystem captures the real vulnerability landscape.

Supporting references:

Task Family: Research and Policy:Policy Analyst:Policy Instrument Development

Translating vulnerability landscape characterizations into mandates, catalogs, advisories, or requirements. The CVE ID is a required field for most formal policy instruments. CVSS scores drive remediation timeline tiers. CWE assignments drive weakness class mandates. Publication dates set compliance clock start points.

Supporting references:

Task Family: Research and Policy:Policy Analyst:Policy Effectiveness Measurement

Assessing whether a policy instrument is achieving its intended effect. BOD 22-01 compliance is measured against CVE-keyed remediation deadlines. Memory-safety trend analysis measures whether CWE-119 and related weakness counts are declining. These measurements depend on CVE corpus quality: if the corpus is incomplete or if CWE assignments are wrong, the effectiveness measurement is wrong.

Supporting references:

Task Family: Research and Policy:Policy Analyst:CVE Program Scope and Coverage Assessment

Assessing whether the CVE program’s scope — which CNAs cover which products, which vulnerability types are in scope, how the counting rules work — is adequate for the policy use case. A policy analyst recommending a mandate that relies on KEV must assess whether KEV’s CVE-ID requirement means the mandate’s reach is limited by CVE program coverage, and whether that coverage gap is policy-relevant.

Supporting references:

Sectors Now Complete

All seven sectors have been developed:

Document History

Phase 1 role and task family inventory developed May 2026. Seven sectors, 19 roles, 59 task families. Supporting references provided for all task families except two (Enterprise:Vulnerability Analyst:Reporting and Metrics and Enterprise:Remediation Coordinator:Patch Planning and Execution), which are marked pending and need targeted research before Phase 2 promotion.