Hace casi veinte años, cuando estudiaba las implicancias jurídicas del software libre, la discusión giraba alrededor de una elección bastante visible: software abierto o propietario, licencias, costos, capacidad de modificación.
Hoy esa discusión quedó chica.
El software moderno rara vez es una pieza aislada. Aplicaciones propias y de terceros incorporan bibliotecas, frameworks, paquetes y componentes desarrollados y mantenidos por otros. Y las organizaciones conviven, además, con sistemas heredados —legacy— construidos años atrás, con dependencias que pueden estar desactualizadas, fuera de soporte o simplemente mal documentadas.
La pregunta ya no es solamente qué software usamos, sino de qué está hecho y de qué depende.
Cuando una dependencia se convierte en riesgo
Log4Shell lo mostró con bastante claridad en 2021. La vulnerabilidad crítica de Log4j obligó a organizaciones de todo el mundo a responder una pregunta aparentemente sencilla: ¿tenemos este componente y dónde?
Para muchas, responderla no fue inmediato.
El caso de xz utils mostró otra dimensión del mismo problema. En 2024 se detectó un intento deliberado de introducir código malicioso en una biblioteca ampliamente distribuida, luego de un proceso de manipulación del proyecto y de sus mantenedores.
Son riesgos diferentes, pero comparten un problema: una organización puede depender críticamente de código que no desarrolló, que no contrató directamente y cuya existencia incluso puede desconocer.
En los sistemas legacy, el problema se profundiza. Inventariar puede significar reconstruir años después qué componentes sostienen una aplicación, qué versiones utiliza, cuáles siguen mantenidas y qué podría verse afectado si una de ellas falla.
SBOM: saber de qué está hecho el software
Una de las respuestas a ese problema es el Software Bill of Materials (SBOM): un inventario estructurado de los componentes que integran un producto de software y de las relaciones entre ellos.
Su valor no está en producir otra lista. Está en permitir responder rápidamente preguntas concretas: ¿este componente vulnerable está en mis sistemas?, ¿en cuáles?, ¿qué versión utilizamos?
El SBOM no reemplaza el inventario de activos ni una CMDB. Los complementa. Una organización puede relacionar infraestructura, servidores, bases de datos y aplicaciones con los componentes de software de los que estas últimas dependen.
El resultado deja de ser un inventario estático para convertirse en un mapa de dependencias.
Adoptar también es decidir
Ahí aparece la dimensión jurídica.
Que un componente haya sido desarrollado por un tercero no externaliza automáticamente el riesgo derivado de incorporarlo.
Importa bajo qué licencia se utiliza, qué obligaciones genera, quién lo mantiene, cómo se conocen sus vulnerabilidades, qué ocurre si queda fuera de soporte y quién debe actuar cuando aparece un incidente.
Y la pregunta no termina en el software desarrollado internamente. Cuando una organización contrata una solución, también incorpora las dependencias elegidas por su proveedor.
Por eso la gobernanza de la cadena de suministro empieza antes de instalar el software: también se diseña en la contratación. Información sobre componentes, actualización y remediación de vulnerabilidades, notificación de incidentes, soporte, continuidad y cooperación ante una contingencia pueden formar parte de las condiciones exigidas al proveedor.
De la buena práctica al cumplimiento
Esta trazabilidad dejó de ser solamente una buena práctica técnica.
La regulación empieza a incorporar obligaciones específicas sobre seguridad de productos digitales y sus componentes. El Cyber Resilience Act europeo, por ejemplo, establece requisitos de ciberseguridad durante el ciclo de vida de los productos con elementos digitales y contempla expresamente la realidad del software libre y de código abierto.
Los estándares de seguridad también incorporan la gestión del riesgo asociado a proveedores y a la cadena de suministro tecnológica.
El movimiento es claro: conocer las dependencias empieza a formar parte de la capacidad de demostrar que el riesgo fue efectivamente gestionado.
Gobernar lo que no escribimos
Una política de componentes y dependencias debería poder responder, al menos, algunas preguntas básicas: qué incorporamos, dónde se utiliza, bajo qué licencia, quién lo mantiene, cómo detectamos vulnerabilidades y qué hacemos cuando deja de ser una opción aceptable.
No todo puede resolverse internamente ni todo componente necesita el mismo nivel de control. La profundidad del análisis dependerá de su criticidad y del riesgo que introduzca.
Pero una organización no puede gestionar una dependencia que desconoce.
Hace veinte años, "tener el software en regla" podía entenderse principalmente como una cuestión de licencias. Hoy significa bastante más: saber qué componentes sostienen nuestros sistemas, bajo qué condiciones los utilizamos, qué riesgos introducen y quién debe actuar cuando alguno falla.
No escribimos todo el código del que dependemos. Pero seguimos siendo responsables de decidir cómo lo incorporamos y cómo gestionamos su riesgo.