DevSecOps: ¿por qué no podemos ser amigos?

Se llama DevSecOps, pero eso no significa que la seguridad tenga que dividir los procesos de desarrollo y operaciones. Por el contrario, puede ser el pegamento que los una, permitiendo a las organizaciones lanzar con más confianza software de mayor calidad con menos vulnerabilidades.

La relación entre desarrolladores e investigadores de seguridad suele ser tensa. Es mucho más fácil escribir software si no tienes que preocuparte de que alguien busque fallos lógicos, problemas de seguridad y otras peculiaridades que no inhiben la funcionalidad del programa pero que podrían acabar convirtiéndose en noticia de primera plana si alguien encuentra la forma de explotarlos en masa.

Pero la mayoría de los investigadores de seguridad no busca vulnerabilidades en el software porque guarden rencor a quienes lo programaron. Lo que buscan es mejorar la calidad del software y mitigar los riesgos que pueda suponer para quienes lo utilizan. No pretenden obstruir el proceso de desarrollo, sino mejorarlo. O, si el proceso en sí no mejora, al menos las personas que utilizan el software pueden ser conscientes de sus defectos.

Por eso la directora de la Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE.UU., Jen Easterly, dijo en Black Hat 2024 que la ciberseguridad es un «problema de calidad del software». ¿Se suponía que ese comentario era un ataque a las empresas que producen software con fallos? Probablemente no. Más bien se trataba de un llamamiento a las organizaciones para que mejoren la calidad de los programas que producen, lo que naturalmente conducirá a un software con menos vulnerabilidades a la espera de ser explotadas.

La marea sube todos los barcos

He aquí algunas de las formas en que las pruebas centradas en la seguridad pueden mejorar la calidad general del software:

• Revisión del código fuente: los investigadores de seguridad pueden analizar el código fuente de un programa para encontrar los fallos lógicos, los problemas de seguridad de la memoria y otras causas de vulnerabilidades. Pero eso no significa que las ventajas de revisar ese código fuente se limiten a mejorar la seguridad. También pueden descubrirse otros problemas, intencionadamente o no, a través de este proceso.
• Pruebas continuas: parte del problema de incorporar el «sec» en DevSecOps es la idea de que buscar fallos de seguridad en el software retrasará su lanzamiento, lo que va en contra de toda la filosofía DevOps. Pero, ¿qué resulta más frustrante, retrasar un lanzamiento público unos días para solucionar vulnerabilidades conocidas o tener que apresurarse a realizar una serie de correcciones de errores a posteriori cuando se descubren esas vulnerabilidades en la versión de lanzamiento?
• Lista de materiales del software: es fácil perder la pista de las dependencias del software de una organización. A los investigadores de seguridad les preocupa que las bibliotecas y los paquetes introduzcan vulnerabilidades, que se les oculte información, etc. Pero enumerar estas dependencias también puede ayudar a los desarrolladores a averiguar qué necesitan añadir, actualizar o incluso eliminar de sus programas para mejorar su calidad.

Mejores informes para equipos dinámicos

Un estudio realizado por ESG en nombre de Synack reveló que el 66% de las organizaciones afirmaba que los informes de las pruebas de penetración eran difíciles de poner en práctica en los sistemas de tickets, manuales de respuesta a incidentes y otros procesos de operaciones de seguridad; el 60% afirmaba que era difícil realizar pruebas con la frecuencia suficiente para seguir el ritmo de las actualizaciones del software en cuestión; y el 47% afirmaba que era poco probable que los equipos de pruebas tuvieran la amplitud de conocimientos necesaria para evaluar completamente las aplicaciones modernas, que pueden ser considerablemente más complejas que el software de antaño.

Son preocupaciones válidas, especialmente cuando las organizaciones piensan en una prueba de penetración tradicional realizada por dos investigadores con dos portátiles durante dos semanas. Pero las ofertas de Pruebas de Penetración como Servicio (PTaaS) pueden abordar todas esas preocupaciones. Una plataforma PTaaS moderna, garantiza que los informes mantengan la relación señal-ruido que los desarrolladores necesitan para averiguar qué problemas deben abordarse en primer lugar, ofrece pruebas continuas que, de hecho, pueden seguir el ritmo de las actualizaciones de las aplicaciones, y recluta investigadores de élite de todo el mundo para tener una combinación de habilidades.

Una parte crucial de la seguridad proactiva

La seguridad se ha tratado a menudo como una práctica reactiva: las organizaciones actualizan su software cuando los investigadores de seguridad revelan vulnerabilidades, intentan mejorar la seguridad de su red cuando son víctimas de ransomware y prometen tomarse la seguridad más en serio cuando el precio de sus acciones cae porque han sido víctimas o causantes de un ataque informático especialmente notable.

Este enfoque está anticuado. Las organizaciones deben ser proactivas a la hora de protegerse a sí mismas y a sus clientes. Las pruebas de penetración continuas pueden ayudar con lo primero; adoptar DevSecOps puede ayudar con lo segundo. En ambos casos, la seguridad debe dejar de ser una ocurrencia tardía.

Firmado: Alejandro Novo, Country Manager de Synack

La entrada DevSecOps: ¿por qué no podemos ser amigos? es original de MuySeguridad. Seguridad informática.