Conocer las vulnerabilidades es solo la mitad de la batalla

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

A medida que avanzamos hacia una TI continua, la seguridad recibe mucha atención. Y así debe ser. Las brechas de seguridad son frecuentes. Cada día se descubren nuevas vulnerabilidades, y la brecha de aplicación de parches no parece reducirse.

Una de las soluciones que se suelen proponer para lograr un código más seguro es analizar el código fuente. Los análisis de seguridad estáticos y dinámicos se han convertido en un componente esencial de los procesos de entrega continua. Nuestras propias canalizaciones internas los incluyen y, en cualquier momento, puedo consultar un panel que me muestra todo lo que detectan esos análisis.

Pero saber que existen vulnerabilidades en el código fuente —como nos recuerda G.I. Joe— es solo la mitad de la batalla. Aunque sería fascinante que la otra mitad fueran realmente láseres azules y rojos, la realidad de la seguridad de las aplicaciones es que la otra mitad consiste en "hacer algo al respecto de esas vulnerabilidades". Por desgracia, no vemos que eso se esté haciendo realidad. Quizá recuerde un informe de Tripwire (Estado de la seguridad de los contenedores en 2019) en el que el 17 % de los encuestados admitió que tenía contenedores vulnerables, sabía cuáles eran y, aun así, los desplegaba. También puede que recuerde un informe de Arxan/IBM de 2017 sobre la seguridad de las aplicaciones móviles y del IoT, según el cual el 53 % de los encuestados utilizaba pruebas de seguridad estáticas y el 51 %, pruebas de seguridad dinámicas para aplicaciones móviles. Y, pese a la gran preocupación por una posible brecha de seguridad, casi la mitad (el 44 %) no tomaba ninguna medida para evitarla.

El problema de no realizar pruebas ni tomar medidas ante vulnerabilidades conocidas casi siempre está relacionado con la presión por reducir el tiempo de obtención de valor. Casi la mitad (48 %) de los desarrolladores afirma que no dispone de tiempo suficiente para dedicarlo a la seguridad (Encuesta de la comunidad DevSecOps de 2018). Otros estudios coinciden: los desarrolladores están sometidos a una enorme presión para producir código con mayor rapidez y frecuencia. Al final, la seguridad sigue siendo el «aspecto» que se sacrifica cuando prima la velocidad, ya sea en la ruta de datos o en la de entrega.

Está más que demostrado que las personas trabajan para alcanzar los objetivos por los que se las evalúa. Y, como los desarrolladores también son personas, esta regla también se aplica a ellos. Si se los evalúa por la rapidez con la que lanzan un producto al mercado, trabajarán para conseguirlo, aunque eso implique saltarse pasos y poner en riesgo la seguridad. Si queremos lanzar aplicaciones seguras al mercado, debemos adoptar un cambio cultural que mida y valore llegar al mercado de forma segura tanto como llegar al mercado rápidamente.

Hasta que eso ocurra, confiar en láseres rojos y azules para hacer frente a las vulnerabilidades será tan seguro como confiar en los desarrolladores.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie