¿Mi pentester, mi enemigo? Los desarrolladores revelan lo que realmente piensan sobre los resultados del pentesting y el análisis estático

A un desarrollador en su hábitat natural se le suele ver en un estado de profunda concentración, programando funciones increíbles con plazos ajustados. La creación de funciones suele ser nuestra parte favorita del trabajo y, en realidad, es el resultado fundamental del ciclo de vida de desarrollo de software (SDLC).

Sin embargo, como hemos comentado anteriormente, muchos de nosotros seguimos priorizando las funciones sobre las mejores prácticas de seguridad. Al fin y al cabo, en la mayoría de las organizaciones, esto se plantea como el trabajo de otra persona y nuestra formación adecuada en seguridad es limitada. Las pruebas de penetración y las herramientas de análisis estático (más conocidas como SAST) son solo una parte del proceso general para mitigar los riesgos de seguridad y operan de forma bastante independiente a nuestro trabajo... hasta que el código vuelve a nosotros para correcciones urgentes, claro está.

Y es en ese momento cuando muchos desarrolladores piensan: "¿Me odian los pentesters?".

Estas interacciones suelen definir a un equipo y su cultura. Lo preocupante es que la falta de comunicación, entendimiento y colaboración general ha creado tensión, al menos por parte del desarrollador. Piénselo: imagine que ha pasado cientos de horas esculpiendo una estatua maravillosa y, de repente, alguien aparece con un martillo y empieza a romper trozos después de decirle que sus cimientos no están a la altura. Esa es la dinámica que se percibe entre un evaluador y un desarrollador: a este último le destrozan sus creaciones de software un extraño que no ha trabajado en el proceso con él; en cambio, le han aumentado la carga de trabajo y retrasado la satisfacción de entregar el código.

Habiéndome adentrado en el ámbito de la seguridad hace mucho tiempo, puedo ver ambas caras de la moneda. Y no, los pentesters no odian a los desarrolladores. Lo más probable es que el pentester esté sobrecargado de trabajo y bajo mucha presión. Como tal, un flujo constante de errores de seguridad comunes que podrían solucionarse fácilmente a nivel de código consume tiempo, recursos y energía mental que deberían dedicarse a los problemas realmente graves.

Siempre vi a los pentesters como una especie de padres. Quieren que lo hagas bien y, cuando no es así... no están enfadados, solo decepcionados.

Ahora que he plantado esa imagen (quizás un poco injusta) en su mente, exploremos esto un poco más a fondo. ¿Qué ha causado esta visión del mundo entre los desarrolladores?

"¡Por supuesto que me pongo a la defensiva; me están diciendo cómo hacer mi trabajo!"

A nadie le gusta sentir que ha hecho un mal trabajo o que a alguien no le gusta lo que hace. Lamentablemente para los desarrolladores, cuando los resultados del análisis estático y las pruebas de penetración vuelven a ellos, puede parecer un boletín de notas. Han recibido calificaciones bajas, pero al final del día, sus jefes los evalúan por las funciones que han creado y el tiempo en que las han entregado, no por si había elementos vulnerables en el software o no.

Para el pobre pentester, este es un caso de "no disparen al mensajero". No es nada personal: su tarea es encontrar errores y los han encontrado. Es cierto que, a nivel personal, quizás algunos pentesters sean más gruñones que otros, pero no están (o no deberían estar) tratando de crucificar a los equipos de desarrollo. Sería mucho más fácil para ambos equipos si estuvieran de acuerdo en lo que constituye una mejor práctica de seguridad. Y no se espera que los desarrolladores sean perfectos; en realidad, el equipo de pruebas está ahí para protegerlos de la entrega de código vulnerable.

"Me han dicho que arregle todos estos problemas menores, ¿no saben que hay prioridades más altas? ¿Y por qué no me ayudan a arreglarlos si tanto les importa?"

Es cierto: la mayor prioridad de un desarrollador siempre será la creación de funciones y, en este loco mundo de rápida digitalización, tendrá que hacerse a gran velocidad. Aunque algunos programadores tienen un interés personal en la seguridad y la programación segura, el sentimiento general es que la seguridad es "problema de otro", lo que inevitablemente incluye a los pentesters.

La mayoría de las vulnerabilidades comunes son, de hecho, problemas menores de remediar; una vez conocidos, las soluciones son sencillas de ejecutar para casos como la inyección de scripts en sitios cruzados (XSS) y la inyección SQL... el problema es que muchos desarrolladores no se dan cuenta de que los están introduciendo en primer lugar, y estos problemas aparentemente menores son la pequeña ventana de oportunidad que un atacante necesita para causar problemas devastadores a una empresa. Según Akamai, entre noviembre de 2017 y marzo de 2019, las vulnerabilidades de inyección SQL representaron el 65% de todos los vectores de ataque basados en la web. Para una vulnerabilidad que tiene una solución conocida desde hace más de veinte años, esa es una estadística aleccionadora.

