> 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/scan-fix-and-prevent/scan-with-snyk/snyk-container/use-snyk-container/analyze-and-fix-container-images.md).
# Analyze and fix container images
You can import container Projects into Snyk using the CLI command [`snyk container monitor`](/developer-tools/snyk-cli/snyk-cli/commands/container-monitor.md). Alternatively, you can import Projects directly from a supported container registry using the Snyk Web UI.
Snyk imports a snapshot of your container image and then scans the snapshot for vulnerabilities. Based on your configuration, daily or weekly, Snyk regularly scans the dependencies snapshotted in that original import, which in turn refers to its tag. Based on your configuration, Snyk sends you an update by email or Slack when any new vulnerabilities are identified.
If the tag for an image changes and the original tag is used for a different image, upon rescanning (daily or weekly), Snyk detects changes to the Linux package dependencies and creates a new snapshot of that Project, but it does not detect changes in the application dependencies and thus does not update the snapshot for application vulnerabilities.
This means that if you frequently reuse a tag to refer to a different image, you must reimport the other image so that Snyk can update the application dependencies.
## Grouping of Container Projects
Depending on how you import images (Snyk CLI, container registry integration, or Kubernetes integration), Projects are grouped differently in the **Projects** tab.
### Project grouping when importing images with Snyk CLI
Snyk groups images and the applications found in the image. However, Snyk CLI does not use image tags for grouping, so Snyk does not do sub-grouping for the different image tags. Thus images from the same repository with different image tags are all grouped.
### Project grouping when importing images with container registry integration
If you import images into Snyk with container registry integration, in the **Projects** list Snyk performs sub-grouping per image tag for each image name.
Images with different image tags grouped in sub-groups
### Project grouping when importing images with the Kubernetes integration
If you import images into Snyk using the Kubernetes integration, the top clickable item represents the workload in the cluster. Snyk performs grouping based on the image in the workload, without sub-grouping per image tag.
## View image vulnerabilities
If the Project is imported from a registry integration, on the **Projects** page, it is marked with the relevant registry icon. If the Project is imported from the CLI, it is marked with a CLI icon. You can also filter to display all container Projects.
When you open a container Project, the analysis and fix advice appear for that Project.
Analysis and fix advice for a container Project
The following information is displayed:
* Project summary: general Project details, including unique details:
* **Image ID** - derived from the container image digest
* **Image tag**
* **Base Image**
* Total dependencies with known vulnerabilities and the total number of vulnerabilities
* Fix advice: If you included your Dockerfile for monitoring, available and actionable fix advice is displayed. To view all fix advice, click **Show more upgrade types**.
The **Issues** tab provides a list of vulnerabilities, including origins and paths, as well as an overview of the vulnerabilities.
In the issues list, you can use the filters available for all supported Project types, as well as the following filters:
* **OS BINARIES** - to see specific binary or OS packages for binaries and packages containing issues.
* **IMAGE LAYER** - to see Dockerfile instructions. If you attach a Dockerfile, you can filter to view issues associated only with the base image, view Dockerfile-related advice (user instruction), or both.
Filters for OS binaries and image layers
{% hint style="info" %}
The **OS BINARIES** filter does not appear if there is only one category of issues in your container, for example, Node binary vulnerabilities or OS packages.\\
The **IMAGE LAYER** filter does not appear if there is no Dockerfile attached.
{% endhint %}
The **Dependencies** tab provides a tree view of the package hierarchy inside the image.
## Fix image vulnerabilities
When providing public base image recommendations, Snyk bases its logic on the origin repo, flavor, and version of the base image it detects.
The Snyk recommendations for upgrading the base image refer to:
* **Minor upgrades**: the safest and best minor upgrade available
* **Major upgrades**: an option for a major upgrade that will reduce more vulnerabilities but with greater risk
* **Alternative upgrades**: viable image options for replacing your current base image with possible different base images that provide the least amount of vulnerabilities.
* Recommendation to rebuild your base image if it is outdated.
Recommendations for upgrading the base image include:
* The name of the recommended base image version
* The number of vulnerabilities that exist in the recommended upgrade
* A summary of the vulnerability severities.
Recommendations for upgrading the base image
---
# 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/scan-fix-and-prevent/scan-with-snyk/snyk-container/use-snyk-container/analyze-and-fix-container-images.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.