En mi tesis defendía al código abierto frente al software propietario. Dos décadas y un puñado de vulnerabilidades célebres después, la pregunta ya no es si el open source es bueno: es cómo gobernamos algo que sostiene a internet y que casi nadie ve en su factura de software.
Linux, el "todo gratis" y lo que vino después
En 2009 dediqué parte de mi investigación a reconstruir la historia que hizo posible GNU/Linux: desde UNIX hasta el modelo de contribución abierta, la descentralización de Internet y la idea de que el código compartido multiplica sus miradas y, con ellas, su corrección. Aquella narrativa sigue siendo cierta, pero hoy se cuenta con un dato que entonces era apenas premonitorio: la mayor parte de lo que corre en internet —servidores, aplicaciones, teléfonos— está construida sobre componentes de código abierto.
La primera corrección necesaria sigue siendo conceptual: el open source no es "gratis". Es software cuya licencia te da libertad, no ausencia de costo. El costo aparece en otro lado: en la responsabilidad de mantener vivo lo que decidiste usar.
Log4j y xz: cuando el corazón corre en open source
A fines de 2021, una biblioteca de logging llamada Log4j —presente en millones de aplicaciones Java, casi todas sin que sus dueños lo supieran— explotó con una vulnerabilidad aprovechable a distancia. El mundo entero entró en carrera: parchear, auditar, apagar sistemas. El incidente demostró que una falla en un componente chico puede prender fuego a toda una cadena.
Poco después, el caso de xz utils lo hizo más inquietante: durante meses un mantenedor fue construyendo confianza en un proyecto de compresión usado por Linux y estuvo a punto de colar una puerta trasera en el acceso remoto del sistema. No fue un error de código: fue ingeniería social cuidadosa sobre un proyecto sostenido por voluntarios. La moraleja no es abandonar el open source; es que la confianza también se audita.
El SBOM como inventario de confianza
La respuesta técnica tiene un nombre poco elegante y una idea sencilla: SBOM —software bill of materials—, la lista de ingredientes de un producto de software. Para cada sistema, qué componentes lo integran, con qué versión, qué parches y bajo qué licencias. Es el análogo moderno del inventario que discutimos en el artículo anterior: saber qué se usa, para qué y bajo qué condiciones.
Con un SBOM, una organización puede saber en horas si un componente comprometido está en su base y responder antes de que la ventana de ataque se cierre. Sin él, queda confiando en que alguien más avise. Y los dos casos anteriores muestran lo que pasa cuando esa confianza no se sostiene.
Marcos normativos y estándares
Estados Unidos y la Unión Europea vienen legislando sobre la cadena de suministro del software: exigencias de transparencia, inventario de componentes y mecanismos de verificación para quienes contratan tecnología crítica. En paralelo, estándares como ISO/IEC 27001 empujan a tratar los riesgos de la cadena de suministro como parte del análisis de riesgos de la información.
Esa tendencia cambia la naturaleza del problema: deja de ser una cuestión puramente técnica. En la medida en que los reguladores piden saber de dónde viene cada componente, el SBOM se transforma en un requisito de cumplimiento.
Gobernanza: qué componentes se admiten
Detrás de todo esto hay una política de componentes de código abierto. Seis decisiones que toda organización debería poder responder:
- Adopción: criterios explícitos sobre qué componentes ingresan al patrimonio tecnológico y quién los aprueba.
- Licencias: revisar la licencia de cada componente con el mismo esmero con que se revisa un contrato: copyleft, permisiva, qué obligaciones arrastra.
- Mantenimiento: estado del proyecto, comunidad activa, antigüedad de las actualizaciones y quién responde si el componente queda huérfano.
- Respuesta: un procedimiento ante una vulnerabilidad en un componente crítico, con responsables y tiempos.
La gobernanza hace con el código prestado lo que ya hicimos con el software propio: que ninguna línea crítica quede sin dueño.
El open source ganó la conversación de fondo de hace veinte años. Hoy la pregunta no es si conviene: es quién responde por cada componente que sostiene tu organización.
Conclusión
Mi tesis terminaba celebrando el triunfo del modelo abierto. Ese triunfo ya está consumado, y el siguiente movimiento le pertenece a otro tipo de responsabilidad: la gobernanza de la cadena de suministro. Lo que hoy está en juego no es el código que escribís, sino el código que adoptás sin leer.
Conocer cada componente, auditar la confianza y saber reaccionar: eso es hoy la versión moderna de "tener el software en regla".