Algunos equipos de pruebas de penetración sí ayudan en la corrección de errores de seguridad, pero otros simplemente entregan un informe con las malas noticias y esperan que los desarrolladores trabajen en las correcciones urgentes, incluso si ya han pasado a un proyecto diferente para cuando esto sucede. Y en algunos casos, el equipo de desarrollo puede enfrentarse a un informe que incluye errores que no pueden (o no se debería esperar que puedan) solucionar; aun así, debe formar parte de los hallazgos y, de nuevo, no debe tomarse como algo personal.

El "punto medio" ideal sería que los pentesters, el personal de seguridad y los gerentes de desarrollo actuaran más como mentores para garantizar que el equipo tenga lo que necesita en términos de formación y herramientas eficaces, dando a cada programador la mejor oportunidad de tener éxito y programar de forma segura desde el principio del SDLC. Ambos equipos realmente deberían encontrarse a mitad de camino para asegurar que la seguridad se considere desde el inicio, como parte de una práctica saludable de DevSecOps.

"Tengo muchos más conocimientos de seguridad de los que me reconocen; estos informes son en su mayoría falsos positivos o no son importantes".

El análisis estático es un elemento del proceso de seguridad en el SDLC, y las herramientas de análisis estático (SAST) desempeñan un papel fundamental. Y sí, los falsos positivos son un problema con estos y otros tipos (DAST/IAST/RAST) de escáneres. Es una molestia en lo que ya es un proceso lento, que requiere una revisión manual del código y ejerce presión tanto sobre los desarrolladores como sobre los pentesters. El personal de pruebas de penetración se ha tomado el tiempo de configurar meticulosamente reglas personalizadas para evitar lecturas inexactas y proporcionar orientación específica para la empresa, pero aun así, algunas lecturas falsas se cuelan y terminan frente a un desarrollador desconcertado.

Este proceso no es perfecto, pero el otro problema es que muchos desarrolladores carecen de los conocimientos suficientes para mitigar de forma constante muchas vulnerabilidades comunes. Dado que la formación en seguridad es escasa en la educación superior y que la eficacia de la formación en el puesto de trabajo es variable, es lógico pensar que también puede haber un exceso de confianza (y no es culpa suya; como sector, debemos mejorar a la hora de proporcionarles lo que necesitan).

"No sabía que esta aplicación iba a ser sometida a pruebas, pero ahora me toca a mí encargarme de las tareas de corrección".

A veces, los ingenieros, desbordados de trabajo, asumen que los pentesters están al acecho, esperando el momento de atacar probando una aplicación y arruinando los planes del equipo de desarrollo. Creen que hacen demasiadas pruebas, que buscan fallos insignificantes y que generan trabajo extra.

El único problema es que ellos también están desbordados (de hecho, más aún: la escasez de profesionales en ciberseguridad ha alcanzado niveles críticos y sigue empeorando) y simplemente no tienen tiempo para hacer pruebas sin motivo. No son los únicos que deciden priorizar las pruebas; puede haber sido una solicitud de la alta dirección, de un cliente, parte de una auditoría de seguridad o incluso el resultado de un programa de recompensas por errores.

Para un desarrollador, que lo aparten de los sprints de creación de funciones actuales para trabajar en correcciones de seguridad es molesto, especialmente si el trabajo no es suyo. Quizás el equipo anterior hizo la última actualización, o fue otro proveedor. Sin embargo, la seguridad es problema de todos. Eso no significa que cada desarrollador deba asumir la responsabilidad de los fallos de seguridad como si los hubiera cometido él mismo, pero sí debe participar en la idea de que la seguridad es una responsabilidad compartida.

¿Cómo seguir a partir de aquí?

A veces, un cambio de mentalidad es todo lo que hace falta para avanzar significativamente en la resolución de un problema. Hemos hablado de la reacción bastante fría que tiene un desarrollador ante unos resultados de pentesting poco favorables, pero ¿y si pudiera convertirlo en un reto? Quizás podría ver al pentester como un competidor amistoso; alguien a quien puede ganar en su propio juego. Al fin y al cabo, un desarrollador consciente de la seguridad que elimina los errores comunes mientras escribe código le pondrá las cosas mucho más difíciles. Por el contrario, un desarrollador que no se centra en la seguridad será superado por completo por sus homólogos pentesters cuando estos puedan vulnerar su software fácilmente.

Puede que los pentesters y los desarrolladores no estén en perfecta sintonía todo el tiempo, pero su relación puede mejorar enormemente cuando una organización trata la seguridad como una prioridad clave y dota a los equipos, especialmente a los desarrolladores, de los conocimientos y herramientas adecuados para tener éxito. Todo depende de si una cultura de seguridad positiva en toda la empresa es una prioridad, y si queremos luchar en la batalla (actualmente perdida) contra las vulnerabilidades comunes, sin duda debería serlo.