> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/developer-tools/integrations/snyk-ci-cd-integrations/snyk-ci-cd-integration-deployment-and-strategies/snyk-container-specific-ci-cd-strategies.md). # 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, uses 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 uses only 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 or OS layer, or the application layer, respectively. This also enables more easily containerized build tasks. * Use CLI options like `--fail-on` and `--severity-threshold` to customize the failure status for the build task. For more advanced testing, 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.snyk.io/developer-tools/integrations/snyk-ci-cd-integrations/snyk-ci-cd-integration-deployment-and-strategies/snyk-container-specific-ci-cd-strategies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.