> Obsidian has a low number of dependencies compared to other apps in our category
Whataboutism. Relative comparisons don't address absolute risk. I checked three random packages: prism pulls 22, remark pulls 51, pixijs 179! So that's 250+ transitive dependencies just from those.
> 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.
Full control? There are still hundreds of dependencies.
> This approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through.
Really? Again, this is just one package: https://npmgraph.js.org/?q=pixijs
> The other packages help us build the app and never ship to users, e.g. esbuild or eslint.
Build tools like esbuild don't ship to users, but a compromised build tool can still inject malicious code during compilation. This is supply chain security 101.
> All dependencies are strictly version-pinned and committed with a lockfile
Version pinning is, I would hope, standard practice in any professional development team years and years ago. It prevents accidental updates but doesn't stop compromised existing versions.
> When we do dependency updates, we:
> [snip]
While these practices are better than nothing, they don't fundamentally address the core issue.
> That gap acts as an early-warning window: the community and security researchers often detect malicious versions quickly
According to whom? Heartbleed, a vulnerability in a package with far more scrutiny than a typical npm module took what, 2 years to be found? The "community detection" assumption is flawed.
I'm not trying to put Obsidian down here - I sympathize, aside from implementing everything themselves, what can they do! I'm trying to point out that while their intent is good, this is a serious problem and their solution is not a solution.
Of course, it's the same in any project with dependencies. It's the same in other languages as well - if they have a convenient package manager. Like Rust and Cargo.
This problem came with the convenience of package managers and it should be fixed there, not by every application like Obsidian. I'm not sure how but maybe once a package is starting to become popular, additional security measures must be put in place for the author to be able to continue to commit to it. Signing requirements, reproducible builds, 2fa, community reputation systems, who knows.
Individual applications can't solve supply chain security through wishful thinking and version pinning.
Package managers need to solve this at the infrastructure level through measures like mandatory code signing, automated security auditing, dependency isolation, or similar system level approaches.
Obsidian's practices are reasonable given the current tooling limitations, but they don't eliminate the fundamental risks that the package managers bring to modern dependency ecosystems.