A verified publisher badge proves that someone controls a domain and has kept a clean record for a set period. It does not prove the plugin's code is safe, that the publisher's accounts are secure, or that the next update is harmless. Treat it as an identity signal, not a safety verdict.
What one marketplace says it checks
The Visual Studio Code documentation explains its blue check mark. The publisher has proven domain name ownership to the Marketplace. The Marketplace has also verified both the existence of the domain and the good standing of the publisher on the Marketplace for at least six months.
That is a meaningful bar. It makes impersonation harder and gives users a stable name to hold accountable. It also does not cover code quality, vulnerability handling or how the publisher protects its release credentials.
VS Code adds a second layer on the user side. Since release 1.97, when a user first installs an extension from a third-party publisher, a dialog asks them to confirm they trust the publisher. Trusting the publisher of an extension pack or an extension with dependencies also means trusting the publishers of the dependencies.
What a badge can and cannot tell a buyer
| Question | Badge answers it? |
|---|---|
| Is this the organization it claims to be? | Mostly, if domain verified |
| Has the publisher been around a while? | Yes, where a time rule exists |
| Is the code free of vulnerabilities? | No |
| Is the publisher's release pipeline secure? | No |
| Will the next update stay within current permissions? | No |
| Is the publisher still maintaining the plugin? | Not necessarily |
Designing your own publisher trust signals
If you run a plugin marketplace, one badge is not enough. Consider separate signals so users can read them separately.
- Identity. Domain ownership, a named legal entity, and a contact for security reports.
- Standing. Time in the marketplace and absence of policy violations.
- Build integrity. Whether releases are signed and, where the registry supports it, built from public source in a recorded pipeline.
- Responsiveness. Whether the publisher answers security reports within your stated window.
- Scope. The permissions requested, shown beside the badge so the two are never separated.
Atlassian's marketplace requirements show the responsiveness idea in practice: partners must name at least one security contact and meet stated timeframes for fixing vulnerabilities.
Stop badges from becoming a loophole
A badge creates a risk of its own: users stop looking. A verified publisher with an overbroad permission request deserves the same scrutiny as an unverified one. Show the permission summary first and the badge second.
Plan for revocation too. If a verified publisher's account is compromised, you need to remove the badge or block releases quickly. Pair the badge with a kill switch and with multi factor authentication requirements on publisher accounts.
Quick check
Should enterprises allow all plugins from verified publishers?
Not automatically. A publisher allowlist is a reasonable starting point, but it should be paired with permission review and version control for sensitive environments.
Can a verified publisher still ship a vulnerable plugin?
Yes. Verification covers identity and standing. Vulnerabilities in code or dependencies are a separate matter and need scanning and fast fixes.
Safeguard covers the dependency side that a badge cannot: SBOM and dependency scanning for the libraries inside a plugin, with policies that apply the same rules to every publisher. You can try it with the free scan.
Sources
Last reviewed: 19 October 2026.
