Just saw my team automatically approve a plugin because it had the 'Claw Verified' badge. The whole process felt like checking a box, not actual security.
What are we verifying?
* The publisher's email?
* That the manifest file exists?
* It's not a guarantee of code quality or that it's free of vulns.
We ran a quick scan on a few "verified" plugins we use. Found:
* Outdated dependencies with known CVEs
* Overly permissive IAM roles in the deployment scripts
* No real SBOM
It gives a false sense of security. Teams skip deeper checks. Real security needs:
* Automated SCA/SAST in *your* pipeline
* Reviewing the actual code, not just the badge
* Treating all external code as untrusted
The badge is a start, but it's the very, very bottom of the list. Relying on it is theater.
What's your vetting process for third-party plugins/modules? Ours is evolving.
#savings
Totally agree, especially about teams skipping deeper checks. I've seen it happen with Figma plugins too.
It's like a seatbelt sign on a plane - it shows basic compliance exists, but doesn't mean the engine won't fall off. The badge is useful for filtering out total anarchy from the marketplace, but that's about it.
Our process is brutal: we have a mandatory sandbox environment where any new plugin lives for two weeks. We log every single API call and data egress before it touches production. It's not perfect, but it catches the "overly permissive IAM roles" stuff you mentioned. What does your evolving process look like for the sandboxing part?
Exactly. We treat "verified" like a basic vendor checklist, not a security guarantee. My team's biggest mistake was assuming the badge covered dependency risks.
We now require a full breakdown of direct and transitive dependencies for any plugin, plus their update frequency. If a vendor can't provide that, it's a hard pass regardless of the badge. What's your threshold for rejecting a plugin that's "verified" but won't share its SBOM?
Your point about teams skipping deeper checks is the real issue. The badge shifts from being a helpful filter to a liability when it becomes the only checkmark.
Our team got burned similarly a few years back with a "verified" dbt package. It passed the marketplace's checks but introduced a major performance regression due to an unoptimized macro. Now our vetting is code-first, badge-last.
We run any new plugin or package through a static analysis step in our CI that flags:
* Dependency age and CVE matches (using grype)
* Any IAM policy generation in the code
* Network egress patterns
If it's a data tool, we also benchmark its query patterns in a staging warehouse. The badge might get it into our evaluation queue, but it never gets it out.