Seguridad y Calidad

Mejor de la mano

Tradicionalmente la seguridad y la calidad han sido gestionadas por diferentes departamentos dentro de las organizaciones. Por un lado, el departamento de QA no se “atreve” a ejecutar pruebas de seguridad, ya que son fundamentalmente diferentes de las pruebas funcionales y de rendimiento, y QA no tiene la experiencia, el personal o las herramientas para ello.

Por otro lado, el departamento de seguridad está más aislado del desarrollo que QA, su trabajo comienza cuando la aplicación está en las fases finales de construcción o incluso una vez implantada. En el contexto de las pruebas de seguridad, las vulnerabilidades o debilidades del sistema no se conocen a priori, es decir, el trabajo consiste en encontrar lo desconocido y documentarlo para solucionarlo. Sin embargo, en el contexto del enfoque QA tradicional, el resultado esperado para cada prueba es conocido y documentado a priori, por lo que el trabajo consiste en encontrar lo conocido y validar que efectivamente funciona como se espera.

QA se centra en validar que la aplicación hace lo que debe hacer, y Seguridad en asegurar que la aplicación no tiene debilidades que permitan ser explotadas.

La pregunta es, ¿qué diferencia un defecto funcional o de rendimiento, de una debilidad que pudiera ser explotada? ¿por qué tradicionalmente los informes de seguridad son independientes de los informes QA? ¿acaso un defecto de seguridad no es un problema de calidad?

Full width banner laptop man

Calidad, QA y testing

Es importante entender que tanto el departamento QA, como los testers o SDET en cada equipo de desarrollo tienen como finalidad hacer el software mejor, sin embargo, desde QA se intenta mejorar la calidad vía una mejora de los procesos de desarrollo, y desde los Testers o SDET intentan mejorar la calidad descubriendo defectos. Dependerá de la organización decidir como se estructuran las áreas; hace años los centros de excelencia en pruebas se pusieron de moda, para ahora dar paso a un testing directamente gestionado por los equipos de desarrollo, manteniendo en muchas ocasiones equipos QA que dan soporte a los testers. En cualquier caso, el objetivo no cambia, mejorar la calidad del producto.

SDET, Software Development Engineer in Test, es un profesional de IT que puede trabajar tanto en el desarrollo como en las pruebas del software.

Un defecto de seguridad, es un problema de calidad

Un defecto derivado de la ejecución de pruebas de seguridad debe ser tratado como un defecto de calidad, y como tal gestionado por QA. A la inversa, hagamos la siguiente reflexión: si la calidad de nuestro software es baja y la calidad del código pobre, es más probable que la aplicación se comporte de forma impredecible o errónea. Incluso una usabilidad pobre también podría darle una oportunidad a un atacante de encontrar vías de entrada.

El equipo de seguridad trabaja para conocer y remediar vulnerabilidades, mientras que el equipo QA trabaja para conocer y eliminar defectos

Otro punto a tener en cuenta es que algunas de las respuestas mas comunes de los desarrolladores a un defecto (“un usuario nunca haría eso” o “esa funcionalidad casi no se utiliza”) no son válidas para los defectos de seguridad, ya que un atacante puede hacer lo que quiera para explotar una vulnerabilidad. Las pruebas de seguridad, al igual que las funcionales o de rendimiento, buscan eliminar riesgos o al menos conocer los riesgos antes del paso a producción si es posible. El equipo de seguridad trabaja para conocer y remediar vulnerabilidades, mientras que el equipo QA trabaja para conocer y eliminar defectos. Calidad y seguridad son dos caras de la misma moneda, un “bug” funcional que se nos ha escapado hoy puede aparecer como una vulnerabilidad de seguridad mañana, y un atacante estará ahí para aprovecharse. La seguridad del software es solo otro elemento más para construir un software de calidad.

El problema de los presupuestos

Normalmente, a los equipos de desarrollo se les mide en base a lo bien que cumplen los requisitos del producto en función del coste acordado y las fechas planificadas. Muchas organizaciones ya se han dado cuenta de que el testinges parte del desarrollo, y como tal se paga desde este presupuesto. Sin embargo, aún es común encontrar empresas donde la seguridad es una partida independiente, y hasta hace unos años tenía sentido, pero con la llegada de DevOps cada vez es mas necesario compartir los costes de la seguridad.

Con la adopción de DevOps, es imperativo que dentro del presupuesto de desarrollo contemplemos partidas significativas para calidad y seguridad.

El problema de los presupuestos independientes es que los defectos de seguridad siguen otro camino en comparación con los defectos funcionales o de rendimiento, y muchas veces es necesario convencer al equipo de desarrollo de que estos defectos deben ser solucionados. Teniendo en cuenta que comúnmente no se registran en las mismas herramientas de gestión del ciclo de vida de la aplicación, y que no suelen tener trazabilidad con requisitos, historias de usuario… ¿Qué incentivo tiene el equipo de desarrollo para priorizarlos y darles solución? Es más ¿y si ningún atacante decide explotar esa vulnerabilidad? Sin embargo, un defecto funcional no va a ser aceptado por el cliente, y como tal, siempre gana en la guerra de las prioridades. Analizar desde un punto de vista financiero una aplicación es una tarea complicada y no extrapolable entre organizaciones. Por eso hablar en detalle de como deben distribuirse los presupuestos entre desarrollo, calidad y seguridad en una organización no tiene mucho sentido. Lo que si podemos asegurar es que, con la adopción de DevOps, es imperativo que dentro del presupuesto de desarrollo contemplemos partidas significativas para calidad y seguridad.

¡Empieza la conversación!

¿Conoces Globe Testing?

¡Descubre como mejorar tu software!