Sobre Ingeniería de Software y la necesidad de regulación

From National Museum of American History

Aviso a navegantes: No, esto no va sobre títulos ni intrusismo profesional.

El desarrollo de software es una disciplina joven, sin embargo hace más de 40 años que empezamos a crear programas para nuestros ordenadores, y eso debería ser tiempo suficiente para haber desarrollado un conjunto de buenas prácticas.

Efectivamente, esas prácticas están ahí. Es seguro que seguirán apareciendo nuevos métodos e ideas para mejorar los procesos y resultados de los ingenieros de software, pero hemos acumulado suficiente conocimiento como para hablar de ingeniería en el más estricto sentido, y no ya de artesanía o arte como se ha venido insinuando durante muchos años.

Seamos realistas

La triste realidad es que todo ese bagaje acumulado no se está aplicando casi nunca en casi ninguna parte.

Vemos cada día como decenas o cientos de páginas web presentan problemas de diseño, usabilidad y rendimiento, así como errores graves y agujeros de seguridad. Nos llegan noticias de ataques en los que consiguen robar contraseñas, números de tarjeta de crédito y otros datos sensibles. Presenciamos ocasionalmente como los funcionarios y trabajadores de entidades bancarias se pelean con el software, o nosotros mismos hemos sufrido en nuestras carnes la mala calidad del software administrativo.

Estos problemas no son meras molestias, suponen pérdidas enormes de tiempo, energía y dinero para el conjunto de la sociedad.

¿Por qué sigue sucediendo? Pues por lo de siempre: ignorancia y … dinero. Las empresas intentan ahorrar en tiempo dedicado al desarrollo, en personal asignado, formación, y no menos importante: infraestructura.

Las empresas que deciden priorizar la calidad de sus productos y servicios por lo general estarán obligadas a ofrecer precios más altos que aquellas que solo piensen en la productividad (mal entendida), y eso las deja en clara desventaja.

¿Regulación como solución?

No hay soluciones “bala de plata” para esto, pero creo que regular algunos aspectos del desarrollo de software nos llevaría por el buen camino.

Hay que señalar que no vale la pena regularlo todo, si una regulación no se puede hacer efectiva por el motivo que sea, entonces no tiene sentido alguno perder el tiempo en ella.

Hablaré de medidas sencillas, fáciles de implantar y controlar. Se podría decir que son simples fantasías y que hay puntos discutibles, seguro que es así. Sin embargo creo hay que empezar con algo, siempre estamos a tiempo de debatir, añadir, quitar y refinar. Tomadlo como una propuesta-esbozo.

1. Control de versiones y trazabilidad

Desde hace muchos años existen herramientas como CVS, SVN, Git, Mercurial o Bazaar que permiten hacer un seguimiento de los cambios efectuados sobre un proyecto (qué cambios se hicieron, quien los hizo, y cuando).

Podéis imaginar qué tipo de ventajas aporta usar estas herramientas sobre no hacerlo: podemos “medir” nuestra propia productividad, reducimos la probabilidad de daños malintencionados (debido a que queda registrado quien lo hizo), es más fácil trazar el origen de los errores introducidos…

A día de hoy la mayoría del sector usa alguna herramienta de control de versiones, siendo Git el campeón indiscutible en cuanto a porcentaje de adopción.

Sin embargo todavía quedan rebeldes que se niegan a avanzar en este aspecto. Suelen ser empresas que mantienen contratos con la administración o fundaciones semi-públicas, que prefieren que no haya mecanismos para hacerles rendir cuentas, y que seguramente todavía mantienen sus contratos debido a algún chanchullo. Me gustaría poder dar nombres (los tengo), pero no quiero acabar en un juzgado.

Mi propuesta es que debería ser obligatorio mantener bajo control de versiones cualquier desarrollo de software que cumpla alguna de las siguientes condiciones:

  • Que gestione información sensible: datos personales, cuentas bancarias, números de tarjeta de crédito, información comercial y/o financiera, etc.
  • Que la seguridad y/o integridad física de seres humanos dependa del software.
  • Que sea software hecho a medida por encargo de un cliente. El historial completo también debería ser entregado al cliente.

2. Changelog

Aunque pueda parecerlo a simple vista, un “changelog” no ofrece lo mismo que los sistemas de control de versiones. Un changelog debe ofrecer una lista de cambios que sean inteligibles para gente sin formación técnica (fundamentalmente debe informar sobre nuevas características y/o correcciones de errores), mientras que las descripciones de los cambios efectuados en el sistema de control de versiones tienen un cariz mucho más técnico y preciso.

