¿Tenemos la madurez suficiente para el Plan de Movilización de Seguridad del Software de Código Abierto?

En el clima económico y el panorama de amenazas actuales, ciertamente no envidio al CISO promedio. Tienen la tarea de garantizar la seguridad, el cumplimiento, la innovación y el valor empresarial, mientras se enfrentan a una batalla cuesta arriba con presupuestos cada vez menores y un mayor escrutinio. Quizás lo más apremiante es el hecho de que cada organización (y su respectivo equipo de desarrollo) se encuentra en diferentes etapas de madurez de seguridad, y no todas están equipadas para dar lo mejor de sí en términos de ciberdefensa.

Los últimos años de escalada en incidentes de ciberseguridad han hecho que sea bastante difícil para los líderes de seguridad mantenerse un paso por delante. Solo con echar un vistazo a algunos de los datos sobre nuestra creciente situación, se revela una verdadera bomba de relojería: más de 33 mil millones de registros serán robados por ciberdelincuentes solo en 2023, un aumento del 175% desde 2018. Se prevé que el costo del cibercrimen alcance los 10,5 billones de dólares para 2025, y el costo promedio de una filtración de datos se ha disparado a 4,24 millones de dólares (aunque solo tenemos que observar incidentes como los de Equifax o Solar Winds para ver que puede ser mucho peor).

Como industria, hemos pasado mucho tiempo esperando a que aparezca un héroe que nos rescate de los villanos de la ciberseguridad que parecen tener más poder del que creíamos posible, incluso hace diez años. Estamos esperando a que más profesionales de la ciberseguridad se unan y nos eleven a un estándar más alto de programa de seguridad, pero es una brecha que no podemos cerrar. Estamos esperando la herramienta milagrosa que prometa automatizar nuestra salida de un riesgo creciente, pero no existe y es muy poco probable que exista. Estamos esperando a nuestro Luke Skywalker para ayudarnos a luchar contra el Lado Oscuro.

Resulta que la ayuda (y la esperanza) está en camino, bajo la forma de El Plan de Movilización para la Seguridad del Software de Código Abierto. Sin embargo, todos debemos hacer un balance y evaluar honestamente si nuestra organización tiene la madurez suficiente —y si nuestros equipos de desarrollo cuentan con el nivel adecuado de concienciación y habilidades en seguridad— para implementar las mejores y más recientes estrategias defensivas, especialmente cuando requieren el apoyo y la ejecución por parte del equipo de desarrollo.

¿Qué es el Plan de Movilización para la Seguridad del Software de Código Abierto?

Este plan de diez puntos fue encabezado por la Open Source Software Foundation (OpenSSF) y la Linux Foundation, en conjunto con funcionarios de la Casa Blanca, los principales CISO y otros líderes sénior de 37 empresas tecnológicas privadas. Con este apoyo combinado tanto en acción como en financiación, el estándar de seguridad del software de código abierto está destinado a fortalecerse considerablemente.

Lo que resulta especialmente interesante es su enfoque en la educación básica y la certificación a nivel de desarrollador, así como en las medidas diseñadas para agilizar las actividades internas de la Lista de Materiales de Software (SBOM). Ambas son notoriamente difíciles de implementar de manera que tengan un impacto duradero, lo que puede atribuirse en parte a los problemas de crecimiento dentro de los programas de seguridad organizacionales y a una falta general de madurez en seguridad entre el grupo de desarrolladores, sin que sea culpa suya. Se encuentran en un entorno de alta presión donde el volumen de código a gran velocidad es lo que impera, frente a plazos cada vez más irrazonables. Añadir aún más tareas en forma de solicitudes de seguridad y mantenimiento de SBOM sin aumentar el tiempo disponible para ellas es una receta que ha fracasado antes de empezar y, lamentablemente, es más común de lo que cabría esperar.

Así que, echemos un vistazo bajo el capó.

Certificación de seguridad para desarrolladores: ¿Ya estamos ahí?

Si hay algo que sabemos con certeza es que los desarrolladores con habilidades en seguridad siguen siendo un bien escaso. Esta es la realidad por varias razones, principalmente porque hasta hace poco, los desarrolladores no formaban parte de la ecuación cuando se trataba de estrategias de seguridad de software dentro de las organizaciones. Si a eso le sumamos que los desarrolladores no tienen muchas razones para priorizar la seguridad (su formación es inadecuada o inexistente, lleva más tiempo, no forma parte de sus KPI y su principal preocupación es hacer lo que mejor saben hacer: crear funciones), obtenemos equipos de desarrollo que no están preparados para lidiar realmente con la seguridad a nivel de código, ni para desempeñar su papel en un ciclo de vida de desarrollo de software (SDLC) modernizado y centrado en DevSecOps.

Si observamos el Plan de Movilización para la Seguridad del Software de Código Abierto, la primera línea del plan de diez puntos aborda las habilidades de seguridad de los desarrolladores, para "Ofrecer educación y certificación básica en desarrollo de software seguro a todos", lo cual es esencial para desarrollar la madurez de seguridad en los equipos de desarrollo. Destacan los problemas que hemos discutido durante algún tiempo, incluido el hecho de que la codificación segura está ausente en la mayoría de los cursos de ingeniería de software a nivel terciario. Es increíblemente alentador ver esto respaldado por personas y departamentos que pueden cambiar el statu quo de la industria, y con el 99% del software mundial conteniendo al menos algo de código de código abierto, este ámbito del desarrollo es un gran lugar para comenzar a centrarse en la formación de los desarrolladores en seguridad.

