I use Obsidian every day. My vault has years of notes, journals, project files, and personal writing in it. It’s one of the few apps I trust with that kind of data. So when I started installing community plugins, I noticed something that bothered me.
Plugins run with the same permissions as the Obsidian app itself — which means full read and write access to your vault, the ability to make network requests to any server, and in some cases the ability to execute shell commands on your machine.
So I built OPA. It clones the plugin’s source code, runs static analysis across eight security categories, checks the dependency tree for known CVEs, and produces a scored report. And its all done on a remote system, not your computer.
I wanted something that could give me a quick, consistent read on what a plugin is actually doing — not a guarantee, but enough signal to make a more informed decision. Something I could run before installing a plugin I’d never heard of, or before updating one that had been sitting in my vault for a year.
I want to be clear about what OPA is and isn’t. It’s a static analysis tool, not a security guarantee. A plugin can score 100/100 and still do something unexpected at runtime. Obfuscated or dynamically generated code can slip past static checks. A score is a signal, not a verdict.
What it does do is surface the obvious stuff quickly — shell execution, network calls to unknown servers, direct filesystem access outside the vault, known vulnerable dependencies. The things that, if I knew about them, would make me think twice. That’s all I was looking for when I started building it, and that’s still what it does.
If you’re a plugin developer, I hope this is useful rather than threatening. A clean audit report is a good thing to be able to point to. And if something is flagged incorrectly, the findings are specific enough that you can understand exactly what triggered them.
You can find the OPA tool here: https://obsidianpluginaudit.com/
Watch the video demo:
