Trust Is Not a Badge

As of August 25, 2026, Dify’s plugin ecosystem is large enough that trust can no longer be communicated with a badge and a reassuring adjective. A marketplace earns confidence through repeatable controls: what enters a package, what a plugin can reach, which version was examined, and what happens when evidence changes.

A Latin proverb advises, “Fide, sed cui vide”—trust, but consider whom you trust. It is a useful operating principle for an open plugin ecosystem: goodwill lowers the cost of collaboration; independent evidence keeps that goodwill scalable.

Our objective is not to promise zero risk. That would be mathematically ambitious and operationally suspicious. The objective is to make risk visible, testable, and actionable—before publication when possible, after publication when necessary, and again whenever a plugin version changes.

From my seat in Dify Developer Relations, this is also a community design problem. Contributors need fast, specific feedback; users need evidence they can interpret; reviewers need controls that reserve human attention for ambiguity instead of repetitive package archaeology.

Some controls are verifiable today in public repositories; others belong to an evolving Marketplace framework. Naming that boundary is governance too: trust declines quickly when a roadmap puts on a fake mustache and introduces itself as shipped.

First, Count the Right Thing

Good governance starts with an unglamorous question: what, exactly, are we counting? Our Marketplace snapshot from July 31, 2026 produces several legitimate numbers, but they describe different populations and operating realities.

Two precise numbers can still answer two entirely different questions. The 263 figure describes labeling in a Marketplace snapshot; 99 describes the operational baseline that reviewers reported as actively maintained. Treating one as proof of the other would be neat, convenient, and wrong.

The same discipline applies to installs and invocations. Installation records show distribution, while invocations show observed use during a defined window; neither alone measures reliability, business value, or maintenance health.

The invocation analysis covers July 13 through August 12, 2026. Its absolute counts may be underreported by roughly two to five times because some pod identity is missing and counters can reset, so we use it for relative trends, share, and ranking—not for theatrical claims about exact volume.

Richard Feynman stated the relevant control more elegantly: “The first principle is that you must not fool yourself—and you are the easiest person to fool.” In practice, that means publishing snapshot dates, definitions, and limitations next to the numbers. A metric without a denominator is often just a confident-looking anecdote.

The Risk Is Already Inside the Package

The most immediate risks are not theoretical. We have observed .difypkg archives containing .env files, .git metadata that may expose credentials, entire virtual environments, .DS_Store, __pycache__, logs, and platform-specific binaries. Some are harmless residue; others can reveal secrets, obscure executable behavior, or increase the attack surface after extraction.

A plugin package should contain a plugin, not the author’s entire laptop autobiography. The joke is deliberately light; the consequence is not. When a plugin is installed, its bundled files are unpacked into the corresponding Dify plugin runtime and may become accessible to the plugin process during execution. Package hygiene is therefore a supply-chain control rather than an aesthetic preference.

Other developer ecosystems provide useful evidence. The GlassWorm campaign compromised multiple extensions distributed through OpenVSX and the VS Code Marketplace, with Koi Security reporting a total impact of 35,800 installations. The technique matters more than the brand name: familiar distribution channels can amplify malicious code when identity, package contents, and behavior are insufficiently examined.

Speed also matters. A fake Prettier Plus extension was removed within four hours, after only six downloads and three installs. That is a small blast radius precisely because detection and response arrived early; “not widely installed” is the result we want, not evidence that the control was unnecessary.

After a phishing-driven takeover of an authorized developer’s npm account, three malicious versions of the LottieFiles npm package were published before the company released a clean version and worked with npm and CDN providers to remove the affected releases. The lesson is consistent across ecosystems: reputation helps discovery, but it cannot substitute for version-level verification, credential security, and a response process that can restrict distribution quickly.

Accidental pollution and deliberate abuse require different judgments, but share a first defense: inspect the artifact, disclose sensitive behavior, record the evidence, and preserve the ability to intervene.

A Trust Pipeline, Not a Security Checkbox

Dify’s public implementation now forms a layered pipeline. Developers can run the Dify Marketplace Toolkit locally before opening a pull request; the contribution template then records the author, plugin, version, source repository, contact information, one risk level, and relevant privacy or security disclosures. Moving feedback left is not bureaucracy—it is cheaper debugging.

