Menos es más seguro: cómo Obsidian reduce el riesgo de ataques a la cadena de suministro Los ataques a la cadena de suministro son actualizaciones maliciosas que se infiltran en el código de código abierto utilizado por muchas aplicaciones. Aquí te mostramos cómo diseñamos Obsidian para garantizar que la aplicación sea un entorno seguro y privado para tus pensamientos. Menos es más seguro Puede sonar obvio, pero la forma principal en que reducimos el riesgo de ataques a la cadena de suministro es evitar depender de código de terceros. Obsidian tiene un bajo número de dependencias en comparación con otras aplicaciones en nuestra categoría. Consulta una lista de bibliotecas de código abierto en nuestra página de Créditos. Funciones como Bases y Canvas se implementaron desde cero en lugar de importar bibliotecas preexistentes. Esto nos da control total sobre lo que se ejecuta en Obsidian. - Para funciones utilitarias pequeñas, casi siempre las reimplementamos en nuestro código. - Para módulos medianos, los bifurcamos y los mantenemos dentro de nuestra base de código si las licencias lo permiten. - Para bibliotecas grandes como pdf.js, Mermaid y MathJax, incluimos archivos conocidos y bloqueados por versión y solo actualizamos ocasionalmente, o cuando llegan correcciones de seguridad. Leemos las notas de lanzamiento, observamos los cambios en upstream y probamos exhaustivamente antes de cambiar. Este enfoque mantiene nuestro gráfico de dependencias poco profundo con pocas subdependencias. Una superficie más pequeña reduce la posibilidad de que una actualización maliciosa se cuele. Lo que realmente se envía en la aplicación Solo un puñado de paquetes son parte de la aplicación que ejecutas, por ejemplo, Electron, CodeMirror, moment.js. Los otros paquetes nos ayudan a construir la aplicación y nunca se envían a los usuarios, por ejemplo, esbuild o eslint. Fijación de versiones y archivos de bloqueo Todas las dependencias están estrictamente fijadas por versión y comprometidas con un archivo de bloqueo. El archivo de bloqueo es la fuente de verdad para las compilaciones, por lo que obtenemos instalaciones deterministas. Esto nos proporciona una pista de auditoría sencilla al revisar cambios. No ejecutamos scripts postinstall. Esto evita que los paquetes ejecuten código arbitrario durante la instalación. Actualizaciones lentas y deliberadas Cuando hacemos actualizaciones de dependencias,: 1. Leemos el registro de cambios de la dependencia línea por línea. 2. Verificamos las subdependencias introducidas por la nueva versión. 3. Comparamos con upstream cuando el conjunto de cambios es grande o arriesgado. 4. Ejecutamos pruebas automatizadas y manuales en todas las plataformas y rutas críticas de usuarios. 5. Comprometemos el nuevo archivo de bloqueo solo después de que estas revisiones pasen. En la práctica, rara vez actualizamos dependencias porque generalmente funcionan y no requieren cambios frecuentes. Cuando lo hacemos, tratamos cada cambio como si estuviéramos tomando una nueva dependencia. El tiempo es un buffer No apresuramos las actualizaciones. Hay un retraso entre la actualización de cualquier dependencia y el lanzamiento de una versión. Ese intervalo actúa como una ventana de advertencia temprana: la comunidad y los investigadores de seguridad a menudo detectan versiones maliciosas rápidamente. Para cuando estamos listos para enviar, el ecosistema generalmente ha señalado cualquier lanzamiento problemático. — Ninguna medida única puede eliminar el riesgo de la cadena de suministro. Pero elegir menos dependencias, gráficos poco profundos, fijaciones de versiones exactas, sin postinstall y un ritmo de actualización lento y centrado en la revisión, hace que Obsidian sea mucho menos probable que se vea afectado y nos da una larga ventana para detectar problemas antes de que el código llegue a los usuarios. Si tienes curiosidad sobre nuestro enfoque más amplio hacia la seguridad, consulta nuestra página de seguridad y auditorías pasadas.