> ## Documentation Index
> Fetch the complete documentation index at: https://www.aptible.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Image and Vulnerability Scanning

> Catch Docker image issues before deploy, and scan for new vulnerabilities between deployments

Maintaining image security doesn’t stop at deployment; it is a continuous process that must be implemented for every release by incorporating these steps in your CI/CD pipeline and image registry:

1. Lint Dockerfiles in CI before build
2. Scan built images in CI before deploy
3. Scan images on an ongoing basis between deployments

# Before Build: lint Dockerfiles in CI

Run Dockerfile linting in CI/CD on every change that touches your image definition. Linters help you catch common issues such as insecure defaults, unnecessary privileges, or outdated base image patterns before you spend time building or deploying.

Add linting as a required CI check so that a failing Dockerfile blocks the pipeline before the build step runs. This applies whether you [deploy via Git](/docs/how-to-guides/app-guides/deploy-from-git) or [deploy via Docker image](/docs/how-to-guides/app-guides/migrate-dockerfile-to-direct-image-deploy).

# Before Deploy: scan built images in CI

After the image is built, scan the artifact in your CI before deploying it. Open-source and commercial image scanners can inspect OS packages and other dependencies for known vulnerabilities. Fail the pipeline, or gate promotion, when findings exceed your policy standards.

Prefer [deploying via Docker image](/docs/how-to-guides/app-guides/migrate-dockerfile-to-direct-image-deploy) to ensure only the scanned artifact ships to production. Build once, scan the image, then deploy the same tagged image to staging and production.

When deploying via Git, Aptible builds the image at deploy time. Lint the Dockerfile in CI, and scan a deployed staging image before promoting the same commit to production. You cannot scan an image between when Aptible builds it and when it is deployed.

Wire scanning into your existing CI flow. See [How to deploy to Aptible with CI/CD](/docs/how-to-guides/app-guides/how-to-deploy-aptible-ci-cd) and [How to integrate Aptible with CI Platforms](/docs/how-to-guides/app-guides/integrate-aptible-with-ci/overview).

# Between deployments: ongoing and registry scanning

Vulnerabilities are disclosed after images are already running. Scanning only at deploy time leaves a gap until the next release. Cover that gap with one or both of:

* **Repository / registry scanning:** Many registries, like Docker Hub and Amazon ECR, can continuously or periodically scan stored images and alert when new CVEs appear against tags running in production.
* **Scheduled CI jobs:** Re-scan the image tags currently deployed to staging and production on a daily or weekly schedule. Treat new high-severity findings the same way you would in a pre-deploy gate: triage, rebuild, and redeploy when needed.

Ensure ongoing scans target the image digests or tags that are live in each environment, not only `latest`.

# Fitting this into Aptible deploys

| Phase           | Goal                                 | Git deploy                                                   | Image deploy                                      |
| --------------- | ------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------- |
| Lint Dockerfile | Catch definition issues before build | Lint in CI before push                                       | Lint in CI before `docker build`                  |
| Scan image      | Catch known CVEs before production   | Scan staging image before promoting the commit to production | Scan the built image, then deploy that same image |
| Ongoing scan    | Catch new CVEs between deploys       | Registry or scheduled scans of deployed tags                 | Registry or scheduled scans of deployed tags      |

Image-based deploys make pre-deploy scanning straightforward because you control the build and can gate on the exact artifact. Git deploys still benefit from Dockerfile linting and from scanning staging before production.