The new, improved Snyk Container CLI
2020年10月29日
0 分で読めますAs more and more of you adopt containers for packaging up your applications, identifying vulnerabilities in them before you ship them is becoming incredibly important.
Snyk has had the ability to test your Docker images using our CLI for over a year now. With the latest release of the CLI, we’re improving the user experience for container users, as well as adding a few more useful features for advanced users.
A new container subcommand
Currently, you test container images using the --docker flag on either snyk test or snyk monitor. This works great for lots of users, and we won’t be breaking that behavior. But it has some downsides too, in particular when viewing the inline help.
If you’re just interested in testing your container images you need to wade through lots of options to determine which ones apply. So we’re introducing a new subcommand to snyk. You can now test your container images for vulnerabilities using:
snyk container test <your-image>
If you want to send that information to Snyk, where we can display it and alert you in the future if new vulnerabilities are found, then the monitor command is also available.
snyk container monitor <your-image>
Snyk makes it easy to test your images wherever they are. If the image is only in your local Docker daemon we’ll test that. If it’s available in a remote registry we’ll pull the image down and test that. Don’t have Docker installed on the machine where you’re testing? No problem. There are lots of different workflows around containers, Snyk makes it easy to test your images however you work.
To reiterate. The previous --docker flag will remain and simply act as an alias for the new command, including the new functionality. We take backward compatibility seriously and don’t want to break any automation you might have around our CLI tooling.
Container specific help
With the new container subcommand, we have Container specific help information available directly in the CLI. This makes it much easier to see straight away how you can use the CLI, from specifying a Dockerfile used to build the image, to excluding the vulnerabilities found in the base image or only reporting on high severity vulnerabilities.
$ snyk container --help
Usage:
$ snyk container [command] [options] [image]
Find vulnerabilities in your container images.
Commands:
test ............... Test for any known vulnerabilities.
monitor ............ Record the state of dependencies and any
vulnerabilities on snyk.io.
Options:
--exclude-base-image-vulns .............. Exclude from display base image vulnerabilities.
--file=<string> ......................... Include the path to the image's Dockerfile for more detailed advice.
-h, --help
--platform=<string> ..................... For multi-architecture images, specify the platform to test. Options are:
[linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x,
linux/386, linux/arm/v7 orlinux/arm/v6]
--json .................................. Return results in JSON format.
--json-file-output=<string>
(test command only)
Save test output in JSON format directly to the specified file, regardless of whether or not you use the `--json` option.
This is especially useful if you want to display the human-readable test output via stdout and at the same time save the JSON format output to a file.
--sarif ................................. Return results in SARIF format.
--sarif-file-output=<string>
(test command only)
Save test output in SARIF format directly to the specified file, regardless of whether or not you use the `--sarif` option.
This is especially useful if you want to display the human-readable test output via stdout and at the same time save the SARIF format output to a file.
--print-deps ............................ Print the dependency tree before sending it for analysis.
--project-name=<string> ................. Specify a custom Snyk project name.
--policy-path=<path> .................... Manually pass a path to a snyk policy file.
--severity-threshold=<low|medium|high>... Only report vulnerabilities of provided level or higher.
Examples:
$ snyk container test alpine
$ snyk container test --platform=linux/arm64 debian
$ snyk container monitor alpine
$ snyk container test docker-archive:archive.tar
$ snyk container test oci-archive:archive.tar
Pro tip: use `snyk container test --file=Dockerfile` for more detailed advice.
For more information see https://snyk.io
Pro tip: use `snyk container test --file=Dockerfile` for more detailed advice.
For more information see https://snyk.ioSome new capabilities
The new snyk container subcommand also comes with some new features for power users.
If you’re working directly with container archives, rather than images, you can now test those for vulnerabilities with Snyk.
For instance, you can save an archive from Docker, and test the resulting archive file like so:
docker save ubuntu:18.04 -o ubuntu.tar
snyk container test docker-archive:ubuntu.tarIf you’re working directly with the standard OCI (Open Container Initiative) images you can test those too.
snyk container test oci-archive:ubuntu.tar
Last but not least, Snyk now supports testing Distroless images. Distroless is an interesting project from Google, producing container base images based on Debian packages, but without a shell, or package manager installed in order to improve security. So you can now test the Distroless base images or images you’ve built using them with Snyk as normal.
$ snyk container test gcr.io/distroless/base | head
Testing gcr.io/distroless/base...
✗ Low severity vulnerability found in openssl/libssl1.1
Description: Cryptographic Issues
Info: https://snyk.io/vuln/SNYK-DEBIAN9-OPENSSL-374708
Introduced through: openssl/libssl1.1@1.1.0l-1~deb9u1, openssl@1.1.0l-1~deb9u1
From: openssl/libssl1.1@1.1.0l-1~deb9u1
From: openssl@1.1.0l-1~deb9u1 > openssl/libssl1.1@1.1.0l-1~deb9u1
From: openssl@1.1.0l-1~deb9u
Next steps
We’re always working to improve the user experience of Snyk, whether in our CLI tool, the Snyk service, our API, or our various developer tools integrations. The new snyk container command should make it easier to use Snyk when you’re focused on containers, and we’ll have more interesting and useful functionality coming to this interface soon.