A maintainer is preparing a repository security advisory for a vulnerability they fixed privately in their open-source package. They want the published advisory to carry an official CVE so downstream consumers can correlate it with other tracking systems, but they have not requested a CVE from any external CVE Numbering Authority. Within the GitHub repository security advisory workflow, what is the most accurate way to obtain a CVE for this advisory?
- AOpen a public issue referencing the fix so a community CVE Numbering Authority notices it and assigns a CVE retrospectively after the fix is disclosed.
- BRequest a CVE identifier through the draft advisory in GitHub, since GitHub is a CVE Numbering Authority and can assign a CVE that is published with the advisory. Correct
- CPublish the advisory first with no CVE, because publication automatically mints a CVE for every repository security advisory once it reaches the Advisory Database.
- DConvert the repository to a verified publisher in the package registry, which is the only route through which GitHub will attach a CVE to the advisory.
Why A is wrong: Relying on a public issue abandons the confidential workflow and leaves CVE assignment to chance; it is neither the supported path nor compatible with assigning a CVE before disclosure.
Why B is correct: GitHub operates as a CVE Numbering Authority for advisories in repositories, so a maintainer can request a CVE from within the draft repository security advisory and have it assigned and published alongside the advisory.
Why C is wrong: This is tempting because publication does feed the Advisory Database, but a CVE is requested deliberately rather than minted automatically for every advisory; publishing without requesting one leaves the CVE field empty.
Why D is wrong: Registry publisher verification governs package provenance and is unrelated to CVE assignment; the CVE request is made through the draft advisory itself, not through registry settings.