El plan cita recursos respetados como los cursos de Fundamentos de Software Seguro de OpenSSF y los extensos recursos de larga trayectoria de la Fundación OWASP. Estos centros de información son invaluables. El despliegue propuesto para hacer llegar estos materiales a los desarrolladores implica reunir a una amplia red de socios, tanto en el sector público como en el privado, además de asociarse con instituciones educativas para hacer del desarrollo seguro de código abierto una característica clave del plan de estudios.

En cuanto a cómo se ganarán los corazones y las mentes de los ingenieros de software de todo el mundo, muchos de los cuales han tenido la seguridad reforzada como algo que no es su trabajo o prioridad, el plan detalla una estrategia de recompensa y reconocimiento dirigida tanto a los desarrolladores que mantienen bibliotecas de código abierto como a los ingenieros en activo que necesitan ver el valor de las certificaciones de seguridad.

Sabemos por experiencia que los desarrolladores responden bien a los incentivos, y que los sistemas de insignias por niveles que muestran el progreso y las habilidades funcionan tan bien en un entorno de aprendizaje como en plataformas como Steam o Xbox.

Sin embargo, lo que preocupa es que no estamos abordando uno de los problemas centrales, que es la impartición de módulos de aprendizaje dentro del programa de seguridad de una organización. Habiendo trabajado estrechamente con desarrolladores durante gran parte de mi carrera, sé lo escépticos que son cuando se trata de herramientas y formación, por no mencionar cualquier cosa que parezca que podría interrumpir el trabajo que es la prioridad número uno. La capacitación de los desarrolladores requiere que se involucren continuamente con el material del curso y, para que esto tenga éxito, debe tener sentido en el contexto de su trabajo diario.

Si consideramos un modelo de madurez establecido como el Modelo de Madurez de Garantía de Software (SAMM), la "Educación y Orientación" es un componente central de la capa de Gobernanza, y hay un enfoque clave en la educación de los desarrolladores. El modelo en su totalidad es vasto y existen pasos progresivos para alcanzar niveles más altos de madurez. Sin embargo, las etapas iniciales recomiendan solo 1 o 2 días de formación formal para los desarrolladores, lo cual apenas es suficiente para arañar la superficie de la concienciación sobre seguridad. Aun así, un informe reciente del Enterprise Strategy Group (ESG) reveló que menos de la mitad de las organizaciones requieren que los desarrolladores participen en una formación formal en seguridad más de una vez al año. Nuestra propia investigación en conjunto con Evans Data reveló que solo el 29% de los desarrolladores cree que la práctica activa de escribir código libre de vulnerabilidades debería ser una prioridad. Existe una clara desconexión entre cómo se imparte y recibe la educación, y lo útil que es realmente para lograr la madurez en seguridad, especialmente si los desarrolladores no ven el valor.

Lista de Materiales de Software: ¿Este plan rompe las barreras de adopción?

Otra área que el plan busca abordar es el caos que suele rodear la creación y el mantenimiento de la Lista de Materiales de Software (SBOM), con la iniciativa “SBOM en todas partes: mejorar las herramientas y la formación sobre SBOM para impulsar su adopción”, que investiga formas de facilitar a los desarrolladores y a sus organizaciones la creación, actualización y uso de SBOM para lograr mejores resultados de seguridad.

En la actualidad, las SBOM no están muy extendidas en la mayoría de los sectores, lo que dificulta aprovechar su potencial para reducir los riesgos de seguridad. El plan cuenta con una estrategia brillante para definir estándares clave para la formulación de SBOM, así como herramientas que faciliten su creación y se adapten al flujo de trabajo de los desarrolladores. Esto por sí solo ayudaría mucho a reducir la carga de una tarea más en el ciclo de vida de desarrollo para unos profesionales que ya tienen demasiados frentes abiertos para crear software a la velocidad que exige el mercado.

Sin embargo, me temo que, en la organización promedio, las responsabilidades de seguridad pueden ser un terreno ambiguo para los desarrolladores. ¿Quién es responsable de la seguridad? En última instancia, es el equipo de seguridad, pero debemos involucrar a los desarrolladores si queremos contar con su ayuda. Las tareas y expectativas deben estar claramente definidas, y ellos necesitan tiempo para asumir estas medidas adicionales como parte de su éxito.

Del software de código abierto al resto del mundo del software

El Plan de Movilización de Seguridad del Software de Código Abierto es ambicioso, audaz y exactamente lo que se necesita para fomentar la responsabilidad de los desarrolladores en materia de seguridad. Fue necesaria una “Alianza Rebelde” de actores poderosos para lograrlo, pero esto demuestra que vamos en la dirección correcta y que estamos dejando atrás la idea de que la brecha de habilidades en ciberseguridad se solucionará por arte de magia.

Es nuestra nueva esperanza, y necesitaremos el esfuerzo de todos para llevar esta estructura más allá del código abierto. No obstante, los profesionales de la seguridad deben hacer examen de conciencia y analizar a los equipos de desarrollo que trabajan en el código que deben proteger. Deben evaluar honestamente sus capacidades actuales, identificar las carencias y trabajar para crear un estado de madurez sólido, proactivo e inclusivo, con un programa que aporte verdaderas competencias de seguridad al equipo de desarrollo. Hasta que no estén capacitados de forma efectiva, seguiremos siendo algo inmaduros en nuestro enfoque frente a las vulnerabilidades a nivel de código.

‍

>> Pon a prueba la madurez de seguridad de tu equipo con nuestro desafío de XSS interactivo y práctico.