GH-500 · Domain 5: Security operations: best practices, prioritization, and remediation · 18% of the exam
Task 5.1: Understand vulnerability context and remediation frameworks
CVEs, CWEs and GitHub security advisories, private vulnerability reporting, and following a vulnerability from report to fix.
Study it
CVE, CWE, security advisories and private vulnerability reporting
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the GitHub documentation page that proves it.
Question 1 · choose 1
A maintainer of a popular npm package has a draft repository security advisory for a vulnerability. The patch will be released in two days, and nothing suggests the flaw is being exploited. What should the maintainer do about publication?
APublish now without a patched version, and edit the advisory once the fix ships
BWait the two days, add the fixed version to the advisory, then publish it
CPublish now and mark the advisory as withdrawn until the fix is released
DSkip the advisory and mention the fix in the release notes only
Show the answer and why
APublish now without a patched version, and edit the advisory once the fix ships
Incorrect
Dependabot would alert users with no safe version to update to.
BWait the two days, add the fixed version to the advisory, then publish it
Correct
When a fix is imminent, disclose with the fix version so alerts offer a safe upgrade.
CPublish now and mark the advisory as withdrawn until the fix is released
Incorrect
Withdrawing an advisory isn't a way to delay its alerts.
DSkip the advisory and mention the fix in the release notes only
Incorrect
Without an advisory, users' Dependabot alerts won't learn about the vulnerability.
Whenever possible, add a fix version to a security advisory before publishing it; otherwise it is published without one and Dependabot alerts users without offering a safe version. If the fix is imminent, wait and disclose with the fix; if it is still in development, say so and edit later; if no fix is planned, say that and include mitigations.
Can GitHub assign a CVE identifier for a vulnerability in a public repository?
AOnly after the advisory has been public for 30 days
BNo; only MITRE assigns CVEs
COnly for repositories owned by GitHub
DYes; GitHub is a CVE Numbering Authority
Show the answer and why
AOnly after the advisory has been public for 30 days
Incorrect
CVEs are requested while drafting.
BNo; only MITRE assigns CVEs
Incorrect
CNAs such as GitHub assign them.
COnly for repositories owned by GitHub
Incorrect
Any eligible public repository can request one.
DYes; GitHub is a CVE Numbering Authority
Correct
GitHub can assign CVE identification numbers.
GitHub is a CVE Numbering Authority (CNA) and is authorized to assign CVE identification numbers. Anyone with admin permissions on a security advisory can request a CVE for it.
What do repository security advisories let maintainers of a public repository do before disclosure?
ADiscuss and fix it privately in a temporary private fork
BHide the repository from search
CDelete the vulnerable commits from the repository's history
DBlock all pushes to the repository
Show the answer and why
ADiscuss and fix it privately in a temporary private fork
Correct
Advisories support private discussion and private forks.
BHide the repository from search
Incorrect
Advisories don't change visibility.
CDelete the vulnerable commits from the repository's history
Incorrect
Advisories don't rewrite history.
DBlock all pushes to the repository
Incorrect
Advisories don't block pushes.
With repository security advisories, maintainers create a draft advisory to discuss the impact privately, collaborate on a fix in a temporary private fork, and publish the advisory once a patch is released.
Who can enable private vulnerability reporting for a public repository?
AAny contributor
BOwners and administrators of the repository
COnly GitHub staff
DOnly security researchers
Show the answer and why
AAny contributor
Incorrect
Only owners and admins can.
BOwners and administrators of the repository
Correct
They can enable the feature.
COnly GitHub staff
Incorrect
Repository owners and admins can.
DOnly security researchers
Incorrect
Researchers use the feature; they don't enable it.
Owners and administrators of public repositories can enable private vulnerability reporting, so that researchers can report vulnerabilities securely in the repository with the Report a vulnerability button.
A repository has a SECURITY.md file. Does that turn on private vulnerability reporting?
AYes, automatically
BYes, once the file names a security contact email address
CNo; it is enabled separately
DNo, because SECURITY.md disables it
Show the answer and why
AYes, automatically
Incorrect
The two are separate.
BYes, once the file names a security contact email address
Incorrect
The file doesn't enable the feature.
CNo; it is enabled separately
Correct
Private reporting is separate from SECURITY.md.
DNo, because SECURITY.md disables it
Incorrect
It doesn't disable anything.
Private vulnerability reporting is separate from a repository's SECURITY.md file; you can only report privately where the feature is enabled. If the repository has a security policy, it is displayed above the reporting form.