Durante años, la industria del software adoptó una cultura de instalar decenas o incluso cientos de bibliotecas externas en prácticamente todos los proyectos. Los frameworks modernos suelen depender de miles de dependencias transitivas, lo que significa que una sola aplicación puede terminar dependiendo de código mantenido por cientos de colaboradores desconocidos.
Aunque este ecosistema ha acelerado enormemente el desarrollo de software, también ha introducido una nueva categoría de riesgos: la cadena de suministro de software (Software Supply Chain).
El Movimiento 0deps nace de una pregunta simple:
¿Y si una aplicación dependiera únicamente del código que realmente controla?
El problema de las dependencias
Cada dependencia incrementa la superficie de ataque.
Puede:
- Introducir vulnerabilidades de seguridad.
- Convertirse en el objetivo de un ataque a la cadena de suministro.
- Ser abandonada.
- Cambiar su API pública.
- Eliminar funcionalidades.
- Romper la compatibilidad hacia atrás.
- Incorporar nuevas dependencias transitivas.
- Publicar versiones incompatibles.
En la práctica, los desarrolladores pierden el control sobre una parte significativa del código que se ejecuta en producción.
Cuanto mayor es el árbol de dependencias, mayor es la superficie potencial de ataque.
La propuesta
En el modelo 0deps, todas las dependencias necesarias se incorporan directamente al repositorio del proyecto.
Las dependencias dejan de descargarse dinámicamente mediante gestores de paquetes durante la instalación o el proceso de compilación.
Todo lo necesario para compilar y ejecutar la aplicación ya se encuentra dentro del repositorio desde el momento en que este se clona.
Esto ofrece varias ventajas importantes:
- Compilaciones reproducibles.
- Menor dependencia de registros de paquetes externos.
- Auditoría de seguridad centralizada.
- Mayor previsibilidad.
- Reducción de la superficie de ataque de la cadena de suministro.
Contratos públicos inmutables
El principio fundamental de 0deps no consiste en hacer que las implementaciones sean inmutables.
Las implementaciones evolucionan.
Los algoritmos evolucionan.
Las correcciones de seguridad evolucionan.
Lo que permanece estable es el contrato público.
Cada biblioteca expone una interfaz pública cuidadosamente diseñada.
Por ejemplo:
authenticate()
createSession()
verifyPasskey()
sendMagicLink()
Estas funciones definen un contrato.
Ese contrato nunca cambia.
La implementación subyacente puede reescribirse por completo.
Los algoritmos pueden cambiar.
Las bibliotecas internas pueden sustituirse.
Los protocolos pueden evolucionar.
Las estructuras de datos pueden rediseñarse.
Ninguno de estos cambios internos afecta la forma en que el resto de la aplicación utiliza la biblioteca.
Actualizaciones de seguridad sin romper aplicaciones
Siempre que se descubre una vulnerabilidad, normalmente surgen dos preocupaciones:
- Corregir la vulnerabilidad.
- Determinar cuántas aplicaciones dejarán de funcionar después de la actualización.
Dentro de la arquitectura 0deps, la segunda preocupación prácticamente desaparece.
Las actualizaciones se realizan internamente.
La implementación detrás de la interfaz se modifica.
La API pública permanece exactamente igual.
Las aplicaciones continúan funcionando sin necesidad de modificar su código.
En otras palabras, la implementación evoluciona mientras el contrato permanece estable.
Adaptadores internos
Toda integración externa queda aislada detrás de un adaptador interno.
Aplicación
↓
Interfaz pública
↓
Adaptador
↓
Implementación
Si una biblioteca externa deja de existir o queda obsoleta mañana, solo será necesario modificar el adaptador.
Ninguna otra parte de la aplicación se verá afectada.
Este aislamiento reduce drásticamente el impacto de los cambios tecnológicos a lo largo del tiempo.
Versionado invisible
Las aplicaciones construidas bajo el modelo 0deps nunca interactúan directamente con las API de bibliotecas externas.
Se comunican exclusivamente mediante contratos internos estables.
Las versiones de las bibliotecas se convierten en un simple detalle de implementación.
Los mantenedores del framework asumen la responsabilidad de las actualizaciones.
Los desarrolladores de aplicaciones continúan utilizando exactamente la misma interfaz, independientemente de los cambios internos.
Seguridad de la cadena de suministro
El objetivo de 0deps no es afirmar que el software se vuelva invulnerable.
Su propósito es reducir significativamente los riesgos asociados a la cadena de suministro de software.
Al eliminar la instalación dinámica de dependencias durante el proceso de compilación, la arquitectura reduce la exposición a amenazas como:
- Publicación de paquetes maliciosos.
- Compromiso de registros de paquetes.
- Ataques de dependency confusion.
- Paquetes de typosquatting.
- Cambios inesperados en dependencias transitivas.
Todo el código ejecutable pasa a formar parte del propio proyecto, lo que permite auditoría, control de versiones y revisiones de seguridad centralizadas.
Estabilidad a largo plazo
El mayor beneficio de 0deps se hace evidente años después de que un proyecto entra en producción.
Los proyectos viven durante décadas.
Las bibliotecas desaparecen.
Los frameworks cambian.
Los ecosistemas evolucionan.
A pesar de todo ello, las aplicaciones continúan utilizando exactamente los mismos contratos públicos.
La responsabilidad de adaptarse a la evolución del ecosistema deja de estar distribuida entre todas las aplicaciones y pasa a concentrarse en los adaptadores internos del proyecto.
Las actualizaciones potencialmente disruptivas se convierten en simples sustituciones de implementación.
El Movimiento
El Movimiento 0deps no está en contra del software de código abierto.
Todo lo contrario.
Reconoce el enorme valor del software libre y de código abierto, pero propone un modelo diferente de consumo.
Las bibliotecas dejan de tratarse como dependencias instaladas dinámicamente.
En su lugar, pasan a ser componentes integrados en el proyecto, auditados, versionados y encapsulados detrás de contratos públicos estables.
El resultado es un software más predecible, más resiliente, más fácil de mantener y significativamente menos expuesto a los riesgos de la cadena de suministro.
Las implementaciones pueden evolucionar indefinidamente.
El contrato permanece inalterado.
Y es precisamente esa estabilidad la que permite que las aplicaciones desarrolladas hoy sigan funcionando exactamente de la misma manera durante muchos años.
Top comments (0)