Menos é mais seguro: como o Obsidian reduz o risco de ataques à cadeia de suprimentos Ataques à cadeia de suprimentos são atualizações maliciosas que se infiltram no código de código aberto usado por muitos aplicativos. Aqui está como projetamos o Obsidian para garantir que o aplicativo seja um ambiente seguro e privado para seus pensamentos. Menos é mais seguro Pode parecer óbvio, mas a principal maneira de reduzir o risco de ataques à cadeia de suprimentos é evitar depender de código de terceiros. O Obsidian tem um número baixo de dependências em comparação com outros aplicativos em nossa categoria. Veja uma lista de bibliotecas de código aberto em nossa página de Créditos. Recursos como Bases e Canvas foram implementados do zero em vez de importar bibliotecas prontas. Isso nos dá controle total sobre o que roda no Obsidian. - Para pequenas funções utilitárias, quase sempre as reimplementamos em nosso código. - Para módulos médios, fazemos um fork e os mantemos dentro de nossa base de código, se as licenças permitirem. - Para grandes bibliotecas como pdf.js, Mermaid e MathJax, incluímos arquivos conhecidos e bloqueados por versão e só atualizamos ocasionalmente, ou quando correções de segurança são lançadas. Lemos notas de lançamento, observamos mudanças upstream e testamos minuciosamente antes de trocar. Essa abordagem mantém nosso gráfico de dependências raso, com poucas sub-dependências. Uma área de superfície menor reduz a chance de uma atualização maliciosa passar despercebida. O que realmente é enviado no aplicativo Apenas um punhado de pacotes faz parte do aplicativo que você executa, por exemplo, Electron, CodeMirror, moment.js. Os outros pacotes nos ajudam a construir o aplicativo e nunca são enviados aos usuários, por exemplo, esbuild ou eslint. Bloqueio de versões e arquivos de bloqueio Todas as dependências são estritamente bloqueadas por versão e comprometidas com um arquivo de bloqueio. O arquivo de bloqueio é a fonte da verdade para as compilações, então obtemos instalações determinísticas. Isso nos dá uma trilha de auditoria direta ao revisar mudanças. Não executamos scripts pós-instalação. Isso impede que pacotes executem código arbitrário durante a instalação. Atualizações lentas e deliberadas Quando fazemos atualizações de dependências, nós: ...