Go Modules Security

Google's Go programming language is all in boom and rocketing in its popularity in the mainstream software development field. Since Golang is a relatively new language, it does not have a long history of vulnerabilities like other programming languages such as Java or even C. But Golang is a growing language and is being explored by many; it has more or less grown in popularity these days. With more code being written in Go, more vulnerabilities will be introduced. These vulnerabilities create a headache while working on Go projects, and require us to better know about and understand security aspects in Go and Go modules. 

The Power of Go Modules

The concept of Go modules was introduced in Go 1.11. A Go module is essentially a collection of Go packages stored in a file tree with a go.mod file at its root. With Go 1.13, Go modules became the official standard for Golang. The two modules essential files are, first, the go.mod file that defines the module path, and second the go.sum file. The go.mod file includes the list of dependencies and imports, and the go.sum file includes basic security considerations. These two files are created by default when you build a Go project. 

The go.sum file has a list of hashes, used as checksums. A checksum is a way to provide authentication that a block of digital data hasn't changed while it's being transmitted or stored. On their own, checksums are used to verify data integrity, but they are not necessarily there to verify that the data or the code is actually secure. 

Recently, JFrog announced a new version of the Go extension for VS Code IDE, available for the community with free download. This integration shows live vulnerability information about every public Go Module, directly into our source editor from the rich metadata of JFrog GoCenter. With security in mind, this provides information on any potential risks from our open-source Go Modules, enabling us to make better judgments, even before our first build.

Learn more about ‘Free Go Module Vulnerability Scanning with Visual Studio Code IDE’

Vulnerability Reporting

Vulnerabilities are monitored and tracked consistently throughout the software development lifecycle of any application. Keeping security in mind, when an issue is detected, it should be reported immediately to allow for remediation and visibility among common and standard organizations. Known vulnerabilities are tracked and classified using the Common Vulnerability and Exposures (CVE) list of publicly published information security vulnerabilities and exposures. Each CVE usually contains a standard identifier number (CVE ID), a status indicator, a brief summary of the vulnerability, and references related to vulnerability reports and advisories. 

More about CVE 

In the words of its origin organization, “CVE is a list of entries – each containing an identification number, a description, and at least one public reference – for publicly known cybersecurity vulnerabilities.”

According to the CVE website, a vulnerability is a mistake in software code that gives an attacker more or less direct access to a system or network. It could allow an attacker to pose as a super-user or system administrator with full access privileges, making them very dangerous. This exposure can allow an attacker to gather customer information and sensitive information that could be used or sold.

New CVE identifiers are added to the CVE website database on a daily basis and are instantly available. The latest versions are available on the CVE List Master Copy page. A free tool, from CERIAS/Purdue University, monitors changes to the CVE List. Also, CVE Change Logs provide daily or monthly changes to the list. 

Security in Go Modules

The most frustrating thing for Go developers is Go Module vulnerabilities, with the approach of DevSecOps best practices and a shifting left strategy, it’s becoming even more relevant for developers to be able to track and report vulnerabilities as early as possible. JFrog GoCenter can help Go developers remove this frustration by tracking and mitigating vulnerabilities. 

JFrog Xray’s security vulnerability scanning of Go modules has recently been added to GoCenter.io! GoCenter has the ability to automatically scan for known vulnerabilities recognized in the public vulnerability database NVD. Those results are stored in GoCenter and exposed on the Security page of the UI, which will list all vulnerabilities that exist in the module version. Learn more about 'GoCenter Reveals Go Module Vulnerabilities With Xray'.

GOPROXY Details

A GOPROXY commands the source of Go module downloads and enables the builds are deterministic and secure. The go command downloads modules from VCS directly, by default, and the GOPROXY environment variable further allows control over the download source. The environment variable configures and enforces the go command to use a Go module proxy.

Configuring a GOPROXY for your Golang development redirects Go module download requests to a cache repository. The GOPROXY’s cache makes the module always available, even if the original in the VCS repo is destroyed.  

A public GOPROXY is a centralized repository accessible to Golang developers across the world. It hosts open-source Go modules from third parties in publicly accessible VCS project repositories. Most repositories, like the JFrog GoCenter public Go modules repository, are provided to the Golang developer community for free.

GoCenter Security

GoCenter uses JFrog Xray to provide free vulnerability scanning for every Go module and version. With over 80,000 modules and over 700,000 module versions, GoCenter can serve as your first step in your Golang security journey.

Start by exploring the dependencies tab, which can show vulnerabilities in each of your module’s dependencies - and drill down the component tree for further information. The security tab for each module provides details like CVE ID, severity level, and description. The top CVEs in GoCenter are displayed on the front page and you can monitor the state of the CVEs for affected versions by clicking on the CVE links. This will provide data around which modules are affected by recent vulnerabilities.

In fact, the most common CVEs happen in Kubernetes related Go Modules. Here are the three most common ones:

• CVE-2019-11253 appears 1041 times with a high severity level of 5.

A short description for this CVE is 'Improper input validation in the Kubernetes API server in versions v1.0-1.12 and versions prior to v1.13.12, v1.14.8, v1.15.5, and v1.16.2 allows authorized users to send malicious YAML or JSON payloads, causing the API server to consume excessive CPU or memory, potentially crashing and becoming unavailable.'

• CVE-2019-9946 appears 972 times with a high severity level of 5.

The description of this CVE is 'Cloud Native Computing Foundation (CNCF) CNI (Container Networking Interface) 0.7.4 has a network firewall misconfiguration which affects Kubernetes. The CNI 'portmap' plugin, used to set up HostPorts for CNI, inserts rules at the front of the iptables nat chains; which take precedence over the KUBE- SERVICES chain. Because of this, the HostPort/portmap rule could match incoming traffic even if there were better fitting, more specific service definition rules like NodePorts later in the chain. The issue is fixed in CNI 0.7.5 and Kubernetes 1.11.9, 1.12.7, 1.13.5, and 1.14.0.'

• CVE-2019-11246 appears 726 times with a high severity level of 5.

The description of this CVE is 'The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine.'

To learn more about security in Go Modules and see recent vulnerabilities, checkout GoCenter: https://gocenter.io and scroll down on the front page to see the CVEs.