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.
- For medium modules 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.
Version pinning and lockfiles
All dependencies are strictly version-pinned and committed with a lockfile. The lockfile is the source of truth for builds so we get deterministic installs. This gives us a straightforward audit trail when reviewing changes.
We do not run postinstall scripts. This prevents packages from executing arbitrary code during installation.
Slow, deliberate upgrades
When we do dependency updates, we:
- Read the dependency’s changelog line-by-line.
- Check sub-dependencies introduced by the new version.
- Diff upstream when the change set is large or risky.
- Run automated and manual tests across platforms and critical user paths.
- Commit the new lockfile only after these reviews pass.
In practice, we rarely update dependencies because they generally work and do not require frequent changes. When we do, we treat each change as if we were taking a new dependency.
Time is a buffer
We don’t rush upgrades. There is a delay between upgrading any dependency and pushing a release. That gap acts as an early-warning window: the community and security researchers often detect malicious versions quickly. By the time we’re ready to ship, the ecosystem has usually flagged any problematic releases.
No single measure can eliminate supply chain risk. But choosing fewer dependencies, shallow graphs, exact version pins, no postinstall, and a slow, review-heavy upgrade cadence together make Obsidian much less likely to be impacted, and give us a long window to detect problems before code reaches users.
If you’re curious about our broader approach to security, see our security page and past audits.