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

Un desarrollador en su hábitat natural suele ser visto en un estado de profunda concentración, programando funciones asombrosas 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 anteriormente, muchos de nosotros seguimos priorizando las funciones por encima de las mejores prácticas de seguridad. Al fin y al cabo, en la mayoría de las organizaciones, se configura para que sea el trabajo de otra persona y la formación adecuada en materia de seguridad para nosotros es limitada. Las herramientas de análisis estático y pruebas de penetración (más conocidas como SAST) son solo una parte del proceso global para mitigar los riesgos de seguridad, ya que funcionan de forma bastante independiente de lo que hacemos nosotros... hasta que recibimos el código para corregirlo, por supuesto.

Y es en ese momento cuando muchos desarrolladores piensan:»¿Me odian los pentésteres?».

Estas interacciones suelen definir un equipo, una cultura. Lo preocupante es que la falta de comunicación, comprensión y colaboración en general ha creado tensión, al menos por parte del desarrollador. Piénsalo: imagina que has pasado unos cientos de horas esculpiendo una estatua maravillosa, y luego alguien viene con un martillo y empieza a romperla en pedazos después de que te haya dicho que sus cimientos no están a la altura. Esa es la dinámica que se percibe entre un probador y un desarrollador: un extraño masacra a sus favoritos del software por parte de un extraño que no ha trabajado en el proceso con ellos; en cambio, han aumentado la carga de trabajo y han retrasado la satisfacción del código de envío.

Tras haberme mudado al ámbito de la seguridad hace mucho tiempo, puedo ver ambos lados de la historia. Y no, los pentestres no odiar desarrolladores. Es muy probable que el pentester esté sobrecargado de trabajo y bajo mucha presión. Por lo tanto, un flujo constante de errores de seguridad comunes que podrían corregirse con bastante facilidad a nivel de código consume tiempo, recursos y espacio libre para dedicarse a los problemas realmente graves.

Siempre he visto a los pentestres como algo parecido a los 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, exploremos 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 dicen 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. Lamentablemente para los desarrolladores, cuando reciben los resultados de los análisis estáticos y de Pentest, pueden sentirse como una boleta de calificaciones. Les han dado calificaciones bajas, pero al final del día, sus los jefes los evalúan según las funciones que han creado y el tiempo que las han entregado, no si había elementos vulnerables en el software o no.

Para el pobre pentester, se trata de un caso de «no mates al mensajero». No es nada personal: tienen la tarea de encontrar errores y los han encontrado. Es cierto que, a nivel personal, puede que algunos pentésteres sean más gruñones que otros, pero no quieren (o no deberían) tratar de crucificar a los equipos de desarrollo. Sería mucho más fácil para ambos equipos si estuvieran en sintonía con lo que constituye una buena práctica de seguridad. Y no se espera que los desarrolladores sean perfectos; siendo realistas, el equipo de pruebas está ahí para protegerlos del envío de código vulnerable.

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

Es cierto: la máxima prioridad de un desarrollador siempre será la creación de funciones y, en este loco mundo de rápida digitalización, tendrá que hacerse con rapidez. Si bien algunos programadores tienen un interés personal en la seguridad y la programación segura, la opinión general es que la seguridad es «un problema de otra persona», lo que inevitablemente incluye a los pentestres.

De hecho, las vulnerabilidades más comunes son problemas menores que deben solucionarse. Una vez conocidas, las soluciones son fáciles de ejecutar para cosas como la creación de scripts entre sitios (XSS) y la inyección de SQL... el problema es que muchos desarrolladores no se dan cuenta de que las están introduciendo desde el principio, y estos problemas aparentemente menores son la pequeña 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 relacionadas con las inyecciones de SQL tuvieron su origen 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 Pentest ayudan a corregir los errores de seguridad, pero otros informarán sobre las malas noticias y esperan que los desarrolladores solucionen las revisiones, incluso si se han mudado a un proyecto diferente cuando esto suceda. Y, en algunos casos, el equipo de desarrollo puede recibir un informe que incluye errores que no pueden (o no se debería esperar que corrijan); aun así, tiene que formar parte de las conclusiones y, una vez más, no tomarse como algo personal.

