feat: add more detail for go std lib reporting on container scans

[jcambier]

Adds some extra detail in anticipation of releasing go std library vuln reporting feature for container (https://snyksec.atlassian.net/browse/CN-872).

This should be able to answer any questions that come up from customers.

---

Note

Low Risk
Documentation-only change with no product or code impact.

Overview
Documentation update in application-vulnerabilities-in-snyk-container-and-snyk-open-source ahead of Go standard library vulnerability reporting on container scans.

The existing golang bullet now links to a new Go standard library vulnerabilities section. That section explains that Snyk Container reports stdlib issues from the Go toolchain version embedded in the binary, without reachability analysis, and that customers may see more findings on existing Projects. It points readers to remediate (rebuild with a fixed toolchain) or reduce noise (ignore issues when not relevant).

^{Reviewed by Cursor Bugbot for commit 7b23c6d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[pecodez]

LGTM

[mihaisau-snyk]

Proposed: "Snyk derives the Go version from the toolchain version compiled into the binary." (active voice)

[mihaisau-snyk]

Proposed: "Snyk does not perform reachability analysis for Go standard library vulnerabilities." (drop "currently")

[mihaisau-snyk]

Proposed: "regardless of which libraries your application's code imports or calls." (adding "your application's code" to make it a bit clearer)

[mihaisau-snyk]

Proposed: "Snyk Container has not always reported these vulnerabilities, so expect an increase in vulnerabilities on your existing Projects." (use "vulnerabilities" consistently instead of "issues"; drop hedging "may")

[mihaisau-snyk]

Proposed: "To address this, you can:" ("either" + colon-introduced list reads awkwardly)

[mihaisau-snyk]

Thanks for addressing the style/clarity feedback — this looks good to me.

[cursor]

Staff tech writer review

The factual explanation of Go standard library detection via toolchain metadata is accurate and clear. I verified the cross-link targets and confirmed the ignore documentation path resolves.

Requesting changes on style and terminology rules, left as one-click suggestions:

Style fixes (folded into the suggestions)

Snyk product name singular ("Snyk Container", not "Snyk Containers") · unbold list lead-in labels (bold is for UI elements and status values only) · avoid modal "may" · "Visit" instead of "see".

  

_{Sent by Cursor Automation: PR review for User Docs}

[cursor]

Use singular product name "Snyk Container" and "visit" instead of "see". (Snyk terminology: product names are singular; "visit" not "see")

Suggested change

* `golang` Projects for Snyk Containers: Snyk does not have access to the list of dependencies as in Snyk Open Source. Therefore, Snyk Container reverse parses binaries, and the result differs slightly from Snyk Open Source. Snyk Container also reports vulnerabilities in the Go standard library, identified from the Go version recorded in the binary (see [Go standard library vulnerabilities](#go-standard-library-vulnerabilities)).

* `golang` Projects for Snyk Container: Snyk does not have access to the list of dependencies as in Snyk Open Source. Therefore, Snyk Container reverse parses binaries, and the result differs slightly from Snyk Open Source. Snyk Container also reports vulnerabilities in the Go standard library, identified from the Go version recorded in the binary (visit [Go standard library vulnerabilities](#go-standard-library-vulnerabilities)).

[cursor]

Avoid modal "may" and unbold list lead-in labels. (Snyk style: bold is reserved for UI elements and status values; avoid ambiguous modal "may")

Suggested change

	Expect to see vulnerabilities from Go standard library packages on your container Projects. These are valid, although not all of them may be reachable by your application's code. Snyk Container has not always reported these vulnerabilities, so expect to see an increase in vulnerabilities on your existing Projects. To address this, you can:
	* **Remediate:** Rebuild the binary with a Go toolchain version that fixes the reported vulnerabilities.
	* **Reduce noise:** [Ignore a reported standard library vulnerability](../../../manage-risk/prioritize-issues-for-fixing/ignore-issues/README.md) if you determine it is not relevant to your application.
	Expect to see vulnerabilities from Go standard library packages on your container Projects. These are valid, although not all of them are reachable by your application's code. Snyk Container has not always reported these vulnerabilities, so expect to see an increase in vulnerabilities on your existing Projects. To address this, you can:
	* Remediate: Rebuild the binary with a Go toolchain version that fixes the reported vulnerabilities.
	* Reduce noise: [Ignore a reported standard library vulnerability](../../../manage-risk/prioritize-issues-for-fixing/ignore-issues/README.md) if you determine it is not relevant to your application.

[cursor]

The current head commit 7b23c6d is reviewed.

  

_{Sent by Cursor Automation: PR review for User Docs}