Cuando un producto hecho a medida para un cliente se entrega por fases, o bien es mantenido a lo largo de un tiempo prolongado, la empresa dedicada al desarrollo/mantenimiento del software debería proveer un changelog a sus clientes.

Parece una trivialidad, sin embargo he visto como flujos enteros de trabajo se rompen por no informar debidamente de los cambios realizados sobre algunos programas en entornos administrativos.

3. Documentación

Es fácil no creerlo, pero una gran parte del software a medida que se desarrolla por encargo no viene acompañado de documentación. Gracias a esto se pueden oír cosas como “It’s not a bug, it’s a feature”. Debería ser obligatorio que cada programa que se entrega venga acompañado de un manual o guía de referencia.

Pequeña pausa: caso práctico

Cierta fundación semi-pública dedicada a la investigación, llamémosla F, está en proceso de reestructuración para poder pasar una certificación ISO9001.
Para conseguirlo encargaron a una empresa de software, llamémosla C, que desarrollara una serie de programas administrativos. C no solo no aplica control de versiones, tampoco provee changelogs y menos aún documenta sus propios engendros.
La redacción del manual ha recaído en el departamento de calidad de F, y suele pasar que el manual queda desfasado por cambios no comunicados.
El departamento de calidad de una fundación y/o empresa no está para redactar manuales, está para asegurar que se siguen una serie de procesos y con ello posibilitar su buen funcionamiento.
Lo que ha hecho C ha sido externalizar sus costes hacia su cliente. El porqué F acepta esta situación daría para otro artículo entero (fruto del “piensa mal y acertarás”).

4. El código fuente debe entregarse

Cuando el software se haya desarrollado para un cliente, el código fuente debería entregarse junto con el programa.

Estoy seguro de que hay un montón de leyes que apuntan en esa dirección, seguramente un cliente que reclame el código tiene todo a su favor para conseguirlo (al menos legalmente). Sin embargo esto no es lo suficientemente explícito a día de hoy, y muchas empresas de software lo incumplen para aumentar la dependencia de sus clientes.

La protección del cliente es un motivo, pero no el único. Os puedo asegurar que nuestra civilización se asienta sobre toneladas de código basura, si la gente supiera como se gestiona su información más sensible se le pondrían los pelos como escarpias.

Forzar que el código lo puedan ver otras personas asegura que, aunque sea por orgullo o vergüenza, el trabajo (por lo general) se hará mejor.

Más allá de medidas civilizadoras

Los cuatro puntos que he expuesto son simples medidas civilizadoras. En sí mismas no hacen nada para mejorar el software, “solo” ayudan a proteger a los clientes finales y facilitan la comunicación.

También hacen falta medidas que actúen de forma directa sobre el proceso de desarrollo. No hay muchos puntos en los que se pueda incidir, ya que sería prácticamente imposible asegurar que en una empresa se siguen ciertas buenas prácticas cuando estas no conciernen a su relación con el mundo exterior.

Por suerte hay algo de margen para influir directamente sobre el desarrollo de software desde el papel de regulador.

5. Algo que debería haber sido evidente: HTTPS… y lo que venga

Los prestadores de servicios online (via web), fundamentalmente aquellos que deben tratar con información sensible, deberían estar obligados a usar HTTPS o los protocolos que le sucedan en el futuro.

Uno podría pensar que cuando se aprobó la LSSI en el año 2002 se habría tenido en cuenta algo tan básico como esto para asegurar la protección de las comunicaciones. Pues no. Los proveedores de servicios online solo están obligados a informar sobre qué medidas de seguridad toman, pero no a tomarlas.

Es cierto que, de forma indirecta, leyes como la LOPD ¹ deberían llevar también a usar protocolos como HTTPS. Pero no parece que esa conclusión sea tan evidente dado que a día de hoy todavía es fácil encontrar comercios electrónicos que funcionan sobre HTTP y no con HTTPS. Como en otros casos, hace falta que la obligación sea explícita.

Añado que este punto es delicado. No se trata de habilitar HTTPS y ya está. Alrededor de esta medida debería haber una serie de puntos explicitando cómo hacerlo. La seguridad no es trivial. No se puede esperar que todo el mundo sepa ofrecerla, ni que cualquiera comprenda las implicaciones de pequeños detalles, como por ejemplo enviar un header HSTS o no hacerlo.

6. Con las contraseñas no se juega

Seguro que casi todos vosotros os habéis encontrado alguna vez en la situación de haber olvidado una clave y haber tenido que recuperarla. Seguro que también os habéis encontrado con servicios que os enviaban una nueva clave por correo electrónico en tal caso. No es tan probable, pero también podría haberos pasado, que os hayan enviado vuestro password original por correo.

