There are no security loopholes, you say it doesn’t count, govulncheck is the referee!

Permalink to this article –

On September 7, 2022, the Go security team published an article “Vulnerability Management for Go” on the Go official blog, officially introducing Go’s tools and solutions to security vulnerability management to all Gophers.

In this post, the Go security team introduced a command line tool called govulncheck . This tool is essentially just a front end of the Go vulnerability database . It scans the Go source code or compiled Go application executable binary files in your repository through the vulncheck package under the vuln repository officially maintained by Go . Form the call graph and call stack of the source code.

The client package under the vuln repository provides an interface and default implementation for accessing vulnerability data sources (supporting multiple data sources). Developers can search for known vulnerabilities from the vulnerability database based on the path or ID of the module. The vulnerability items are stored and transmitted in OSV, Open Source Vulnerability format , and the vuln repository also provides an implementation package osv for the osv format.

Figure: Go Security Vulnerability Solution Architecture – from Go Official Blog

Note: You can also develop your own vulnerability check front-end based on the vulncheck package, client package, etc. under the vuln repository, or integrate it into your organization’s internal toolchain.

Like sumdb, proxy, etc., Go officially maintains a default vulnerability database As shown in the figure above, this database accepts data from well-known vulnerability data sources, such as: NVD , GHSA , etc. The Go security team found and Bugfixes and bugs submitted by the most maintainers of the go open source project.

If you are the maintainer of a well-known go open source project, after you find and fix the vulnerabilities of your project, you can find the submission/reporting entry for different types of vulnerabilities on the Go vulnerability management page , and the Go security team will report the public vulnerability information you report. Review and confirm.

Well, as Gophers, we are more concerned about whether there are security vulnerabilities in the Go project we are developing, either from the Go compiler or from a dependent, vulnerable third-party package. We have to learn to scan our projects using the govulncheck tool.

govulncheck is currently maintained under According to the official blog, the tool will be released together with the Go installation package later, but it is unknown whether it will be integrated into the go command. Now to use govulncheck, we have to install it manually with the following command:

 $go install[email protected]

After the installation is successful, you can execute the following command in the root directory of your Go project to perform a vulnerability check on the entire project:

 $govulncheck ./...

Here are the results of a scan of my own project (scanned with Go 1.18):

 $govulncheck ./... govulncheck is an experimental tool. Share feedback at Scanning for dependencies with known vulnerabilities... Found 9 known vulnerabilities. Vulnerability #1: GO-2022-0524 Calling Reader.Read on an archive containing a large number of concatenated 0-length compressed files can cause a panic due to stack exhaustion. Call stacks in your code: raft/fsm.go:193:29: calls io/ioutil.ReadAll, which eventually calls compress/gzip.Reader.Read Found in: compress/[email protected] Fixed in: compress/[email protected] More info: Vulnerability #2: GO-2022-0531 An attacker can correlate a resumed TLS session with a previous connection. Session tickets generated by crypto/tls do not contain a randomly generated ticket_age_add, which allows an attacker that can observe TLS handshakes to correlate successive connections by comparing ticket ages during session resumption. Call stacks in your code: raft/raft.go:68:35: calls, which eventually calls crypto/tls.Conn.Handshake Found in: crypto/[email protected] Fixed in: crypto/[email protected] More info: ... ... Vulnerability #6: GO-2021-0057 Due to improper bounds checking, maliciously crafted JSON objects can cause an out-of-bounds panic. If parsing user input, this may be used as a denial of service vector. Call stacks in your code: cmd/demo1/main.go:352:23: calls, which eventually calls Found in:[email protected] Fixed in:[email protected] More info: ... ... Vulnerability #9: GO-2022-0522 Calling Glob on a path which contains a large number of path separators can cause a panic due to stack exhaustion. Call stacks in your code: service/service.go:45:12: calls, which eventually calls path/filepath.Glob Found in: path/[email protected] Fixed in: path/[email protected] More info: === Informational === The vulnerabilities below are in packages that you import, but your code doesn't appear to call any vulnerable functions. You may not need to take any action. See for details. Vulnerability #1: GO-2022-0537 Decoding big.Float and big.Rat types can panic if the encoded message is too short, potentially allowing a denial of service. Found in: math/[email protected] Fixed in: math/[email protected] More info: ... ... Vulnerability #9: GO-2021-0052 Due to improper HTTP header santization, a malicious user can spoof their source IP address by setting the X-Forwarded-For header. This may allow a user to bypass IP based restrictions, or obfuscate their true source. Found in:[email protected] Fixed in:[email protected] More info:

