A medida que continuamos nuestro viaje hacia la TI continua, nos centramos mucho en la seguridad. Y así debe ser. Las infracciones abundan. Diariamente se descubren vulnerabilidades y la falta de parches no parece reducirse.
Una de las soluciones que se sugieren a menudo para lograr un código más seguro es la de escanear el código fuente. Los análisis de seguridad estáticos y dinámicos se han convertido en un ingrediente básico de los procesos de entrega continua. Nuestras propias tuberías internas los incluyen, y puedo, en cualquier momento, echar un vistazo a un panel que me informa todo sobre lo que encuentran esos análisis.
![]() |
Pero saber que existen vulnerabilidades en el código fuente –como nos recuerda GI Joe– es sólo la mitad de la batalla. Si bien sería fascinante si la otra mitad realmente fuera láseres azules y rojos, la realidad de la seguridad de las aplicação es que la otra mitad está "haciendo algo con respecto a esas vulnerabilidades". Lamentablemente no vemos que esa realidad se haga realidad. Tal vez recuerde un informe de Tripwire ( Estado de la seguridad de los contenedores, 2019 ) en el que el 17 % de los encuestados admitió tener contenedores vulnerables, sabía lo que eran y los implementó de todos modos. También puede recordar un informe de Arxan/IBM de 2017 sobre seguridad de aplicação móviles e IoT que descubrió que el 53 % de los encuestados utiliza pruebas de seguridad estáticas y el 51 % utiliza pruebas de seguridad dinámicas para aplicaciones móviles. Y a pesar de las importantes preocupaciones por una posible violación de datos, casi la mitad (44%) no estaba tomando medidas para evitarla. |
El problema de no realizar pruebas ni hacer nada acerca de las vulnerabilidades conocidas casi siempre está relacionado con la presión para disminuir el tiempo necesario para obtener valor. Casi la mitad (48%) de los desarrolladores dicen que no tienen suficiente tiempo para dedicarlo a la seguridad ( Encuesta de la comunidad DevSecOps de 2018 ). Otras encuestas coinciden: existe una presión increíble sobre los desarrolladores para producir código más rápido y con mayor frecuencia. Resulta que la seguridad sigue siendo el "elemento" que se deja de lado cuando la velocidad está en juego, ya sea en la ruta de datos o de entrega.
Está bien establecido que las personas trabajan en función de lo que se les mide. Y como los desarrolladores son personas, eso significa que también están sujetos a esa regla. Si se mide su éxito por llegar rápidamente al mercado, trabajarán para lograrlo, incluso si eso significa saltear pasos que comprometan la seguridad. Si vamos a entregar aplicações seguras al mercado, debemos adoptar un cambio cultural que mida y valore la llegada segura al mercado tanto como la rapidez con la que llega al mismo .
Hasta que eso ocurra, estaremos tan seguros confiando en los láseres rojos y azules para lidiar con las vulnerabilidades como lo estamos en los desarrolladores.