While this helps you avoid unexpected changes, it's also more tedious to have
to look up and include the image digest for base image versions manually each
time you want to update it. And you're opting out of automated security fixes,
which is likely something you want to get.

Docker Scout's default [**Up-to-Date Base Images**
policy](../../scout/policy/_index.md#up-to-date-base-images) checks whether the
base image version you're using is in fact the latest version. This policy also
checks if pinned digests in your Dockerfile correspond to the correct version.
If a publisher updates an image that you've pinned, the policy evaluation
returns a non-compliant status, indicating that you should update your image.

Docker Scout also supports an automated remediation workflow for keeping your
base images up-to-date. When a new image digest is available, Docker Scout can
automatically raise a pull request on your repository to update your
Dockerfiles to use the latest version. This is better than using a tag that
changes the version automatically, because you're in control and you have an
audit trail of when and how the change occurred.

For more information about automatically updating your base images with Docker
Scout, see [Remediation](/manuals/scout/policy/remediation.md).

## Build and test your images in CI

When you check in a change to source control or create a pull request, use
[GitHub Actions](../ci/github-actions/_index.md) or another CI/CD pipeline to
automatically build and tag a Docker image and test it.

## Dockerfile instructions

Follow these recommendations on how to properly use the [Dockerfile instructions](/reference/dockerfile.md)
to create an efficient and maintainable Dockerfile.

> [!TIP]
>
> Want a better editing experience for Dockerfiles in VS Code?
> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.

### FROM

Whenever possible, use current official images as the basis for your
images. Docker recommends the [Alpine image](https://hub.docker.com/_/alpine/) as it
is tightly controlled and small in size (currently under 6 MB), while still
being a full Linux distribution.

For more information about the `FROM` instruction, see [Dockerfile reference for the FROM instruction](/reference/dockerfile.md#from).

### LABEL

You can add labels to your image to help organize images by project, record
licensing information, to aid in automation, or for other reasons. For each
label, add a line beginning with `LABEL` with one or more key-value pairs.
The following examples show the different acceptable formats. Explanatory comments are included inline.

Strings with spaces must be quoted or the spaces must be escaped. Inner
quote characters (`"`), must also be escaped. For example:

```dockerfile
# Set one or more individual labels
LABEL com.example.version="0.0.1-beta"
LABEL vendor1="ACME Incorporated"
LABEL vendor2=ZENITH\ Incorporated
LABEL com.example.release-date="2015-02-12"
LABEL com.example.version.is-production=""
```

An image can have more than one label. Prior to Docker 1.10, it was recommended
to combine all labels into a single `LABEL` instruction, to prevent extra layers
from being created. This is no longer necessary, but combining labels is still
supported. For example:

```dockerfile
# Set multiple labels on one line
LABEL com.example.version="0.0.1-beta" com.example.release-date="2015-02-12"
```

The above example can also be written as:

```dockerfile
# Set multiple labels at once, using line-continuation characters to break long lines
LABEL vendor=ACME\ Incorporated \
      com.example.is-beta= \
      com.example.is-production="" \
      com.example.version="0.0.1-beta" \
      com.example.release-date="2015-02-12"
```

See [Understanding object labels](/manuals/engine/manage-resources/labels.md)
for guidelines about acceptable label keys and values. For information about
querying labels, refer to the items related to filtering in