Snyk Container-specific CI/CD strategies

The best time to implement Snyk Container in your pipeline is after the container image is built, that is, after running the equivalent of docker build, and before your image is either pushed into your registry (docker push) or deployed to your running infrastructure (helm install, kubectl apply, and so on).

Typically, the way you run your container build-test-deploy pipeline depends on whether a Docker daemon is available to the build agent.

Running a pipeline if a Docker daemon is available

Snyk can help if the following circumstances exist:

• You are running your build tooling, such as Jenkins, directly on a host that has Docker natively installed.

• Your pipeline tasks run inside containers that have the Docker socket[/var/run/docker.sock] bind-mounted to the host.

• You are running a Docker-inside-Docker setup.

Snyk can provide help as follows:

• When you run snyk container test $IMAGE_NAME, Snyk looks for that image in your local daemon storage, and if the image does not exist, use the equivalent of a docker pull to download the image from your upstream registry.

• For registry authentication, Snyk uses the credentials you already configured with something like docker login.

• You can specify --file=Dockerfile on 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.

Running a pipeline if a Docker daemon is not available

Snyk can help if the following circumstances exist:

• You containerize each build task but do not mount the Docker socket for security and performance reasons.

• Pipeline tasks are split across hosts, or even clusters, and rely on artifacts to be handed off through a central volume or intermediate registry/object store.

• You work exclusively in an ecosystem that only uses OCI-compliant container images.

Snyk can provide help as follows:

• Run either snyk container test docker-archive:archive.tar or snyk container test oci-archive:archive.tar to get Snyk vulnerability results against tar-formatted container images, either in Docker or OCI format, without relying on the Docker daemon.

• The tar archive can be generated by your build process using the equivalent of docker save and stored in a shared volume or object store. This can be accessed by the build agent container running the Snyk binary, with no other dependencies required.

Recommendations for integration with container images

• Regardless of how you integrate with container images during CI, run a Snyk Container scan as a separate build step from your Snyk Open Source (application SCA) test. This allows you to isolate build failures to vulnerabilities within either the container/OS layer or the application layer, respectively. This also enables more easily containerized build tasks.

• Use CLI flags like --fail-on and --severity-threshold to customize the failure status for the build task. For more advanced usage, you can use --json to generate a JSON file containing the full vulnerability report and set your own build failure status based on the JSON data.

• Pass --exclude-base-image-vulns to report only vulnerabilities introduced by your user layers, rather than vulnerabilities that come from the base image of the container, that is the image you specify in the FROM line in the Dockerfile.

• Run snyk container monitor following snyk container test, or check the Monitor box on your plugin settings, to keep a record of the bill of materials for the 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-name to specify a unique identifier for the release to ensure production containers are tracked separately from others in your build process.