Supply chain attacks are malicious updates that sneak into open source code used by many apps. Here’s how we design Obsidian to ensure that the app is a secure and private environment for your thoughts.
Less is safer
It may sound obvious but the primary way we reduce the risk of supply chain attacks is to avoid depending on third-party code. Obsidian has a low number of dependencies compared to other apps in our category. See a list of open source libraries on our Credits page.
Features like Bases and Canvas were implemented from scratch instead of importing off-the-shelf libraries. This gives us full control over what runs in Obsidian.
For small utility functions we almost always re-implement them in our code.
we almost always re-implement them in our code. For medium modules we fork them and keep them inside our codebase if the licenses allows it.
we fork them and keep them inside our codebase if the licenses allows it. For large libraries like pdf.js, Mermaid, and MathJax, we include known-good, version-locked files and only upgrade occasionally, or when security fixes land. We read release notes, look at upstream changes, and test thoroughly before switching.
This approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through.
What actually ships in the app
Only a handful of packages are part of the app you run, e.g. Electron, CodeMirror, moment.js. The other packages help us build the app and never ship to users, e.g. esbuild or eslint.
... continue reading