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

Un desarrollador, en su hábitat natural, a menudo se encuentra en un estado de profunda concentración, codificando características impresionantes 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 del desarrollo de software (SDLC).

Sin embargo, como hemos comentado antes, muchos de nosotros seguimos dando prioridad a las funciones sobre las mejores prácticas de seguridad. Después de todo, en la mayoría de las organizaciones, está configurado para ser el trabajo de otra persona y la formación de seguridad adecuada para nosotros es limitada. Las pruebas de penetración y las herramientas de escaneo de análisis estático (más conocidas como SAST) son sólo una parte del proceso general para mitigar los riesgos de seguridad, operando de forma bastante independiente de lo que hacemos... hasta que el código nos llega de vuelta para las correcciones, por supuesto.

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

Estas interacciones suelen definir un equipo, una cultura. Lo preocupante es que la falta de comunicación, entendimiento y colaboración en general ha creado tensiones, al menos en el lado del desarrollador. Piénsalo: Imagínate que has pasado unos cientos de horas esculpiendo una estatua maravillosa, y entonces llega alguien con un martillo y empieza a romper trozos de ella después de haberte dicho que sus cimientos no están a la altura. Esa es la dinámica que se percibe entre un probador y un desarrollador: este último ve cómo su software es masacrado por una persona ajena que no ha trabajado en el proceso con él; en cambio, ha ampliado la carga de trabajo y retrasado la satisfacción de enviar el código.

Al haber entrado en el espacio de la seguridad hace tiempo, puedo ver ambos lados de la historia. Y no, los pentesters no odian a los desarrolladores. El pentester está, con toda probabilidad, sobrecargado de trabajo y bajo mucha presión. Por ello, un flujo constante de errores de seguridad comunes que podrían arreglarse fácilmente a nivel de código le quitan tiempo, recursos y espacio para pensar en los problemas realmente serios.

Siempre vi a los pentesters como una especie de padres. Quieren que te vaya bien, y cuando no lo haces... no se enfadan, solo se decepcionan.

Ahora que he puesto esa imagen (quizás un poco injusta) en tu mente, vamos a explorar esto un poco más a fondo. ¿Qué ha provocado 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 su trabajo. Desgraciadamente, cuando los desarrolladores reciben los resultados de los análisis estáticos y los pentest, pueden sentirse como si se tratara de un boletín de notas. Les han puesto notas bajas, pero al final del día, sus jefes les evalúan por las características que han construido y el tiempo que han entregado, no por si había elementos vulnerables en el software o no.

Para el pobre pentester, este es un caso de "no disparar al mensajero". No es nada personal: su misión es encontrar bugs, y los han encontrado. Es cierto que, de persona a persona, puede que algunos pentesters sean más gruñones que otros, pero no pretenden (o no deberían) crucificar a los equipos de desarrollo. Sería mucho más fácil para ambos equipos si estuvieran en la misma página con lo que constituye la mejor práctica de seguridad. Y no se espera que los desarrolladores sean perfectos; siendo realistas, 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 mayores? ¿Y por qué no me ayudan a arreglarlos si les importa tanto?"

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

