This article shows you how to analyze your applications written in Go using NG SAST. It assumes that you have already set up and authenticated with ShiftLeft.


NG SAST analyzes only source code written in Go 1.12 - 1.18, not compiled applications.

You must have the appropriate version of Go installed on the machine on which you're running ShiftLeft.

The VM or the environment you use should support building Go applications correctly. Try building the Go application first using go build (or make build if you're using a Makefile) command before attempting code analysis.

SCA (beta): To identify open-source vulnerabilities in Go applications, ShiftLeft CORE requires one of the following package formats: Gopkg.lock, go.mod, go.sum.

Analyzing your Go application


ShiftLeft offers a sample application that you can use to run and test NG SAST. It also includes a functioning configuration file to demonstrate how you can leverage GitHub Actions to automate code analysis whenever you open a new Pull Request (PR).

To analyze your Go application, run:

sl analyze --app <name> --go <path>
--app <name>The name of the application to be analyzed
--goThe flag identifying the application's language
<path>The path to your project. If you're executing sl analyze in the package's directory, you can pass in shorthands like .. You can also use /<absolute-path-of-directory-of-package> or ./... (current project and sub-projects).

See the CLI reference for additional sl analyze options.

We strongly recommend against passing in paths to individual .go files when running sl analyze. Doing so results in ShiftLeft analyzing only that file and none of the files in the same project on which it depends.

We also discourage you from passing in paths like ..., all, std, and ./vendor. Those will include dependencies in the scan that, in most cases, you do not want scanned.

See Package lists and patterns for more information.

Scanning for open-source vulnerabilities

For SCA, ShiftLeft looks for information about open-source packages in the project path you provided when running sl analyze. Depending on how your project repo is structured, you may also need to provide an additional configuration option so that ShiftLeft CORE can identify where your dependencies are located (for example, if you're running sl analyze for a package other than ., please use --oss-project-dir <project-dir> to specify the location of the <project-dir> directory where Gopkg.lock, go.mod or go.sum is located).

Sample usage

go build
sl analyze --app shiftleft-go-example --go .

Using cgo

If your application uses cgo and you're running into problems during analysis, please consider disabling it first for code analysis using the standard CGO_ENABLED switch like so:

CGO_ENABLED=0 sl analyze --app <name> --go <package>

Tagging results with your branch name

To include the branch name in your NG SAST results, allowing you to distinguish one set of results from another, add the following to your invocation of ShiftLeft:

sl analyze --tag branch=`git symbolic-ref --short HEAD`

If you're working in a GitHub environment (e.g., GitHub Actions), you can also use --tag branch=${{ github.head_ref }} to populate your branch name.

If you don't provide a branch name, but ShiftLeft detects one available in your environment, it will use that name.


If you have any issues scanning your project, please see our general troubleshooting page, as well as our Go-specific suggestions that follow.

Build-related errors

  • Most of the errors seen regarding the analysis of Go applications involve an environment that had not been set up correctly. Ensure that the environment on which you run ShiftLeft mirrors your development environment as closely as possible.

  • Try building the app. If the application uses a Makefile, run:

    make build

    Otherwise, use:

    go build ./...
  • For applications that involve a complex build process or Docker, review the Dockerfile to ensure that it was defined correctly.

  • If the Go application includes private modules that are available in a non-GitHub environment, such as GitLab or AWS CodeCommit, ensure the authentication keys are set up and the application builds cleanly before performing code analysis.