Pues bien, algo así (tanto el primer como el segundo caso) debería estar prohibido. Es indigno de nuestra profesión ofrecer una solución tan mala, y sobretodo tan peligrosa.

Las claves nunca, bajo ningún concepto o circunstancia, deberían almacenarse “en claro” en sitio alguno. Ni en la base de datos, ni en un log, y menos aun en un email. Si el dueño de la clave quiere hacerlo está en su derecho, pero el proveedor de servicios no debería ser el eslabón débil de la cadena.

Las contraseñas deberían guardarse solo en forma de “hash” con “salt” (o algún método criptográfico equivalente o superior en cuanto a seguridad), y guardarnos de usar funciones hash como MD5, muy fáciles de “romper” a día de hoy.

Regular este punto no sería sencillo, pero es seguro que se podría conseguir fijar unos mínimos estándares.

En cuanto a los mecanismos de recuperación de cuenta, deberían ir por la vía de ofrecer un enlace vía email u otro sistema de comunicación para que el usuario pudiera decidir él mismo cual es su nueva clave. No entraría en asuntos como 2FA porque sería excesivamente complejo regularlo (y seguramente contraproducente).

7. Algunas “sutilezas” sobre seguridad

La seguridad es muy extensa, y debo admitir que es agotador intentar cubrir el asunto en un artículo que habla sobre regulaciones. Sin embargo creo que debería ser uno de los pilares de una regulación sobre el desarrollo de software. Entiéndase que, dado que es un esbozo, me tome la libertad de resumir algunos de los puntos que considero importantes en un par de párrafos y omitir otros también potencialmente importantes.

Quedan por cubrir asuntos como los ataques por fuerza bruta (la regulación debería obligar a que al menos hubiera métodos defensivos básicos ante esos ataques), o las filtraciones no intencionadas de información al atacante.

En cuanto a las filtraciones, me refiero a cosas tan sencillas como no enviar mensajes del estilo “El usuario no existe”, o “clave incorrecta”. Es más razonable enviar algo mucho menos informativo como “credenciales incorrectas”, sin llegar a informar en qué se ha equivocado el usuario (que es un atacante potencial).

Hay ejemplos menos obvios y más complejos, como los ataques de temporización, en los que el atacante consigue información sobre las credenciales midiendo los tiempos de respuesta del servicio online. Sin embargo sería muy difícil regular aspectos como estos, ya que es prácticamente imposible demostrar que el proveedor de servicios está incumpliendo la normativa sin tener que incurrir en un ataque.

8. “Calidad” de código: Cobertura de tests

Es probable que esta última fuera la medida que salvara si me dijeran que solo se puede aplicar una.

En ingeniería de software tenemos diferentes formas de asegurar la calidad del producto. La más evidente es probarlo manualmente, es algo que por lo general hay que hacer, sin embargo eso no es suficiente.

Una de las formas más estrictas de verificación se llama “verificación formal”, y es exageradamente costosa, así que no os marearé con eso.

Por suerte tenemos pruebas unitarias, pruebas funcionales, pruebas de integración y pruebas de regresión. Que sí son factibles y deseables.

A partir de estas pruebas automatizadas se pueden obtener ciertas métricas que llamamos “cobertura”. Esta cobertura puede ser sobre “clases”, “funciones”, “líneas de código” o “ramificaciones” (de menor a mayor precisión).

La cobertura nos dice qué porcentaje del programa ha sido ejecutado durante las pruebas automatizadas, de forma que podemos intuir cuanto se puede confiar en su buen funcionamiento (cuanto más alta sea la cobertura, mejor).

Una buena regulación obligaría a tener un porcentaje mínimo de cobertura para software a medida o que gestionara información sensible, pero también para software del que depende la seguridad física de seres humanos.

Un 100% para clases y funciones, y por encima del 70% o 60% para líneas de código y ramificaciones. Otro asunto es que probablemente esos mínimos deberían depender de la misión del software. Particularmente yo pediría cifras por encima del 95% para software que opera centrales nucleares, dispositivos médicos o sistemas de control de aviación. Y seguro que me quedo corto.

En el caso de software desarrollado a medida, el cliente debería tener el derecho a conocer las cifras exactas de cobertura y se deberían ofrecer aunque no fueran solicitadas. Si el cliente no sabe qué es la cobertura de código entonces nunca la pedirá.

Para acabar

Pido disculpas por la extensión y la poca frescura del artículo, me hubiera gustado poder ofrecer más ejemplos sobre por qué creo que estas medidas son tan necesarias, pero me temo que me habría extendido aún más.

Quiero inspirar a alguien con esto, generar algo de ruido, y sobretodo movilizar a quienes estén interesados en que nuestra sociedad progrese. ¿Alguien dispuesto a hacer lobby?