Compartir comentarios
Las respuestas se generan en base a la documentación.

Introducción a la evaluación de políticas en Docker Scout

Tabla de contenidos

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. 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:

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 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.

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, 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.

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.

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.

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:

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 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.

Atestaciones de la cadena de suministro

El tipo de política Supply Chain Attestations comprueba si tus imágenes tienen atestaciones SBOM y de procedencia (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:

$ docker buildx build --provenance=true --sbom=true -t <IMAGE> --push .

Para obtener más información sobre la compilación con atestaciones, consulta Atestaciones.

Si estás utilizando GitHub Actions para compilar y enviar tus imágenes, aprende cómo puedes configurar la acción 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:

FROM alpine
RUN echo "Hi"

Mientras que en el siguiente caso, el usuario root se configura explícitamente:

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 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.

FROM alpine AS builder
COPY Makefile ./src /
RUN make build

FROM alpine AS runtime
COPY --from=builder bin/production /app
ENTRYPOINT ["/app/production"]
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 usoPatrón
Permitir todas las imágenes de Docker Hubdocker.io/*
Permitir todas las Imágenes Oficiales de Dockerdocker.io/library/*
Permitir imágenes de una organización específicadocker.io/orgname/*
Permitir etiquetas de un repositorio específicodocker.io/orgname/repository:*
Permitir imágenes en un registro con el nombre de host registry.example.comregistry.example.com/*
Permitir etiquetas slim de imágenes NodeJSdocker.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.

Puertas de calidad de SonarQube

El tipo de política SonarQube Quality Gates se basa en la integración con 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) 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) 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

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) durante la compilación. Docker Scout utiliza atestaciones de procedencia para averiguar la versión de la imagen base.