Se ha dicho antes… mucho antes. Es el filósofo Voltaire del siglo XVIII a quien se le atribuye el mérito del eterno proverbio «Lo perfecto es enemigo de lo bueno».
Pero aquí estamos, siglos después, y sigue siendo relevante, en este caso para el desarrollo de software moderno. Si intenta hacer que el software sea perfecto, no sólo fracasará en eso, sino que tampoco podrá sacar el producto al mercado.
Para hacer lo bueno y al mismo tiempo hacer las cosas es necesario establecer prioridades: solucionar los problemas más grandes, eliminar las peores amenazas y llevar el producto al mercado. Eso es lo que DevSecOps, bien hecho, puede hacer.
Pero hacerlo bien (integrar la seguridad en el desarrollo y las operaciones) no ha sido fácil. Todavía no lo es. Los equipos de DevOps todavía ven con demasiada frecuencia al equipo de seguridad como un lastre para su principal prioridad: la velocidad. Creen que es seguridad o velocidad, pero no ambas.
Ese es el caso incluso después de más de una década de esfuerzos para lograr la seguridad al ritmo del desarrollo. La Conferencia RSA 2020 en San Francisco contó con un día de conferencias magistrales, paneles de discusión y talleres sobre cómo mejorar DevSecOpsy la mayor parte de ellos se centraron en lo que se ha convertido en un mantra: para lograr que los equipos de DevOps creen software seguro, hacer que la forma segura sea la más fácil y rápida.
Ese mismo año, el informe «Building Security in Maturity Model» (BSIMM) de 2020 de Synopsys documentó el mensaje de los desarrolladores: «Nos encantaría tener seguridad en nuestros flujos de valor si no nos frenan».
La industria de la seguridad ha logrado avances continuos en esa área. Las herramientas automatizadas de prueba de seguridad de aplicaciones (AST) ahora son estándar. Son mucho más rápidos que las pruebas manuales y señalan defectos mientras se crea el código, en lugar de al final del ciclo de vida de desarrollo de software (SDLC).
Pero la tensión persiste porque las porterías siguen moviéndose. Lo que solía parecer rápido ahora se considera intolerablemente lento, gracias a tecnologías como las tuberías de entrega continua. Se espera que la velocidad vuelva a aumentar con el uso cada vez mayor de herramientas de inteligencia artificial generativa para escribir código.
Como dijo recientemente Jason Schmitt, director general de Synopsys Software Integrity Group, existe un “debate constante sobre dónde nos encontramos en ese aspecto”. [security vs. speed] continuo”.
Pero la noticia alentadora es que también hay un impulso continuo dentro de la industria de la seguridad para eliminar la percepción de que es un juego de suma cero, donde un lado u otro tiene que perder, y los usuarios de software también pierden.
De hecho, es importante hacer bien DevSecOps. La seguridad no puede ser una ocurrencia tardía en un mundo donde su falta puede permitir a los ciberdelincuentes infligir una lista de horrores a sus víctimas: identidad robada, compras fraudulentas con tarjetas de crédito robadas, cuentas bancarias saqueadas, robo de propiedad intelectual y daños personales comprometidos. y datos financieros. Y sí, se gastan millones para pagar a los atacantes de ransomware.
Schmitt ve dos tendencias prometedoras para hacer que la seguridad y la velocidad sean beneficiosas para todos. Una es la innovación continua en herramientas automatizadas que sean lo suficientemente rápidas como para mantenerse al día con el ritmo acelerado del desarrollo moderno. El otro es un cambio cultural en el que los equipos de seguridad trabajan con Dev y Ops desde el comienzo de un proyecto.
Steven Zimmerman, gerente de soluciones de seguridad DevOps de Synopsys Software Integrity Group, se refirió a ese cambio cultural en un reciente AppSec decodificado entrevista en video, señalando que DevSecOps exitoso requiere interacción de equipo multifuncional comenzando en el nivel de planificación y estrategia: capacitar a los equipos de desarrollo pero también comprender sus prioridades. «Es una alineación organizacional», dijo, «donde todos tienen un asiento en la mesa».
De hecho, el informe BSIMM ha señalado durante años que las organizaciones han impulsado la madurez de sus iniciativas de seguridad de software mediante la contratación y capacitación de “campeones de seguridad” voluntarios de los equipos de desarrollo y operaciones.
Eso no significa un cambio de responsabilidad: el equipo de seguridad todavía es dueño de la seguridad y la velocidad sigue siendo la principal presión sobre los desarrolladores. Pero ese tipo de colaboración ayuda a lograr seguridad y velocidad.
Otro factor que facilita la seguridad rápidamente es establecer prioridades. Si los desarrolladores son bombardeados constantemente con notificaciones sobre defectos triviales, se sentirán abrumados por el «ruido» y los ignorarán todos, lo que degrada la seguridad. O, si se ven obligados a ocuparse de todos ellos, el desarrollo puede paralizarse.
Sin embargo, las herramientas automatizadas se pueden configurar para reflejar las prioridades de una organización. Las aplicaciones internas que nunca llegan a la Internet pública no necesitan el mismo nivel de pruebas que las aplicaciones externas. Las aplicaciones críticas para el negocio necesitan más atención que aquellas que no lo son.
«Necesitamos brindar información relevante a nuestros equipos de desarrollo y DevOps que los ayude a identificar los problemas más urgentes que deben solucionarse», dijo Zimmerman, «y brindarles la información que les ayude a solucionarlos».
Limitar las notificaciones de AST a lo que es más importante solucionar «puede acelerar la detección de riesgos y evitar obstruir el proceso de DevSecOps», dijo Zimmerman.
Una advertencia: una de las tendencias más recientes en DevSecOps son las plataformas de desarrollo que ofrecen funciones de prueba de seguridad «livianas» diseñadas para priorizar la velocidad, la simplicidad y la facilidad de uso.
No hay nada de malo en utilizar herramientas de seguridad ligeras. Pero es importante conocer sus límites. No permita que le den una falsa sensación de seguridad integral, porque sus capacidades también son livianas. Detectan vulnerabilidades más simples y relativamente menores que son fáciles de encontrar, pero no son tan buenos para detectar defectos más sofisticados y peligrosos como secuencias de comandos entre sitios o inyección SQL en aplicaciones grandes con millones de líneas de código.
El desarrollo de software confiable necesita pruebas tanto livianas como intensas. Eso significa que el desafío obvio para la industria de la seguridad es hacer que las herramientas más sofisticadas sean tan rápidas como las más simples.
Para lograrlo se necesita trabajo en equipo: estrategia y planificación con personas, herramientas y plataformas trabajando juntas. Aún no es algo común, pero es posible. Así que no renuncies ni a la velocidad ni a la seguridad. Ambas cosas son posibles y necesarias.
Para más información sobre cómo Synopsys puede ayudar a generar confianza en su software, visite www.synopsys.com/software.