Si las herramientas de AppSec son la solución definitiva, ¿por qué tantas empresas no las están utilizando?

Una versión de este artículo apareció en SC Magazine. Ha sido actualizado y distribuido aquí.

‍

Uno de los muchos dilemas a los que se enfrentan los especialistas en seguridad actuales es encontrar el equilibrio adecuado de soluciones para gestionar los riesgos cibernéticos. ¿Cómo debería repartirse el presupuesto entre herramientas y personal? ¿Qué conjunto de herramientas funcionará mejor con la infraestructura tecnológica existente? Con tantas opciones disponibles, no hay respuestas fáciles, y elegir las incorrectas costará tiempo y dinero más adelante.

Un informe reciente reveló que el mercado de herramientas de seguridad de aplicaciones apunta a un crecimiento «explosivo» de aquí a 2025, una clara señal de su papel indiscutible en las prácticas exitosas de DevSecOps y de su creciente relevancia en el sector ante el aumento del volumen de código con posibles vulnerabilidades de seguridad.

Sin embargo, existe un problema curioso. Casi la mitad de las organizaciones lanzan código vulnerable a sabiendas, a pesar de utilizar una serie de herramientas de AppSec diseñadas precisamente para evitarlo. Para productos con una demanda de mercado innegable y en rápido crecimiento, esto tiene poco sentido. ¿Por qué tantas empresas invierten en herramientas de seguridad sofisticadas para luego ignorar sus hallazgos o ni siquiera utilizarlas? Es un poco como comprar una casa frente a la playa para terminar durmiendo en una tienda de campaña en el bosque.

Existen varias razones por las que las herramientas de AppSec no se están utilizando como cabría esperar; el problema no reside tanto en las herramientas ni en su funcionalidad, sino en cómo se integran en el programa de seguridad en su conjunto.

Más herramientas no equivalen a menos problemas.

A medida que las empresas evolucionan sus procesos de desarrollo de software, pasando de Agile a DevOps y hasta el nirvana que representa DevSecOps (bueno, por ahora es lo mejor que tenemos), es inevitable que se adquieran múltiples escáneres, monitores, firewalls y todo tipo de herramientas de AppSec por el camino. Aunque pueda parecer que «cuantos más, mejor», a menudo esto conduce a una infraestructura tecnológica que se asemeja al monstruo de Frankenstein, con toda la imprevisibilidad que ello conlleva.

Con presupuestos y recursos expertos cada vez más limitados para el volumen de trabajo requerido, intentar deshacer el entuerto y encontrar el mejor camino a seguir es una tarea desalentadora, y el código que necesita ser escaneado y corregido no deja de acumularse. No es de extrañar que muchas organizaciones hayan tenido que seguir lanzando código, aunque resulta alarmante y sigue suponiendo un riesgo inmenso para nuestros datos y nuestra privacidad.

Las herramientas de escaneo son lentas, y esto afecta a la agilidad de las versiones.

Lograr la seguridad a gran velocidad es una especie de quimera en el desarrollo de software, y la verdad es que todavía estamos intentando conseguirlo incluso mientras guiamos a las organizaciones hacia la adopción de un enfoque orientado a DevSecOps. La revisión manual y meticulosa del código pudo funcionar como salvaguarda de seguridad en los años 90, pero en una época en la que producimos cientos de miles de millones de líneas de código, es un plan tan eficaz como intentar preparar un campo de fútbol con unas tijeras de uñas.

Las herramientas de escaneo automatizan el proceso de encontrar posibles problemas, realizando esa parte de revisión meticulosa del código por nosotros. El problema es que siguen siendo lentas en el contexto de un pipeline de CI/CD a pleno rendimiento, y ninguna herramienta detecta todas las vulnerabilidades. Además, hay un par de problemas evidentes con los resultados que se arrojan al equipo de seguridad tras un escaneo:

