Detecting, Reporting and Mitigating Vulnerabilities for Go Modules

UPDATE: As of May 1, 2021 – GoCenter central repository has been sunset and all features will be deprecated. For more information on the sunsetting of the centers read the deprecation blog post

Go Module vulnerabilities frustrate the lives of many Go developers and can turn a simple project into a battle of endurance between the dev and their patience. With the process of CI/CD shifting left more and more, it’s becoming even more pertinent for developers to be able to track and report vulnerabilities as early as possible. JFrog GoCenter can help track and mitigate vulnerabilities and make the lives of Go developers easier.

Reporting Vulnerabilities 

Vulnerabilities are monitored consistently throughout the development lifecycle of any system application and should be reported by anyone who finds the issue so that it’s remediation can be tracked and shared among common organizations. Known vulnerabilities are tracked and classified using the Common Vulnerability and Exposures (CVE) – a list of publicly disclosed information security vulnerabilities and exposures. Each CVE contains a standard identifier number (CVE ID), a status indicator, a brief description of the vulnerability and references related to vulnerability reports and advisories. 

CVE isn’t a vulnerability database – instead, CVE is designed to allow vulnerability databases and other tools to be linked together and facilitates comparisons between security tools and services. The National Vulnerability Database (NVD) is a free, public database that uses the CVE list identifiers and includes fix information, scoring and other pertinent information for each vulnerability.

Detected vulnerabilities must be reported to one of the CVE Numbering Authorities (CNA) accompanied by detailed documentation explaining the impact of the vulnerability and at least one codebase that it affects before it can be recognized as a common vulnerability and assigned a CVE ID. For reference, the format for the CVE ID = CVE prefix + Year + Arbitrary Digits. Below is an example of a CVE ID entry:

The Data Complexity of Securing Go Modules

Securing Go modules can be a tricky task, specifically because of the relationship between Go modules and Go packages. Once the security data for a Go module is received, it’s difficult to correlate that data to a specific module version. This is because security vulnerabilities exist on the package level but are reported on the module level. This can leave the impression that the entire module is vulnerable, but that’s often not the case. More than likely, your module will remain secure unless you consume the vulnerable package data. 

Let’s use CVE-2020-10660 as an example. Below is an excerpt from the version 1.3.4 changelog detailing the effects of this vulnerability: 

gopkg.in/hashicorp/vault.v0 and github.com/hashicorp/vault, have both been affected by CVE-2020-10660 in HashiCorp Vault and Vault Enterprise versions 0.9.0 through 1.3.3. While using these packages they may, under certain circumstances, have an entity’s group membership inadvertently include groups that the entity no longer has permissions to. 

Another vulnerability was identified in Vault Enterprise such that, under certain circumstances, existing nested-path policies may give access to namespaces created after-the-fact. Luckily, there was a change made to fix these vulnerabilities in version 1.3.4.

Looking above, the fix was made within github.com/hashicorp/vault. The module istio.io/istio has a dependency on github.com/hashicorp/vault in its go.mod file. Normally, you would assume that the security of istio.io/istio would be compromised, but it’s only using github.com/hashicorp/vault/api package, so its code is not affected by the vulnerability. See the source code below.

Mitigating your Software Vulnerabilities

Now that you understand the process of how Go Module vulnerabilities are reported and some details around the security complexities, let’s see how to mitigate these threats in future development.

To start, let’s look at the github/hashicorp/vault Go module in GoCenter.

Using CVE data, JFrog Xray is able to scan all the dependencies in a go.mod file held by GoCenter and identify every vulnerability. GoCenter exposes this Xray data on the Dependencies tab to provide you detailed information about vulnerable components at every level of your dependency tree. You’ll see a warning triangle next to each vulnerable module. You can then click on the vulnerable module and be routed to that page. From there, view the Versions tab to look for a secure version of that module so that you can upgrade that in your go.mod file.

Once all components and dependencies have been identified, their information is cross-referenced with other vulnerability feeds and databases to alert you of any potential threats. Basic Xray vulnerability scanning for Go modules is available for free on  GoCenter, shown in the Security tab:

Keeping your Software Secure with GoCenter

GoCenter is a public GOPROXY and central repository with over 700,000 Go module versions. When using GoCenter as your GOPROXY, you can be sure that the version of code downloaded is the correct version from the correct source code. GoCenter as your GOPROXY works seamlessly with Go commands and has the advantage of being secure, fast, available and storage efficient. 

Many Golang developers can also bring GoCenter’s vulnerability information directly into their IDE, using the free JFrog extension for VS Code.

With the CI/CD cycle shifted to the left more and more, GoCenter’s security features can help you identify whether or not there are vulnerable dependencies in the public Go module versions you are importing.