A Go advisory can say the vulnerable symbols appear only on certain operating systems or architectures. A scanner that matches only module name and version ignores those fields, so a Linux service can be flagged for a Windows-only flaw. Check the advisory's goos and goarch values before you act or dismiss.
What the Go database records
The Go vulnerability database format has an ecosystem specific section for each affected module. Its imports list names the package path and the symbols, meaning functions or methods, that contain the flaw. Two more optional fields sit beside them:
| Field | Meaning, per the Go database documentation |
|---|---|
| goos | The execution operating system where the symbols appear, if known |
| goarch | The architecture where the symbols appear, if known |
The words "if known" matter. When the fields are empty, the entry does not claim the flaw is limited to one platform. When they are filled in, the database is telling you the vulnerable code only appears on those targets.
Why this produces odd-looking findings
Go compiles per target. The same module can include different files for Windows and Linux, chosen at build time. A flaw in a Windows-only file is simply not in your Linux binary.
A tool that looks at your go.mod file sees the module and its version, finds an advisory, and reports it. It never asks which platform you build for. A tool that reads the symbol data does ask. The govulncheck documentation says that different build configurations may have different known vulnerabilities, and that for source analysis the configuration is the Go version found on the PATH, while for binaries it is the one used to build the binary.
A four step check
- Open the advisory and find the affected imports section.
- Read the goos and goarch values. If both are empty, treat the finding as applying everywhere.
- List the targets you actually ship, for example Linux on amd64 and arm64.
- Compare. If none of your targets is in the list, the finding does not apply to your build today.
Then write the reason down. "Advisory lists Windows only, we ship Linux only, checked on this date" is a useful note. It also needs a re-check trigger, because adding a new target later changes the answer.
Do not dismiss on a hunch
Platform limits are specific and checkable, which makes them a sound reason to lower priority. A guess is not. Three things can quietly invalidate a dismissal:
- A new build target, such as a Windows build of a tool that was Linux only.
- Developer machines that run the same code, even if production does not.
- An advisory update that widens the platform list.
Keep the note next to the finding, and review it when your build matrix changes. For how to record a dismissal so others can audit it, see the dismissal comment post.
Quick check
Does an empty goos field mean the flaw is on every OS?
It means the database does not limit it to specific systems. Treat the finding as applying to all of your targets unless the advisory text says otherwise.
Is a version-only scanner wrong to report this?
It is reporting what it can see, which is the module and version. It cannot tell you the finding is inapplicable, so you have to check the platform fields yourself.
Where do I read these fields?
In the Go vulnerability database entry for the advisory, under the affected module's ecosystem specific imports.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
Last reviewed: 19 October 2026.
