Menos é mais seguro: como a Obsidian reduz o risco de ataques à cadeia de suprimentos Os ataques à cadeia de suprimentos são atualizações maliciosas que se infiltram no código-fonte aberto usado por muitos aplicativos. Veja 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ódigos de terceiros. O Obsidian tem um baixo número 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 para uso. Isso nos dá controle total sobre o que é executado em Obsidian. - Para pequenas funções utilitárias, quase sempre as reimplementamos em nosso código. - Para módulos médios, nós os bifurcamos e os mantemos dentro de nossa base de código, se as licenças permitirem. - Para bibliotecas grandes como pdf.js, Mermaid e MathJax, incluímos arquivos com bloqueio de versão em boas condições e atualizamos apenas ocasionalmente ou quando as correções de segurança chegam. Lemos as notas de versão, analisamos as alterações upstream e testamos minuciosamente antes de mudar. Essa abordagem mantém nosso gráfico de dependências superficial com poucas subdependências. Uma área de superfície menor reduz a chance de uma atualização maliciosa escapar. O que realmente é enviado no aplicativo Apenas alguns pacotes fazem parte do aplicativo que você executa, por exemplo, Electron, CodeMirror moment.js. Os outros pacotes nos ajudam a criar o aplicativo e nunca enviam para os usuários, por exemplo, esbuild ou eslint. Fixação de versão e arquivos de bloqueio Todas as dependências são estritamente fixadas na versão e confirmadas com um arquivo de bloqueio. O arquivo de bloqueio é a fonte da verdade para compilações, portanto, obtemos instalações determinísticas. Isso nos dá uma trilha de auditoria direta ao revisar as alterações. Não executamos scripts de pós-instalação. Isso impede que os pacotes executem código arbitrário durante a instalação. Atualizações lentas e deliberadas Quando fazemos atualizações de dependência, nós: 1. Leia o changelog da dependência linha por linha. 2. Verifique as subdependências introduzidas pela nova versão. 3. Diferencie upstream quando o conjunto de alterações for grande ou arriscado. 4. Execute testes automatizados e manuais em plataformas e caminhos críticos do usuário. 5. Confirme o novo arquivo de bloqueio somente após a aprovação dessas revisões. Na prática, raramente atualizamos as dependências porque elas geralmente funcionam e não exigem alterações frequentes. Quando o fazemos, tratamos cada mudança como se estivéssemos assumindo uma nova dependência. O tempo é um buffer Não apressamos atualizações. Há um atraso entre a atualização de qualquer dependência e o envio de uma versão. Essa lacuna atua como uma janela de alerta antecipado: a comunidade e os pesquisadores de segurança geralmente detectam versões maliciosas rapidamente. Quando estamos prontos para lançar, o ecossistema geralmente sinaliza quaisquer lançamentos problemáticos. — Nenhuma medida isolada pode eliminar o risco da cadeia de suprimentos. Mas escolher menos dependências, gráficos superficiais, pinos de versão exatos, sem pós-instalação e uma cadência de atualização lenta e pesada de revisão juntos tornam a Obsidian muito menos provável de ser afetada e nos dão uma longa janela para detectar problemas antes que o código chegue aos usuários. Se você estiver curioso sobre nossa abordagem mais ampla de segurança, consulte nossa página de segurança e auditorias anteriores.