Local validation covers safe archive extraction, package contents, secret patterns, binaries, manifest fields including source, contact, and privacy information, README quality, dependencies with OSV vulnerability checks, Python compilation and safety patterns, and warnings for prohibited financial activity. It also inspects observed access domains and supports optional network.domains declarations, which matter because dynamically constructed SDK URLs can evade static analysis.

In the public dify-plugins workflows, pr-risk-label.yaml, pre-check-plugin.yaml, pre-check-plugin-sandbox.yaml, and upload-merged-plugin.yaml provide risk labeling, automated checks, sandbox-oriented validation, and post-merge upload controls. CI separates blocking errors from warnings, and the package is revalidated after merge before upload. Automation augments reviewers; it does not acquire judgment merely because the YAML is green.

That separation is intentional. Blocking findings stop publication when evidence crosses a defined line; warnings surface context that may be legitimate but still deserves review. Conflating the two would either normalize dangerous packages or turn every unusual implementation into a small constitutional crisis.

After upload, the toolkit supports submitting a scan report used by the Access Domain and Security blocks. That is an important implementation path, but it should not be confused with a claim that every planned Marketplace surface is already broadly available. Security grades, rating presentation, and feedback mechanics remain part of an evolving framework.

Evolving current-version security grade semantics

The model evaluates only the current version and requires a rescan after every upgrade; an old grade should never follow new code by inertia. Official, Partner, or Verified status can support a decision, but cannot replace artifact evidence. Confirmed malicious behavior or a serious security issue bypasses ordinary grading and moves directly to restriction, removal, or manual review.

Make the rating legible at a glance

The evolving Security details design makes the grade visible before the prose is read. The badge sits at the upper right: S is green; C is red and adds a prominent pre-installation warning.

The dependency list repeats that hierarchy. Each package shows its version and a green or red marker, exposing affected dependencies quickly. Color accelerates recognition; grade, warning text, package name, and version preserve accessibility and auditability.

Figure 1 — S means “clear”; C means “review.” Neither is a guarantee.

PRD state C — visible warning and affected versions.

PRD state S — clear evidence and no warning.

Figure 2 — Eight controls build version-scoped evidence.

Figure 3 — CI blocks failures and routes warnings to review.

Transparency Is a Control

Transparency is most useful before enablement, when a user can still make an informed choice. In practice, a plugin can operate in three materially different ways:

1. Local-only execution. The plugin runs as code in the local runtime and does not phone home or send data to an external service.
2. Customer-connected service. The customer supplies an API key or account and directly chooses to engage the external provider through the plugin.
3. Dify-connected service. Dify supplies credentials or exposes a unified, hosted third-party capability as part of the product experience.

Those are not cosmetic labels. Different facts create different governance, contracting, and responsibility patterns. The analysis may change by deployment and data flow, so this is a product-governance framework, not legal advice.

“Sunlight is said to be the best of disinfectants.” — Louis D. Brandeis

For plugin users, sunlight means concrete information. Before enablement, they should be able to see the external domains and services involved, along with the categories of data that may leave their environment: prompts, outputs, files, account or workspace data, metadata, logs, and credentials. An unlisted endpoint does not become harmless because it is shy.

Useful disclosure also explains why the data is processed; where it is stored or handled; how long it is retained; whether it may be used for model training or product improvement; and which privacy notice, DPA, or service terms apply. Customer confirmation and a visible history of material changes turn that information into an operational control rather than ceremonial prose.

Whatever the contract role, Dify still owns its part of the system: runtime isolation, transport security, enforceable declarations, review, and action when behavior diverges from disclosure. The analysis may vary; the duty to design responsibly does not.

Licenses Are Part of the Supply Chain

A plugin marketplace also distributes permissions. The practical chain is simple to state and easy to neglect: the author must have permission to provide the plugin to Dify, Dify must have permission to host and distribute it, and the user must receive sufficient permission to install and use it. If any link is unclear, a technically clean package can still carry a governance defect.

Open-source software travels through every step of that chain. Its notices, attribution requirements, source-availability duties, modification terms, and redistribution conditions do not disappear inside a convenient package format. Licenses, like gravity, remain operational whether or not the release checklist mentions them.

