Snyk test and snyk monitor in CI/CD integration
Depending on your approach and goals, you may need to use both the snyk monitor and snyk test commands in your pipeline. Examples and details follow.
CLI examples in a build pipeline
Use snyk monitor to expose vulnerabilities and post to the Snyk UI for ongoing monitoring:
Use snyk test to fail the build on high severity issues:
To see the full list of options in the CLI, run the snyk test --help, snyk monitor --help, and snyk container --help commands or see the help docs.
Exit Codes
The snyk test command 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 help docs for the command you are using to find the meaning of the exit codes.
The snyk monitor command 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.
To silence Snyk CLI exit codes for the snyk test command to avoid failing the build step, use || true at the end of the command. || true sets the exit code of the scan to 0. This can be used to continue with a CI/CD pipeline even when there are vulnerabilities.
Common CLI options in a CI/CD integration
Among the most common options used in a CI/CD integration are the following:
-- 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.
--org=<ORG_ID>: Specify the ORG_ID to run Snyk commands for a specific organization. This influences where new projects are created after running the monitor command, some features availability, and private tests limits. If you have multiple organizations, you can set a default from the CLI using:
Set a default to ensure all newly tested or monitored projects are tested under your default organization. If you need to override the default, use the --org=<ORG_ID> option.
The default<ORG_ID> is the current preferred organization in your Account settings.
Configuring options for failing builds
You can add options to the snyk test command 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)
You can also fail the build for any other parameter in the Snyk JSON output (such as CVSS score), using a wrapper like snyk-filter, or using additional tooling like snyk-delta to fail the build only for issues found since the last build. For information on using snyk-filter and snyk-delta see Failing of builds in the Snyk CLI.
Ignoring issues
By default if issues are not ignored, or if you are not using snyk-delta, a snyk test in your pipeline fails the build when issues are found. To allow builds to continue without resolving these issues, you can:
Use the Snyk Python API for bulk ignores: see https://github.com/snyk-labs/pysnyk and https://github.com/snyk-labs/pysnyk/blob/master/examples/api-demo-9c-bulk-ignore-vulns-by-issueIdList.py
Creating custom build artifacts
You can use JSON output from Snyk commands to create custom test reports as build artifacts, using the snyk-to-html utility or other custom processing you develop.
Creating work items for new vulnerabilities
Snyk allows you to automatically create new work items in JIRA (see Jira integration documentation). You can customize this code for your specific requirements, or adapt it to work with other work management systems.
See Jira tickets for new vulns to get started, or review the API to create Jira tickets.
Last updated