Seguridad del software de código abierto: explicación
Escrito por
0 minutos de lectura
Seguridad del software de código abierto: definición
La seguridad del software de código abierto es esencial para gestionar sus componentes y dependencias, y mitigar los riesgos y vulnerabilidades asociados al software de terceros.
El software de código abierto se ha vuelto muy popular en los últimos años gracias a su naturaleza colaborativa y pública, lo que facilita su uso tanto a desarrolladores como a actores maliciosos. Cuando los adversarios descubren que una aplicación está expuesta a una vulnerabilidad conocida públicamente, pueden atacar cualquier aplicación desarrollada con ese código abierto. Casos como las vulnerabilidades de Log4j y Apache Struts demuestran que esto representa un riesgo real y, a veces, grave para las organizaciones.
Es fundamental administrar los componentes y las dependencias de código abierto para mitigar este riesgo. Sin embargo, es difícil tener visibilidad de todos los componentes de código abierto que se usan en una aplicación y resulta tedioso comparar manualmente esos componentes con bases de datos de vulnerabilidades conocidas. Las dependencias anidadas complican aún más la situación, ya que es necesario proteger no solo el código que escriben los desarrolladores, sino también todo el código abierto que usan y las dependencias incluidas en ese código.
En esta publicación definiremos la seguridad del código abierto, analizaremos los riesgos asociados con el software de código abierto y presentaremos herramientas y procesos para mitigar los riesgos que enfrentan las organizaciones al usarlo.
¿Qué es la seguridad del código abierto?
La seguridad del código abierto abarca los riesgos y las vulnerabilidades asociados con el software de terceros, así como las herramientas y los procesos que se usan para protegerlo. Las herramientas de seguridad pueden automatizar la detección de bibliotecas y dependencias de código abierto en el código, analizar cómo se usan esos componentes en las aplicaciones y activar alertas o medidas correctivas cuando detectan vulnerabilidades. Prácticas como la autenticación de dos factores agregan otra capa de seguridad para proteger contra las filtraciones.
Informe de Snyk
Estado de la seguridad del código abierto en 2022
Un análisis de la complejidad y los riesgos de la cadena de suministro de software, en colaboración con The Linux Foundation.
4 beneficios del software de código abierto
Las exigencias empresariales impulsan ciclos más rápidos de desarrollo y lanzamiento de software. Para responder a estas demandas, los desarrolladores recurren cada vez más al software de código abierto para complementar el código desarrollado internamente.
Su popularidad se debe a algunos factores:
Costo: Los desarrolladores de software pueden usar, modificar y compartir libremente software de código abierto de dominio público, mientras una comunidad mundial de desarrolladores y voluntarios se ocupa de su mantenimiento. Incluso los paquetes comerciales de código abierto son relativamente económicos frente al costo de desarrollar código personalizado desde cero.
Facilidad de uso: La naturaleza abierta y prediseñada del software de código abierto permite a los desarrolladores usar código existente para satisfacer necesidades específicas. Así, tienen más tiempo para dedicarse a tareas de mayor valor.
Calidad: Como una comunidad de desarrolladores crea, usa e inspecciona el código abierto, en teoría hay menos errores, ya que las vulnerabilidades se descubren y se corrigen rápidamente.
Velocidad: Al usar software de código abierto, los desarrolladores pueden llevar aplicaciones empresariales valiosas al mercado más rápido.
En algunos casos, la adopción del software de código abierto se ha duplicado o incluso ha aumentado más, lo que brinda a los desarrolladores las ventajas de las economías de escala: hay más herramientas disponibles y más desarrolladores con mejor capacitación que se incorporan al mercado. Al mismo tiempo, existen compensaciones entre apertura y vulnerabilidad, agilidad y calidad.
Figura 1: nuevos paquetes creados por el ecosistema cada año
Usar software de código abierto significa confiar en personas que no conoces para mantener el código del que dependen tus aplicaciones. Por eso, es fundamental usar sistemas y herramientas para minimizar los posibles riesgos.
3 riesgos de seguridad del software de código abierto
Casi todas las aplicaciones nativas de la nube dependen de componentes de código abierto. Sin embargo, como nadie se responsabiliza de su mantenimiento ni de su seguridad, el software de código abierto está expuesto a varios riesgos, entre ellos:
1. Vulnerabilidades en las dependencias de código abierto
Estas incluyen vulnerabilidades conocidas y desconocidas. Entre las conocidas están las que tienen asignado un número de vulnerabilidad y exposición común (CVE), las divulgadas en Internet, las compartidas en bases de datos públicas de vulnerabilidades y las incluidas en bases de datos privadas. En general, cuanto más conocida es una vulnerabilidad, más urgente es la necesidad de corregirla.
Además de rastrear las vulnerabilidades, también es fundamental rastrear cada dependencia de código abierto de una aplicación. Las dependencias transitivas —cuando unas dependencias dependen de otras— son motivo especial de preocupación porque las herramientas de seguridad y las auditorías las detectan con menos facilidad. Por eso, conviene usar herramientas o procesos que permitan identificar y auditar todas las dependencias de una aplicación.
2. Riesgos de cumplimiento de licencias
Los desarrolladores deben comprender cada tipo de licencia de software de los paquetes de código abierto que usan para poder utilizar el código de forma acorde con sus términos. Esto requiere conocer las condiciones de las licencias y hacerlas cumplir en todos los proyectos. Para hacer cumplir las licencias de código abierto, las organizaciones necesitan tener una visibilidad profunda de cómo se usan estos componentes. También es importante supervisar continuamente las licencias, ya que el titular de los derechos de autor puede cambiar la licencia de una biblioteca.
3. Paquetes de código abierto sin mantenimiento
Por lo general, los paquetes de código abierto reciben mantenimiento de un solo desarrollador o de un equipo pequeño, si es que alguien se ocupa de ellos. Los desarrolladores de proyectos comunitarios de código abierto no tienen el compromiso de mantener el software, que se ofrece «tal cual». Por eso, los usuarios son responsables de dedicar tiempo y recursos a comprobar que el código sea seguro. Por suerte, hay herramientas útiles que pueden simplificar este proceso, como Snyk Advisor, que analiza los paquetes según su nivel de mantenimiento, comunidad, estado de seguridad y popularidad para ayudarte a evaluar el estado de los paquetes de código abierto que usas.
¿Quieres conocer más sobre los riesgos del software de código abierto? Lee nuestra publicación: 5 riesgos potenciales del software de código abierto.
Estadísticas clave del informe sobre el estado del código abierto
Los datos aportan conocimiento, por eso Snyk encuestó a desarrolladores y profesionales de seguridad para conocer sus inquietudes sobre la seguridad del código abierto, las tendencias de vulnerabilidades en paquetes e imágenes de contenedores y las prácticas que usan los encargados del mantenimiento y las organizaciones para proteger su software. Publicamos los hallazgos en nuestro informe sobre el estado de la seguridad del código abierto de 2020. Estos son algunos de sus principales resultados.
Aumenta la adopción del código abierto
Los ecosistemas de código abierto siguen expandiéndose debido a las demandas del mercado y a la realidad empresarial. npm lideró el crecimiento, con un aumento interanual de más del 33 % y 1.8 millones de paquetes en marzo de 2022. La mayoría de las vulnerabilidades de código abierto siguen detectándose en dependencias indirectas:
npm: 86 %
Ruby: 81 %
Java: 74 %
La cultura de seguridad del código abierto se orienta hacia los desarrolladores
Los encuestados indicaron que consideran la seguridad una responsabilidad compartida entre departamentos:
El 85 % consideró que los desarrolladores eran responsables de la seguridad del código abierto
El 55 % consideró que los equipos de seguridad eran responsables
El 35 % consideró que operaciones tenía un papel que desempeñar
Tendencias de vulnerabilidades
Las vulnerabilidades nuevas disminuyeron un 20 % en general, y las vulnerabilidades de cross-site scripting (XSS) fueron las más reportadas.
Figura 2: vulnerabilidades identificadas en ecosistemas desde 2014
Desafíos de contenedores y orquestación
Las imágenes base oficiales etiquetadas como latest suelen incluir vulnerabilidades conocidas. La imagen oficial de Node destaca con casi 700 vulnerabilidades conocidas. Más del 30 % de los participantes de la encuesta no revisa los manifiestos de Kubernetes para detectar configuraciones inseguras, y los requisitos de controles de recursos relacionados con la seguridad no se implementan ampliamente en Kubernetes.
Figura 3: vulnerabilidades en imágenes de contenedor oficiales
Tendencias de seguridad del código abierto en 2022
Durante el último año, varias tendencias dominaron la conversación sobre la seguridad del código abierto: la seguridad de la cadena de suministro, los cambios culturales en torno a la responsabilidad, la disminución de las vulnerabilidades recién descubiertas, la dependencia de los encargados voluntarios del mantenimiento del código abierto y los cambios en las expectativas sobre la corrección de vulnerabilidades.
Los ataques a la cadena de suministro son cada vez más comunes
Los componentes de software de terceros se almacenan en un repositorio centralizado que conforma la cadena de suministro de software. Esta cadena es un vector de ataque atractivo, ya que los actores maliciosos pueden atacar puntos vulnerables del proceso de desarrollo sin necesidad de modificar los repositorios de software. Por ejemplo, pueden explotar fallas de diseño mediante un ataque de confusión de dependencias o espacios de nombres, o aprovechar componentes de terceros para comprometer los datos de los usuarios y acceder a sistemas internos.
Cada eslabón es un posible vector de ataque, por lo que es importante proteger la cadena de suministro desde el código fuente hasta la implementación. Las vulnerabilidades de la cadena de suministro no son nuevas, pero fueron un tema central de conversación en 2021 y aparecieron reiteradamente en la orden ejecutiva de ciberseguridad del presidente Biden.
Cambio cultural hacia una responsabilidad compartida por la seguridad
¿Quién debería ser responsable de la seguridad? Una de las tendencias más prometedoras que hemos observado es el cambio hacia una responsabilidad compartida entre los equipos de desarrollo, seguridad y operaciones.
El cambio hacia un enfoque de DevSecOps es positivo, pero el 47 % de los encuestados afirmó que no cuenta con programas específicos para impulsar la responsabilidad compartida, y solo el 15 % implementó programas de security champions, definidos como una práctica de seguridad clave en el modelo de madurez de aseguramiento de software (SAMM) de OWASP. Esto demuestra que todavía existe una brecha entre reconocer la necesidad de compartir la responsabilidad y llevarla a la práctica.
Según el informe State of DevOps de Puppet, también hemos aprendido que, a medida que las organizaciones maduran en sus prácticas de DevOps, también maduran sus prácticas de seguridad.
«A medida que mejoran las prácticas de DevOps, DevSecOps surge de forma natural. Las organizaciones con un alto nivel de evolución adoptaron el enfoque shift left: la mayoría integra la seguridad en los requisitos (51 %), el diseño (61 %), la compilación (53 %) y las pruebas (52 %). En cambio, en la mayoría de las organizaciones de nivel intermedio, el equipo de seguridad participa cuando se programa una auditoría de producción (48 %) y cuando se reporta un problema en producción (45 %).»
Se detectaron menos vulnerabilidades
Un hallazgo sorprendente del informe es que las vulnerabilidades nuevas disminuyeron un 20 % en general. Esta tendencia se da en un momento de crecimiento explosivo de los ecosistemas de código abierto, lo que la hace particularmente notable.
No hay una explicación clara de por qué disminuyó el crecimiento de las vulnerabilidades de código abierto mientras el panorama se duplicó con creces en algunos ecosistemas, pero esto sugiere que las mejoras en la concientización, las prácticas y las herramientas de seguridad están dando resultados.
Seguiremos prestando atención a esta tendencia, pero todavía es demasiado pronto para bajar la guardia con respecto a los controles y las prácticas de seguridad.
Los encargados del mantenimiento del código abierto se enfrentan a las corporaciones
Es probable que aumenten las tensiones entre los encargados del mantenimiento del código abierto que están insatisfechos con las corporaciones y organizaciones que monetizan productos creados con su software sin financiar a quienes lo mantienen.
Una encuesta de Tidelift de 2021 a 400 encargados del mantenimiento de proyectos de código abierto reveló que el 46 % no recibe ningún pago y que solo el 26 % gana más de 1,000 dólares al año por su trabajo de mantenimiento. Más de la mitad (59 %) dejó o consideró dejar de mantener un proyecto, y casi la mitad de los encuestados indicó que la falta de compensación económica era su principal motivo de descontento con esa labor.
Este descontento tiene consecuencias reales. Por ejemplo, en enero de 2022, el encargado del mantenimiento del popular paquete npm colors introdujo código malicioso que provoca un bucle infinito e interrumpe cualquier uso del paquete.
La versión defectuosa de colors se descargó más de 95,000 veces. Colors se usa en varios otros proyectos, incluidos el asistente de línea de comandos prompt (~500,000 descargas semanales) y el propio aws-cdk de AWS (~2 millones de descargas semanales), por lo que representa un motivo importante de preocupación.
Algo similar ocurrió con el popular paquete npm faker, que mantiene la misma persona. El encargado abrió una incidencia para anunciar que dejaría de mantener gratis esos proyectos, que usan numerosas empresas de Fortune 500.
Los plazos para corregir vulnerabilidades aún no cumplen con las expectativas
Según la encuesta Open Source Security 2020, el 47 % de las personas encuestadas espera que una vulnerabilidad se corrija en la semana posterior a su descubrimiento, y casi el 18 % espera que se corrija en un día.
Figura 4: Expectativas sobre las correcciones de vulnerabilidades de código abierto
En realidad, solo el 35 % de las vulnerabilidades en los proyectos analizados se corrigió en menos de 20 días, mientras que el 36 % tardó 70 días o más; el tiempo promedio para corregirlas fue de 68 días.
Está claro que las organizaciones deben gestionar las expectativas en torno a su nivel de riesgo. Deben tener en cuenta los SLA para corregir vulnerabilidades de código abierto, especialmente cuando una persona colaboradora es responsable de mantener el código.
Métricas clave para tu estrategia de seguridad de código abierto
Una buena forma de empezar es hacer un seguimiento cuidadoso de las métricas de seguridad de código abierto en las bibliotecas que usas. Considera métricas como:
La cantidad de días entre el descubrimiento de una vulnerabilidad y su corrección
El tiempo promedio para fusionar un pull request después de que se reporta un problema
El tiempo que te toma corregir el código por tu cuenta
Estas respuestas te permiten entender mejor cómo respondes a los problemas de seguridad en los paquetes que utilizas, para que puedas crear una estrategia de gestión de componentes y descubrir y abordar vulnerabilidades.
Además, toma la iniciativa con los paquetes de código abierto que usas. Envía pull requests a quienes los mantienen para que estén al tanto de los problemas. Comprende cómo el software de código abierto afecta a tu negocio y justifica la gestión sistemática del software de código abierto.
6 capacidades que debes buscar en una herramienta de seguridad de código abierto
Las herramientas de seguridad cumplen una función clave en la estrategia de seguridad de código abierto. Permiten revisar automáticamente el código abierto para detectar vulnerabilidades conocidas y consultar bases de datos de vulnerabilidades que ayudan a comprender su posible impacto y los pasos para corregir los problemas. Estas herramientas pueden monitorear continuamente el código en producción e integrar la seguridad y la gestión de licencias y gobernanza en todo el proceso de desarrollo de software.
1. Vista integral de los paquetes y las vulnerabilidades que los afectan
Como tener visibilidad de los componentes y las dependencias de código abierto forma parte del desafío de seguridad, contar con una manera de inventariar y evaluar los componentes automáticamente permite controlar el entorno de código abierto. Busca herramientas de automatización que identifiquen componentes en todos los pipelines de CI/CD y evalúen el nivel de amenaza que representan. ¿La aplicación realmente usa los componentes vulnerables?
2. Capacidad para gestionar licencias
Las herramientas de seguridad pueden revisar continuamente el código de terceros y el código personalizado para detectar vulnerabilidades y riesgos de licencias mientras se escribe en el entorno de desarrollo, sin necesidad de analizar los repositorios de código.
3. Automatización
Las herramientas de seguridad te permiten monitorear y detectar vulnerabilidades automáticamente. En caso de una brecha, pueden evaluar los daños y definir una respuesta adecuada. También puedes establecer políticas para correcciones, solicitudes, parches y actualizaciones de dependencias a fin de automatizar estos procesos.
4. Integraciones directas con herramientas, flujos de trabajo y pipelines de automatización para desarrolladores
Integrar la seguridad directamente en las herramientas y los procesos de desarrollo ayuda a agilizar la protección del código. Los complementos permiten que los desarrolladores apliquen correcciones fácilmente desde la CLI o el IDE. Las integraciones de GitHub permiten probar repositorios, proyectos y pull requests, y aplicar correcciones mediante pull requests automatizados.
5. Base de datos actualizada y enriquecida que va más allá de los CVE conocidos
Las herramientas de seguridad van más allá de las bases de datos públicas de vulnerabilidades conocidas y crean bases de datos propias y seleccionadas cuidadosamente. Estas incluyen vulnerabilidades con números CVE, las que aparecen en avisos de seguridad, las identificadas en sistemas de seguimiento de problemas y las que se comentan en foros o redes sociales, entre otras.
6. Monitoreo continuo de proyectos
Las herramientas de seguridad pueden monitorear continuamente las aplicaciones en producción para evitar automáticamente la explotación de vulnerabilidades. Así, las aplicaciones pueden supervisarse y defenderse por sí mismas ante ataques o problemas de licencias.
Para obtener más información sobre cómo elegir una herramienta de seguridad para monitorear componentes de código abierto, lee nuestra guía Cómo elegir herramientas SCA.
6 beneficios de usar Snyk para la seguridad del software de código abierto
Snyk Open Source ofrece una herramienta de seguridad diseñada para desarrolladores que integra la seguridad de las aplicaciones en todo el pipeline de desarrollo de software. Así, puedes crear e implementar aplicaciones con software de código abierto y proteger el código frente a vulnerabilidades y problemas de licencias.
1. Compatible con DevSecOps
Snyk Open Source se integra en el ciclo de vida del desarrollo de software (SDLC) desde la primera línea de código. Hemos invertido mucho en integraciones para que el análisis de seguridad y licencias sea lo más sencillo posible. Esto hace que los desarrolladores sean directamente responsables de la seguridad de sus aplicaciones y permite crear ciclos de colaboración productivos con los equipos de seguridad y operaciones.
También creamos un DevSecOps Hub, que destaca la tecnología, los procesos y las personas que ayudan a las organizaciones a desarrollar una cultura DevOps que integra la seguridad de forma eficaz; y nuestra DevSecOps Community, que reúne a desarrolladores y líderes de seguridad a través de un portal de soporte, eventos virtuales y en vivo, y un programa de embajadores que brinda a los referentes de seguridad una conexión más directa con Snyk.
2. Corrige problemas dentro de los flujos de trabajo de desarrollo
Snyk Open Source se integra en herramientas para desarrolladores como Atlassian Bitbucket, Visual Studio Code, Maven Central, GitHub y JetBrains. Así, los desarrolladores pueden acceder a Snyk y detectar vulnerabilidades y problemas de licencias en la herramienta que prefieran.
3. Pocos falsos positivos
El equipo de especialistas en seguridad de Snyk gestiona su base de datos para mantener una tasa baja de falsos positivos. Analiza y prueba cada elemento de la base de datos, asigna una puntuación y un vector CVSS a cada vulnerabilidad, invierte en investigación propia para descubrir nuevas vulnerabilidades e incluye resúmenes seleccionados manualmente con fragmentos de código cuando corresponde.
4. Vista del árbol de dependencias
Snyk usa el administrador de paquetes de tu aplicación para crear un árbol de dependencias y mostrarlo en la interfaz de usuario de Snyk. Esto permite visualizar qué componente causa un problema y ayuda a Snyk a abordarlo, incluso si se trata de una dependencia transitiva. También permite automatizar la creación de una lista de materiales de software (SBOM) directamente en los flujos de trabajo de desarrollo. Una vez que tengas tu SBOM, puedes analizarla para detectar vulnerabilidades de seguridad con SBOM Checker de Snyk.
5. Correcciones automatizadas
Snyk sugiere automáticamente correcciones para las vulnerabilidades desde la CLI, el IDE y los pipelines de CI/CD cuando están disponibles. Si no hay una corrección disponible para una dependencia, Snyk puede avisarte cuando esté disponible una o cuando se descubran nuevas vulnerabilidades relacionadas.
6. Gobernanza y licencias
La gestión del cumplimiento de licencias de Snyk Open Source te permite administrar licencias desde los flujos de trabajo de desarrollo mediante la aplicación automatizada de políticas y una gestión detallada. Así puedes monitorear cada etapa, desde la primera línea de código hasta la aplicación implementada, para asegurarte de que tus proyectos no infrinjan ninguna licencia.
Analiza tus dependencias de código abierto en busca de vulnerabilidades
Encuentra, prioriza y corrige vulnerabilidades automáticamente y gratis con Snyk.
Sección de preguntas frecuentes
¿Qué es la seguridad de código abierto?
La seguridad de código abierto se refiere a los riesgos que enfrentan hoy los desarrolladores y los equipos de seguridad al ejecutar código abierto de terceros en sus aplicaciones, así como a los procesos, las metodologías y las herramientas que implementan para mitigarlos. Los ataques recientes que explotan vulnerabilidades en código abierto han generado costos enormes para las organizaciones y han puesto de relieve la importancia de la seguridad de código abierto y la necesidad de implementar y monitorear estrategias relacionadas.
¿Por qué es importante la seguridad de código abierto?
El código abierto impulsa la transformación digital que vemos hoy y lo usan empresas de todos los tamaños y sectores. Sin embargo, también conlleva riesgos. Reconocerlos es un primer paso importante, pero debe ir acompañado de una inversión y un mantenimiento continuos de un plan de seguridad de código abierto bien definido que incluya pruebas y monitoreo continuos de seguridad.
¿Cuáles son los riesgos del código abierto?
Los desarrolladores incorporan grandes cantidades de dependencias de código abierto sin controles de seguridad ni visibilidad. Estas dependencias son mantenidas por voluntarios externos a la organización, pero quienes las mantienen no tienen la obligación de actualizarlas ni protegerlas. Además, por su naturaleza pública, los actores maliciosos pueden conocer y explotar las vulnerabilidades en cuanto los desarrolladores se enteran de ellas. Estos son algunos de los riesgos del software de código abierto.