We see that the information output by govulncheck is divided into two parts, one part is the security loopholes in the scanned project, you must fix these loopholes; the other part (separated by === Informational ===) is to list some Packages with security vulnerabilities that you directly import or depend on indirectly, but you do not directly call functions or methods in the vulnerable package, so no remedial action is required. In this way, we only need to focus on the first part of the information.

According to the host where the vulnerability is located, the information in the first part can also be divided into two categories: one is the vulnerability introduced by the Go language itself (including the Go compiler, Go runtime, and the Go standard library, etc.), and the other is third-party vulnerabilities. Vulnerabilities introduced by packages (both directly and indirectly dependent).

Our workarounds are different for these two types of vulnerabilities.

The solution to the first type of vulnerability is very simple, just upgrade the Go version directly . For example, here I upgrade my Go version from Go 1.18 to the latest Go 1.18.6 (just released on September 7, 2022) to eliminate the above All Type 1 vulnerabilities.

The second type of vulnerability, that is, the vulnerability introduced by third-party packages, requires careful consideration to eliminate it.

We also divide it into two cases:

  • There is a security vulnerability in the directly dependent package

If there is a security vulnerability in the code of the directly dependent package of the project, this situation is relatively simple. According to the fix prompt of govulncheck, you can directly upgrade (go get) to the corresponding version.

  • A security vulnerability exists in an indirect dependency package

Suppose our project depends on package A, and package A depends on package B, and govulncheck just scans that package B has a vulnerability, and the function/method of the vulnerability is called by our project through package A. How can we fix it?

Can we directly upgrade the version of package B? uncertain! This is related to the dependency management mechanism of go module. The premise of correct management of go module is that the versions of all packages truly conform to the semver (semantic version) specification . If the B package does not fully comply with the semver specification, once the B package version is upgraded alone, it is likely that the A package cannot use the upgraded B package and our project cannot be compiled. In this case, we should first consider upgrading the A package. If the A package is a basic library that we can control, such as common, we should first eliminate the loopholes of the A package (by the way, upgrade the version of the B package), Such vulnerability situations are then eliminated by upgrading the A package version.

If package A is not a package we can control, but a public open source package, then we must first check whether package A has released a new version that fixes the vulnerability of package B. If found, just upgrade package A to the new version. Solve the problem.

If package A does not fix the vulnerability of package B, then the problem is slightly more complicated. We can try to upgrade the B package to fix it. If it still cannot be repaired, then we can either submit a PR to the A package, or fork a copy of A, fix it ourselves and directly rely on the forked A.

If this indirect dependency chain is relatively long, it is indeed more tedious to fix such a vulnerability. You must be patient to upgrade the version of the dependency package layer by layer from the direct dependency package.

The launch of the govulncheck tool enriches our means of checking projects for security vulnerabilities. If your project is open source on github, you can also use github’s weekly security alert to get security vulnerability information (as shown in the following figure):

And github provides a very convenient one-click fix solution.

For private commercial projects within the company, no matter what tool you used to perform security scans on the software supply chain , now we have govulncheck, and it is recommended to use it to scan regularly.

“Gopher Tribe” Knowledge Planet aims to create a high-quality Go learning and advanced community! High-quality first published Go technical articles, “three-day” first published reading rights, analysis of the current situation of Go language development twice a year, reading the fresh Gopher daily 1 hour in advance every day, online courses, technical columns, book content preview, must answer within 6 hours Guaranteed to meet all your needs about the Go language ecosystem! In 2022, the Gopher tribe will be fully revised, and will continue to share knowledge, skills and practices in the Go language and Go application fields, and add many forms of interaction. Everyone is welcome to join!





I love texting : Enterprise-level SMS platform customization development expert smspush : A customized SMS platform that can be deployed within the enterprise, with three-network coverage, not afraid of large concurrent access, and can be customized and expanded; the content of the SMS is determined by you, no longer bound, with rich interfaces, long SMS support, and optional signature. On April 8, 2020, China’s three major telecom operators jointly released the “5G Message White Paper”, and the 51 SMS platform will also be newly upgraded to the “51 Commercial Message Platform” to fully support 5G RCS messages.

The famous cloud hosting service provider DigitalOcean released the latest hosting plan. The entry-level Droplet configuration is upgraded to: 1 core CPU, 1G memory, 25G high-speed SSD, and the price is 5$/month. Friends who need to use DigitalOcean can open this link : to open your DO host road.

Gopher Daily Archive Repository –

my contact information:

  • Weibo:
  • Blog:
  • github:

Business cooperation methods: writing, publishing books, training, online courses, partnership entrepreneurship, consulting, advertising cooperation.

© 2022, bigwhite . All rights reserved.

This article is reprinted from
This site is for inclusion only, and the copyright belongs to the original author.

Leave a Comment