¿Estamos lo suficientemente maduros para el Plan de Movilización de la Seguridad del Software de Código Abierto?

En el clima económico actual y el panorama de las amenazas, ciertamente no envidio al CISO medio. Tienen la tarea de ofrecer seguridad, cumplimiento, innovación y valor empresarial, al tiempo que se enfrentan a una ardua batalla con presupuestos cada vez más reducidos y un mayor escrutinio. Tal vez sea más apremiante el hecho de que cada organización (y su respectivo equipo de desarrollo) se encuentra en diferentes etapas de madurez de seguridad, y no todos están equipados para dar lo mejor de sí en términos de ciberdefensa. 

La escalada de incidentes de ciberseguridad de los últimos años ha dificultado mucho que los responsables de seguridad vayan un paso por delante. Basta con echar un vistazo a algunos de los datos sobre nuestra creciente situación para ver que se trata de un polvorín: solo en 2023, los ciberdelincuentes robarán más de 33.000 millones de registros, lo que supone un aumento del 175% respecto a 2018. Se prevé que el coste de la ciberdelincuencia alcanzará los 10,5 billones de dólares en 2025, y el coste medio de una filtración de datos se ha disparado hasta los 4,24 millones de dólares (aunque solo tenemos que echar un vistazo a incidentes como los de Equifax o Solar Winds para ver que puede ser mucho peor). 

Como industria, llevamos mucho tiempo esperando que aparezca un héroe que nos rescate de los malos 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 suban al carro y nos eleven a un nivel superior de programa de seguridad, pero es una brecha que no podemos cerrar. Estamos esperando la solución de herramientas de bala de plata que promete automatizarnos para alejarnos del riesgo creciente, pero no existe y es muy poco probable que exista. Estamos esperando que nuestro Luke Skywalker nos ayude a luchar contra el Lado Oscuro.

Resulta que la ayuda (y la esperanza) está en camino, en forma de Plan de movilización de la seguridad del software de código abierto. Sin embargo, todos debemos hacer un balance y evaluar honestamente si somos lo suficientemente maduros en nuestra organización -y si nuestros equipos de desarrollo tienen el nivel adecuado de conciencia y habilidades de seguridad- para implementar las últimas y mejores estrategias defensivas, especialmente cuando requieren el apoyo y la ejecución del equipo de desarrollo.

¿Qué es el plan de movilización de 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, junto con funcionarios de la Casa Blanca, los principales CISO y otros altos dirigentes de 37 empresas tecnológicas privadas. Con este apoyo combinado, tanto en acciones como en financiación, el estándar de seguridad del software de código abierto va a ser mucho más fuerte. 

Lo que es especialmente interesante es su enfoque en la educación y certificación de base a nivel de desarrolladores, y las medidas diseñadas para racionalizar las actividades internas de la lista de materiales de software (SBOM). Ambas son notoriamente difíciles de implementar de una manera que tenga un impacto duradero, lo que puede atribuirse en parte a los dolores de crecimiento dentro de los programas de seguridad de la organización, y una falta general de madurez de seguridad entre la cohorte de desarrollo, sin culpa alguna. Se encuentran en un entorno de olla a presión en el que reina el volumen de código a gran velocidad, frente a plazos cada vez más irrazonables. Añadir aún más tareas en forma de peticiones de seguridad y mantenimiento de SBOM sin aumentar el tiempo disponible para ellas es una receta que ha fracasado antes de empezar, y tristemente, es más común de lo que podríamos esperar.

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

Certificación de seguridad para desarrolladores: ¿Hemos llegado ya a ese punto?

Si hay algo que sabemos con certeza es que los desarrolladores con conocimientos de seguridad siguen siendo un bien escaso. Esta es la realidad por una serie de razones, a saber, que 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 esto le sumamos que los desarrolladores no tienen muchos motivos para dar prioridad a 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 funcionalidades), tenemos equipos de desarrollo que no están preparados para ocuparse realmente de 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 nos fijamos en el Plan de Movilización de la Seguridad del Software de Código Abierto, la primera línea del plan de diez puntos se ocupa de las habilidades de seguridad de los desarrolladores, para "Ofrecer educación y certificación de desarrollo de software seguro de base para todos", que es esencial para construir la madurez de la seguridad en los equipos de desarrollo. Destacan los problemas que hemos discutido durante algún tiempo, incluyendo el hecho de que la codificación segura es MIA de la mayoría de la ingeniería de software courses en el nivel terciario. Es increíblemente alentador ver que esto es apoyado por individuos y departamentos que pueden cambiar el statu quo de la industria, y con el 99% del software del mundo que contiene al menos algo de código abierto, este ámbito de desarrollo es un gran lugar para empezar a centrarse en la formación de los desarrolladores en materia de seguridad.

El plan cita recursos venerables como los fundamentos del software seguro de la OpenSSF courses, y los amplios y antiguos recursos de la Fundación OWASP. Estos centros de información son inestimables. El despliegue propuesto para difundir estos materiales con el fin de capacitar a los desarrolladores implica reunir una amplia red de socios, tanto en el sector público como en el privado, además de asociarse con instituciones educativas para que el desarrollo seguro de código abierto sea una característica clave del plan de estudios. 

