What is Go's vulnerability database at vuln.go.dev, and what does a GO-2024-1234 entry add over a CVE record?

## The database Go keeps its own vulnerability database, served at `https://vuln.go.dev` and rendered for humans at `pkg.go.dev/vuln`. It is curated by the Go security team rather than scraped, and it is deliberately scoped to the Go ecosystem: modules identified by module path, plus the Go standard library and toolchain. Every record has an identifier shaped `GO-YYYY-NNNN` - the year it was published and a sequence number, for example `GO-2024-1234`. Records are served in the OSV JSON schema (the same interchange format used by other open-source advisory databases) with Go-specific extensions. ## Where entries come from Three streams feed it: 1. **Public advisory feeds** - CVE records and GitHub security advisories that name a Go module. 2. **Direct reports** - maintainers of Go modules, and reporters using the Go project's security reporting process, can get an entry created without a CVE ever existing. 3. **The Go project itself** - every security fix in a Go release produces an entry against the standard library or the toolchain. The practical consequence of stream 2 is that **a CVE-only workflow has blind spots in Go**: there are `GO-` entries with no CVE alias at all. ## What a single entry carries - **Affected module path** - `example.com/lib`, or the pseudo-module `stdlib` for standard-library issues, or `toolchain` for issues in the programs shipped with a Go release such as the `go` command. - **Version ranges** - which versions introduced the problem and which version fixed it, expressed as Go module versions, so it lines up directly with what your `go.mod` requires. - **Affected packages** - a module can hold many packages, and usually only one is affected. - **Affected symbols** - within each package, the exported functions, methods and types whose methods carry the vulnerability. This is the field that has no counterpart in a CVE record. - **Summary, details and references** - prose, plus links to the fix commit or issue. - **Aliases** - the `CVE-...` and `GHSA-...` ids for the same issue, when they exist. ## Why the symbol list matters A classic manifest scanner answers one question: *is a version I depend on in the affected range?* That question is cheap and it over-reports badly, because a large module can have one vulnerable parser and fifty innocent packages, and you may import none of the fifty-one directly. Because Go entries name symbols, tooling can answer a much sharper question: *does any path through my program reach one of those functions?* That is the whole basis of Go's reachability analysis, and it is why a Go-native scan of a service typically produces a handful of findings where a manifest scan produces dozens. ## GO ids versus CVE ids Think of the GO id as the primary key for Go and the CVE id as one alias among several. Two rules of thumb: - **Every direction works through aliases.** If someone hands you `CVE-2024-XXXXX` and asks whether your service is affected, look it up by alias and you land on the GO entry, which tells you the module and the symbols. - **Do not assume a CVE exists.** Filtering your process on "has a CVE" quietly drops real Go advisories. ## What the entry does not decide for you The entry states facts: affected module, versions, symbols, fix. It does not tell you how urgent this is in your environment, whether the vulnerable path is exposed to untrusted input, or what your team's deadline for fixing it should be. Those are judgment calls layered on top of the record, and the record is only the input to them. ## Standard library coverage The `stdlib` pseudo-module is worth internalising early, because it behaves differently from every other row in a report. There is no dependency to upgrade - the affected "versions" are Go releases, and the fixed version is a Go release. You resolve those entries by building with a newer toolchain, not by touching `go.mod`'s require list.