Los Dieciséis Voluntarios que Sostenían Medio Internet: Lo Que Log4j Enseñó Sobre el Proveedor de su Proveedor

Conocí a un gerente de riesgo tecnológico que me contó que su empresa tenía, en el papel, un mapa impecable de proveedores críticos: quién les daba el software de facturación, quién alojaba su nube, quién procesaba sus pagos. Un mapa auditado, con planes de contingencia para cada nombre en la lista. Y sin embargo, en diciembre de 2021, pasó un fin de semana entero sin dormir parchando un componente que no aparecía en ese mapa por ningún lado.

Ese componente se llamaba Log4j, y casi nadie en su empresa sabía que lo tenían.

Log4j es una pequeña herramienta de registro de eventos, del tipo que usan miles de programas para anotar, en segundo plano, qué está pasando dentro de un sistema. No la vende nadie: es de código abierto, gratuita, y durante años vivió enterrada dentro de programas empresariales de todo tipo, desde sistemas de nómina hasta plataformas de videojuegos. El 9 de diciembre de 2021 se hizo pública una falla en esa herramienta, bautizada como Log4Shell, que permitía a cualquier atacante tomar control remoto de un servidor con apenas un mensaje de texto malicioso. Recibió la calificación más alta posible de severidad, diez sobre diez.

El giro: nadie había contratado a ese proveedor

Aquí está la parte que descolocó a los equipos de riesgo de medio mundo. Log4j no era un proveedor de nadie, en el sentido tradicional. Ninguna empresa había firmado un contrato con ella, ninguna la había evaluado en un proceso de compras, ninguna la tenía en su lista de terceros críticos. Estaba ahí porque el software que sí habían comprado, de un proveedor de confianza y con años de relación, la traía adentro, como una pieza más, comprada a su vez a otro proveedor, que a su vez la había tomado de otro.

En los días siguientes a la alerta, se confirmó la vulnerabilidad en servidores de Apple, Amazon, Twitter, Cloudflare, Steam, Baidu, Tencent y cientos de empresas más. El videojuego Minecraft, propiedad de Microsoft, fue de los primeros en verse afectado. Ninguna de esas compañías había "elegido" trabajar con Log4j de forma directa. La herramienta llevaba años ahí, cuatro o cinco capas por debajo de la relación comercial visible, sosteniendo silenciosamente una porción enorme de la infraestructura digital del planeta.

Lo que casi nadie pone en el mismo documento

La parte que más incomodó a los equipos de continuidad no fue la falla técnica. Fue descubrir quién mantenía esa pieza tan crítica: un equipo de apenas dieciséis voluntarios repartidos por el mundo, que trabajaban en su tiempo libre y sin sueldo. El desarrollador que escribió la corrección del error crítico tenía, en ese momento, solo tres personas patrocinando su trabajo de forma voluntaria. Una pieza de la que dependían bancos, aerolíneas, hospitales y gobiernos, mantenida con el mismo presupuesto que un pasatiempo de fin de semana.

Los planes de continuidad de negocio suelen mapear con cuidado a los proveedores de primer nivel: el que factura, el que aloja, el que procesa pagos. Muy pocos bajan una capa más y preguntan de qué depende ese proveedor, y menos aún preguntan de qué depende el proveedor de ese proveedor. Log4j vivía justo ahí, en un nivel que la mayoría de los procesos de gestión de riesgo de terceros ni siquiera contempla como pregunta.

Lo que sí funciona

No se trata de auditar personalmente cada línea de código que corre dentro de cada programa que su empresa usa; eso, para la inmensa mayoría de las organizaciones, no es viable. Se trata de asumir que esa capa invisible existe y prepararse para ella.

Primero, exija a sus proveedores de software una lista de los componentes de terceros que traen incluidos, lo que en la industria se conoce como inventario de software. Si un proveedor no puede entregar esa lista, esa incapacidad es en sí misma una señal de riesgo.

Segundo, en su matriz de riesgo de terceros, agregue una categoría distinta a "proveedor directo": dependencias que no contrató nadie, pero de las que depende su operación de todas formas. No necesita nombrarlas todas; necesita reconocer que la categoría existe.

Tercero, diseñe su plan de respuesta a incidentes asumiendo que la próxima falla crítica no vendrá de un proveedor con el que tiene contrato, sino de uno que nunca supo que tenía. La pregunta útil no es "¿confiamos en nuestros proveedores?", es "¿qué hacemos el día en que la falla viene de alguien que no está en ninguna lista?".

Cuarto, priorice la velocidad de parcheo por encima de la certeza de origen. Cuando Log4Shell se hizo pública, las empresas que sobrevivieron mejor no fueron las que mejor conocían su cadena de dependencias, sino las que tenían un proceso capaz de identificar y actualizar sistemas expuestos en horas, no en semanas.

Quinto, revise si su empresa depende de algún componente crítico, tecnológico o no, sostenido por muy poca gente. Un solo proveedor pequeño, un solo desarrollador, un solo taller artesanal en su cadena de suministro física, pueden ser su propio Log4j: invisibles hasta que fallan.

Sexto, entienda que el riesgo de terceros ya no termina en el proveedor que factura. Termina donde termine la cadena real de dependencias, y esa cadena casi siempre es más larga y más profunda de lo que muestra cualquier contrato firmado.

El cierre

Meses después de Log4Shell, seguían apareciendo sistemas sin parchar en empresas que juraban tener todo bajo control. La lección no fue sobre una herramienta de registro de eventos. Fue sobre cuántas empresas de primer nivel, con comités de riesgo y auditorías anuales, dependían para seguir operando de dieciséis personas anónimas que nunca conocieron, trabajando gratis, en un rincón de internet que ningún contrato mencionaba.