En cuanto a la forma de ganarse los corazones y las mentes de los ingenieros de software de todo el mundo, muchos de los cuales han visto reforzada la seguridad como algo que no es su trabajo ni su prioridad, el plan detalla una estrategia de recompensa y reconocimiento para dirigirse tanto a los desarrolladores que mantienen las 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 distintivos por niveles que muestran el progreso y la habilidad funcionan tan bien en un entorno de aprendizaje como en algo como Steam o Xbox.

Sin embargo, lo que preocupa es que no estamos abordando uno de los problemas principales, y es la entrega de módulos de aprendizaje dentro del programa de seguridad de una organización. Al haber 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 hablar de cualquier cosa que parezca que pueda interrumpir el trabajo que es la prioridad número uno. La capacitación de los desarrolladores requiere que se comprometan continuamente con el material del curso, y para que esto tenga éxito, tiene que tener sentido en el contexto de su trabajo diario.

Si consideramos un modelo de madurez establecido como el Modelo de Madurez de Aseguramiento del 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 del desarrollador. El modelo en su totalidad es amplio, y hay pasos progresivos para alcanzar niveles más altos de madurez. Sin embargo, las etapas iniciales recomiendan sólo 1 ó 2 días de formación formal para los desarrolladores, lo que apenas es suficiente para arañar la superficie de la conciencia de seguridad. Incluso así, un informe reciente del Enterprise Strategy Group (ESG) reveló que menos de la mitad de las organizaciones exigen a los desarrolladores que participen en una formación formal sobre seguridad más de una vez al año. Nuestra propia investigación en conjunto con Evans Data reveló que sólo el 29% de los desarrolladores cree que se debe priorizar la práctica activa de escribir código libre de vulnerabilidades. Existe una clara desconexión entre la forma en que se imparte y se recibe la formación, y su utilidad real para lograr la madurez en materia de seguridad, especialmente si los desarrolladores no ven su valor.

Lista de materiales de software: ¿Este plan rompe las barreras de adopción?

Otra área que el plan pretende abordar es la calamidad que a menudo existe en torno a la creación y el mantenimiento de la lista de materiales de software (SBOM), con la corriente "SBOM Everywhere - Improve SBOM Tooling and Training to Drive Adoption" (SBOM en todas partes: mejorar las herramientas y la formación de SBOM para impulsar la adopción), que investiga formas de facilitar a los desarrolladores y a sus organizaciones la creación, actualización y uso de SBOM para impulsar mejores resultados de seguridad.

En la actualidad, los SBOM no están ampliamente adoptados en la mayoría de los sectores verticales, lo que dificulta el aprovechamiento de su potencial para reducir los riesgos de seguridad. El plan cuenta con una brillante estrategia para definir los estándares clave para la formulación de los SBOM, así como herramientas para facilitar su creación que se ajusten a la forma de trabajar de los desarrolladores. Sólo con esto se conseguiría disminuir la carga de otra tarea del SDLC para los desarrolladores, que ya están dando muchas vueltas para crear software a la velocidad de la demanda. 

Lo que me temo, sin embargo, es que en la organización media, las responsabilidades de seguridad pueden ser una verdadera zona gris para los desarrolladores. ¿Quién es el responsable de la seguridad? En última instancia, es el equipo de seguridad, pero los desarrolladores deben participar en el viaje si queremos su ayuda. Hay que definir claramente las tareas y las expectativas, y necesitan tiempo para asumir estas medidas adicionales de su éxito. 

Del OSS al resto del mundo del software

El Plan de Movilización de la Seguridad del Software de Código Abierto es ambicioso, audaz y exactamente lo que se necesita para impulsar la responsabilidad de los desarrolladores en materia de seguridad. Ha sido necesaria una "Alianza Rebelde" de algunos actores poderosos que se han unido, pero esto sirve como prueba de que estamos avanzando en la dirección correcta y dejando atrás la idea de que la brecha de habilidades de ciberseguridad se arreglará mágicamente. 

Es nuestra nueva esperanza, y nos va a hacer falta a todos para impulsar esta estructura más allá del OSS. Sin embargo, los profesionales de la seguridad deben mirar dentro de sí mismos, y analizar los equipos de desarrollo que trabajan en el código que tienen la tarea de proteger. Deben hacer un assessment honesto de sus capacidades actuales, donde están las lagunas, y trabajar para crear un estado maduro de última etapa que sea hermético, proactivo, e incluya un programa que imparta verdaderas habilidades de seguridad a la cohorte de desarrollo. Hasta que no estén significativamente habilitadas, es posible que todavía estemos un poco inmaduros en nuestro enfoque de las vulnerabilidades a nivel de código.

‍

>> Ponga a prueba la madurez de su equipo en materia de seguridad con nuestro desafío XSS práctico e interactivo.