This document explains how we handle vulnerability issue triage in the x/vulndb issue tracker.
All vulnerabilities in the Go vulnerability database are currently stored as a YAML file in the reports/ directory.
Each vulnerability is given an ID with the format GO-YYYY-NNNN.
For a detailed explanation of the report format, see doc/format.md.
Any issue must be in one of the following states. Maintainers of the Go vulndb move issues from one state to another. The intent behind these explicit states is to describe the (minimum) next steps required to bring the issue to resolution.
Issues are intended to move between these states:
+-------------+ | | via CL +------------>| NeedsReport +----------+ | | | | | +-------------+ | +---------+--------+ v | | Closed New ---->|NeedsInvestigation| | (optional) | +------------+ ^ +----------+-------+ | | | | | NotGoVuln +-----------+ +----------->| | +------------+
The issue has been filed by the vulndb worker
The issue will have the title:
x/vulndb: potential Go vuln in <module/package>: <CVE ID>
To transition from this state, someone must:
NotGoVulnlabel should be applied at the time the issue is closed for tracking purposes (such as data on how to improve the automatic triager).
If an issue is labeled with
NeedsReport and is not assigned to anyone, you can add a new report to the database by following these steps:
git clone https://go.googlesource.com/vulndb
go run ./cmd/vulnreport create <GitHub issue number>. (Note: You will need a GitHub access token).
x/vulndb: add <GO Vuln ID> for <CVE ID> <description> Fixes golang/vulndb#<GitHub Issue #>
vulnreport will download the github.com/CVEProject/cvelist repository and create a YAML report template for the CVE at the specified GitHub issue number.
Occasionally, we will receive new information about a Go vulnerability and want to update the existing report.
In that case, reopen the issue for the report to discuss the change, rather than create a new issue.