snyk monitorcommand is recommended. If you use one of the Snyk CI plugins, it is recommended that you configure the plugin to not fail the build.
snyk monitorto expose results provides information without disrupting processes.
snyk testto your build or enable the fail functionality to make Snyk fail your builds, providing the results output to the console. Your developers or DevOps teams can use the results to decide whether to stop or continue the build.
snyk monitorif your
snyk testreturns a successful exit code.
ORG_IDin the organization's settings page.
snyk testcommand is synchronous; it ends with an exit code. Your build system can use exit codes to either pass or fail the build based on the test results. See the CLI reference for the meaning of the exit codes.
snyk monitorcommand posts a snapshot of the dependency tree for your project to your Snyk account and monitors that snapshot for vulnerabilities. It is an asynchronous command that does not end with an exit code based on the vulnerability status. For
snyk monitor, exit codes signify success or failure in creating the snapshot to monitor.
snyk testcommand to avoid failing the build step, use
|| trueat the end of the command.
|| truesets the exit code of the scan to 0. This can be used to continue with a CI/CD pipeline even when there are vulnerabilities.
snyk testcommands in your pipeline.
snyk monitorto exposed vulnerabilities and post to the Snyk UI for ongoing monitoring:
snyk testto fail the build on high severity issues:
snyk testcommand to refine parameters that can result in a failed build:
--severity-threshold=high: Fail the build only for high severity issues
--fail-on=upgradable: fail the build only for issues that are upgradable (can be fixed with Snyk fix advice)
snyk testin your pipeline fails the build when issues are found. To allow builds to continue without resolving these issues, you can:
monitorcommand to specify the correct Python command for execution:
--file=option because your manifest file is not the standard
requirements.txt, you must use the following option to specify Pip as the package manager
.slnfile, you can specify the path to the file, and Snyk scans all the sub projects that are part of the repo, for example:
--yarn-workspacesoption to test and monitor your packages. The root lockfile will be referenced for scans of all the packages. Use the
--detection-depthoption to find sub-folders that are not auto discovered by default.
snyk testand target a specific project file, for example:
pom.xml). This is fast and efficient, but can be difficult to scale, especially if you are not familiar with the project.
--detection-depthoptions, the Snyk CLI or CI/CD plugin searches up to the
--detection-depthin the folder structure for any manifests that match the supported file types. Each project is scanned and has its own result. Similarly, if you are using
snyk monitor,a separate result is created for each project. This provides a good way to automate scanning, especially if you have projects spanning node, .net, python, and so on.
--all-projectsworks, as it invokes gradle-specific options behind the scenes in the form of:
snyk test --file=build.gradle --all-sub-projectswhen it finds the build file as part of the
--file=for each manifest of the other languages and package managers. You must then use
--configuration-matchingto scan a complex Gradle project.
snyk container test $IMAGE_NAME, Snyk looks for that image in your local daemon storage, and if the image does not exist, does the equivalent of a docker pull to download it from your upstream registry.
--file=Dockerfileon the command line to link the image vulnerability results with the Dockerfile that built the image, to receive inline fix advice and alternate base image suggestions.
snyk container test docker-archive:archive.taror
snyk container test oci-archive:archive.tarto get Snyk vulnerability results against tar-formatted container images (either in Docker or OCI format) without relying on the Docker daemon.
--severity-thresholdto customize the failure status for the build task. For more advanced usage, you can use
--jsonto generate a JSON file containing the full vulnerability report, and set your own build failure status based on the JSON data.
--exclude-base-image-vulnsto report only vulnerabilities introduced by your user layers, rather than vulnerabilities that come from the base image of the container (the image you specify in the FROM line in the Dockerfile).
snyk container monitorfollowing
snyk container test(or simply check the Monitor box on your plugin settings), to keep a record of the bill of materials for this container within the Snyk UI and proactively monitor for new vulnerabilities on a daily basis. This is useful when pushing new releases into production environments. You can use
--project-nameto specify a unique identifier for the release to ensure production containers are tracked separately from others in your build process.
DEBUG=*or use the
-doption to capture logs:
-- all-projects: Auto-detect all projects in working directory
-p: Prune dependency trees, removing duplicate sub-dependencies. Continues to find all vulnerabilities, but may not find all of the vulnerable paths.
monitorcommand, some features availability, and private tests limits. If you have multiple organizations, you can set a default from the CLI using: