Empezando por la "izquierda de la izquierda": ¿Es el código seguro siempre un código de calidad?

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y sindicado aquí.

Cuando hablo con los desarrolladores sobre seguridad, uno de mis mantras es que "el único código de calidad es el código seguro". Esto sigue siendo cierto; puede que nos hayamos librado del desastre cuando el software vulnerable estaba en la calle en los años 90, pero no vale la pena correr el riesgo hoy en día. A lo largo de los años, muchos han trabajado duro para inculcar a los desarrolladores una mentalidad consciente de la seguridad y, al hacerlo, han conseguido que la seguridad sea sinónimo de calidad cuando se trata de un autoassessment de su código.

Sin embargo, después de reflexionar (y de debatir con mis compañeros), quizá sea simplificar demasiado el concepto. Es totalmente posible crear un código que sea realmente seguro, pero que muestre signos de una técnica de desarrollo novata, o de otras áreas problemáticas que lo hagan menos que ideal.

Nuestro sector habla largo y tendido sobre la noción de "desplazamiento hacia la izquierda". En mi opinión, se trata de "empezar" por la izquierda permitiendo a las cohortes de ingenieros compartir la responsabilidad de la seguridad (al ser un aspecto de la calidad), y dándoles el poder de borrar las vulnerabilidades comunes al alcance de su mano (literalmente). Sin embargo, a la luz de este enigma actual, parece que hay que ir un poco más allá.

El código de cierto nivel de calidad es, por definición, también seguro, pero todo el código seguro no es necesariamente de buena calidad. ¿Es la fórmula de empezar por la "izquierda de la izquierda" para garantizar unos estándares de codificación seguros puros?

¿Qué aspecto tiene un código seguro de "mala calidad"?

Pongamos la lupa sobre este fragmento de código:

Si analizamos este código desde el punto de vista de la seguridad, este fragmento es efectivamente seguro, y no es un punto de entrada para que un atacante explote una vulnerabilidad de inyección SQL.  

¿Es un ejemplo de código de alta calidad? Desgraciadamente, no. Un simple cambio en el argumento de un int(eger) a un valor String permite que la entrada del usuario de forma libre manipule la consulta, en contraste con un número que no puede. Ese cambio -o un copiado y pegado desordenado del String sql desde otro lugar- crea inmediatamente un entorno en el que son posibles las vulnerabilidades de inyección SQL, y todos los riesgos asociados a ellas:

Las medidas de seguridad tenían aquí un alcance muy limitado, mientras que un desarrollador más minucioso (o, experimentado) podría haber adoptado un enfoque diferente y haber considerado las implicaciones de una estructura de argumentos ineficiente. Enviar código de esta manera no sólo es una mala práctica, sino que da un mal ejemplo a otros miembros de la cohorte de desarrollo.

La "triple amenaza" del software: Forma, función, ¿fortaleza?

Una "triple amenaza" en la industria del entretenimiento es un individuo que puede actuar, bailar y cantar con un nivel igualmente alto de habilidad. Son las personas temidas y envidiadas en cada audición, y son los unicornios de un espacio ya competitivo. Cada industria tiene su propia versión de un ejemplo excepcional de sus productos y servicios, y el software no es una excepción.

Si pensamos en tres elementos clave en las aplicaciones que son difíciles de equilibrar con una calidad igual (alta), podrían ser la funcionalidad/elegancia, más la seguridad férrea, más la rentabilidad si se tiene en cuenta la velocidad de entrega requerida. Ahora bien, este último atributo es, sin duda, un factor definitorio de la aplicación de las otras dos opciones, y puede ser un catalizador para que la calidad general decaiga con el tiempo.

Sin embargo, ¿es necesario que todos los programas informáticos actúen como Hugh Jackman, o podemos salirnos con la suya con Nicolas Cage? Pongámoslo así: si puedes tener a Lobezno en tu equipo, entonces da lo mejor de ti.

