¿Estamos lo suficientemente maduros para el plan de movilización de seguridad del software de código abierto?

En el clima económico actual y el panorama de amenazas, ciertamente no envidio al CISO promedio. 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. Quizás lo más urgente sea el hecho de que todas las organizaciones (y sus respectivos equipos de desarrollo) se encuentran en diferentes etapas de madurez en materia de seguridad y no todas están preparadas para dar lo mejor de sí en términos de ciberdefensa.

Los últimos años de aumento de los incidentes de ciberseguridad han hecho que sea bastante difícil para los líderes de seguridad mantenerse un paso por delante. Con solo echar un vistazo a algunas de las ideas basadas en datos sobre nuestra creciente situación, se revela algo así como un barril de pólvora: más de Los ciberdelincuentes robarán 33 mil millones de registros solo en 2023, lo que representa un aumento del 175% con respecto a 2018. El Se prevé que el coste de la ciberdelincuencia alcance los 10,5 billones de dólares en 2025, y el costo promedio de una violación de datos se ha disparado hasta 4,24 millones de dólares (aunque solo tenemos que observar incidentes como Equifax o Solar Winds para ver que puede ser mucho peor).

Como industria, llevamos mucho tiempo esperando a que llegara un héroe y nos rescatara de los villanos de la ciberseguridad, que parecen tener más poder del que creíamos posible, incluso hace diez años. Estamos esperando que más profesionales de la ciberseguridad se unan y nos eleven a un programa de seguridad de mayor nivel, pero es una brecha que no podemos cerrar. Estamos esperando la solución mágica que promete automatizarnos para evitar un riesgo cada vez mayor, pero no existe y es muy poco probable que exista. Estamos esperando a que Luke Skywalker nos ayude a luchar contra el Lado Oscuro.

Resulta que la ayuda (y la esperanza) están en camino, en forma de El plan de movilización de seguridad del software de código abierto. Sin embargo, todos debemos hacer un balance y evaluar honestamente si nuestra organización es lo suficientemente madura (y si nuestros equipos de desarrollo tienen el nivel adecuado de conocimientos y habilidades en materia de seguridad) para implementar las mejores y más recientes estrategias defensivas, especialmente cuando requieren el apoyo del equipo de desarrollo y su ejecución.

¿Qué es el plan de movilización de seguridad del software de código abierto?

Este plan de diez puntos fue encabezado por la Fundación de Software de Código Abierto (OpenSSF) y la Fundación Linux, junto con funcionarios de la Casa Blanca, altos CISO y otros líderes sénior de 37 empresas de tecnología privadas. Con este apoyo combinado, tanto en lo que respecta a la acción como a la financiación, el estándar de seguridad del software de código abierto va a ser mucho más sólido.

Lo que es especialmente interesante es que se centran en la educación básica y la certificación a nivel de desarrollador, y en las medidas diseñadas para simplificar las actividades internas de la lista de materiales del 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 de los programas de seguridad organizacionales, y a una falta general de madurez en materia de seguridad entre los miembros del grupo de desarrollo, algo que no es culpa suya. 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 irracionales. Añadir aún más tareas en forma de tareas de seguridad y mantenimiento de la SBOM sin aumentar el tiempo disponible para ellas es una receta que ha fracasado incluso antes de empezar y, lamentablemente, es más común de lo que cabría esperar.

Así que, echemos un vistazo a lo que hay detrás del capó.

Certificación de seguridad para desarrolladores: ¿ya lo hemos conseguido?

Si hay algo que sabemos con certeza, es que desarrolladores expertos en seguridad siguen siendo un bien escaso. Esta es la realidad por varias razones, a saber, que hasta hace poco, los desarrolladores no formaban parte de la ecuación en lo que respecta a las estrategias de seguridad del software dentro de las organizaciones. Si a esto le sumamos que los desarrolladores no tienen muchos motivos 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), tenemos equipos de desarrollo que no están preparados para abordar realmente 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 analizamos el Plan de movilización para la seguridad del software de código abierto, la primera línea del plan de diez puntos es abordar las habilidades de seguridad de los desarrolladores para «ofrecer educación y certificación básicas para el desarrollo de software seguro a todos», lo cual es esencial para desarrollar la madurez en materia de seguridad en los equipos de desarrollo. En ellos se destacan las cuestiones de las que hemos hablado durante algún tiempo, incluido el hecho de que la programación segura no figura en la mayoría de los cursos de ingeniería de software de nivel terciario. Resulta increíblemente alentador ver que esto cuenta con el apoyo de personas y departamentos que pueden cambiar el status quo del sector, y con El 99% del software del mundo contiene al menos algunos código fuente abierto, este ámbito del desarrollo es un excelente lugar para empezar a centrarse en la formación de desarrolladores en materia de seguridad.

