Trivy flags 9 Go CVEs in the sf binary — is this expected?

[abarbosa-ssg]

Hello,

We scan our Docker image with Trivy and it reports 9 HIGH vulnerabilities attributed to /usr/local/bin/sf (where we store the binary).
Trivy reads the Go build metadata embedded in the binary (gobinary parser) and matches the module versions listed there against the Go vulnerability database:

Library	Vulnerability	Severity	Status	Installed	Fixed in
golang.org/x/image	CVE-2026-46603	HIGH	fixed	v0.44.0	v0.45.0
stdlib (go v1.26.5)	CVE-2026-33818	HIGH	fixed	v1.26.5	1.25.13 / 1.26.6 / 1.27.0-rc.3
stdlib (go v1.26.5)	CVE-2026-39821	HIGH	fixed	v1.26.5	1.25.13 / 1.26.6 / 1.27.0-rc.3
stdlib (go v1.26.5)	CVE-2026-46600	HIGH	fixed	v1.26.5	1.26.6 / 1.27.0-rc.3
stdlib (go v1.26.5)	CVE-2026-56853	HIGH	fixed	v1.26.5	1.25.13 / 1.26.6 / 1.27.0-rc.3
stdlib (go v1.26.5)	CVE-2026-56858	HIGH	fixed	v1.26.5	1.25.13 / 1.26.6 / 1.27.0-rc.3
stdlib (go v1.26.5)	CVE-2026-56859	HIGH	fixed	v1.26.5	1.25.13 / 1.26.6 / 1.27.0-rc.3
stdlib (go v1.26.5)	CVE-2026-56860	HIGH	fixed	v1.26.5	1.25.13 / 1.26.6 / 1.27.0-rc.3
stdlib (go v1.26.5)	CVE-2026-56862	HIGH	fixed	v1.26.5	1.25.13 / 1.26.6 / 1.27.0-rc.3

Advisories (Avd.aquasec.com): CVE-2026-46603, CVE-2026-33818, CVE-2026-39821, CVE-2026-46600, CVE-2026-56853, CVE-2026-56858, CVE-2026-56859, CVE-2026-56860, CVE-2026-56862.

We thought the new version would fix those but they don't.
Is this detection expected/correct? Since the sf binary is built with go v1.26.5 and statically embeds its dependency list, Trivy reports any CVE affecting those toolchain/library versions even if the affected code path (net/http, html/template, encoding/xml, crypto/tls, …) is likely never exercised by sf.
We assume Trivy's Go analysis is purely version-based with no call-graph analysis.
Is a sf release rebuilt against a patched Go toolchain planned? Since all stdlib findings would disappear with Go ≥ 1.26.6 (or 1.25.13 on the 1.25 line), and the golang.org/x/image one with x/image ≥ 0.45.0.
If not, is there an accepted way to handle these findings — e.g. a documented policy that these are non-exploitable in a file-identification CLI, or a signature/checksum list of known-good sf builds we should rely on instead?

For context: sf runs as a short-lived CLI in our pipeline (reads local files, no network listeners), so the practical exposure of these CVEs looks low — we mainly need to know whether we can safely document this as accepted risk or should wait for a patched release.

Thanks !

[richardlehane]

Hi @abarbosa-ssg thanks for raising this discussion. No problem for me to do another point release tonight with an update mod file to address these.
I don't run Trivy myself & typically will only be aware of CVEs when I get Github dependabot alerts. Happy in future to receive issues/discussions to bring my attention to any further CVEs you encounter

[abarbosa-ssg]

That would be perfect, thank you ! I'll raise them when I have new ones.

[richardlehane]

new release is available now, let me know if any issues

[abarbosa-ssg]

It's green now, thanks !