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 cuelan en el código fuente abierto utilizado por muchas aplicaciones. Así es como diseñamos Obsidian para garantizar que la aplicación sea un entorno seguro y privado para sus pensamientos. Menos es más seguro Puede parecer obvio, pero la principal forma en que reducimos el riesgo de ataques a la cadena de suministro es evitar depender del código de terceros. Obsidian tiene un bajo número de dependencias en comparación con otras aplicaciones de 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 listas para usar. Esto nos da un control total sobre lo que se ejecuta en Obsidian. - Para pequeñas funciones de utilidad, casi siempre las volvemos a implementar en nuestro código. - Para los 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 con versión bloqueada y solo actualizamos ocasionalmente, o cuando llegan correcciones de seguridad. Leemos las notas de la versión, analizamos los cambios ascendentes y probamos a fondo antes de cambiar. Este enfoque mantiene nuestro gráfico de dependencias poco profundo con pocas subdependencias. Un área expuesta más pequeña reduce la posibilidad de que se cuele una actualización malintencionada. Lo que realmente se envía en la aplicación Solo un puñado de paquetes forman parte de la aplicación que ejecuta, por ejemplo, Electron, CodeMirror, moment.js. Los otros paquetes nos ayudan a crear 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 ancladas a la versión y confirmadas 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 da una pista de auditoría sencilla al revisar los cambios. No ejecutamos scripts posteriores a la instalación. Esto evita que los paquetes ejecuten código arbitrario durante la instalación. Actualizaciones lentas y deliberadas Cuando hacemos actualizaciones de dependencias, hacemos lo siguiente: 1. Lea el registro de cambios de la dependencia línea por línea. 2. Verifique las subdependencias introducidas por la nueva versión. 3. Diff aguas arriba cuando el conjunto de cambios es grande o arriesgado. 4. Ejecute pruebas automatizadas y manuales en todas las plataformas y rutas de usuario críticas. 5. Confirme el nuevo archivo de bloqueo solo después de que pasen estas revisiones. En la práctica, rara vez actualizamos las 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 amortiguador No apresuramos las actualizaciones. Hay un retraso entre la actualización de cualquier dependencia y el envío de una versión. Esa brecha actúa como una ventana de alerta 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 marcado cualquier lanzamiento problemático. — Ninguna medida por sí sola puede eliminar el riesgo de la cadena de suministro. Pero elegir menos dependencias, gráficos poco profundos, pines de versión exacta, sin postinstalación y una cadencia de actualización lenta y con muchas revisiones hacen que Obsidian sea mucho menos probable que se vea afectado y nos brindan una larga ventana para detectar problemas antes de que el código llegue a los usuarios. Si tiene curiosidad acerca de nuestro enfoque más amplio de la seguridad, consulte nuestra página de seguridad y auditorías anteriores.