# Cómo se prueban las Docker Hardened Images


Las Docker Hardened Images (DHI) están diseñadas para ser seguras, mínimas y estar listas
para producción. Para garantizar su confiabilidad y seguridad, Docker emplea una estrategia
de pruebas exhaustiva, que puedes verificar de forma independiente utilizando atestaciones
firmadas y herramientas abiertas.

Cada imagen se prueba para comprobar el cumplimiento de estándares, la funcionalidad y la
seguridad. Los resultados de estas pruebas se incorporan como atestaciones firmadas, que se
pueden [inspeccionar y verificar](#visualizar-y-verificar-la-atestacion-de-pruebas) mediante
programación utilizando la CLI de Docker Scout.

## Descripción general de la estrategia de pruebas

El proceso de pruebas para las DHI se centra en dos áreas principales:

- Cumplimiento de estándares de imagen: Garantizar que cada imagen cumpla con estrictos
  estándares de tamaño, seguridad y compatibilidad.
- Funcionalidad de la aplicación: Verificar que las aplicaciones dentro de las imágenes
  funcionen correctamente.

## Cumplimiento de estándares de imagen

Cada DHI se somete a rigurosos controles para cumplir con los siguientes estándares:

- Superficie de ataque mínima: Las imágenes se construyen para ser lo más pequeñas posible,
  eliminando componentes innecesarios para reducir posibles vulnerabilidades.
- Casi cero CVE conocidos: Las imágenes se escanean utilizando herramientas como Docker Scout
  para garantizar que estén libres de vulnerabilidades y exposiciones comunes (CVE) conocidas.
- Soporte multiarquitectura: Las DHI se construyen para múltiples arquitecturas (`linux/amd64`
  y `linux/arm64`) para garantizar una amplia compatibilidad.
- Compatibilidad con Kubernetes: Las imágenes se prueban para ejecutarse de forma fluida dentro
  de clústeres de Kubernetes, asegurando que cumplan con los requisitos para entornos de
  orquestación de contenedores.

## Pruebas de funcionalidad de la aplicación

Docker prueba las Docker Hardened Images para garantizar que se comporten como se espera en
escenarios típicos de uso. Esto incluye verificar que:

- Las aplicaciones se inicien y ejecuten correctamente en entornos de contenedores.
- El comportamiento en tiempo de ejecución se alinee con las expectativas de upstream.
- Las variantes de construcción (como las imágenes `-dev`) admitan las tareas comunes de
  desarrollo y construcción.

El objetivo es garantizar que las DHI funcionen de inmediato para los casos de uso más comunes,
manteniendo al mismo tiempo el diseño minimalista y endurecido.

## Pruebas automatizadas e integración con CI/CD

Docker integra pruebas automatizadas en sus pipelines de Integración Continua/Despliegue Continuo
(CI/CD):

- Escaneos automatizados: Cada construcción de imagen activa escaneos automatizados para
  detectar vulnerabilidades y realizar comprobaciones de cumplimiento.
- Construcciones reproducibles: Los procesos de construcción están diseñados para ser
  reproducibles, garantizando la consistencia en diferentes entornos.
- Supervisión continua: Docker supervisa continuamente nuevas vulnerabilidades y actualiza las
  imágenes en consecuencia para mantener los estándares de seguridad.

## Atestación de pruebas

Docker proporciona una atestación de pruebas que detalla los procesos de prueba y validación a
los que se ha sometido cada DHI.

### Visualizar y verificar la atestación de pruebas

Puedes ver y verificar esta atestación utilizando la CLI de Docker Scout.

1. Utiliza el comando `docker scout attest get` con el tipo de predicado de prueba:

   ```console
   $ docker scout attest get \
     --predicate-type https://scout.docker.com/tests/v0.1 \
     --predicate \
     dhi.io/<image>:<tag>
   ```

   > [!NOTE]
   >
   > Si la imagen existe localmente en tu dispositivo, debes anteponer el prefijo `registry://`
   > al nombre de la imagen. Por ejemplo, utiliza `registry://dhi.io/python` en lugar de
   > `dhi.io/python`.

   Por ejemplo:

   ```console
   $ docker scout attest get \
     --predicate-type https://scout.docker.com/tests/v0.1 \
     --predicate \
     dhi.io/python:3.13
   ```

   Esto contiene una lista de pruebas y sus resultados.

   Ejemplo de salida:

    ```console
        v SBOM obtained from attestation, 101 packages found
        v Provenance obtained from attestation
        {
          "reportFormat": "CTRF",
          "results": {
            "summary": {
              "failed": 0,
              "passed": 1,
              "skipped": 0,
              "start": 1749216533,
              "stop": 1749216574,
              "tests": 1
            },
            "tests": [
              {
                ...
   ```

2. Verifica la firma de la atestación de pruebas. Para asegurarte de que la atestación es
   auténtica y está firmada por Docker, ejecuta:

   ```console
   docker scout attest get \
     --predicate-type https://scout.docker.com/tests/v0.1 \
     --verify \
     dhi.io/<image>:<tag> --platform <platform>
   ```

   Ejemplo de salida:
   
   ```console
    v SBOM obtained from attestation, 101 packages found
    v Provenance obtained from attestation
    v cosign verify registry.scout.docker.com/docker/dhi-python@sha256:70c8299c4d3cb4d5432734773c45ae58d8acc2f2f07803435c65515f662136d5 \
        --key https://registry.scout.docker.com/keyring/dhi/latest.pub --experimental-oci11

      Verification for registry.scout.docker.com/docker/dhi-python@sha256:70c8299c4d3cb4d5432734773c45ae58d8acc2f2f07803435c65515f662136d5 --
      The following checks were performed on each of these signatures:
        - The cosign claims were validated
        - Existence of the claims in the transparency log was verified offline
        - The signatures were verified against the specified public key

    i Signature payload
    ...
    ```

Si la atestación es válida, Docker Scout confirmará la firma y mostrará el comando `cosign
verify` correspondiente.

Para ver otras atestaciones, como SBOM o informes de vulnerabilidad, consulta [Verificar una
imagen](/dhi/how-to/verify/).