A mature governance design therefore needs visible license declarations, discoverable OSS components, checks for copyleft and AGPL-sensitive obligations, and a way to surface required source, notices, or license text. It also needs a clear relationship between developer terms and any license or EULA passed through to the user. These controls help reviewers ask the right questions; they do not convert an automated label into legal advice.

Some implementation choices remain evolving design considerations. A dedicated manifest license field, license allow or deny lists, AGPL-specific SaaS routing, a standard EULA, and click-through acceptance could all improve consistency, but I would not describe them as shipped unless the product and repository evidence support that claim. In governance, future tense is a useful security feature.

Maintenance Is Governance

Security review answers whether a version can enter the ecosystem. Maintenance governance answers what happens after it does. To make that question tractable, we analyze plugins in four cohorts: Official Model, Official non-model, Community Model, and Community non-model. Comparing within cohorts keeps a specialized model provider from being judged by the same demand curve as a general-purpose utility.

To keep that prioritization transparent, the demand index combines 60% invocation percentile and 40% install percentile within each cohort. We pair it with a criticality score from 1 to 5, because popularity and operational importance are related but not identical. A rarely invoked authentication or data connector can still deserve serious attention.

Figure 4 — Demand, criticality, and freshness set maintenance priority.

Here, P0, P1, and P2 are maintenance priorities, not project-delivery phases. Freshness adds another signal: Fresh means updated within 30 days, Maintained means 31–90 days, and Older means more than 90 days. Estimated recurring effort is grouped as S at 1–2, M at 3–5, and L at 6–10 person-days per quarter.

That effort model matters because maintenance is constrained by capacity, not optimism. Scenarios of 30, 60, or 120 person-days per quarter are planning envelopes, not service-level agreements. A maintenance plan without capacity is a wish wearing a spreadsheet.

Official ownership should concentrate on funded P0 and P1 work. For community plugins, the ladder is adopt → co-maintain → sponsor or monitor, chosen according to demand, criticality, maintainer health, and strategic fit. The remaining P2 and Watch set should stay community-led, supported by lightweight validation and clear escalation paths, without an implied recurring Official SLO.

This is not a verdict on quality or authorship. It is a reproducible allocation of finite attention, refreshed as usage, freshness, and ecosystem needs change. Governance that cannot revise priorities is merely historical documentation with excellent posture.

The Trade-offs We Choose Deliberately

Governance becomes credible when it names the trade-offs instead of pretending they have disappeared.

Contributor friction versus safety. Every check adds work somewhere. Local validation moves that work earlier, where an author can fix a package before opening a PR, instead of discovering the issue after a reviewer and three CI jobs have already formed a committee around it.

Automation versus false positives. Deterministic failures should block; ambiguous signals should begin as warnings. Shadow mode, measured false-positive rates, documented exceptions, and gradual tightening let a rule earn enforcement authority rather than receive it by enthusiasm.

Transparency versus false assurance. A security grade or domain list represents version-specific evidence available at a point in time. It is not a warranty, and a new release should not inherit an old result by family resemblance. Rescanning and visible status changes are essential because stale confidence is still stale.

Official focus versus community autonomy. Dify should provide enforceable guardrails, reliable tooling, and a clear path for escalation while preserving room for independent experimentation. The objective is a healthy commons, not a walled garden with unusually thorough CI.

My preferred operating principle is straightforward: make the safe path easy, make material behavior visible, and make enforcement proportionate to evidence. When the evidence changes, the decision should be able to change with it.

Trust is not created by one review, one badge, or one policy launch. It is produced continuously by verification, transparent product signals, maintainable ownership, and a fair response process. That is why trust is a feature—and why, like every serious feature, it needs tests, operators, and another release.

If you build plugins for Dify, review the submission requirements and run the Marketplace Toolkit before opening a PR. For implementation guidance, start with Dify’s official plugin documentation.

Sources and Method

This article combines four evidence layers: a Marketplace inventory snapshot dated July 31, 2026; SaaS invocation data from July 13 to August 12, 2026; Dify's internal governance and maintenance-design documents; and public implementation evidence checked on August 25, 2026. Snapshot numbers are not live counters, and invocation totals are used for relative prioritization rather than absolute-volume claims.

This article describes governance design and engineering practice. It is not legal advice, a certification, or a promise that any plugin is risk-free.