Empezar «a la izquierda de la izquierda»: ¿el código seguro es siempre un código de calidad?

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y distribuido 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; es posible que hayamos escapado a un desastre cuando el software vulnerable salió a la venta en la década de los 90, pero hoy no vale la pena correr el riesgo. A lo largo de los años, muchos han trabajado arduamente para inculcar en los desarrolladores una mentalidad consciente de la seguridad y, al hacerlo, es de esperar que la seguridad sea sinónimo de calidad en lo que respecta a la autoevaluación de su código.

Sin embargo, tras una reflexión (y un debate entre mis compañeros), quizás esté simplificando demasiado el concepto. Es totalmente posible crear código que sea realmente seguro, pero que muestre signos de una técnica de desarrollo incierta u otras áreas problemáticas que lo hagan menos que ideal.

Nuestra industria habla extensamente sobre la noción de «cambiar a la izquierda». En mi opinión, se trata de «empezar» por la izquierda, permitiendo que las cohortes de ingeniería compartan la responsabilidad de la seguridad (que es un aspecto de la calidad) y dándoles la posibilidad de borrar las vulnerabilidades comunes al alcance de la mano (literalmente). Sin embargo, a la luz de este dilema actual, parece que hay que ir un poco más allá.

El código de un cierto nivel de calidad es, por definición, también seguro, pero no todo el código seguro es necesariamente de buena calidad. ¿Empezar «a la izquierda de la izquierda» es la fórmula para garantizar estándares de codificación puros y seguros?

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

Vamos a ver con lupa este fragmento de código:

Si analizamos este código desde una perspectiva de seguridad, este fragmento es seguro y no es un punto de entrada para que un atacante aproveche una vulnerabilidad de inyección SQL.

¿Es un ejemplo de código de alta calidad? La verdad es que no, lamentablemente. Un simple cambio en el argumento de int (ger) a un Cuerda El valor permite que la entrada del usuario de forma libre manipule la consulta, a diferencia de un número que no puede. Ese cambio (o copiar y pegar de forma fortuita la cadena sql desde otro lugar) crea inmediatamente un entorno en el que es posible que se produzcan vulnerabilidades en la inyección de SQL y todos los riesgos asociados a ellas:

En este caso, las medidas de seguridad tenían 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 argumental ineficiente. Un código de envío como este no solo es una mala práctica, sino que también es un mal ejemplo para otros miembros de la cohorte de desarrolladores.

La «triple amenaza» del software: ¿forma, función, parecido a una fortaleza?

Una «triple amenaza» en la industria del entretenimiento es una persona que puede actuar, bailar y cantar con un nivel de habilidad igualmente alto. Son las personas temidas y envidiadas en todas las audiciones, y son los unicornios de un espacio ya de por sí competitivo. Cada sector tiene su propia versión de un ejemplo excepcional y de primer nivel de sus productos y servicios, y el software no es la 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 y la elegancia, además de una seguridad férrea y la rentabilidad si tenemos en cuenta la velocidad de entrega requerida. Ahora bien, este último atributo es, sin duda, un factor determinante para la eficacia con la que se aplican las otras dos opciones, y puede ser un catalizador para que la calidad general decaiga con el tiempo.

Sin embargo, ¿es necesario que todo el software funcione como Hugh Jackman o podemos salirnos con la suya con Nicolas Cage? Pongámoslo de esta manera: si consigues meter a Wolverine en tu equipo, lo harás lo mejor que puedas.

Martin Fowler hizo la pregunta: ¿Vale la pena la alta calidad? en el desarrollo de software, concluyendo que no solo «valió la pena», sino que en realidad fue más barato con el tiempo. La mayoría de los usuarios no se van a poner a analizar minuciosamente si el código es un desastre o si la seguridad es tan importante como todo lo demás. Sin embargo, quienes utilicen las herramientas perderán un tiempo precioso rehaciendo código torpe para añadir funciones más nuevas, o revisando las partes principales del proyecto para entender lo que está pasando o, en el peor de los casos, solucionando una vulnerabilidad que el equipo de AppSec ha conseguido recuperar y ha retrasado su producción. Dedicar tiempo ahora a crear código seguro y de buena calidad ahorra muchos problemas futuros, sin mencionar el costo de desentrañar un trabajo mal ejecutado.

Los desarrolladores expertos en seguridad escriben código que conserva su visión creativa y de resolución de problemas en la entrega de funciones, y se preocupan por eliminar los problemas de seguridad comunes que los ingenieros pueden controlar en su etapa del proceso. El código seguro no es muy eficaz de forma aislada, y por eso la idea de empezar «de izquierda a izquierda» ayudará a fomentar una cultura de seguridad como algo natural para los desarrolladores, ya que les permitirá ofrecer funciones increíbles con un riesgo reducido.

Comenzar «a 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 del software durante mucho tiempo, pero es evidente que el éxito ha sido desigual. Se explicaron los errores de configuración de seguridad 21% de las filtraciones de datos basadas en la nube el año pasado, con errores cometidos por aficionados, como almacenar contraseñas en texto sin formato, que provocaron graves pérdidas de productividad, ingresos y confianza de los clientes para las empresas afectadas.

Eso, y los propios usuarios pueden ser su peor enemigo cuando se trata de proteger sus propios datos. Demasiada gente siguen utilizando la palabra «contraseña» como contraseña o utilizan la misma combinación en varias cuentas confidenciales.

No conozco a ningún desarrollador que se ponga manos a la obra 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 sólido y funcional y en el que los usuarios puedan navegar de una manera que tenga sentido para ellos, con la menor interrupción posible.

Si pones demasiados pasos y restricciones complejos, es posible que los usuarios se desconecten para no volver nunca (lo que sería un desastre para una nueva aplicación), lo que sería demasiado confuso y podrías terminar causando un dolor de cabeza al equipo de soporte al responder a las consultas de los usuarios que intentan acceder a sus cuentas. Si lo pones demasiado fácil, estarás fallando en lo que respecta a la seguridad.

Una experiencia de usuario segura y exitosa debe integrar una seguridad estricta en un flujo que tenga sentido, presentado de manera que no reste valor a todo lo demás que es atractivo del software. No cabe duda de que puedes cumplir el objetivo de programar una función de inicio de sesión segura, introduciendo todo tipo de requisitos complejos de contraseñas, CAPTCHA, minijefes y cuatro oleadas de zombis, pero si se trata de un desastre total que repele a los usuarios, es que no da en el blanco.

Siente las bases para la excelencia del software.

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

Comenzar «a la izquierda de la izquierda» es un concepto que prioriza a los desarrolladores y requiere que las organizaciones se tomen en serio la idea de mejorar su cohorte de ingenieros. Los desarrolladores preocupados por la seguridad valen su peso en oro, y el apoyo en forma de formación, suministro de las herramientas adecuadas y la oportunidad de ser asesorados por desarrolladores más experimentados fomentará un entorno en el que el código se elabore con una mentalidad que priorice la seguridad, con la precisión y la atención al detalle necesarias para llevar el software al siguiente nivel.

¿Estás listo para encender el fuego de la codificación segura que llevas dentro? Enfréntate al desafío.

‍