Los mantenedores de código abierto quieren protegerse, pero al 70% le faltan conocimientos
26 de febrero de 2019
0 minutos de lecturaTe damos la bienvenida al informe anual de Snyk sobre el estado de la seguridad del código abierto de 2019. Este informe se divide en varias publicaciones:
Los paquetes de Maven Central se duplican; npm indexa un cuarto de millón de paquetes nuevos
Las vulnerabilidades en bibliotecas de aplicaciones aumentaron un 88% en dos años
Los mantenedores de código abierto quieren protegerse, pero al 70% le faltan conocimientos
Las diez imágenes de Docker más populares tienen al menos 30 vulnerabilidades cada una
Las vulnerabilidades ReDoS en npm aumentan un 143% y el XSS sigue creciendo
También puedes descargar nuestro atractivo informe en PDF, elaborado artesanalmente, que reúne toda esta información y mucho más en un solo lugar.
Descarga el informe sobre el estado de la seguridad del código abierto de 2019
La postura de seguridad de los mantenedores de código abierto
Es probable que la mayoría de los desarrolladores y mantenedores coincida en que la seguridad debe desempeñar un papel importante al crear productos y escribir código. Sin embargo, no existen reglas fijas que los mantenedores deban seguir para crear proyectos de código abierto, por lo que sus estándares de seguridad pueden variar considerablemente.
Los mantenedores dedican su tiempo y esfuerzo a distintos aspectos del proyecto, a menudo funcionales, lo que puede hacer que la seguridad tenga menos prioridad durante el proceso.
Desde nuestro informe anterior, publicado en 2017, se observa una tendencia positiva en la participación y concientización sobre seguridad.
Los mantenedores de código abierto afirmaron que sus conocimientos de seguridad están mejorando, pero aún no son suficientes: el promedio es de 6.6/10
Este año, la mayoría de los usuarios calificó sus conocimientos de seguridad como intermedios, con un promedio de 6.6 sobre 10. Una pequeña parte (7%) se calificó con un nivel bajo, mientras que la proporción mayoritaria con conocimientos intermedios en realidad bajó al 63%, frente al 56% del año pasado.
Los mayores cambios se observan en las calificaciones bajas y altas. El año pasado, solo el 17% calificó sus conocimientos de seguridad como altos; este año, la cifra aumentó a casi el 30%. También observamos un cambio similar en los conocimientos de seguridad calificados como bajos: llegaron al 26% el año pasado, pero este año representan solo el 7%.
El 70% de los mantenedores de código abierto afirmó que no tiene sólidos conocimientos de seguridad
Auditorías de seguridad
Una auditoría de seguridad puede formar parte de una revisión de código en la que otros desarrolladores se aseguran de que se sigan las prácticas recomendadas para escribir código seguro. También puede consistir en distintas variantes de pruebas de seguridad de aplicaciones estáticas o dinámicas. Ya sean manuales o automáticas, las auditorías son fundamentales para detectar y reducir las vulnerabilidades de tu aplicación. Deben realizarse con la mayor frecuencia y anticipación posibles durante el desarrollo para reducir el riesgo de exposición y filtraciones de datos más adelante.
Uno de cada cuatro mantenedores de código abierto no audita sus bases de código
El año pasado, el 44% de las personas encuestadas afirmó que nunca había realizado una auditoría de seguridad. Este año, la cifra es considerablemente menor: el 26% de los usuarios afirmó que no audita su código fuente. Este año vemos una tendencia positiva hacia la realización de auditorías periódicas en todos los ciclos. En comparación con el informe del año pasado, aumentó en promedio un 10% la cantidad de usuarios que audita su código fuente con mayor frecuencia, tanto trimestral como anualmente.
Los profesionales de seguridad suelen mencionar el enfoque de desplazar la seguridad hacia la izquierda para abordar los problemas y riesgos potenciales de seguridad en etapas más tempranas del ciclo de vida de las aplicaciones. Este enfoque puede ofrecer a los desarrolladores información valiosa mediante la automatización y ayudar a los equipos de seguridad a seguir el ritmo acelerado del desarrollo continuo moderno.
Desplazar la seguridad hacia la izquierda es fundamental y, en ocasiones, incluso decisivo para reducir el costo de los incidentes que solo se detectan en producción. Una forma de abordar la seguridad antes en el proceso y aumentar las probabilidades de que los desarrolladores adopten estas prácticas es elegir herramientas fáciles de usar para ellos y diseñadas para integrarse con sus flujos de trabajo actuales.
¿Cómo se enteran los mantenedores de las vulnerabilidades?
Es más probable que alerten a los mantenedores sobre un problema de seguridad a que lo descubran por su cuenta. Una práctica recomendada aceptada por la industria es contar con una política de divulgación responsable, que detalle cómo los investigadores de seguridad y otras personas deben informar de forma segura las vulnerabilidades a los mantenedores del proyecto.
Según los datos de la encuesta, podemos concluir que casi la mitad (48%) de las personas encuestadas se entera de una vulnerabilidad de seguridad en su código a través de un canal público, por ejemplo, cuando alguien abre un problema público o se comunica por correo electrónico.
El 72% de los usuarios afirmó que se entera de las vulnerabilidades en su código al revisar personalmente su propio código. Sin embargo, el 62% indicó que solo tiene conocimientos de seguridad de nivel intermedio, mientras que apenas el 30% considera que su experiencia en seguridad es alta.
Además, aunque la mayoría de los usuarios (72%) afirma que revisa su propio código para encontrar vulnerabilidades, el 48% se entera de las vulnerabilidades en su código únicamente cuando otra persona abre un problema público. Esto demuestra lo difícil que es depender de la revisión de un solo mantenedor, incluso si se considera que tiene buenos conocimientos de seguridad.
Inclusión y divulgación
Una de las preguntas de investigación que queríamos responder era cuánto tiempo pasa desde que una vulnerabilidad se incorpora a la base de código hasta que se descubre y divulga. Para responderla, analizamos varias de las principales bibliotecas del ecosistema npm y las vulnerabilidades que se descubrieron en ellas durante 2018.
Como es difícil y requiere mucho tiempo automatizar este análisis con precisión, examinamos las seis principales bibliotecas de npm y analizamos sus bases de código para comparar las fechas de los commits que introdujeron y corrigieron las vulnerabilidades. Por supuesto, estos cálculos están algo sesgados porque usamos una muestra pequeña, pero el rango y el orden de las cifras siguen siendo interesantes.
En estas siete bibliotecas, el menor tiempo desde la inclusión hasta la corrección fue de casi un año, 289 días para ser exactos. El tiempo mediano fue de casi 2.5 años y el peor caso que observamos fue de 5.9 años.
En el foco: Equifax, un año después
Un informe reciente del gobierno de Estados Unidos calificó la famosa filtración de datos de Equifax como completamente evitable y demostró lo importante que es desplazar la seguridad hacia la izquierda e integrarla en el flujo de trabajo de desarrollo.
Con una mentalidad de DevSecOps y buenas prácticas, un equipo de desarrollo podría haber evitado el impacto de la vulnerabilidad de Struts si:
los desarrolladores hubieran detectado el problema con herramientas de análisis de dependencias de código abierto integradas en su flujo de trabajo mediante complementos para IDE o linters de código.
cada nueva compilación ejecutada por un servidor de CI hubiera probado automáticamente las dependencias de la aplicación mediante un complemento del servidor de CI o una tarea de CLI. Esto habría señalado de inmediato la nueva vulnerabilidad, detenido el trabajo de CI y exigido una corrección antes de continuar.
hubiera existido una solución de monitoreo para notificar a los desarrolladores sobre la nueva vulnerabilidad en sus dependencias.
Un monitoreo adicional y un análisis del comportamiento de la aplicación durante la ejecución, así como de las funciones vulnerables que invoca, podrían haber alertado sobre las vulnerabilidades de la biblioteca Struts.
Publicación de correcciones
Una parte crucial de la divulgación responsable de vulnerabilidades es la rapidez con que se corrige y publica una solución. Es importante solucionar el problema vulnerable lo antes posible para reducir el tiempo que permanece en el código y dar a los usuarios tiempo suficiente para actualizar a una versión corregida, idealmente antes de que el problema se vuelva de conocimiento público.
Como las comunidades de código abierto dependen en gran medida del trabajo voluntario de los desarrolladores (¡muchísimas gracias a todas las personas maravillosas que contribuyen al software de código abierto! Su valioso trabajo se agradece mucho, aunque pocas veces se reconozca o agradezca públicamente), es interesante medir qué tan rápido pueden responder los mantenedores de software de código abierto a una vulnerabilidad y ofrecer una corrección.
Una amplia mayoría de los usuarios, el 84%, afirma que probablemente respondería con una corrección en menos de una semana. El 56% probablemente la abordaría en un día, mientras que el 22% afirma que puede solucionar un problema de seguridad en unas horas después de que se informe la vulnerabilidad. ¡No todos los héroes usan capa!
Ritmo de corrección
Al examinar Snyk Vulnerability Database, podemos determinar qué paquetes han publicado versiones que incluyen correcciones de vulnerabilidades. Esto revela una situación poco ideal en algunos ecosistemas: ¡te estamos mirando a ti, JavaScript! Los ecosistemas de Java y Python muestran una gran atención a las vulnerabilidades de seguridad, mientras que JavaScript y Node.js en conjunto indican que solo el 59% de los paquetes cuenta con correcciones conocidas para las vulnerabilidades divulgadas.
En el foco: divulgación responsable de vulnerabilidades
Una ventaja importante de contar con una política de divulgación responsable es proteger a los usuarios. Cuando se informa de una vulnerabilidad y se evalúa de manera confidencial junto con el mantenedor del proyecto, este puede preparar una corrección antes de que la información se haga pública. Si los mantenedores actúan rápidamente y publican una corrección, ofrecen a sus usuarios un período para actualizar a la versión corregida. Este plazo reduce considerablemente la cantidad de usuarios que utilizan las versiones vulnerables.
Creemos que contar con una política de divulgación responsable también comunica el firme compromiso del mantenedor con la seguridad. Como buena práctica, recomendamos agregar una insignia a la página principal del proyecto e incluir un archivo de políticas SECURITY.MD en el repositorio.
En el informe anterior, descubrimos que es mucho más probable que los mantenedores con una política pública de divulgación reciban informes confidenciales de los usuarios que quienes no cuentan con ella.
Cerca del 21% de los mantenedores sin una política pública de divulgación recibió avisos privados sobre una vulnerabilidad, en comparación con el 73% de los mantenedores que sí contaban con una política.
Los sitios web son susceptibles a vulnerabilidades de seguridad web y se beneficiarían de pautas claras sobre políticas de seguridad web. Una propuesta emergente para ayudar en este sentido es SECURITY.TXT (RFC 5785), que ya ha empezado a adoptarse. El objetivo de un archivo de políticas de este tipo es comunicar de manera efectiva a los investigadores de seguridad los contactos pertinentes, los idiomas preferidos, la política específica y los métodos de comunicación, incluidas las claves públicas, para divulgar vulnerabilidades de seguridad de forma segura y eficiente.
Sigue leyendo:
Los paquetes de Maven Central se duplican; npm indexa un cuarto de millón de paquetes nuevos
Las vulnerabilidades en bibliotecas de aplicaciones aumentaron un 88% en dos años
Los mantenedores de código abierto quieren protegerse, pero al 70% le faltan conocimientos
Las diez imágenes de Docker más populares tienen al menos 30 vulnerabilidades cada una
Las vulnerabilidades ReDoS en npm aumentan un 143% y el XSS sigue creciendo
Empieza con los desafíos de Capture the Flag
Aprende a resolver desafíos de captura la bandera con nuestro taller virtual introductorio a pedido.