Never Emitted: Reporter Attribution in GitHub's Machine-Readable Vulnerability Records

Abstract

The CVE record format defines a credits container that names who found or reported a vulnerability, with a typed role per entry. The OSV schema defines an equivalent field. GitHub, which assigns CVE identifiers for advisories in its ecosystems, collects this information from reporters, requires them to accept it, displays it on the advisory page, and serves it through its own REST API. It emits it into neither standardized format. Across 238 GitHub-assigned CVE records whose linked advisory publicly credits at least one party, zero carry a credits container, while all 238 carry metrics and problemTypes, two fields the CVE schema leaves optional exactly as it leaves credits. Across 302 advisories in the same pool we retrieved GitHub's own OSV export file, and zero carry a credits field. The omission is not a property of either format: the Erlang Ecosystem Foundation populates the CVE field on 18 of 18 records in the same pool using a freely available client for CVE Services. In a census of all 4,889 published CVE records in a two-week window, 46.9% carry credits, GitHub's rate is 0 of 570 without any advisory filter, and assigner behaviour is concentrated at the extremes without being exhausted by them: 16 assigners emit the field on no record and 13 on essentially every record, while 8 assigners covering 23% of the records sit in between. A request to close the gap has been open since January 2023; GitHub's stated reason for deferring it is quoted verbatim. We further show that the NVD API schema defines no credits field, so attribution that CNAs do emit does not reach the database most tooling consumes: of 43 credit-bearing records traced from advisory to CVE record to NVD, none retained it. We release the collection scripts and a frozen snapshot of every API response.