El «punto medio» para esto sería que los pentestres, el personal de seguridad y los gerentes de desarrollo actuaran más bien como mentores para garantizar que el equipo tenga lo que necesita en términos de capacitación y herramientas eficaces, dando a los programadores individuales la mejor oportunidad de tener éxito y programar de forma segura desde el principio del SDLC. Ambos equipos deberían reunirse a mitad de camino para garantizar que la seguridad se tenga en cuenta desde el principio, como parte de una práctica saludable de DevSecOps.

«Tengo conocimientos de seguridad mucho mejores de los que me imaginan; 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 del 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 de escáneres (DAST/IAST/RAST). Es una molestia en lo que ya de por sí es un proceso lento, que requiere una revisión manual del código y ejerce presión tanto sobre los desarrolladores como sobre los pentésteres. El personal de Pentesting se ha tomado su tiempo para configurar meticulosamente reglas personalizadas para evitar lecturas inexactas y ha proporcionado directrices específicas para cada empresa. Sin embargo, algunas lecturas falsas se escapan y acaban en manos de un desarrollador que se rasca la cabeza.

Este proceso no es perfecto, pero el otro problema es que muchos desarrolladores carecen de los conocimientos suficientes para mitigar muchas de las vulnerabilidades comunes de forma constante. Dado que la formación en seguridad es poco frecuente en la educación superior 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 exceso de confianza en juego (y no es su culpa: nosotros, como industria, necesitamos mejorar a la hora de proporcionarles lo que necesitan).

«No sabía que esta aplicación se iba a probar, pero ahora me he quedado con las tareas de corrección».

A veces, los ingenieros, con exceso de trabajo, asumen que los pentésteres están colgando entre bastidores, esperando el momento de atacar probando una aplicación y haciendo llover a todo el equipo de desarrollo. Hacen pruebas exageradas, son quisquillosos y crean trabajo extra.

El único problema con eso es que ellos también tienen exceso de trabajo (más aún, de hecho), la escasez de habilidades de ciberseguridad es en niveles nefastos y empeorando) y simplemente no tengo tiempo para hacer la prueba sin motivo. No son los únicos responsables de la toma de decisiones a la hora de priorizar las pruebas; podrían 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, perder los sprints actuales de creación de funciones para trabajar en soluciones de seguridad es molesto, especialmente si no es su trabajo. Es posible que la última actualización la haya realizado un equipo anterior u otro proveedor. Sin embargo, la seguridad es un problema de todos. Esto no significa que todos los desarrolladores tengan que hacerse cargo de los errores de seguridad como si los hubieran creado todos ellos mismos, pero sí tienen que unirse a la fiesta en términos de que la seguridad es una responsabilidad compartida.

¿Hacia dónde desde aquí?

A veces, un cambio de mentalidad puede ser todo lo que se necesita para lograr avances significativos en la solución de un problema. Ya hemos hablado de la reacción bastante fría que tienen los desarrolladores ante unos resultados poco favorables en un Pentest, pero ¿y si pudieran convertirlo en un desafío? Quizá puedan pensar en el pentester como un competidor amistoso, alguien a quien pueden derrotar en su propia partida. Al fin y al cabo, un desarrollador preocupado por la seguridad que pueda eliminar los errores más comunes a medida que escribe código hará que su trabajo sea mucho más difícil. Por el contrario, un desarrollador que no se centre en la seguridad será superado ampliamente por sus homólogos de Pentester cuando puedan descifrar fácilmente su software.

Es posible que los pentestres y los desarrolladores no se unan en armonía el 100% de las veces, pero su relación puede mejorar considerablemente si una organización aborda la seguridad como una prioridad clave y capacita a los equipos con los conocimientos y las herramientas adecuados para tener éxito, especialmente a los desarrolladores. Todo depende de si una cultura de seguridad positiva que abarque a toda la empresa es una prioridad, y si queremos librar la batalla (actualmente) perdida contra las vulnerabilidades comunes, no cabe duda de que debería serlo.