> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.15/onboard-cortex-xsoar/docker/docker-images-in-cortex-xsoar/docker-image-security.md).

# Docker Image Security

Apply Docker image security practices for Cortex XSOAR 6.15 integrations and automations.

The project that contains the source Dockerfiles used to build the images and the accompanying files is fully open source and [available for review](https://github.com/demisto/dockerfiles). Cortex XSOAR uses the secure Docker Hub registry for its [Docker images](https://hub.docker.com/u/demisto). However, when using Cortex XSOAR on-prem, or in an Engine environment, you can also use the [PANW registry](#UUID-5b0a4208-5f53-e2a6-17a1-fafc20c7f1d6). You can view the Docker trust information for each image at the [image info branch](https://github.com/demisto/dockerfiles-info/blob/master/README.md).

### Vulnerability Management

We automatically update our open source Docker images and their accompanying dependencies (OS and Python). Examples of automatic updates can be viewed on [GitHub](https://github.com/demisto/dockerfiles/pull/700).

We maintain Docker image information which includes information on Python packages, OS packages and image metadata for all our Docker images. [Data image information](https://github.com/demisto/dockerfiles-info/blob/master/README.md) is updated nightly.

All of our images are continuously scanned using Cortex Cloud for known and newly published vulnerabilities, in two scenarios:

* Every new image, and every new version of an image, are scanned before publishing to our public registries, as part of our CI/CD process.
* All existing images are continuously scanned to check whether new vulnerabilities were published and now exist in those images.

We evaluate all critical/high findings and actively work to prevent and mitigate security vulnerabilities.

Cortex XSOAR ensures container images are fully patched and do not contain unnecessary packages. Patches and dependencies are applied automatically via our open source dockerfiles build project.

### **Response Prioritization**

We remediate any critical and high level vulnerabilities, irrespective of who found them. Issues may be discovered by external researchers, found during internal testing, encountered by customers or reported by other organizations and vendors.

Any vulnerability with a possible exploitation against our images would be responded to with utmost urgency. If we conclude that there is a risk for our customers, we will issue an advisory with recommended actions and mitigations. Advisories are published at: <https://security.paloaltonetworks.com/>.

In each version release (every 3 months,) we publish a new version of our content, that will use the latest and secure versions of our images.

### **Troubleshooting**

* Purge old and unused images periodically.
* If you scanned the Docker images locally, and found some critical CVE’s - Make sure you use the latest version of the pack, as it should have the latest version of the image. In addition, purge the old and unused image with vulnerabilities.


---

# 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 following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.15/onboard-cortex-xsoar/docker/docker-images-in-cortex-xsoar/docker-image-security.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

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.