Martin Fowler se preguntó si la alta calidad merecía la pena en el desarrollo de software, y llegó a la conclusión de que no sólo "merecía la pena", sino que además era más barata con el tiempo. La mayoría de los usuarios no van a mirar bajo el capó para evaluar si el código es un desastre, ni si la seguridad se hizo tan importante todo lo demás. Sin embargo, los que están en las herramientas perderán un tiempo precioso rehaciendo el código descuidado para añadir nuevas características, o rastreando las partes principales del proyecto para entender lo que está pasando, o, el peor de los casos: arreglar una vulnerabilidad que ha rebotado del equipo de AppSec y ha retrasado la producción. Dedicar tiempo ahora a hacer que el código sea seguro y de buena calidad ahorra muchos dolores de cabeza en el futuro, por no mencionar el coste de desentrañar un trabajo mal ejecutado.

Los desarrolladores expertos en seguridad escriben un código que mantiene su visión creativa y de resolución de problemas en la entrega de características, teniendo en cuenta la eliminación de las trampas de seguridad comunes que los ingenieros pueden controlar en su etapa del proceso. El código seguro no es terriblemente eficaz de forma aislada, y por eso la noción de empezar "por la izquierda de la izquierda" ayudará a respaldar una cultura de seguridad como segunda naturaleza para los desarrolladores, incorporada a su capacidad de ofrecer características sorprendentes con un riesgo reducido.

Empezar por la "izquierda de la izquierda" es fundamental para una experiencia de usuario segura.

La seguridad ha sido una consideración en la experiencia del usuario de software durante mucho tiempo, aunque claramente ha tenido un éxito desigual. Los errores de configuración de la seguridad representaron el 21% de las filtraciones de datos en la nube durante el año pasado, con errores de aficionados como el almacenamiento de contraseñas en texto plano que provocaron graves pérdidas de productividad, ingresos y confianza de los clientes en las empresas afectadas.

Además, los propios usuarios pueden ser su peor enemigo cuando se trata de proteger sus propios datos. Demasiada gente sigue usando "contraseña" como contraseña, o usando la misma combinación en varias cuentas sensibles.

No conozco a ningún desarrollador que se ponga a dar puñetazos cuando le dicen que tiene que trabajar en una pantalla de inicio de sesión, y no es de extrañar: es un equilibrio delicado diseñar un flujo de seguridad que sea robusto, funcional y que los usuarios puedan navegar de una manera que tenga sentido para ellos, con la menor interrupción.

Si se introducen demasiados pasos y restricciones complejas, los usuarios pueden desconectarse para no volver (un desastre para una aplicación nueva), si se hace demasiado confuso, se puede acabar provocando una migraña colectiva en el equipo de soporte mientras se atienden las consultas de los usuarios que intentan acceder a sus cuentas. Si lo haces demasiado fácil, estarás fallando en la parte de seguridad.

Una experiencia de usuario segura y satisfactoria debe integrar la seguridad en un flujo que tenga sentido y que se presente de forma que no desvirtúe todo lo demás que tiene de atractivo el software. Sin duda se puede cumplir el objetivo de codificar una función de inicio de sesión segura, poniendo todo tipo de requisitos de contraseñas complejas, CAPTCHA, mini-jefes y cuatro oleadas de zombis, pero si es un lío total que repele a los usuarios, se está perdiendo el objetivo.

Sentar las bases de la excelencia del software.

Como desarrollador, sé que la gran mayoría de nosotros nos sentimos orgullosos de nuestro trabajo y queremos hacer lo correcto. Las molestas bolas curvas, como las limitaciones de tiempo, los cambios repentinos en el objetivo actual o las correcciones urgentes, pueden interrumpir el flujo y conducir a errores, pero la cruda verdad es que muchos ingenieros de software no están preparados para el éxito.

Empezar por la "izquierda de la izquierda" es un concepto que da prioridad a los desarrolladores, y requiere que las organizaciones se tomen en serio la mejora de su cohorte de ingenieros. Los desarrolladores concienciados con la seguridad valen su peso en oro, y el apoyo en forma de formación, la provisión de las herramientas adecuadas y la oportunidad de ser tutelados por desarrolladores más experimentados fomentará un entorno en el que el código se elabore con una mentalidad que dé prioridad a la seguridad, con la precisión y la atención al detalle necesarias para llevar el software al siguiente nivel.

¿Listo para encender el fuego de la codificación segura en ti mismo? Acepta el reto.

‍