Most modern software today has moved aggressively into using third-party open source dependencies to reduce duplication and accelerate development by using pre-existing code. These dependencies are often built and managed by a distributed team of engineers and while this model of building software has often resulted in faster feature improvement (better feedback loops that help functional issues improve early), it also means that the code in your OSS dependencies change quickly and new issues can be introduced.
Shift Left for Security
Catching and fixing issues in your dependencies early is one part of a principle called “shift left” or “shift left testing.” Shift left testing requires engineers build strong testing methodologies (with automation) early-on. Shifting left saves time and costs in debugging and QA, dramatically reducing time between releases, ultimately resulting in higher quality software.
Among other concerns, developers now need to be more aware of security vulnerabilities – not just in their own code, but in dependencies as well. Enabling developers to identify safe and vulnerable open source components is an essential start to shifting left security.
Keeping Go Modules Safe
Shift left testing in Golang can be challenging because Go modules often use direct as well as transitive dependencies and many of those have new versions that are updated at different times. Ensuring the security of dependencies and strong testing in Golang is also important because:
- The scale, speed, and frequency of Go application releases
- Spread of Go-based microservices as the backbone of major enterprise applications
- Multi-channel device use for the same application means software updates must work on phones, browsers, tablets, gaming systems and others effectively.
But if you’re a Golang developer, how do you know what to test, and what to test for? Do you have time to dig into the origin of every OSS dependency? Luckily, the JFrog Community Team has a free tool that can help you shift-left without hampering your productivity.
JFrog GoCenter and VS Code Extension
For users of VS Code, the JFrog Extension for VS Code enables free security vulnerability identification of your OSS Go module dependencies. Once installed, the extension automatically flags high, medium, and low vulnerability CVE issues using CVSS v2 ratings directly in your user interface. So you can know even before you build your full Go application or module, that a specific dependency is vulnerable, and how severely.
The VS Code extension draws this security information from JFrog GoCenter, our free public repository of over 740,000 (and growing!) open source Go module versions. In addition to being available as a fast, public GOPROXY, GoCenter performs deep-recursive scanning of all Go modules with JFrog Xray, tagging each with security information from the National Vulnerability Database.
When viewing your `go.mod` file in the VS code IDE:
- Vulnerable modules are marked with a wavy underscore.
- Hovering over the module name reveals its severity level.
- Click the lightbulb icon to view the full dependency tree of that module version.
Other free features included in the extension are:
- Module License Info and ReadMe info available from GoCenter
- Recommendations to upgrade to the latest version of a module
- Quick view into the dependency tree including transitive dependency information
- Links to GoCenter security tab to see CVE details and issue description
Using the VS Code IDE Extension for Go
Each of the features in the extension were included to help the Golang community develop software in a faster and safer way and allow every developer to be a champion of some of the testing principles included in the shift left philosophy. You can import any Go module into VSCode and the extension will automatically scan it and provide severity information and metadata from GoCenter.
First, with VSCode installed on my machine, I click on the Extensions logo on the left of VSCode and search for “JFrog” in the search box at the top-left.
After installing the extension, using a real world example, I create a testing file for my Go application which parses YAML.
I build out the following test validation package and import my modules:
I run a go test and my test files PASS ok.
Everything looks good, but wait — when I go to the
go.mod file I notice a wavy underscore under
gopkg.in/yaml.v2 v2.2.7. It looks like my test files actually have a vulnerability in the module yaml.v2 v2.2.7.
This version of
gopkg.in/yaml.v2 has 1 medium vulnerability. Shoot!
When I click on the underlined module name, a lightbulb appears and I can see a few options. I want to see the CVE details so I click on the option to see it in GoCenter.
This is what I see in GoCenter. The security tab shows me the details of this vulnerability:
I definitely don’t want this vulnerability in my application.
Luckily, if I go back into VSCode – with the JFrog extension installed, I can click on the “upgrade dependencies” link and it will automatically import a newer version of this module.
Now we’ve upgraded to the latest version:
No wavy underline – looks like this one is clean! I do a
go mod tidy to clean up the
go.mod file and hit save. Now my application is vulnerability free.
Congratulations! You fixed an issue before your production QA team even noticed!
Go Forth and Defend
While this simple example may not cover the full testing needs of a shift left philosophy, it does demonstrate the power of the JFrog VSCode Extension, and how important it is that Go developers understand how easily vulnerabilities can be introduced in different versions of their module’s dependencies.