{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiebgzejyvgk3gbgpyptqhvzklo3tp5q34jrgks2v2362aozq6ce5a",
    "uri": "at://did:plc:7ojgqtrhpkmgyhzgazqc6hiz/app.bsky.feed.post/3lz7ewwwjdbn2"
  },
  "path": "/blog/less-is-safer/",
  "publishedAt": "2026-04-30T09:30:03.400Z",
  "site": "https://obsidian.md",
  "tags": [
    "secure and private",
    "our Credits page",
    "Bases",
    "Canvas",
    "security page"
  ],
  "textContent": "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.\n\n### Less is safer\n\nIt 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.\n\nFeatures 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.\n\n  * **For small utility functions** we almost always re-implement them in our code.\n  * **For medium modules** we fork them and keep them inside our codebase if the licenses allows it.\n  * **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.\n\n\n\nThis approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through.\n\n### What actually ships in the app\n\nOnly 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.\n\n### Version pinning and lockfiles\n\nAll 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.\n\nWe do not run postinstall scripts. This prevents packages from executing arbitrary code during installation.\n\n### Slow, deliberate upgrades\n\nWhen we do dependency updates, we:\n\n  1. Read the dependency's changelog line-by-line.\n  2. Check sub-dependencies introduced by the new version.\n  3. Diff upstream when the change set is large or risky.\n  4. Run automated and manual tests across platforms and critical user paths.\n  5. Commit the new lockfile only after these reviews pass.\n\n\n\nIn 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.\n\n### Time is a buffer\n\nWe 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.\n\n* * *\n\nNo 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.\n\nIf you're curious about our broader approach to security, see our security page and past audits.",
  "title": "Less is safer: how Obsidian reduces the risk of supply chain attacks",
  "updatedAt": "2025-09-19T00:00:00.000Z"
}