# 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.
