Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Recuerda git blame? En algún momento, alguien va a ejecutar el código heredado y se pondrán de manifiesto las decisiones que tomaste hace años. Se quedarán desconcertados. Quizá el proyecto haya pasado a otras manos. Quizá hayas dejado la empresa. QUIZÁS, tal vez, el proyecto se traspasó a la comunidad para que lo desarrollara. Pero el problema es que nadie sabe por qué hiciste lo que hiciste ni cuáles eran las limitaciones a las que te enfrentabas. La pregunta que surge es sencilla: ¿por qué elegiste este dep en lugar de otro?
Las decisiones que tomes hoy sobre las dependencias son un mensaje para quien, en el futuro, herede el código. Sin embargo, ese mensaje rara vez llega a su destino. Normalmente no es más que una línea en package.json con un rango de versiones como ^2.4.1 y nada que explique cómo llegó hasta allí. Esa laguna es precisamente donde muchos sistemas de gestión de dependencias de código abierto se desmoronan sin que nadie se dé cuenta.
No es una instantánea
Añadir un paquete no equivale a quedarse con un artefacto estático. Lo que se hereda es una trayectoria. Entre bastidores, hay muchos elementos en movimiento y personas involucradas cuando incorporas la biblioteca más reciente y avanzada, y muchos paquetes traen consigo dependencias transitivas mantenidas por personas de las que nunca has oído hablar. El comando de instalación no comunica nada de esto. Los mantenedores siguen adelante, y el código también. Un paquete permanece inactivo durante meses y, a menudo, nadie se da cuenta hasta que surge un CVE y no hay nadie disponible para aplicar un parche.
El archivo de bloqueo ayuda a controlar lo que se instala. Registra el árbol resuelto, incluidas las versiones y, en el caso de los paquetes del Registro, los hash de integridad, pero no explica por qué está ahí nada de ello. La falta de explicación se hace patente más adelante, normalmente en el peor momento posible. Alguien intenta implementar una corrección de seguridad y descubre que la dependencia que necesita actualizar no ha tenido ninguna versión nueva en años y sigue estando vinculada a una versión de Node.js que dejó de estar en servicio hace mucho tiempo. No es nada bueno.
Este es el código fuente que algún día entregarás.
Heredado sin contexto
La persona que se haga cargo de tu código no heredará tu proceso de pensamiento. Solo tendrá unas pistas, con muy poco contexto. La dependencia que elegiste fue probablemente la decisión correcta, teniendo en cuenta el tiempo disponible, el plazo y las alternativas que barajaste. Todo tenía sentido en aquel momento. Pero que el código resista el traspaso es otra historia. Si nadie ha dejado por escrito el razonamiento, la siguiente persona no podrá distinguir entre una decisión meditada y un error fortuito.
Imagina una dependencia fijada en una versión antigua, con un mensaje de confirmación que dice: pin, do not bump. ¿Un cambio radical en la API? ¿Un problema con la licencia? ¿Una fuga de memoria bajo carga? Nadie puede afirmar si el motivo sigue siendo válido, así que el pin se mantiene porque modificarlo parece más arriesgado. Sin el contexto, una decisión sensata empieza a parecer una negligencia.
Así pues, la siguiente persona o bien confía ciegamente en tu decisión o bien vuelve a analizarla desde cero. Ambas opciones son costosas. La primera conlleva el riesgo de seguir adelante con algo que, sin que nos diéramos cuenta, ha resultado ser una decisión errónea. La segunda supone perder tiempo volviendo a llegar a una conclusión a la que ya habías llegado.
Aquí es donde un traspaso de código abierto puede volverse un poco complicado. Una bifurcación incluye el código, el historial de commits y cualquier documentación que se haya incorporado al repositorio. No incluye los garabatos de los cuadernos, los hilos de Slack ni los comentarios de los tickets, donde se encontraba gran parte del razonamiento. La persona que se hace cargo del proyecto tiene que reconstruir ese contexto a base de mucho esfuerzo o lo perderá en un mar de solicitudes de incorporación de cambios.
Los traspasos también se producen en las fases iniciales. En 2018, el responsable del mantenimiento de event-stream, un popular paquete de npm, cedió los derechos de publicación a un voluntario que se ofreció a ayudar. El 9 de septiembre, según el informe de incidencias de npm, el nuevo responsable del mantenimiento añadió flatmap-stream como dependencia con el rango ^0.1.0. El 5 de octubre, [email protected] se distribuía con código ofuscado que solo se activaba en la versión final de la cartera de bitcoins Copay, donde accedía a las claves privadas. Cualquier instalación que resolviera ese rango desde cero, sin un archivo de bloqueo que lo fijara 0.1.0, se descargó la versión maliciosa. Permaneció ahí hasta que un desarrollador la señaló el 20 de noviembre.
La descomposición es silenciosa, pero la documentación no lo es
Las razones que motivan la elección de las dependencias no envejecen de la misma manera. Algunas se mantienen sólidas durante una década. Otras, no. Algunas se deterioran casi de inmediato. El deterioro no suele ser visible hasta que alguien se fija en ello, normalmente a raíz de un análisis de seguridad, de que un componente llegue al final de su vida útil (EOL) o de una auditoría. El mantenimiento del software y la herencia del código abierto se parecen mucho a la compra de una casa antigua. Nadie se fija en los cimientos hasta que empiezan a ceder.
npm outdated compara las versiones instaladas con los rangos que hayas indicado y con la última versión disponible, aunque solo para las dependencias directas, a menos que añadas --all. npm view <package> time muestra cuándo se publicó cada versión. Ninguno de estos datos constituye una puntuación de calidad, ya que una biblioteca consolidada puede pasar años sin publicar ninguna versión y un repositorio muy activo puede, aun así, estar mal gestionado.
La gestión de dependencias de código abierto suele describirse como el proceso de selección, actualización y protección de los paquetes. Mantener vivo el razonamiento también forma parte de esa lista. Los equipos que transfieren los códigos fuente de forma ordenada dejan un rastro: por qué se eligió una dependencia, por qué se fijó una versión y cuál es el plan cuando algo llega al final de su vida útil (EOL).
La parte que tú controlas
No puedes controlarlo todo, sobre todo quién se encargará del mantenimiento de un paquete dentro de seis años. No puedes controlar si un proyecto del que dependes acaba abandonándose, cambia de rumbo o se bifurca. Lo que sí puedes controlar es lo bien que documentas tu proceso. Un registro de las decisiones y del razonamiento que hay detrás de ellas hará muy feliz a la próxima persona que herede el código.
Cada una de estas tres herramientas responde a una pregunta diferente. Un ADR (Architecture Decision Record) explica el «porqué», a menudo en forma de un breve archivo Markdown en docs/adr/ registrando el contexto, las opciones barajadas, la decisión y sus consecuencias. Una SBOM (lista de materiales de software) responde a la pregunta «qué». Se trata de un inventario legible por máquina, normalmente en formato SPDX o CycloneDX, de los componentes de una compilación determinada, incluidas las dependencias transitivas cuando el generador las captura. La procedencia responde a las preguntas «dónde» y «cómo». Un paquete publicado con Procedencia de npm procedente de un proveedor de CI/CD en la nube compatible incluye un certificado que lo vincula a su repositorio de origen y a su compilación. Esto indica de dónde procede el código, pero no garantiza que sea seguro.
La documentación refleja la intención. No puede garantizar la fiabilidad de los propios paquetes. Los registros públicos ofrecen medidas de seguridad, como firmas, verificación de la procedencia y eliminación de paquetes maliciosos, pero muchos paquetes siguen careciendo de procedencia, y ninguno de esos controles permite saber si los editores actuales son los mismos en los que confiaste el día de la adopción.
SecureChain sigue un enfoque diferente. Recompila paquetes de código abierto a partir de fuentes verificadas en entornos aislados y reforzados, los analiza en busca de malware y los distribuye desde un repositorio gestionado. Los paquetes incluyen una certificación de procedencia SLSA de nivel 3 para la recompilación, así como datos de VEX (Vulnerability Exploitability eXchange) sobre qué vulnerabilidades conocidas les afectan, cuáles no y cuáles se han corregido. Dependiendo del paquete, también incluyen una SBOM de sus componentes.
Tarde o temprano, algún elemento de tu árbol alcanzará el final de su vida útil, el momento en el que sus responsables dejan de publicar parches de seguridad, y lo más probable es que eso ocurra después de que te hayas ido. El «Endless Lifecycle Support» (ELS) retroaplica los parches de seguridad a las versiones en fin de vida útil que están cubiertas, de modo que una versión incluida en el programa que ya esté en producción siga recibiendo parches. El equipo que herede tu código fuente no se verá obligado a elegir entre seguir ejecutando el código sin parches o realizar una reescritura de emergencia bajo presión. Esto les da tiempo para tomar una decisión meditada sobre la migración, en lugar de una tomada por pánico.
Reflexiones finales
Cada dependencia que añades supone un compromiso a largo plazo que traspasas a quien se encargue posteriormente del mantenimiento del proyecto. El código perdura más allá de los equipos, los puestos de trabajo y las empresas. Al documentar los motivos que hay detrás de tus elecciones en cuanto a dependencias, mantener un registro verificable de lo que lanzas y planificar para el día en que finalice el soporte de los desarrolladores originales, le das al código fuente que algún día entregarás una oportunidad real de convertirse en un activo, y no en una trampa.
