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: 1. Lemos o changelog da dependência linha por linha. 2. Verificamos sub-dependências introduzidas pela nova versão. 3. Comparamos upstream quando o conjunto de mudanças é grande ou arriscado. 4. Executamos testes automatizados e manuais em várias plataformas e caminhos críticos do usuário. 5. Comprometemos o novo arquivo de bloqueio apenas após essas revisões serem aprovadas. Na prática, raramente atualizamos dependências porque geralmente funcionam e não requerem mudanças frequentes. Quando o fazemos, tratamos cada mudança como se estivéssemos assumindo uma nova dependência. O tempo é um buffer Não apressamos as atualizações. Há um atraso entre atualizar qualquer dependência e lançar uma versão. Essa lacuna atua como uma janela de alerta precoce: a comunidade e os pesquisadores de segurança frequentemente detectam versões maliciosas rapidamente. Quando estamos prontos para enviar, o ecossistema geralmente já sinalizou quaisquer lançamentos problemáticos. — Nenhuma medida única pode eliminar o risco da cadeia de suprimentos. Mas escolher menos dependências, gráficos rasos, bloqueios de versão exatos, sem pós-instalação e um ritmo de atualização lento e focado em revisões juntos tornam o Obsidian muito menos propenso a ser impactado e nos dão uma longa janela para detectar problemas antes que o código chegue aos usuários. Se você está curioso sobre nossa abordagem mais ampla à segurança, veja nossa página de segurança e auditorias passadas.