1. Hay una gran cantidad de falsos positivos (y negativos)
2. Algún experto en seguridad tiene que sentarse a realizar una revisión manual para separar los errores reales de los fantasmas
3. A menudo, se revelan demasiadas vulnerabilidades comunes que deberían haberse detectado antes de desplegar el código. ¿De verdad quieres que tus expertos en seguridad, que son muy costosos, se distraigan con minucias en lugar de ocuparse de los problemas de seguridad graves?
4. Los escáneres detectan, no corrigen.

Incluso en una organización que hace todo lo posible por seguir las mejores prácticas de ciberseguridad y adaptarse a los tiempos incluyendo la seguridad en cada etapa del proceso, el problema anterior sigue siendo un obstáculo si los escáneres son la principal medida de protección, y demasiados errores comunes frenan al equipo a la hora de desplegar código seguro. Es lógico que se tomen atajos, y eso suele traducirse en depender del mínimo indispensable de herramientas que no pueden cubrir todos los riesgos potenciales, incluso si se ha adquirido un conjunto completo de soluciones.

Cierta automatización dirigida por la tecnología puede reducir la calidad del código

El escaneo y las pruebas soportan la carga de los procesos automatizados en las herramientas de AppSec, junto con elementos esenciales como firewalls y monitorización, pero otras herramientas comunes pueden erosionar inadvertidamente los fundamentos de seguridad prácticos con el paso del tiempo.

Por ejemplo, la tecnología RASP (autoprotección de aplicaciones en tiempo de ejecución) se aplica a menudo para reforzar la postura de seguridad sin sacrificar la velocidad de codificación. Opera en el entorno de ejecución de una aplicación, protegiendo contra la entrada de código malicioso, ataques en tiempo real y señalando cualquier comportamiento de ejecución extraño.

Sin duda es una capa de protección adicional, pero si se considera como una salvaguarda contra cualquier debilidad potencial en el código, los desarrolladores pueden volverse complacientes, especialmente cuando se enfrentan a plazos de lanzamiento cada vez más imposibles para publicar nuevas funciones. Es posible que no se sigan las prácticas de codificación segura, bajo la suposición de que la autoprotección en tiempo de ejecución detectará cualquier error. Los desarrolladores no se esfuerzan por crear patrones de codificación inseguros, pero la seguridad a menudo se desprioriza en favor de la entrega de funciones, especialmente cuando se asume que existe una salvaguarda automatizada.

Las herramientas pueden fallar (y, en el caso de RASP, a menudo funcionan en modo de monitoreo para evitar falsos positivos, lo que solo proporciona visibilidad, no protección, ante un ataque), y cuando eso sucede, es el código seguro y de alta calidad en el que se puede confiar siempre. La conciencia de seguridad en cada rol que interactúa con el código es fundamental para DevSecOps, y que los desarrolladores no se capaciten o no produzcan código seguro es un error. Escribir código seguro o inseguro requiere el mismo esfuerzo; lo que realmente requiere energía es adquirir el conocimiento para programar de forma segura. El tiempo dedicado a implementar y optimizar RASP se puede aprovechar mucho mejor capacitando a los desarrolladores para que no cometan el error desde el principio.

Equilibrar herramientas y personas: no es una solución mágica, pero es lo más cercano que tenemos (por ahora).

El principio fundamental de DevSecOps es hacer de la seguridad una responsabilidad compartida, y las organizaciones que crean el software que impulsa nuestras vidas (desde la red eléctrica hasta nuestros timbres) deben involucrar a todos en este proceso para garantizar un mayor nivel de seguridad.

Las herramientas no lo harán todo, y ni siquiera es la forma más económica. Con diferencia, los mejores resultados se obtienen priorizando la formación en seguridad relevante para todos los que tocan el código, trabajando activamente para mantener la seguridad presente en el equipo de desarrollo y construyendo una cultura de seguridad positiva liderada por personas, con un conjunto de herramientas que desempeñe un papel de apoyo.

Incluso ante limitaciones de tiempo, recortes y otros factores que quitan el sueño a los expertos en seguridad, si los desarrolladores no introducen defectos de seguridad comunes desde el principio, esas herramientas (se utilicen o no) representan un factor de riesgo mucho menor.

‍