# Introducción a la evaluación de políticas en Docker Scout En la gestión de la cadena de suministro de software, mantener la seguridad y fiabilidad de los artefactos es una prioridad absoluta. La evaluación de políticas en Docker Scout introduce una capa de control sobre las capacidades de análisis existentes. Te permite definir reglas de la cadena de suministro para tus artefactos y te ayuda a realizar un seguimiento de su rendimiento, en relación con tus reglas y umbrales, a lo largo del tiempo. Aprende cómo puedes utilizar la evaluación de políticas para garantizar que tus artefactos se alineen con las mejores prácticas establecidas. ## Cómo funciona la evaluación de políticas Cuando activas Docker Scout para un repositorio, las imágenes que envías se [analizan automáticamente](/scout/explore/analysis/). El análisis te ofrece información detallada sobre la composición de tus imágenes, incluyendo qué paquetes contienen y a qué vulnerabilidades están expuestas. La evaluación de políticas se basa en la función de análisis de imágenes, interpretando los resultados del análisis frente a las reglas definidas por las políticas. Una política define los criterios de calidad de imagen que deben cumplir tus artefactos. Por ejemplo, la política **No AGPL v3 licenses** (Sin licencias AGPL v3) marca cualquier imagen que contenga paquetes distribuidos bajo la licencia AGPL v3. Si una imagen contiene dicho paquete, esa imagen no cumple con esta política. Algunas políticas, como la política **No AGPL v3 licenses**, son configurables. Las políticas configurables te permiten ajustar los criterios para adaptarse mejor a las necesidades de tu organización. En Docker Scout, las políticas están diseñadas para ayudarte a mejorar progresivamente tu postura de seguridad y de cadena de suministro. Mientras que otras herramientas se centran en proporcionar un estado de aprobado o reprobado, las políticas de Docker Scout visualizan cómo los pequeños cambios incrementales afectan al estado de la política, incluso cuando tus artefactos no cumplen con los requisitos de la política (todavía). Al realizar un seguimiento de cómo cambia la brecha de incumplimiento a lo largo del tiempo, puedes ver más fácilmente si tu artefacto está mejorando o deteriorándose en relación con la política. Las políticas no tienen por qué estar relacionadas necesariamente con la seguridad de las aplicaciones y las vulnerabilidades. También puedes utilizar políticas para medir y realizar un seguimiento de otros aspectos de la gestión de la cadena de suministro, como el uso de licencias de código abierto y la actualización de la imagen base. ## Tipos de políticas En Docker Scout, una _política_ se deriva de un _tipo de política_. Los tipos de políticas son plantillas que definen los parámetros principales de una política. Puedes comparar los tipos de políticas con las clases en la programación orientada a objetos, donde cada política actúa como una instancia creada a partir de su tipo de política correspondiente. Docker Scout admite los siguientes tipos de políticas: - [Vulnerabilidad basada en gravedad](#vulnerabilidad-basada-en-gravedad) - [Licencias conformes](#licencias-conformes) - [Imágenes base actualizadas](#imagenes-base-actualizadas) - [Vulnerabilidades de alto perfil](#vulnerabilidades-de-alto-perfil) - [Atestaciones de la cadena de suministro](#atestaciones-de-la-cadena-de-suministro) - [Usuario no root por defecto](#usuario-no-root-por-defecto) - [Imágenes base aprobadas](#imagenes-base-aprobadas) - [Puertas de calidad de SonarQube](#puertas-de-calidad-de-sonarqube) - [Imagen endurecida de Docker (DHI) válida o imagen base DHI](#imagen-endurecida-de-docker-dhi-valida-o-imagen-base-dhi) Docker Scout proporciona automáticamente políticas por defecto para los repositorios donde está habilitado, excepto para las siguientes políticas, que son opcionales y deben configurarse: - La política **SonarQube Quality Gates**, que requiere la [integración con SonarQube](/scout/integrations/code-quality/sonarqube/) antes de su uso. - La política **Valid Docker Hardened Image (DHI) or DHI base image**, que se puede configurar si deseas imponer el uso de Docker Hardened Images. Puedes crear políticas personalizadas a partir de cualquiera de los tipos de políticas admitidos, o eliminar una política por defecto si no es aplicable a tu proyecto. Para obtener más información, consulta [Configurar políticas](/scout/configure/). ### Vulnerabilidad basada en gravedad El tipo de política **Severity-Based Vulnerability** comprueba si tus artefactos están expuestos a vulnerabilidades conocidas. Por defecto, esta política solo marca vulnerabilidades de gravedad crítica y alta para las cuales hay una versión de corrección disponible. Esencialmente, esto significa que hay una solución fácil que puedes implementar para las imágenes que no cumplen con esta política: actualizar el paquete vulnerable a una versión que contenga una corrección para la vulnerabilidad. Las imágenes se consideran no conformes con esta política si contienen una o más vulnerabilidades que quedan fuera de los criterios especificados en la política. Puedes configurar los parámetros de esta política creando una versión personalizada de la misma. Los siguientes parámetros de política son configurables en una versión personalizada: - **Antigüedad** (Age): El número mínimo de días desde que se publicó por primera vez la vulnerabilidad. La razón para marcar únicamente las vulnerabilidades de una cierta antigüedad mínima es que las vulnerabilidades recién descubiertas no deberían hacer que tus evaluaciones fallen hasta que hayas tenido la oportunidad de abordarlas. - **Gravedades** (Severities): Niveles de gravedad a considerar (por defecto: `Critical, High`). - **Solo vulnerabilidades solucionables** (Fixable vulnerabilities only): Si se deben reportar únicamente las vulnerabilidades que tienen una versión de corrección disponible (habilitado por defecto). - **Tipos de paquetes** (Package types): Lista de tipos de paquetes a considerar. Esta opción te permite especificar los tipos de paquetes, como [definiciones de tipo de paquete PURL](https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst), que deseas incluir en la evaluación de políticas. Por defecto, la política considera todos los tipos de paquetes. Para obtener más información sobre la configuración de políticas, consulta [Configurar políticas](/scout/configure/). ### Licencias conformes El tipo de política **Compliant Licenses** comprueba si tus imágenes contienen paquetes distribuidos bajo una licencia inadecuada. Las imágenes se consideran no conformes si contienen uno o más paquetes con dicha licencia. Puedes configurar la lista de licencias que esta política debe buscar y agregar excepciones especificando una lista de permitidos (en forma de PURLs). Consulta [Configurar políticas](/scout/configure/). ### Imágenes base actualizadas El tipo de política **Up-to-Date Base Images** comprueba si las imágenes base que utilizas están actualizadas. Las imágenes se consideran no conformes con esta política si la etiqueta que utilizaste para compilar tu imagen apunta a un resumen (digest) diferente al que estás usando. Si hay una discrepancia en los resúmenes, significa que la imagen base que estás usando está desactualizada. Tus imágenes necesitan atestaciones de procedencia (provenance) para que esta política se evalúe correctamente. Para obtener más información, consulta [Sin datos de imagen base](#sin-datos-de-imagen-base). ### Vulnerabilidades de alto perfil El tipo de política **High-Profile Vulnerabilities** comprueba si tus imágenes contienen vulnerabilidades de la lista seleccionada de Docker Scout. Esta lista se mantiene actualizada con vulnerabilidades recién divulgadas que son ampliamente reconocidas como riesgosas. La lista incluye las siguientes vulnerabilidades: - [CVE-2014-0160 (OpenSSL Heartbleed)](https://scout.docker.com/v/CVE-2014-0160) - [CVE-2021-44228 (Log4Shell)](https://scout.docker.com/v/CVE-2021-44228) - [CVE-2023-38545 (cURL SOCKS5 heap buffer overflow)](https://scout.docker.com/v/CVE-2023-38545) - [CVE-2023-44487 (HTTP/2 Rapid Reset)](https://scout.docker.com/v/CVE-2023-44487) - [CVE-2024-3094 (XZ backdoor)](https://scout.docker.com/v/CVE-2024-3094) - [CVE-2024-47176 (OpenPrinting - `cups-browsed`)](https://scout.docker.com/v/CVE-2024-47176) - [CVE-2024-47076 (OpenPrinting - `libcupsfilters`)](https://scout.docker.com/v/CVE-2024-47076) - [CVE-2024-47175 (OpenPrinting - `libppd`)](https://scout.docker.com/v/CVE-2024-47175) - [CVE-2024-47177 (OpenPrinting - `cups-filters`)](https://scout.docker.com/v/CVE-2024-47177) Puedes personalizar esta política para cambiar qué CVE se consideran de alto perfil configurando la política. Las opciones de configuración personalizada incluyen: - **CVE excluidas** (Excluded CVEs): Especifica las CVE que deseas que esta política ignore. Por defecto: `[]` (ninguna de las CVE de alto perfil se ignora) - **CISA KEV**: Habilita el seguimiento de vulnerabilidades del catálogo de Vulnerabilidades Conocidas y Explotadas (KEV) de CISA. El [catálogo KEV de CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) incluye vulnerabilidades que se están explotando activamente en entornos reales. Cuando está habilitada, la política marca las imágenes que contienen vulnerabilidades del catálogo KEV de CISA. Habilitado por defecto. Para obtener más información sobre la configuración de políticas, consulta [Configurar políticas](/scout/configure/). ### Atestaciones de la cadena de suministro El tipo de política **Supply Chain Attestations** comprueba si tus imágenes tienen atestaciones [SBOM](/build/metadata/attestations/sbom/) y de [procedencia (provenance)](/build/metadata/attestations/slsa-provenance/). Las imágenes se consideran no conformes si carecen de una atestación SBOM o de una atestación de procedencia con procedencia de _modo max_. Para garantizar el cumplimiento, actualiza tu comando de compilación para adjuntar estas atestaciones durante la compilación: ```console $ docker buildx build --provenance=true --sbom=true -t --push . ``` Para obtener más información sobre la compilación con atestaciones, consulta [Atestaciones](/build/metadata/attestations/). Si estás utilizando GitHub Actions para compilar y enviar tus imágenes, aprende cómo puedes [configurar la acción](/build/ci/github-actions/attestations/) para aplicar atestaciones SBOM y de procedencia. ### Usuario no root por defecto Por defecto, los contenedores se ejecutan como el superusuario `root` con privilegios completos de administración del sistema dentro del contenedor, a menos que el Dockerfile especifique un usuario predeterminado diferente. Ejecutar contenedores como un usuario privilegiado debilita su seguridad en tiempo de ejecución, ya que significa que cualquier código que se ejecute en el contenedor puede realizar acciones administrativas. El tipo de política **Default Non-Root User** detecta imágenes configuradas para ejecutarse como el usuario `root` predeterminado. Para cumplir con esta política, las imágenes deben especificar un usuario no root en la configuración de la imagen. Las imágenes no cumplen con esta política si no especifican un usuario predeterminado que no sea root para la etapa de ejecución (runtime). Para las imágenes no conformes, los resultados de la evaluación muestran si el usuario `root` se configuró explícitamente para la imagen o no. Esto te ayuda a distinguir entre las violaciones de la política causadas por imágenes donde el usuario `root` es implícito, y imágenes donde `root` se configura a propósito. El siguiente Dockerfile se ejecuta como `root` por defecto a pesar de no estar configurado explícitamente: ```Dockerfile FROM alpine RUN echo "Hi" ``` Mientras que en el siguiente caso, el usuario `root` se configura explícitamente: ```Dockerfile FROM alpine USER root RUN echo "Hi" ``` > [!NOTE] > > Esta política solo comprueba el usuario predeterminado de la imagen, tal como está configurado en el > blob de configuración de la imagen. Incluso si especificas un usuario predeterminado que no sea root, > todavía es posible invalidar el usuario predeterminado en tiempo de ejecución, por ejemplo, utilizando la > bandera `--user` para el comando `docker run`. Para que tus imágenes cumplan con esta política, utiliza la instrucción del [`USER`](/reference/dockerfile/#user) Dockerfile para configurar un usuario predeterminado que no tenga privilegios de root para la etapa de ejecución. Los siguientes fragmentos de Dockerfile muestran la diferencia entre una imagen conforme y una no conforme. **No conforme** ```dockerfile FROM alpine AS builder COPY Makefile ./src / RUN make build FROM alpine AS runtime COPY --from=builder bin/production /app ENTRYPOINT ["/app/production"] ``` **Conforme** ```dockerfile {hl_lines=7} FROM alpine AS builder COPY Makefile ./src / RUN make build FROM alpine AS runtime COPY --from=builder bin/production /app USER nonroot ENTRYPOINT ["/app/production"] ``` ### Imágenes base aprobadas El tipo de política **Approved Base Images** garantiza que las imágenes base que utilizas en tus compilaciones se mantengan y sean seguras. Esta política comprueba si las imágenes base utilizadas en tus compilaciones coinciden con alguno de los patrones especificados en la configuración de la política. La siguiente tabla muestra algunos patrones de ejemplo para esta política. | Caso de uso | Patrón | | ----------------------------------------------------------------------------- | -------------------------------- | | Permitir todas las imágenes de Docker Hub | `docker.io/*` | | Permitir todas las Imágenes Oficiales de Docker | `docker.io/library/*` | | Permitir imágenes de una organización específica | `docker.io/orgname/*` | | Permitir etiquetas de un repositorio específico | `docker.io/orgname/repository:*` | | Permitir imágenes en un registro con el nombre de host `registry.example.com` | `registry.example.com/*` | | Permitir etiquetas slim de imágenes NodeJS | `docker.io/library/node:*-slim` | Un asterisco (`*`) coincide hasta el carácter que le sigue, o hasta el final de la referencia de la imagen. Ten en cuenta que se requiere el prefijo `docker.io` para que coincida con las imágenes de Docker Hub. Este es el nombre de host del registro de Docker Hub. Esta política se puede configurar con las siguientes opciones: - **Fuentes de imágenes base aprobadas** (Approved base image sources) Especifica los patrones de referencia de imagen que deseas permitir. La política evalúa las referencias de imagen base frente a estos patrones. Por defecto: `[*]` (cualquier referencia es una imagen base permitida) - **Solo etiquetas compatibles** (Only supported tags) Permitir únicamente las etiquetas compatibles cuando se utilicen Imágenes Oficiales de Docker. Cuando esta opción está habilitada, las imágenes que utilizan etiquetas no compatibles de imágenes oficiales como su imagen base activan una violación de la política. Las etiquetas compatibles para las imágenes oficiales se enumeran en la sección **Supported tags** del resumen del repositorio en Docker Hub. Habilitado por defecto. - **Solo distribuciones de SO compatibles** (Only supported OS distributions) Permitir únicamente Imágenes Oficiales de Docker de versiones de distribuciones Linux compatibles. Cuando esta opción está habilitada, las imágenes que utilizan distribuciones de Linux no compatibles que han llegado al final de su vida útil (como `ubuntu:18.04`) activan una violación de la política. Habilitar esta opción puede hacer que la política informe que no hay datos si no se puede determinar la versión del sistema operativo. Habilitado por defecto. Tus imágenes necesitan atestaciones de procedencia (provenance) para que esta política se evalúe correctamente. Para obtener más información, consulta [Sin datos de imagen base](#sin-datos-de-imagen-base). ### Puertas de calidad de SonarQube El tipo de política **SonarQube Quality Gates** se basa en la [integración con SonarQube](/integrations/code-quality/sonarqube/) para evaluar la calidad de tu código fuente. Esta política funciona ingiriendo los resultados del análisis de código de SonarQube en Docker Scout. Defines los criterios para esta política utilizando las [puertas de calidad (quality gates)](https://docs.sonarsource.com/sonarqube/latest/user-guide/quality-gates/) de SonarQube. SonarQube evalúa tu código fuente frente a las puertas de calidad que hayas definido en SonarQube. Docker Scout muestra la evaluación de SonarQube como una política de Docker Scout. Docker Scout utiliza atestaciones de [procedencia (provenance)](/build/metadata/attestations/slsa-provenance/) o la anotación OCI `org.opencontainers.image.revision` para vincular los resultados del análisis de SonarQube con las imágenes de contenedor. Además de habilitar la integración de SonarQube, también debes asegurarte de que tus imágenes tengan la atestación o la etiqueta. ![El SHA del commit de Git vincula la imagen con el análisis de SonarQube](/images/scout-sq-commit-sha.webp) Una vez que envías una imagen y se completa la evaluación de la política, los resultados de las puertas de calidad de SonarQube se muestran como una política en el Docker Scout Dashboard y en la CLI. > [!NOTE] > > Docker Scout solo puede acceder a los análisis de SonarQube creados después de que se habilite la > integración. Docker Scout no tiene acceso a las evaluaciones históricas. Activa > un análisis de SonarQube y una evaluación de política después de habilitar la integración para > ver los resultados en Docker Scout. ### Imagen endurecida de Docker (DHI) válida o imagen base DHI El tipo de política **Valid Docker Hardened Image (DHI) or DHI base image** garantiza que tus imágenes sean Docker Hardened Images (DHI) o estén compiladas utilizando una DHI como imagen base. Esta política valida las imágenes comprobando si existe una atestación de resumen de verificación firmada por Docker que sea válida. La política considera que una imagen es conforme si: - La imagen en sí es una Docker Hardened Image con una atestación de resumen de verificación firmada por Docker válida, o - La imagen base utilizada en la compilación (identificada a partir de las atestaciones de procedencia SLSA) tiene una atestación de resumen de verificación firmada por Docker válida. Las imágenes no cumplen con esta política si carecen de la atestación de resumen de verificación firmada por Docker requerida y no están compiladas a partir de una imagen base con dicha atestación. Esta política no tiene parámetros configurables. ## Sin datos de imagen base Existen casos en los que no es posible determinar información sobre las imágenes base utilizadas en tus compilaciones. En tales casos, las políticas **Up-to-Date Base Images** y **Approved Base Images** se marcan como **No data** (Sin datos). Este estado de "sin datos" ocurre cuando: - Docker Scout no sabe qué etiqueta de imagen base utilizaste. - La versión de la imagen base que utilizaste tiene múltiples etiquetas, pero no todas las etiquetas están desactualizadas. Para asegurarte de que Docker Scout siempre conozca tu imagen base, puedes adjuntar [atestaciones de procedencia (provenance)](/build/metadata/attestations/slsa-provenance/) durante la compilación. Docker Scout utiliza atestaciones de procedencia para averiguar la versión de la imagen base.