Skip to main content

Presentamos el Informe sobre el estado de la seguridad del código abierto de 2017

Escrito por
Headshot of Tim Kadlec

Tim Kadlec

16 de noviembre de 2017

0 minutos de lectura

Conoce nuestro nuevo Informe sobre seguridad del código abierto de 2020. Este informe analiza las preocupaciones sobre la seguridad del código abierto en 2020 y las tendencias de vulnerabilidades en paquetes e imágenes de contenedores.

¡Hoy nos entusiasma presentar el Informe sobre el estado de la seguridad del código abierto de 2017! Puedes descargar el informe completo como PDF gratuito.

El código abierto es increíble y crece rápidamente. Cuantas más empresas dependen de él para sus aplicaciones, más importante es garantizar que los componentes que desarrollamos y usamos sean seguros. El Informe sobre el estado de la seguridad del código abierto ofrece una visión general del panorama de la seguridad del código abierto: analiza dónde estamos hoy y qué podemos hacer para tener más seguridad mañana.

El informe reúne datos de una encuesta que realizamos en septiembre a más de 500 usuarios y mantenedores de código abierto (¡muchísimas gracias a todas las personas que respondieron!), datos internos de Snyk basados en más de 40,000 proyectos, así como información publicada por Red Hat Linux y datos que recopilamos al analizar millones de repositorios de Github y paquetes en registros. Trabajamos con el increíble equipo de Sparkbox para reunir todo en un sitio web y un PDF con un diseño atractivo.

El informe reveló muchísimos datos interesantes. Por ejemplo, ¿sabías que:

  • Las vulnerabilidades en bibliotecas de código abierto aumentaron un 53.8% en 2016, mientras que las vulnerabilidades de Red Hat Linux disminuyeron.

  • El tiempo promedio desde que se crea por primera vez una vulnerabilidad en un paquete hasta que se divulga es de 2.5 años, pero el tiempo promedio desde la divulgación hasta que se publica una corrección es de solo 16 días.

  • El 79.5% de los mantenedores de código abierto afirma no tener una política de divulgación pública, y quienes sí la tienen tienen más de tres veces más probabilidades de recibir una divulgación privada sobre una vulnerabilidad.

  • De los 433,000 sitios analizados, el 77% ejecuta al menos una biblioteca de JavaScript del lado del cliente con una vulnerabilidad de seguridad conocida.

Como señalamos en la conclusión del informe, proteger el código abierto no sucederá de la noche a la mañana. Pero si nos unimos y hacemos un esfuerzo consciente por dar pequeños pasos para mejorar nuestra postura de seguridad, podremos mejorar el estado de la seguridad del código abierto y, en el proceso, garantizar que siga siendo un ecosistema dinámico y próspero.

Leer más

blog feature ai lilac
Blog

Convierte tu backlog de vulnerabilidades en pull requests con la remediación agéntica

Evo Remediation Agent ya está disponible en Open Preview e incorpora la resolución automatizada de dependencias a Evo Agentic AppSec. Ahora, los equipos de AppSec pueden ejecutar campañas de remediación continuas

illustration hero ai
Blog

PHP corrige dos vulnerabilidades críticas de RCE sin autenticación (CVE-2026-109618, CVE-2026-109619): actualiza ahora

Dos fallas críticas en el ciclo de solicitudes de PHP pueden permitir la ejecución remota de código sin autenticación. Actualiza a una versión corregida o instala una corrección retroportada por un proveedor para las versiones anteriores.

blog feature ai pink
Blog

El riesgo de un modelo de IA depende de a qué puede acceder

La puntuación de riesgo de un modelo es solo una parte del panorama: su impacto depende de los datos, las herramientas y las acciones a las que puede acceder la aplicación. Descubre cómo los equipos de seguridad pueden verificar ese alcance y elegir controles específicos.