Análisis de vulnerabilidades

Container Analysis proporciona análisis de vulnerabilidades y almacenamiento de metadatos para contenedores. En esta página, se describe el análisis de vulnerabilidades.

Análisis de vulnerabilidades

Las vulnerabilidades de software son debilidades que pueden provocar una falla accidental del sistema o que alguien puede usar en su beneficio intencionalmente.

Container Analysis realiza análisis de vulnerabilidades en imágenes de Container Registry y supervisa la información sobre las vulnerabilidades para mantenerla actualizada. Este proceso consta de dos tareas principales: análisis y análisis continuo.

Cuando se completa el análisis de una imagen, el resultado de vulnerabilidad producido es el conjunto de casos de vulnerabilidades para esa imagen.

Análisis

Container Analysis analiza las imágenes nuevas cuando se suben a Container Registry. Este análisis extrae información sobre los paquetes del sistema en el contenedor.

Container Analysis analiza las imágenes solo una vez, según el resumen de la imagen. Esto significa que agregar o modificar etiquetas no activará análisis nuevos; solo cambiará el contenido de la imagen.

Container Analysis solo detecta paquetes supervisados de forma pública para las vulnerabilidades de seguridad.

Análisis continuo

Container Analysis crea casos de vulnerabilidades que se encuentran cuando subes la imagen. Después del análisis inicial, supervisa de forma continua los metadatos de las imágenes analizadas en Container Registry para detectar vulnerabilidades nuevas.

A medida que Container Analysis recibe información nueva y actualizada sobre vulnerabilidades de la fuente de vulnerabilidades, actualiza los metadatos de las imágenes analizadas a fin de mantenerlas actualizadas, lo que crea nuevos casos de vulnerabilidades para las nuevasnotas y eliminar casos de vulnerabilidades que ya no son válidos.

Fuente de vulnerabilidad

La API de Container Analysis admite el análisis de vulnerabilidades de los paquetes para distribuciones de Linux y obtiene datos de CVE de las siguientes fuentes:

Versiones compatibles

Container Analysis admite el análisis de vulnerabilidades para las siguientes versiones de SO:

  • Debian GNU/Linux: Versiones 9, 10
  • Ubuntu: Versiones: 12.04, 12.10, 13.04, 14.04, 14.10, 15.04, 15.10, 16.05, 16.10, 17.04, 17.10, 18.04, 18.10, 20.04
  • Alpine Linux: Versiones: 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12
  • CentOS: Versiones: 6, 7, 8 y versiones anteriores
  • Red Hat: Versiones: 6, 7, 8 y versiones secundarias

Niveles de gravedad de las vulnerabilidades

Container Analysis utiliza los siguientes niveles de gravedad:

  • Crítico
  • Alto
  • Medio
  • Bajo
  • Mínimo

Los niveles de gravedad son etiquetas cualitativas que reflejan factores como la capacidad de explotación, el alcance, el impacto y la madurez de la vulnerabilidad. Por ejemplo, si una vulnerabilidad permite que un usuario remoto acceda con facilidad a un sistema y ejecute código arbitrario sin autenticación ni interacción del usuario, esa vulnerabilidad se clasifica como crítica.

Hay dos tipos de gravedad asociados con cada vulnerabilidad:

  • Gravedad efectiva: el nivel de gravedad que asigna la distribución de Linux. Si los niveles de gravedad específicos de la distribución no están disponibles, Container Analysis usa el nivel de gravedad que le asigna el proveedor de la nota.

  • Puntuación de CVSS: La puntuación del sistema Common Vulnerability Scoring System (CVSS) y el nivel de gravedad asociado. Consulta la especificación CVSS 3.0 para obtener detalles sobre cómo se calculan las puntuaciones de CVSS.

Para una vulnerabilidad determinada, es posible que la gravedad derivada de la puntuación de CVSS calculada no coincida con la gravedad efectiva. Las distribuciones de Linux que asignan niveles de gravedad usan sus propios criterios para evaluar los impactos específicos de una vulnerabilidad en sus distribuciones.

Cuenta de servicio de Container Analysis predeterminada

Container Analysis analiza tus imágenes de contenedor con una cuenta de servicio, una Cuenta de Google especial que recopila información sobre tus imágenes en tu nombre. El correo electrónico de la cuenta de servicio de Container Analysis es service-[PROJECT_NUMBER]@container-analysis.iam.gserviceaccount.com. Esta cuenta utiliza la función agente de servicio de Container Analysis.

Si habilitas el análisis de vulnerabilidades, la API de Container Scanning que usa esta función también utiliza una Cuenta de Google especial. El correo electrónico de esa cuenta de servicio es service-[PROJECT_NUMBER]@gcp-sa-containerscanning.iam.gserviceaccount.com. La cuenta utiliza la función agente del servicio de Container Scanner.

Puedes ver las cuentas de servicio de tu proyecto a través del Menú de IAM de Cloud Console.

Interfaces de Container Analysis

En Cloud Console, puedes ver las vulnerabilidades de imágenes y los metadatos de los contenedores en Container Registry.

Puedes usar la herramienta gcloud para ver las vulnerabilidades y los metadatos de las imágenes.

También puedes usar la API de REST de Container Analysis para realizar cualquiera de estas acciones. Al igual que con otras API de Cloud Platform, debes autenticar el acceso con OAuth2. Una vez que te hayas autenticado, puedes usar la API para crear casos y notas nuevas, ver los casos de vulnerabilidades, etcétera.

La API de Container Analysis admite gRPC y REST/JSON. Puedes realizar llamadas a la API a través de las bibliotecas cliente o mediante el uso de cURL para REST/JSON.

Controla la implementación de imágenes vulnerables

Según la información de vulnerabilidad que proporciona Container Analysis, puedes usar la autorización binaria para crear una lista de anunciantes permitidos de vulnerabilidad como parte de tu canalización de Cloud Build. Si las vulnerabilidades infringen la política en la lista de anunciantes permitidos, la compilación falla.

También puedes integrar Container Analysis en la autorización binaria para crear certificaciones, lo que puede evitar que las imágenes de contenedor con problemas de seguridad conocidos se ejecuten en la implementación.

¿Qué sigue?