Estado de la seguridad del código abierto en 2023, según Snyk: seguridad de la cadena de suministro, IA y más

La IA, los falsos positivos y la lenta adopción de herramientas de seguridad siguen siendo motivo de preocupación, pero las correcciones más rápidas y los avances en la seguridad de la cadena de suministro son señales alentadoras.

El incidente de Log4Shell de 2021 puso el foco en la seguridad del software de código abierto, y especialmente en la seguridad de la cadena de suministro. Los 18 meses posteriores al incidente trajeron una atención a la seguridad del software de código abierto mayor que en cualquier otro momento de la historia. Organizaciones como OpenSSF y AlphaOmega, así como grandes empresas tecnológicas, están destinando recursos considerables a herramientas y educación. Pero ¿está mejorando realmente la seguridad del software de código abierto? ¿Y en qué aspectos los esfuerzos siguen siendo insuficientes? 

En Snyk nos propusimos responder esta pregunta en nuestro informe más reciente, el Estado de la seguridad del código abierto en 2023. Encuestamos a cientos de profesionales técnicos y analizamos datos anonimizados del uso real de nuestra suite de productos para recopilar estos resultados. El informe busca arrojar luz sobre el estado actual y futuro de la seguridad de la cadena de suministro y ofrecer a las organizaciones una forma de avanzar a medida que crece la industria de la cadena de suministro de software. Estos son algunos de nuestros hallazgos más importantes.

La seguridad de la cadena de suministro no avanza al ritmo del desarrollo

Muchas organizaciones enfrentan una brecha entre la innovación y la seguridad de la cadena de suministro. Aunque la mayoría usa tecnología avanzada para la cadena de suministro, descubrimos que la mayoría de las personas encuestadas no protege estos procesos con prácticas como auditorías continuas, monitoreo de dependencias indirectas o revisión temprana de las calificaciones de seguridad de los paquetes de código abierto durante el desarrollo. Es significativo que el 40 % de las personas encuestadas todavía no usa tecnologías de seguridad fundamentales como el análisis de composición de software (SCA) y las pruebas estáticas de seguridad de aplicaciones (SAST). 

A medida que las herramientas de desarrollo de código abierto siguen creciendo y atrayendo la atención de actores maliciosos, las empresas deben considerar la adopción de enfoques de seguridad de la cadena de suministro.

La automatización y la IA crean nuevas oportunidades y desafíos

El auge de la automatización y la IA está teniendo un impacto claro en el desarrollo de aplicaciones. Vemos grandes avances en el uso de estas tecnologías para la seguridad. Pero ¿estas tecnologías emergentes mejoran o perjudican la postura de seguridad? 

Según nuestro informe, todavía hay dudas sobre estas nuevas tecnologías y opiniones divididas sobre si las herramientas de IA mejorarán o no la seguridad del código. También vemos resultados dispares en la eficacia de la automatización de la seguridad: el 61 % de las personas encuestadas dijo que la automatización aumentó los falsos positivos. 

A pesar de estas opiniones diversas, la mayoría de las organizaciones sigue apostando por estas nuevas tecnologías para el desarrollo y la seguridad. Solo el tiempo dirá cómo afectan la IA y la automatización a la seguridad de la cadena de suministro de software.

La seguridad de la cadena de suministro aún no se ha integrado desde las primeras etapas

Un principio fundamental de la seguridad de la cadena de suministro es capacitar a los desarrolladores para que detecten vulnerabilidades antes en el ciclo de vida del desarrollo de software (SDLC). Esto implica darles herramientas y capacitación para escribir código más seguro y realizar análisis con mayor frecuencia. Estas prácticas mejoran la velocidad y la eficiencia del SDLC, ya que se bloquean menos compilaciones durante las pruebas previas a la implementación y se devuelven menos a los desarrolladores para corregirlas. 

Nuestra encuesta reveló que integrar la seguridad desde las primeras etapas sigue siendo una tarea pendiente. Solo el 40 % de las personas encuestadas indicó que su organización implementa herramientas de seguridad en los IDE de los desarrolladores, y un porcentaje aún menor las usa localmente en la línea de comandos. Las herramientas de compilación y los repositorios de código son los lugares más comunes para las herramientas de seguridad: ambos rondan el 65 %. Esta estadística muestra que los equipos siguen incorporando herramientas de seguridad de la cadena de suministro en etapas posteriores del desarrollo, como parte de los procesos de compilación o de registro de código, en lugar de adoptar un enfoque continuo para la seguridad del código. 

