Durante anos, a indústria de software adotou uma cultura de instalar dezenas — ou até centenas — de bibliotecas externas em praticamente todos os projetos. Frameworks modernos frequentemente dependem de milhares de dependências transitivas, o que significa que uma única aplicação pode acabar dependendo de código mantido por centenas de colaboradores desconhecidos.
Embora esse ecossistema tenha acelerado o desenvolvimento de software, ele também introduziu uma nova categoria de risco: a cadeia de suprimentos de software (Software Supply Chain).
O Movimento 0deps nasce de uma pergunta simples:
E se uma aplicação dependesse apenas do código que ela realmente controla?
O problema das dependências
Toda dependência aumenta a superfície de ataque.
Ela pode:
- Introduzir vulnerabilidades de segurança.
- Tornar-se alvo de um ataque à cadeia de suprimentos.
- Ser abandonada.
- Alterar sua API pública.
- Remover funcionalidades.
- Quebrar compatibilidade retroativa.
- Introduzir novas dependências transitivas.
- Publicar versões incompatíveis.
Na prática, os desenvolvedores perdem o controle sobre uma parcela significativa do código que é executado em produção.
Quanto maior a árvore de dependências, maior a superfície potencial de ataque.
A proposta
No modelo 0deps, toda dependência necessária é incorporada diretamente ao repositório do projeto.
As dependências deixam de ser baixadas dinamicamente por gerenciadores de pacotes durante a instalação ou o processo de build.
Tudo o que é necessário para compilar e executar a aplicação já está presente no repositório desde o momento em que ele é clonado.
Isso proporciona diversos benefícios importantes:
- Builds reproduzíveis.
- Menor dependência de registries externos.
- Auditoria de segurança centralizada.
- Maior previsibilidade.
- Redução da superfície de ataque da cadeia de suprimentos.
Contratos Públicos Imutáveis
O princípio central do 0deps não é tornar a implementação imutável.
Implementações evoluem.
Algoritmos evoluem.
Correções de segurança evoluem.
O que permanece estável é o contrato público.
Cada biblioteca expõe uma interface pública cuidadosamente projetada.
Por exemplo:
authenticate()
createSession()
verifyPasskey()
sendMagicLink()
Essas funções definem um contrato.
Esse contrato nunca muda.
A implementação por trás dele pode ser completamente reescrita.
Os algoritmos podem mudar.
Bibliotecas internas podem ser substituídas.
Protocolos podem evoluir.
Estruturas de dados podem ser redesenhadas.
Nenhuma dessas mudanças internas afeta a forma como o restante da aplicação utiliza a biblioteca.
Atualizações de Segurança sem Quebrar Aplicações
Sempre que uma vulnerabilidade é descoberta, normalmente existem duas preocupações:
- Corrigir a vulnerabilidade.
- Descobrir quantas aplicações deixarão de funcionar após a atualização.
Na arquitetura 0deps, essa segunda preocupação praticamente desaparece.
As atualizações acontecem internamente.
A implementação por trás da interface é modificada.
A API pública permanece exatamente a mesma.
As aplicações continuam funcionando sem exigir alterações de código.
Em outras palavras, a implementação evolui enquanto o contrato permanece estável.
Adaptadores Internos
Toda integração externa é isolada por meio de um adaptador interno.
Aplicação
↓
Interface Pública
↓
Adaptador
↓
Implementação
Se uma biblioteca externa deixar de existir ou for descontinuada amanhã, apenas o adaptador precisará ser alterado.
Nenhuma outra parte da aplicação será afetada.
Esse isolamento reduz drasticamente o impacto das mudanças tecnológicas ao longo do tempo.
Versionamento Invisível
Aplicações construídas sobre o modelo 0deps nunca interagem diretamente com APIs de bibliotecas externas.
Elas se comunicam exclusivamente com contratos internos estáveis.
As versões das bibliotecas tornam-se um detalhe de implementação.
Os mantenedores do framework assumem a responsabilidade pelas atualizações.
Os desenvolvedores da aplicação continuam utilizando exatamente a mesma interface, independentemente das mudanças internas.
Segurança da Cadeia de Suprimentos
O objetivo do 0deps não é afirmar que o software se torna invulnerável.
Seu objetivo é reduzir significativamente os riscos da cadeia de suprimentos de software.
Ao eliminar a instalação dinâmica de dependências durante o processo de build, a arquitetura reduz a exposição a ameaças como:
- Publicação de pacotes maliciosos.
- Comprometimento de registries.
- Ataques de dependency confusion.
- Pacotes de typosquatting.
- Mudanças inesperadas em dependências transitivas.
Todo o código executado passa a fazer parte do próprio projeto, permitindo auditoria, versionamento e revisão de segurança centralizados.
Estabilidade de Longo Prazo
O maior benefício do 0deps torna-se evidente anos após o lançamento de um projeto.
Projetos duram décadas.
Bibliotecas desaparecem.
Frameworks mudam.
Ecossistemas evoluem.
Mesmo assim, as aplicações continuam interagindo exatamente com os mesmos contratos públicos.
A responsabilidade de acompanhar a evolução do ecossistema deixa de estar distribuída entre todas as aplicações e passa a ser centralizada nos adaptadores internos do projeto.
Atualizações potencialmente disruptivas tornam-se simples substituições de implementação.
O Movimento
O Movimento 0deps não é contra o software de código aberto.
Muito pelo contrário.
Ele reconhece o enorme valor do open source, mas propõe um modelo diferente de consumo.
As bibliotecas deixam de ser tratadas como dependências instaladas dinamicamente.
Em vez disso, tornam-se componentes incorporados ao projeto, auditados, versionados e encapsulados por contratos públicos estáveis.
O resultado é um software mais previsível, mais resiliente, mais fácil de manter e significativamente menos exposto aos riscos da cadeia de suprimentos.
As implementações podem evoluir indefinidamente.
O contrato permanece inalterado.
E é justamente essa estabilidade que permite que aplicações escritas hoje continuem funcionando exatamente da mesma forma muitos anos no futuro.
Top comments (0)