Contributing to the Go Vulnerability Database: A Practical Guide Published on 16 Jan 2025 by Vinu K

Security vulnerabilities in software dependencies are inevitable. What matters is how quickly and accurately they’re tracked. The Go Vulnerability Database powers tools like govulncheck, helping developers identify vulnerable code in their projects. Recently, I contributed CL734660 to add missing symbols to vulnerability report GO-2025-4188. This post walks through what the Go Vulnerability Database is, why contributions matter, and how you can make your own.

What is the Go Vulnerability Database?

The Go Vulnerability Database is Go’s authoritative source for security vulnerabilities affecting Go modules, packages, and the standard library. Maintained by the Go Security team, it uses the Open Source Vulnerability (OSV) schema—a standardized format that enables interoperability with other security tools across the ecosystem.

Each vulnerability entry includes:

This data powers govulncheck, which scans your code and dependencies to identify whether you’re actually calling vulnerable functions—not just importing a vulnerable module.

Why Accurate Vulnerability Data Matters

Inaccurate vulnerability reports create two problems:

False Positives: A report with overly broad version ranges or missing symbol information flags code that isn’t actually vulnerable. Developers waste time investigating non-issues, and over time, they start ignoring alerts entirely.

False Negatives: A report with incorrect “fixed” versions or missing affected packages fails to warn developers who are using vulnerable code. The vulnerability goes undetected.

For leadership, this translates directly to:

• Developer productivity: Fewer false alarms means engineers spend time on real issues
• Security posture: Accurate data means genuine vulnerabilities get addressed
• Compliance confidence: Auditors trust well-maintained, precise vulnerability records

The Contribution: Adding Symbols to GO-2025-4188

In CL734660, I updated the vulnerability report for GO-2025-4188 by adding missing symbol information.

The Problem

The existing report lacked specific symbol data—it identified the vulnerable module and version range but didn’t specify which functions or methods were actually vulnerable. Without this information, govulncheck would flag any import of the module, even if the vulnerable code paths were never called.

Before: Entry without symbol information

The Solution

I updated the report to include the symbols field under ecosystem_specific.imports, explicitly listing the vulnerable functions. This allows govulncheck to perform call graph analysis—only alerting developers if their code actually invokes the vulnerable symbols.

After: Entry with symbols added

The Impact

After this change:

• Precision improved: Developers using the module but not the vulnerable functions no longer receive false alerts
• Trust increased: The report accurately reflects the actual risk surface
• Tooling benefited: govulncheck can now provide actionable, accurate guidance

How to Contribute: Step-by-Step

If you discover missing or inaccurate information in a vulnerability report, here’s how to contribute a fix.

1. Open an Issue

Before making any changes, open an issue to track your contribution:

1. Go to github.com/golang/vulndb/issues/new/choose
2. Select “Suggest an edit to an existing report”
3. Fill in the details: the GO-ID you’re updating, what’s incorrect, and what you propose to fix
4. Submit the issue and note the issue number — you’ll need this for your commit message

This creates a paper trail and allows maintainers to discuss the proposed changes before you submit code.

2. Set Up the Environment

Clone the vulndb repository and install the tooling:

git clone https://go.googlesource.com/vulndb
cd vulndb
go install ./cmd/vulnreport

3. Find the Report to Update

Vulnerability reports live in the data/reports/ directory as YAML files. You can also search vuln.go.dev by GO-ID, CVE, or module path to find the relevant entry.

4. Make Your Changes

Open the YAML file and update the necessary fields. Common updates include:

Adding missing symbols:

affected:
  - package:
      name: github.com/example/module
      ecosystem: Go
    ranges:
      - type: SEMVER
        events:
          - introduced: "0"
          - fixed: "1.2.3"
    ecosystem_specific:
      imports:
        - path: github.com/example/module/vulnerable
          symbols:
            - VulnerableFunction
            - AnotherRiskyMethod

Correcting version ranges:

ranges:
  - type: SEMVER
    events:
      - introduced: "1.0.0"
      - fixed: "1.2.4"  # Updated from incorrect 1.2.3

Adding aliases:

aliases:
  - CVE-2025-XXXXX
  - GHSA-xxxx-xxxx-xxxx

5. Validate Your Changes

Run the vulnreport tool to check for issues. The number 4188 comes from the GO-ID identifier GO-2025-4188:

$ vulnreport fix 4188
info: fix: operating on 1 report(s)
info: fix data/reports/GO-2025-4188.yaml
info: GO-2025-4188: checking that all packages exist
info: GO-2025-4188: checking symbols (use -skip-symbols to skip this)
info: GO-2025-4188: checking for missing GHSAs and CVEs (use -skip-alias to skip this)
info: GO-2025-4188: checking that all references are reachable
info: fix: processed 1 report(s) (success=1; skip=0; error=0)

This validates the YAML structure, checks for common errors, and ensures compliance with the OSV schema.

6. Submit for Review

Create a commit with a clear message that references the issue you opened in Step 1:

git commit -m "data/reports: add symbols for GO-2025-4188

Updates the affected symbols list to enable precise
call graph analysis in govulncheck.

Fixes golang/vulndb#XXXX"

Important: Replace #XXXX with the actual issue number from Step 1. This links your commit to the issue and automatically closes it when merged.

Submit your change via Gerrit (Go’s code review system) or open a pull request on the GitHub mirror.

Tip: Notify the original contributor

After opening your PR on GitHub, use GitHub blame on the report file to find the original author. The commit message will show the contributor’s username and the Change List number (e.g., CL734660). Add a comment to your PR tagging them:

@<contributor>, fyi as you own CL<XXXXXX>

This gives the original contributor visibility into updates to their work and can speed up the review process since they have context on the vulnerability.

7. Address Review Feedback

The Go Security team will review your change, checking:

• Version range accuracy against upstream fix commits
• Symbol correctness (are these actually the vulnerable entry points?)
• Reference completeness (links to advisories, fixes, announcements)
• Schema compliance

Be prepared to iterate based on feedback.

What Happens After Merge

Once your change is approved and merged:

1. Database Update: The YAML is processed into JSON/OSV format and published to vuln.go.dev

2. Tool Propagation: govulncheck fetches the updated database on its next run, incorporating your corrections

3. Developer Impact: Users scanning their projects now receive accurate, actionable vulnerability information

The turnaround is typically quick—changes are reflected in the live database within the normal update cycle.

Best Practices for Contributors

Reopen, don’t duplicate: If updating an existing report, work within the original issue thread rather than creating a new one. This maintains context and avoids fragmentation.

Be precise with versions: Use exact semantic versions. The difference between fixed: "1.2.3" and fixed: "1.2.4" could mean the difference between a real vulnerability and a false alarm.

Include all aliases: Add CVE and GHSA identifiers so the vulnerability is discoverable regardless of which identifier someone searches for.

Link your references: Include URLs to the original advisory, the fix commit, and any relevant issue discussions. This helps reviewers verify your changes and helps future readers understand the context.

Test with govulncheck: Before submitting, verify that your changes produce the expected behavior. Create a test project that imports the vulnerable symbols and confirm govulncheck correctly identifies (or doesn’t identify) the issue.

For Leadership: Why This Matters

Maintaining accurate vulnerability data isn’t just a technical exercise—it’s risk management:

When your organization consumes Go modules, you inherit their vulnerabilities. Accurate database entries ensure you know exactly what you’re inheriting—and what you need to fix.

References

• Go Vulnerability Database — Official vulnerability database and API
• Database Documentation — Schema details and contribution guidelines
• golang/vulndb Repository — Source repository for vulnerability reports
• govulncheck — The official vulnerability scanning tool
• OSV Schema Specification — The standard vulnerability format
• CL734660 — My contribution adding symbols to GO-2025-4188