El plan cita recursos venerados como el Fundamentos del software seguro de OpenSSF los cursos y los amplios y antiguos recursos de la Fundación OWASP. Estos centros de información tienen un valor incalculable. La implementación propuesta para distribuir estos materiales para mejorar las habilidades de los desarrolladores implica reunir a una amplia red de socios, tanto del sector público como privado, además de asociarse con instituciones educativas para hacer del desarrollo seguro del 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 reforzado la seguridad como algo que no es su trabajo o prioridad, el plan detalla una estrategia de recompensas y reconocimientos 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 distintivos escalonados que muestran el progreso y las habilidades funcionan igual de bien en un entorno de aprendizaje que en 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. Tras haber trabajado en estrecha colaboración con desarrolladores durante gran parte de mi carrera, sé lo escépticos que son en lo que respecta a las herramientas y la formación, por no hablar de 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 interactúen 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 software Assurance (SAMM), la «Educación y orientación» es un componente central de la capa de gobierno, y hay un enfoque clave en la educación de los desarrolladores. 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 solo de 1 a 2 días de formación formal para los desarrolladores, lo que no es suficiente para empezar a tomar conciencia de la seguridad. Incluso entonces, un informe reciente del Enterprise Strategy Group (ESG) reveló que menos de la mitad de las organizaciones exigen a los desarrolladores que realicen una formación formal en seguridad más de una vez al año. Nuestro investigación propia 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 se debe priorizar. Existe una clara desconexión entre la forma en que se imparte y se recibe la educación y su utilidad real para lograr la madurez en materia de seguridad, especialmente si los desarrolladores no ven el valor.

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

Otra área que el plan busca abordar es la calamidad que a menudo existe en torno a la creación y el mantenimiento de la lista de materiales del software (SBOM), con la transmisión «SBOM en todas partes: mejore las herramientas y la capacitación de las SBOM para impulsar la adopción», que investiga formas de facilitar a los desarrolladores y sus organizaciones la creación, actualización y uso de las SBOM para obtener mejores resultados de seguridad.

Tal como están las cosas, los SBOM no se adoptan ampliamente en la mayoría de los mercados verticales, lo que dificulta aprovechar su potencial para reducir los riesgos de seguridad. El plan incluye una estrategia brillante para definir los estándares clave para la formulación de las SBOM, así como herramientas para facilitar la creación que se ajusten a la forma en que trabajan los desarrolladores. Estas medidas por sí solas contribuirían en gran medida a reducir la carga que supone una nueva tarea relacionada con el SDLC para los desarrolladores, que ya se están esforzando por crear software a la velocidad de la demanda.

Sin embargo, lo que me temo es que en la organización promedio, las responsabilidades de seguridad pueden ser una verdadera área gris para los desarrolladores. ¿Quién es responsable de la seguridad? En última instancia, es el equipo de seguridad, pero necesitamos que los desarrolladores se pongan manos a la obra si queremos su ayuda. Las tareas y las expectativas deben estar claramente definidas, y necesitan tiempo para tomar estas medidas adicionales para garantizar su éxito.

De 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 es exactamente lo que se necesita para impulsar la responsabilidad de los desarrolladores en materia de seguridad. Fue necesaria una «alianza rebelde» en la que participaron algunos actores poderosos, pero esto demuestra que vamos en la dirección correcta y dejamos atrás la idea de que el déficit de habilidades en ciberseguridad se solucionará por arte de magia.

Es nuestra nueva esperanza y será necesario que todos impulsemos esta estructura más allá del OSS. Sin embargo, los profesionales de la seguridad deben analizar su interior y analizar a los equipos de desarrollo que trabajan en el código que tienen la tarea de proteger. Deben hacer una evaluación honesta de sus capacidades actuales y determinar cuáles son las carencias, y trabajar para crear un estado maduro en una fase avanzada que sea hermético, proactivo e inclusivo con respecto a un programa que imparta verdaderas habilidades de seguridad a la generación de desarrolladores. Hasta que no se habiliten de manera significativa, es posible que sigamos siendo un poco inmaduros en nuestro enfoque de las vulnerabilidades a nivel de código.

‍

>> Pon a prueba la madurez de seguridad de tu equipo con nuestras prácticas e interactivas Desafío XSS!