_content/doc/security/vuln: add section on non-Go versions
Add a section explaining how our tooling handles versions
that are not recognized by the Go module proxy.
diff --git a/_content/doc/security/vuln/database.md b/_content/doc/security/vuln/database.md
index 6b0767f..64d7558 100644
--- a/_content/doc/security/vuln/database.md
+++ b/_content/doc/security/vuln/database.md
@@ -211,6 +211,26 @@
For information on other fields in the schema, refer to the [OSV spec](https://ossf.github.io/osv-schema).
+## Note on Versions
+
+Our tooling attempts to automatically map modules and versions in
+ource advisories to canonical Go modules and versions, in accordance with
+standard [Go module version numbering](https://go.dev/doc/modules/version-numbers).
+Tools like `govulncheck` only work correctly with standard Go module versions.
+
+In some cases, such as when a Go project uses its own versioning system,
+this mapping can fail.
+
+If the mapping fails, the Go vulnerability database report may conservatively
+list all versions as affected. This is to avoid the false-negatives that
+would occur if we published unrecognized version ranges. (These unrecognized
+versions are still listed in the text description of the report for informational
+purposes.)
+
+If you notice false-positives in `govulncheck` due to this issue, please
+[suggest an edit](https://github.com/golang/vulndb/issues/new?assignees=&labels=Needs+Triage%2CSuggested+Edit&template=suggest_edit.yaml&title=x%2Fvulndb%3A+suggestion+regarding+GO-2024-2965&report=GO-XXXX-YYYY) to the vulnerability report and we
+will review it.
+
## Examples
All vulnerabilities in the Go vulnerability database use the OSV schema
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. | Gerrit |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. | Gerrit |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. | Gerrit |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. | Gerrit |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. | Gerrit |
source advisories to canonical Go modules and versions, in accordance with
standard [Go module version numbering](/doc/modules/version-numbers).
Maybe shorten 'Go module version numbers'.
Tools like `govulncheck` only work correctly with standard Go module versions.
'only work correctly' is a bit strong.
How about 'are designed to work with'?
Tools like `govulncheck` only work correctly with standard Go module versions.
Maybe say a bit of how it is used 'to decide when a module contains a vulnerability or if it does not as it has been fixed'. (That is not a great sentence though. Please edit.)
In some cases, such as when a Go project uses its own versioning system,
uber-nit: 'scheme'
list all versions as affected. This is to avoid the false-negatives that
Suggestion: 'This ensures that tools do not fail to report vulnerabilities due to unrecognized version ranges (e.g. false-negatives). Conservatively listing all versions as affected may cause tools to report a fixed version of a module as containing the vulnerability incorrectly (e.g. a false-positive).'
list all versions as affected. This is to avoid the false-negatives that
'all Go versions as affected'
would occur if we published unrecognized version ranges. (These unrecognized
versions are still listed in the text description of the report for informational
purposes.)
I wouldn't promise this. Maybe drop this sentence?
If you notice false-positives in `govulncheck` due to this issue, please
Any FP is enough of a reason to report. Suggestion: 'If you believe that `govulncheck` is incorrectly reporting an issue, please ...'.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. | Gerrit |