Snyk CLI: one getting started page, two CLIs, and a release only Makefile

The manifest says 1.0.0-monorepo and the tags say v1.1307.4

The root `package.json` names the package `snyk`, describes it as a library and cli utility, and carries the version `1.0.0-monorepo`:

  "name": "snyk",
  "version": "1.0.0-monorepo",
  "description": "snyk library and cli utility",
  "bin": {
    "snyk": "bin/snyk"
  },
  "engines": {
    "node": "^22 || ^24",
    "npm": "^11.12.1"
  },
  "workspaces": [
    "packages/*"
  ],

No published tag looks like that. The most recent releases are v1.1309.0 preview builds published between 2026-10-27 and 2026-10-30, while the last push to the repository was on 2026-11-02, so the tree is current and the version string inside it is not the one any release was cut from. Two other entries decide whether a build works at all: the binary is wired to `bin/snyk`, and the engines field pins node `^22 || ^24` with npm `^11.12.1`.

Four scan verbs, and three prerequisites none of them supply

Each content type has its own verb, and the page pairs every verb with a prerequisite the verb cannot provide for you:

snyk test
snyk code test
snyk container test ubuntu:18.04
snyk iac test /path/to/kubernetes_file.yaml

Open source scanning wants a supported manifest such as `package.json`, `pom.xml`, or `composer.lock` in the directory you changed into, and the worked example still targets `ubuntu:18.04` for containers. Before Open source scanning you must have your package manager installed, with third party tools such as Gradle or Maven sitting on the `PATH`. Before testing an Open source Project you must build it, with limited exceptions. And before scanning your code at all, the page routes you to a code execution warning document first, which is the one piece of the flow that is a warning rather than a step. Whether your project qualifies at all is settled in three other documents: one covers supported languages, package managers and frameworks for Open Source and Code, one lists the operating system distributions Container supports, and one lists supported IaC languages and cloud providers.

GitBook callout markers and a stray backslash ship in the README

The getting started page is an export from a docs system, and the export markers are still in the file. A callout survives as a literal template directive, its text follows, and the closing directive ends it:

{% hint style="info" %}
Before you can use the CLI for Open Source scanning, you must install your package manager. The needed third-party tools, such as Gradle or Maven, must be in the `PATH`.
{% endhint %}

The same thing happens later, where the Kubernetes example is introduced with a trailing backslash used to force a line break, and the command lands on the line after it. The section on test output carries a figure captioned `Snyk CLI test command output example`, and the report is described in prose: severity per issue, a link, the path the vulnerable module took into your system, and fix guidance. An onboarding wizard and a linked video are offered as alternatives for the same material. Neither artifact changes what the CLI does, and all of it is a fair signal about how much of this page is generated for a hosted docs site rather than written for people reading the repository, where a code block that starts with `{%` tells you nothing about the tool.

One experimental agent command, in a tree that already ships AGENTS.md and CLAUDE.md

Automated agents get one command instead of four verbs:

snyk agent test --experimental
snyk agent --help

It runs Open Source, Code and Secrets scans in a single pass and returns compact output built to be cheap in tokens. The page marks it experimental and subject to change and points at the help command for details. Secrets is not among the four content types listed in the page's introduction. The tree already carries `AGENTS.md` and `CLAUDE.md` beside `CONTRIBUTING.md` and `SECURITY.md`, so machine instructions for automated contributors exist in the same repository as a command that has not been declared stable.

The Makefile refuses to be a build tool and leaves packaging to npx pkg

The Makefile states its own limit in the first three lines: it is only for building release artifacts, CLIv1 scripts belong to `npm run`, and the default goal prints that help text. The packaging command underneath is:

PKG := npx pkg ./ --compress Brotli --options max_old_space_size=32768
PKG_NODE_VERSION := $(shell cat .nvmrc)
export BINARY_OUTPUT_FOLDER = binary-releases

The node version comes out of `.nvmrc`, artifacts land in `binary-releases`, and separate output folders are created for fips and for experimental builds. The webpack scripts that build the TypeScript CLI raise the node heap to 8192 MB on both the dev and the prod path. None of that covers the Go half, which sits in `cliv2/` with its own Makefile, and the repository also carries `cliv2-private/`, `ts-binary-wrapper/`, `binary-deployments.json`, and a `docker-desktop/` directory.

A private Go module changes which build you get, with no flag

The build mode is detected unless you set it: the Makefile assigns `BUILD_MODE ?=`, which only applies when BUILD_MODE is not already set. The Makefile points at `cliv2-private`, and if `cliv2-private/go.mod` exists and `go mod download` succeeds inside that directory, the mode becomes private; otherwise it falls back to public:

PRIVATE_DIR = $(WORKING_DIR)/cliv2-private
BUILD_MODE ?= $(if $(_CAN_BUILD_PRIVATE),private,public)
SHASUM_CMD = shasum

The same file branches on `go env GOHOSTOS` for the host, choosing `shasum` on anything that is not windows and a PowerShell script under `cliv2/scripts/` when it is, and it switches between `python` and `python3` for the same reason. So unless BUILD_MODE is set, the shape of a release built from a clone can change depending on whether a private checkout happens to be present. That is a build you cannot reproduce from the public tree alone.

The page that gets you started contains no install command

Installation here is two outbound links, to a document about installing or updating the CLI and a document about authenticating the machine, plus a pointer to the release notes for changes in each release. The first command on the page arrives at the verification step, which is `snyk --help`, and the alternative check runs `snyk test ionic` against a public npm package that belongs to somebody else. Licensing is equally thin: the root carries a `LICENSE` file and a `Contributor-Agreement.md`, and GitHub reports the licence as NOASSERTION rather than a named license.

Editorial conclusion

Snyk earns its place on teams that already keep a built project, a package manager on the PATH, and an authenticated account, because all three are prerequisites rather than setup steps. Before adopting it, read the code execution warning, give CI its own credentials instead of a shared login, and confirm which build mode your clone produces, since a private module changes the artifact unless BUILD_MODE is set. Pin by tag, because the manifest carries a placeholder version.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. snyk/cli on GitHub