Obsidian vaults accumulate plugins the way home labs accumulate Raspberry Pis. One comes from a Reddit thread, another from a YouTube tutorial, and eighteen months later you have a dozen community plugins installed and no idea which of them still have maintainers — or what any of them can actually reach inside your vault.
Since May, Obsidian has been quietly fixing the information half of that problem. Every plugin version that lands in the community directory now gets an automated scan, and the results are published as a safety scorecard on the Obsidian Community site — the same catalog as the in-app browser, but with the receipts attached. A piece over on XDA, “Obsidian launched safety scorecards for every plugin, and checking mine changed what I keep installed”, is what finally pushed me to run the audit on my own vaults. Here’s the short version of what the scorecards say, and how to act on them without losing an evening to tab-hopping.
What the scorecard actually measures
Each plugin page on the Community site has a Scorecard tab, and the sidebar boils it down to two bars:
- Health — is anyone still looking after this? It pulls recent commit activity and install counts. A plugin with a commit five days ago and 97,000 installs is alive; a plugin whose last release predates your current laptop is a maintenance risk regardless of how well it scans.
- Review — does the code scan clean? Dependency vulnerabilities, suspicious patterns like base64 blobs, and — the part I care about most — whether the published build can be reproduced byte-for-byte from the public source repository.
Below the bars sit Disclosures: what the plugin can reach. This is where you learn that your drawing plugin reads the system clipboard and can see every file path in the vault. Usually that’s not malice — some feature needs it — but it’s a fair bet nobody ever asked you about it. Every scorecard also carries a work-in-progress banner, which is honest: treat the whole thing as evidence, not a verdict.
Read it like a pipeline, not a rating
If you run CI for a living, none of this is conceptually new. Health is your bus-factor signal. Review is dependency scanning plus build provenance — the same “can I rebuild what I shipped?” question that SLSA-style attestations ask. Disclosures are permissions, the blast radius. Read a plugin page the way you’d read a green check on a pull request: it means the checks ran, not that the code loves you.
Two specifics worth internalizing before you panic:
- “Malware scan not available” is not a red flag. It shows up on big, boring plugins like Dataview and Templater too. It means there is no result to display — absence of evidence, not evidence of absence.
- A reproducible build is the strongest signal on the page. If Obsidian could rebuild the plugin from source and get a file identical to the one you installed, then what’s sitting in your vault is code anyone can read. That beats every heuristic.
The audit, in twenty minutes
- Open Settings → Community plugins and write down everything installed — including the disabled ones. The disabled ones are where the deletions come from.
- Look each plugin up on the Community site and check three things: the Review bar, the Disclosures, and the last commit date.
- Apply three rules:
- Reproducible build plus live maintenance → keep, carry on.
- Health and Review disagree → investigate or drop. A healthy-looking plugin that fails review, or whose description still references a model from three years ago, is a fossil with good PR.
- Disabled for more than a few months → uninstall. Reinstalling takes thirty seconds. This boring rule improves your vault’s security more than any scanner ever will.
The October 30 cutoff the app never mentions
There’s a deadline attached to all this that Obsidian doesn’t surface in the app at all: scorecard results on existing plugins are informational-only until October 30, 2026. After that, a plugin whose latest release fails review — actual errors, not a mere “caution” rating — gets pulled from the directory and can no longer be installed from the app.
If one of your workhorses is on the wrong side of that line, you have three moves, in order of preference: check the plugin’s repository, since most failures will be build issues a maintainer is already patching; back up the plugin folder from .obsidian/plugins/ so a reinstall stays possible even if it’s delisted; or go find the replacement now, on your own schedule, rather than mid-project.
Why this matters more for work vaults
A personal vault leaking clipboard contents is annoying. A small-business vault holding client notes, meeting records, and the odd pasted credential is a different asset class entirely. Plugins are third-party code with filesystem access to all of it, and “it was fine when I installed it in 2023” is not a control — that’s a hope with a version number. Moving from one-time hand review of the first submission to automated scans of every version is the biggest security improvement the Obsidian ecosystem has made. But scorecards only work if somebody reads them.
Twenty minutes, once a quarter, with a delete-first bias. That’s the entire practice.