La mayoría de las vulnerabilidades comunes son, de hecho, problemas menores para remediar - una vez conocidos, las correcciones son simples de ejecutar para cosas como el cross-site scripting (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 para 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, es una estadística aleccionadora.

Algunos equipos de pentest ayudan a remediar los fallos de seguridad, pero otros proporcionan un informe con las malas noticias y esperan que los desarrolladores trabajen en las correcciones, incluso si se han trasladado a un proyecto diferente para cuando esto sucede. Y en algunos casos, el equipo de desarrollo puede enfrentarse a un informe que incluya fallos que no pueden (o no se debe esperar que los solucionen); aun así, debe formar parte de las conclusiones y, de nuevo, no debe tomarse como algo personal.

El "término medio" para esto sería que los pentesters, el personal de seguridad y los directores de desarrollo actuaran más bien como mentores para garantizar que el equipo tiene lo que necesita en términos de formación y herramientas eficaces, dando a los codificadores individuales la mejor oportunidad de tener éxito y codificar de forma segura desde el principio del SDLC. Ambos equipos deberían reunirse a mitad de camino para garantizar que la seguridad se tiene en cuenta desde el principio, como parte de una práctica saludable de DevSecOps.

"Tengo muchos más conocimientos de seguridad de los que se me atribuyen; 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 escaneo de análisis estático (SAST) juegan 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 la revisión manual del código y presiona tanto a los desarrolladores como a los pentesters. El personal de pentesting se ha tomado el tiempo de configurar meticulosamente las reglas personalizadas para evitar lecturas inexactas y ha proporcionado orientación específica para la empresa, sin embargo, algunas lecturas falsas se cuelan y terminan frente a un desarrollador que se rasca la cabeza.

Este proceso no es perfecto, pero el otro problema es que muchos desarrolladores carecen de conocimientos suficientes para mitigar muchas de las vulnerabilidades más comunes de forma constante. Dado que la formación en seguridad es escasa en la educación terciaria y que la formación en el puesto de trabajo varía en cuanto a su eficacia, es lógico que también haya un cierto exceso de confianza (y no es culpa de ellos: nosotros, como industria, tenemos que mejorar para dotarles de lo que necesitan).

"No sabía que esta aplicación iba a ser probada, pero ahora estoy atascado con las tareas de corrección".

A veces, los ingenieros sobrecargados de trabajo asumen que los pentesters están esperando el momento de probar una aplicación y arruinar el desfile del equipo de desarrollo. Están probando en exceso, son puntillosos, están creando trabajo extra.

El único problema es que ellos también están sobrecargados de trabajo (más aún, de hecho, la escasez de habilidades de ciberseguridad está en niveles terribles y empeorando) y simplemente no tienen tiempo para hacer pruebas sin razón. No son los únicos que toman la decisión de dar prioridad a las pruebas; pueden haber sido solicitadas por la alta dirección, un cliente, como parte de una auditoría de seguridad o incluso determinadas como resultado de un programa de recompensas por errores.

Para un desarrollador, ser retirado de los sprints de creación de características actuales para trabajar en correcciones de seguridad es molesto, especialmente si no es su trabajo. Tal vez un equipo anterior hizo la última actualización, u otro proveedor. Sin embargo, la seguridad es un problema de todos. Eso no significa que todos los desarrolladores tengan que apropiarse de los errores de seguridad como si los hubieran hecho ellos mismos, pero sí tienen que participar en la fiesta en términos de que la seguridad es una responsabilidad compartida.

¿A dónde vamos a partir de aquí?

A veces, un cambio de mentalidad puede ser todo lo que se necesita para avanzar significativamente en la solución de un problema. Ya hemos hablado de la reacción más bien fría que tiene un desarrollador ante los resultados menos favorables de un pentest, pero ¿qué pasaría si pudiera convertirlo en un reto? Tal vez podrían pensar en el pentester como un competidor amistoso; alguien a quien pueden vencer en su propio juego. Después de todo, un desarrollador consciente de la seguridad que puede eliminar los errores comunes mientras escribe el código va a hacer su trabajo mucho más difícil. Por el contrario, un desarrollador que no se centra en la seguridad va a ser ampliamente superado por sus homólogos pentester cuando puedan romper fácilmente su software.

Puede que los pentesters y los desarrolladores no estén unidos en armonía el 100% de las veces, pero su relación puede mejorar enormemente cuando una organización aborda la seguridad como una prioridad clave, y empodera a los equipos con los conocimientos y las herramientas adecuadas para tener éxito, especialmente a los desarrolladores. Todo se reduce a si una cultura de seguridad positiva en toda la empresa es una prioridad, y si vamos a luchar la batalla (actualmente) perdida contra las vulnerabilidades comunes, absolutamente debería serlo.