GH-500 - Security operations: best practices, prioritization, and remediation (18% of the exam) - Section 5.1

Apply CVE, CWE, and GitHub Security Advisory concepts within end-to-end remediation workflows across security alerts and advisories.

Apply CVE identifiers, CWE classifications, and GitHub Security Advisory data to contextualise security alerts within an end-to-end remediation workflow. Recognise how advisories link a CVE to the affected package versions and guide the appropriate fix target.

CVECWEGitHub Security Advisoryremediation workflow

Practice question for this objective

Free sampleSecurity operations: best practices, prioritization, and remediationmedium

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.

Recognise that GitHub is a CVE Numbering Authority and a maintainer can request a CVE from within a draft repository security advisory. GitHub is an authorised CVE Numbering Authority for vulnerabilities disclosed through repository security advisories. From a draft advisory, a maintainer can request a CVE identifier, which GitHub assigns and then publishes together with the advisory and its GHSA identifier when the embargo lifts. The CVE is not minted automatically for every advisory on publication, and it does not depend on public issues or registry publisher status, so requesting it explicitly within the draft is the correct workflow.

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.

See more GH-500 practice questions, answers explained.

Exam traps in Security operations: best practices, prioritization, and remediation

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-500 bank for this domain.

Without a CVE the advisory is treated as a draft, so Dependabot records it but suppresses the alert until a CVE Numbering Authority assigns an identifier.
Why it is wrong: This is tempting because a CVE feels like the authoritative stamp, but GitHub-reviewed advisories drive alerts as soon as they are published with affected ranges; the alert is not held back waiting for a CVE.
Publishing the advisory triggers GitHub to push a security update pull request directly into every downstream repository that depends on the package.
Why it is wrong: This is tempting because remediation pull requests are a real feature, but GitHub does not push fixes into other people's repositories on publication; each downstream repository only gets a security update pull request if it has Dependabot security updates enabled for itself.
Dismiss the alert as a false positive, since malware advisories describe supply-chain reports rather than genuine vulnerabilities in the package's own code.
Why it is wrong: A malware classification is a deliberate, reviewed finding that the package is harmful, so it is not a false positive; dismissing it leaves a malicious dependency in the build.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.