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

Una versión de este artículo apareció en Dark Reading. Ha sido actualizado y distribuido aquí.

Cuando hablo con 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 hayamos evitado el desastre cuando el software vulnerable circulaba libremente en los años 90, pero hoy en día no vale la pena correr el riesgo. Muchos han trabajado duro a lo largo de los años para inculcar una mentalidad consciente de la seguridad en los desarrolladores y, al hacerlo, con suerte han hecho que la seguridad sea sinónimo de calidad cuando se trata de una autoevaluación de su código.

Sin embargo, tras reflexionar (y debatir un poco con mis colegas), quizás sea simplificar demasiado el concepto. Es totalmente posible crear código que sea efectivamente seguro, pero que muestre signos de técnicas de desarrollo novatas u otras áreas problemáticas que lo hacen menos que ideal.

Nuestra industria habla largo y tendido sobre la noción de "desplazarse a la izquierda" (shifting left). En mi opinión, todo consiste en "empezar" a la izquierda permitiendo que los equipos de ingeniería compartan la responsabilidad de la seguridad (como un aspecto de la calidad) y dándoles el poder de eliminar vulnerabilidades comunes al alcance de sus manos. A la luz de este dilema actual, sin embargo, parece que hay que ir un paso más allá.

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

¿Cómo es el código seguro de "mala calidad"?

Pongamos este fragmento de código bajo la lupa:

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

¿Es un ejemplo de código de alta calidad? Lamentablemente, no. Un simple cambio en el argumento de un int(eger) a un valor de tipo String permite que la entrada de usuario de formato libre manipule la consulta, a diferencia de un número, que no puede hacerlo. Ese cambio —o un copiar y pegar descuidado del SQL de tipo String desde otro lugar— crea inmediatamente un entorno donde las vulnerabilidades de inyección SQL son posibles, junto con todos los riesgos asociados:

Las medidas de seguridad tenían un alcance muy limitado aquí, mientras que un desarrollador más minucioso (o experimentado) podría haber adoptado un enfoque diferente y considerado las implicaciones de una estructura de argumentos ineficiente. Distribuir código como este no solo es una mala práctica, sino que sienta un mal precedente para otros miembros del equipo de desarrollo.

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

Una "triple amenaza" en la industria del entretenimiento es una persona capaz de actuar, bailar y cantar con un nivel de habilidad igualmente alto. Son las personas temidas y envidiadas en cada audición, y son los unicornios de un espacio ya de por sí competitivo. Cada industria tiene su propia versión de un ejemplo excepcional y de primer nivel 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 (alta) igualitaria, podrían ser la funcionalidad/elegancia, una seguridad a prueba de balas y la rentabilidad al considerar la velocidad de entrega requerida. Ahora bien, ese último atributo es, sin duda, un factor determinante en cómo se aplican las otras dos opciones, y puede ser un catalizador para que la calidad general disminuya con el tiempo.

Sin embargo, ¿todo el software necesita rendir como Hugh Jackman, o podemos conformarnos con Nicolas Cage? Digámoslo así: si puedes conseguir a Wolverine en tu equipo, entonces da lo mejor de ti.

Martin Fowler planteó la pregunta: ¿Vale la pena el costo de la alta calidad? en el desarrollo de software, concluyendo que no solo "valía la pena", sino que en realidad era más barato a largo plazo. La mayoría de los usuarios no van a mirar bajo el capó para evaluar si el código es un desastre o si la seguridad se consideró tan importante como todo lo demás. Sin embargo, quienes trabajan con las herramientas perderán un tiempo precioso rehaciendo código descuidado para añadir nuevas funciones, o revisando partes importantes del proyecto para entender qué está pasando, o, en el peor de los casos: corrigiendo una vulnerabilidad que ha sido devuelta por el 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 futuros, por no mencionar el costo de deshacer un trabajo mal ejecutado.

Los desarrolladores expertos y conscientes de la seguridad escriben código que conserva su visión creativa y de resolución de problemas en la entrega de funciones, teniendo en cuenta la eliminación de los errores 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 es por eso que la noción de empezar "a la izquierda de la izquierda" ayudará a fomentar una cultura de seguridad como algo natural para los desarrolladores, integrada en su capacidad para ofrecer funciones increíbles con un riesgo reducido.

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

La seguridad ha sido una consideración en la experiencia de usuario del software durante mucho tiempo, pero claramente ha tenido un éxito desigual. Las configuraciones de seguridad incorrectas representaron el 21% de las brechas de datos en la nube durante el último año, con errores de principiante como almacenar contraseñas en texto plano, lo que resultó en graves pérdidas de productividad, ingresos y confianza del cliente para las empresas afectadas.

Además, los propios usuarios pueden ser su peor enemigo a la hora de proteger sus datos. Demasiadas personas siguen usando «password» como contraseña o emplean la misma combinación en varias cuentas confidenciales.

No conozco a ningún desarrollador que celebre tener que trabajar en una pantalla de inicio de sesión, y no es de extrañar: diseñar un flujo de seguridad que sea robusto, funcional y fácil de usar para el usuario, sin causar molestias, es un equilibrio delicado.

Si añades demasiados pasos y restricciones, los usuarios pueden abandonar la aplicación para no volver (un desastre para una app nueva); si lo haces demasiado confuso, el equipo de soporte sufrirá constantes dolores de cabeza atendiendo consultas. Si es demasiado fácil, fallas en la seguridad.

Una experiencia de usuario segura y exitosa debe integrar la seguridad en un flujo lógico, sin restar valor a lo que hace atractivo al software. Puedes programar una función de inicio de sesión segura con requisitos complejos, CAPTCHA y mil obstáculos, pero si es un caos que repele al usuario, no sirve de nada.

Sienta las bases de la excelencia en el software.

Como desarrollador, sé que la mayoría nos enorgullecemos de nuestro trabajo y queremos hacer las cosas bien. Los imprevistos, como las limitaciones de tiempo, los cambios de objetivos o las correcciones urgentes, pueden causar errores, pero la cruda realidad es que muchos ingenieros no cuentan con las condiciones necesarias para triunfar.

Empezar «a la izquierda de la izquierda» es un concepto centrado en el desarrollador que exige que las organizaciones se tomen en serio el desarrollo de su equipo. Los desarrolladores concienciados con la seguridad valen su peso en oro; la formación, las herramientas adecuadas y la mentoría fomentan un entorno donde el código se crea con una mentalidad de seguridad, precisión y atención al detalle.

¿Listo para despertar tu pasión por la programación segura? Acepta el reto.

‍