Nadie escribe todo el código

Una aplicación web moderna típica tiene unas pocas miles de líneas escritas por su equipo, y cientos de miles que vienen de librerías: la que conecta con la base de datos, la que valida formularios, la que genera fechas, la que dibuja gráficas.

Eso no es pereza, es sensato: nadie debería escribir su propio código de cifrado ni su propio motor de plantillas. Se usa lo que ya está probado por miles de personas.

Pero tiene una consecuencia directa: heredas los fallos de todo eso.

Cuando alguien publica un problema en una librería muy usada, todas las aplicaciones que la incluyen lo tienen desde ese momento — y muchas ni siquiera saben que la incluyen, porque las librerías traen a su vez otras librerías.

De ahí que la pregunta «¿qué versión es esto?» aparezca en cada módulo de esta ruta. No es curiosidad administrativa: es la que dice qué fallos públicos te aplican hoy.

La lista de lo que una aplicación incluye está escrita en un archivo del propio proyecto — cada lenguaje tiene el suyo. Y existen herramientas que leen esa lista y la comparan contra bases de datos públicas de fallos conocidos.

El resultado es una lista de «tienes esta versión, y esta versión tiene este problema documentado».

Tres cosas que conviene saber sobre esto, porque es donde la práctica se separa de la teoría:

No todo hallazgo aplica. Una librería puede tener un fallo en una función que tu aplicación nunca llama. Sigue apareciendo en el informe. Distinguir lo que aplica de lo que no es trabajo humano, y es la parte que las herramientas no hacen.

Actualizar tiene coste. Una versión nueva puede romper cosas. Por eso las actualizaciones no se aplican solas en producción, y por eso hay servidores con versiones de hace años: alguien decidió que el riesgo de romper era mayor. A veces acertó y a veces no.

Lo que no sabes que tienes es lo peor. El caso clásico: una librería que nadie recuerda haber incluido, que vino como dependencia de otra, y que resulta estar en todas partes.

Hay una versión más incómoda de este problema, y conviene nombrarla porque es de las que más han crecido.

Si tu aplicación se construye instalando librerías desde internet cada vez, entonces quien controle una de esas librerías puede meter código en tu aplicación. No hace falta atacarte a ti: basta con atacar algo en lo que confías.

Ha pasado de varias formas: una librería popular cuyo mantenedor entrega el proyecto a alguien que la modifica, un paquete con un nombre casi idéntico al que querías instalar, una cuenta de desarrollador comprometida.

Se llama cadena de suministro, y la defensa no es dejar de usar librerías —eso no es opción— sino:

• Fijar las versiones, para que una instalación no traiga algo distinto mañana
• Revisar lo que se añade, sobre todo si es poco conocido
• Reducir el número, porque cada una es una relación de confianza más

Y con eso cierras el módulo con la misma idea de siempre, en su última forma:

La seguridad de un sistema es la de todo lo que confía, no la de lo que escribió.

La clínica no escribió su servidor web, ni su base de datos, ni la mitad de su portal. Y respondía por todo.