Skip to main content

El 80 % de los desarrolladores no aborda la seguridad de Docker

Escrito por

William Henry

Docker report DARK

17 de abril de 2019

0 minutos de lectura

Te damos la bienvenida al informe sobre seguridad de Docker: Adelantar la seguridad de Docker. Este informe se divide en varias publicaciones:

También puedes descargar nuestro informe en PDF, elaborado con mucho esmero, que reúne toda esta información y mucho más en un solo lugar.

Responsabilidad sobre la seguridad de los contenedores

Cuando Docker es una parte integral de tu propio ecosistema, alguien debe hacerse responsable. La mayoría coincide en que esa responsabilidad es compartida. Al preguntar quién es responsable de la seguridad de los contenedores (con la opción de elegir más de una respuesta), la mayoría de las personas encuestadas opinó que los desarrolladores deberían hacerse cargo de ella (68 %), seguidos por los equipos de operaciones (39 %).

Gráfico de barras que pregunta quién es responsable de la seguridad de las imágenes de contenedores: desarrolladores, 68 %; operaciones, 39 %; equipo de seguridad, 27 %; otros, 3 %; nadie, 12 %.

Aunque la responsabilidad de la seguridad es compartida en DevOps o, mejor aún, en DevSecOps, vemos que la mayoría considera que los desarrolladores tienen un papel clave. Esto coincide con lo que vemos respecto a la responsabilidad por la seguridad del código de las aplicaciones. Según el informe El estado de la seguridad del código abierto, el 81 % de las personas encuestadas cree que los desarrolladores deberían hacerse responsables de la seguridad de sus aplicaciones.

También puede ser conveniente que las organizaciones colaboren con el proveedor de confianza de las imágenes base para gestionar algunos de los riesgos de seguridad al trabajar con sus pipelines de CI/CD. Proveedores como Red Hat ofrecen imágenes analizadas y firmadas. También responden rápidamente a las CVE en imágenes base, lo que puede activar la reconstrucción de las imágenes de las aplicaciones en los pipelines de CI/CD. Esto no elimina la necesidad de realizar análisis durante el ciclo de vida de DevOps, pero reduce el tiempo entre la presencia de imágenes vulnerables en producción y la disponibilidad de imágenes seguras. Compartir el riesgo con un tercero puede ayudar a reducir el riesgo general.

Pruebas de seguridad en la capa del sistema operativo

Lamentablemente, solo el 19 % de los desarrolladores afirma analizar sus imágenes de Docker durante el desarrollo para detectar vulnerabilidades en la capa del sistema operativo. Esto significa que más del 80 % de los desarrolladores no adelanta la seguridad para analizar sus imágenes durante el desarrollo. Descubrir las vulnerabilidades más adelante resulta más costoso.

Además, la mitad de las personas usuarias (50 %) no realiza ningún tipo de análisis de la capa del sistema operativo de sus imágenes de Docker. Es importante saber qué contiene esa capa. Usar imágenes de Docker a ciegas es muy peligroso, ya que sin duda incorporarán innumerables vulnerabilidades. Puedes reducir el riesgo fácilmente si las analizas y primero identificas las vulnerabilidades conocidas de cada imagen que estés considerando.

Gráfico de barras horizontal que pregunta cuándo se analizan las imágenes de Docker en busca de vulnerabilidades del sistema operativo: el 50 % responde que no las analiza, el 31 % lo hace durante la compilación y el 19 % durante el desarrollo.

Al usar una herramienta para analizar imágenes de Docker, como la que ofrece Snyk, puedes detectar las imágenes vulnerables durante todo el ciclo de desarrollo. El proceso comienza en el entorno local: cuando un desarrollador elige una imagen de Docker, el análisis impide que las imágenes vulnerables ingresen en tu entorno. Repite el análisis en todas las etapas y hasta el final del pipeline de CI/CD para evitar que una imagen con vulnerabilidades conocidas llegue a producción.

Es natural que se descubran vulnerabilidades en las imágenes con el paso del tiempo, por lo que es fundamental dar seguimiento a las imágenes en producción. El tiempo promedio hasta que se encuentra y se reporta una vulnerabilidad es de 2,5 años. Actualmente, solo el 9 % de las personas usuarias afirma analizar sus imágenes en producción. Una imagen pudo haber sido segura cuando se implementó en producción, pero a partir de ese momento, más del 90 % de los desarrolladores desconoce el estado actual de seguridad de sus imágenes.

Cómo descubrir vulnerabilidades

También preguntamos cómo se enteran las personas de que un contenedor que están usando tiene vulnerabilidades divulgadas. Es probable que el 45 % nunca lo verifique. Una cantidad considerable de personas encuestadas (15 %) consulta bases de datos públicas, como la base de datos de CVE. Sin embargo, ten en cuenta que la base de datos de CVE es apenas la punta del iceberg. El proceso de registro de una CVE puede tardar varias semanas y muchas vulnerabilidades quizá ni siquiera lleguen a registrarse como CVE, aunque aún representen un riesgo importante para tu sistema.

Gráfico de barras que muestra cómo se detectan nuevas vulnerabilidades en contenedores implementados: herramientas de análisis 33 %, equipo de seguridad 22 %, bases de datos 15 %, otros 3 %, probablemente no se detecten 45 %.

Sigue leyendo:

Descarga el informe ahora!

Leer más

feature customer snowflake
Article

Seguridad desde el inicio: presentamos la integración de Snyk Studio con Snowflake Cortex Code

Snyk Studio se integra con Snowflake Cortex Code para analizar código generado por IA, dependencias y contenedores en busca de vulnerabilidades durante el desarrollo.

blog feature pypi spoof
Article

Toda la Snyk AI Security Platform, gratis para quienes mantienen proyectos de código abierto

Quienes mantienen proyectos de código abierto reciben reportes de vulnerabilidades reales sin parar y necesitan ayuda para priorizarlas, corregirlas y publicar soluciones más rápido. El Secure Developer Program de Snyk ofrece a los proyectos que cumplen los requisitos acceso gratis a Snyk AI Security Platform.

feature insights announcement
Blog

Compromiso de la cadena de suministro de node-gyp: un gusano de npm que se propaga solo y se oculta en binding.gyp

Un nuevo gusano de npm abusa de binding.gyp para activar node-gyp durante la instalación y permitir que paquetes maliciosos ejecuten código sin scripts del ciclo de vida. Roba credenciales, persiste en GitHub y se propaga entre mantenedores.