Para hacer realidad la visión de integrar proactivamente la seguridad desde las primeras etapas, los desarrolladores deben tener acceso a las mismas herramientas de seguridad que los equipos de DevOps, seguridad de aplicaciones y otras áreas posteriores del proceso. Aunque el 40 % no es una cifra baja, significa que las herramientas de seguridad todavía son minoría en las herramientas de flujo de trabajo más importantes para los desarrolladores.

Los falsos positivos de la automatización son inaceptablemente altos

Muchas organizaciones han implementado medidas de seguridad automatizadas en el pipeline de código. Esto ha provocado un aumento de falsos positivos en las alertas de vulnerabilidades, lo que puede afectar la productividad. En la encuesta, el 64 % de las organizaciones automatizó el análisis de código, el 61 % automatizó la gestión de actualizaciones de software, el 59 % automatizó las pruebas (unitarias y de seguridad) y el 58 % automatizó las prácticas de codificación segura (linters, formato, etc.). Aunque facilita el análisis de vulnerabilidades, las herramientas de seguridad automatizadas también han aumentado la tasa de falsos positivos. El 60 % de las personas encuestadas afirmó que la automatización aumentó los falsos positivos, frente al 30 % que dijo que los redujo. Los falsos positivos representaron una parte considerable de las alertas: el 62 % de las personas encuestadas afirmó que el 25 % o más de las alertas de vulnerabilidades recibidas eran falsos positivos. El 35 % informó que el 50 % o más de sus alertas eran falsos positivos.

Este alto porcentaje de falsos positivos genera una enorme carga técnica para los equipos de seguridad y desarrollo y puede socavar los beneficios de la automatización. Los equipos deberán enfocarse en formas de reducir los falsos positivos para mejorar realmente la seguridad de la cadena de suministro de software. 

Hay ventajas y desventajas en el aumento de la respuesta de seguridad

Varios ataques de alto perfil han aumentado la atención sobre la seguridad de la cadena de suministro. Los equipos de ingeniería y seguridad también enfrentan presión de organismos gubernamentales, como la Orden Ejecutiva de Estados Unidos para mejorar la ciberseguridad nacional y la próxima Ley de Ciberresiliencia de la Unión Europea. 

Debido a estos factores, varias personas encuestadas han acelerado recientemente sus prácticas de seguridad. Algunas de estas iniciativas incluyen nuevas herramientas, mayor frecuencia de análisis de código y capacitación.

Pero, a pesar de la exigencia federal de una lista de materiales de software (SBOM) de 2021, solo el 42 % de las organizaciones usa una SBOM. Y quienes la usan se enfrentan a una situación de «Torre de Babel» con sus SBOM. Nuestro informe reveló que las organizaciones usan varias herramientas de desarrollo de software, CI/CD y seguridad de la cadena de suministro para generar SBOM. Como resultado, las SBOM actuales son diversas y pueden carecer de interoperabilidad, lo que dificulta analizarlas de manera significativa. Así que, aunque muchas organizaciones «marcan la casilla de la SBOM», todavía no aprovechan todo su potencial.

La seguridad de la cadena de suministro está mejorando, pero aún queda trabajo por hacer

En general, el Informe sobre el estado de la seguridad de la cadena de suministro de software en 2023 muestra que, aunque la seguridad de la cadena de suministro de software está mejorando, aún queda trabajo por hacer. Como señal de que vamos por buen camino, nuestra investigación mostró una mejora en el tiempo de corrección (TTF) en todos los niveles de gravedad y en la mayoría de los principales ecosistemas de código abierto. De hecho, actualmente el TTF de los componentes de código abierto supera al de las correcciones en el software propietario. Hay varias explicaciones posibles para estas tendencias positivas, como una mayor adopción de herramientas de seguridad de código abierto como SCA, más financiamiento y personal dedicado a corregir vulnerabilidades críticas de código abierto, y una mayor conciencia sobre la seguridad en los proyectos de código abierto, entre otras. 

Por otro lado, también observamos que la superficie de ataque del código abierto sigue siendo muy amplia y que muchas organizaciones ignoran vulnerabilidades de ecosistemas importantes como JavaScript, Java y Debian. Por ejemplo, la vulnerabilidad Log4Shell sigue sin corregirse en numerosas organizaciones, incluso 18 meses después de que se descubriera.

Nuestros hallazgos también indican que estamos en un período de transición: pasamos de enfoques anteriores a métodos y tecnologías más nuevos. En definitiva, esto significa que vamos por buen camino, pero debemos seguir avanzando e innovando para reducir el riesgo del código abierto en el futuro.

Lee el informe completo o consulta hoy mismo los aspectos destacados en nuestra página web interactiva.