DEV Community: HOL (Hashgraph Online)

Trust Before Install: Why We Built Codex Plugin Scanner

Michael Kantor — Thu, 02 Apr 2026 03:06:11 +0000

Originally published at https://hol.org/blog/trust-before-install-why-we-built-codex-plugin-scanner

Codex plugins can do real work.

They can package skills, connect apps, expose MCP servers, and extend what Codex can access or automate. That makes them powerful. It also means they introduce a new trust surface.

A plugin is not just a manifest file. It can include remote endpoints, local commands, repository workflows, install metadata, marketplace metadata, and reusable skills that influence behavior. Runtime safeguards still matter, but they are only part of the story. Teams also need a way to evaluate plugin quality and risk before a plugin gets installed, shared, or listed publicly.

That is why we built Codex Plugin Scanner.

It is an open-source scanner for Codex plugins that checks security, publishability, MCP risk, workflow hygiene, and overall ecosystem readiness. The goal is simple: make it easier to understand whether a plugin is safe and well-structured before it spreads.

The problem

Most existing security tooling was not built for this ecosystem.

A linter can catch syntax issues. A secret scanner can catch some exposed credentials. A dependency scanner can point out vulnerable packages. Those tools are useful, but they do not answer the main questions plugin authors, reviewers, and registries actually have:

Is this plugin manifest valid and publishable?
Are its declared paths safe?
Does it point to risky MCP endpoints?
Does it normalize unsafe approval patterns?
Does it ship repository automation that introduces supply-chain risk?
Is it ready for listing in a broader plugin ecosystem?

That gap gets bigger as the ecosystem grows.

What Codex Plugin Scanner does

Codex Plugin Scanner was built specifically for Codex plugins. It scores the applicable plugin surface from 0 to 100, produces structured findings, and helps maintainers catch issues before release.

The scanner evaluates plugins across several categories:

1. Manifest validation

It checks whether the plugin manifest exists, parses correctly, includes required fields, uses semantic versioning, and contains the metadata needed for distribution.

It also validates interface metadata, verifies assets and links, and checks that referenced paths stay inside the repository.

2. Security

It looks for common security problems such as:

hardcoded secrets
dangerous MCP command patterns
insecure remote MCP transports
approval bypass defaults
shell injection patterns
unsafe dynamic execution patterns like eval()

3. Operational security

This is one of the most useful parts of the scanner.

A plugin does not just ship code. It often ships automation. The scanner checks GitHub workflows for issues like:

third-party actions that are not pinned to full SHAs
overly broad workflow permissions
unsafe checkout patterns
missing dependency update automation
missing lockfiles or weak dependency pinning

That helps teams catch supply-chain issues that are easy to miss in a basic plugin review.

4. Best practices

The scanner also checks for project hygiene, including:

README.md
LICENSE
SECURITY.md
.codexignore
committed .env files
missing skills directories
malformed SKILL.md frontmatter

5. Marketplace and ecosystem readiness

If a plugin includes marketplace metadata, the scanner validates that too. This makes it easier to assess whether a plugin is ready to be listed, shared, or ingested into registries and discovery surfaces.

6. Skill security

When skills are present, the scanner can perform deeper analysis. It also supports optional Cisco-backed skill analysis for teams that want an additional review layer.

Why the scoring model matters

We did not want a score that was noisy or misleading.

A lot of scanners treat every possible surface as mandatory. That creates bad results. A small plugin gets penalized for not shipping marketplace metadata. A simple skills package gets scored as incomplete because it does not expose MCP configuration.

That does not reflect reality.

Codex Plugin Scanner only scores the surfaces that actually apply to the plugin being scanned. If a plugin does not include .mcp.json, it is not penalized for that. If it does not use marketplace metadata, those checks are not counted against it.

That makes the final score much more useful across different plugin types.

Built for real workflows

The scanner is designed to fit into the workflows teams already use.

You can run it locally during development, wire it into CI, use it in pre-commit, or export results into GitHub code scanning.

It supports multiple output formats, including:

text
JSON
Markdown
SARIF

A typical run looks like this:

pip install codex-plugin-scanner
codex-plugin-scanner ./my-plugin \
  --format sarif \
  --output codex-plugin-scanner.sarif \
  --fail-on-severity high

That makes it straightforward to use as a local quality gate or as part of an automated release process.

More than a scanner

One thing we cared about from the start was making the output useful beyond a terminal window.

The GitHub Action can export a machine-readable payload with metadata such as plugin name, description, score, grade, severity counts, source repository, source SHA, scanner version, and timestamp.

That opens the door to things like:

plugin registry ingestion
automated badges
awesome-list submissions
ecosystem dashboards
CI trust gates

In other words, the scanner is not just for maintainers. It can also become part of the broader trust infrastructure around the plugin ecosystem.

What this means for the ecosystem

We think the Codex plugin ecosystem needs a trust layer.

As more people build and publish plugins, the challenge is no longer just creating functionality. It is helping users and reviewers understand what they are installing and whether it meets a reasonable standard for safety and quality.

That does not mean one score should replace human judgment. It should not.

What it should do is make the obvious problems easier to catch, make reviews more consistent, and give teams a common baseline for plugin quality.

That is the role Codex Plugin Scanner is meant to play.

Why we built it

We built Codex Plugin Scanner because trust should not be an afterthought.

If plugins are going to become a serious part of how developers and teams extend Codex, then the ecosystem needs tooling that is built for that exact surface area. Not generic security theater. Not a checklist copied from somewhere else. Something purpose-built.

That is what this project is.

It is an open-source scanner for a new plugin ecosystem that needs better safety, clearer standards, and better distribution hygiene from day one.

Get involved

If you are building Codex plugins, maintaining a registry, or thinking about trust and distribution in this ecosystem, take a look at the project and try it on your own repositories.

Repo: https://github.com/hashgraph-online/codex-plugin-scanner

We think the ecosystem will be healthier if plugin quality is easier to measure, easier to improve, and easier to trust.

Building a Decentralized Registry in Go with HCS-2 on Hedera

Michael Kantor — Sat, 28 Feb 2026 00:00:00 +0000

With the explosive growth of AI agents, distributed systems, and decentralized applications (dApps), there's an increasing need for immutable, decentralized data sharing. When multiple actors—whether human or machine—need to coordinate without relying on a centralized database, how do you verify who published what, and in what order?

Enter the Hedera Consensus Service (HCS).

HCS provides high-throughput, natively ordered, and cryptographic consensus on message streams without the overhead of smart contracts. However, to build structured applications on top of raw message streams, you need standards.

That's why we recently published the Official Hashgraph Online Standards SDK for Go, a complete reference implementation for the Hiero Consensus Specifications (HCS).

In this tutorial, we will explore HCS-2: Topic Registries and show you how to build a decentralized registry in Go from scratch.

Why Go?Direct link to Why Go?

Go (Golang) is uniquely positioned for decentralized systems. Its native concurrency model (goroutines), fast compilation, and strongly typed ecosystem make it the language of choice for building robust infrastructure like the Hedera Mirror Node, Hyperledger Fabric, and countless Web3 indexers.

By releasing a dedicated Go SDK for HCS, we are providing Go developers with a first-class, typed, and idiomatic path to interacting with decentralized standards on the Hedera public ledger.

What is an HCS-2 Topic Registry?Direct link to What is an HCS-2 Topic Registry?

The HCS-2 Specification defines a standard for creating append-only, verifiable data registries on Hedera.

At its core, a registry is a Hedera topic where messages conform to a specific JSON schema. HCS-2 supports two types of registries:

Append-Only : A continuous stream of events or records.
Indexed : A key-value store where later entries can "overwrite" or update the state of previous keys using deterministic indexing.

This is perfect for use cases like:

AI Agent identity directories
Decentralized package managers
Supply chain provenance logs
Certificate revocation lists

Let's write some code to see this in action.

PrerequisitesDirect link to Prerequisites

Before we begin, you'll need:

Go 1.22 or higher installed.
A Hedera Testnet account (Account ID and Private Key). You can get one from the Hedera Developer Portal.

Create a new directory for your project and initialize a Go module:

mkdir go-registry-democd go-registry-demogo mod init go-registry-demo

Next, install the Standards SDK for Go:

go get github.com/hashgraph-online/standards-sdk-go@latest

Set your environment variables (or place them in a .env file):

export HEDERA_ACCOUNT_ID="0.0.xxxxx"export HEDERA_PRIVATE_KEY="302..."export HEDERA_NETWORK="testnet"

Step 1: Initialize the HCS-2 ClientDirect link to Step 1: Initialize the HCS-2 Client

First, let's create our main Go file and initialize the hcs2 client. The SDK provides a clean configuration pattern for setting up the client.

package mainimport (    "context"   "fmt"   "log"   "os"    "github.com/hashgraph-online/standards-sdk-go/pkg/hcs2")func main() {   ctx := context.Background() // Initialize the HCS-2 Client  // Notice we can pull configuration directly from the environment   client, err := hcs2.NewClient(hcs2.ClientConfig{ OperatorAccountID: os.Getenv("HEDERA_ACCOUNT_ID"), OperatorPrivateKey: os.Getenv("HEDERA_PRIVATE_KEY"), Network: "testnet", // Explicitly use testnet  })  if err != nil { log.Fatalf("Failed to initialize HCS-2 client: %v", err)    }   fmt.Println("Successfully initialized HCS-2 Client!")}

Step 2: Creating an Indexed RegistryDirect link to Step 2: Creating an Indexed Registry

Now, let's create a new decentralized registry. We will create an Indexed registry, which functions like a global, immutable key-value store.

When you create a registry using the SDK, it communicates directly with the Hedera network to allocate a new cryptographic Consensus Topic and formats the topic memo according to the HCS-2 specification.

Append this to your main.go:

    // ... previous code ...    fmt.Println("Creating a new HCS-2 Indexed Registry...") // Create the registry  result, err := client.CreateRegistry(ctx, hcs2.CreateRegistryOptions{ RegistryType: hcs2.RegistryTypeIndexed, UseOperatorAsAdmin: true, // We retain administrative control UseOperatorAsSubmit: true, // We must sign future entries   })  if err != nil { log.Fatalf("Failed to create registry: %v", err)    }   topicID := result.TopicID.String()  fmt.Printf("✅ Registry created successfully!\nTopic ID: %s\n", topicID)

Step 3: Writing Data to the RegistryDirect link to Step 3: Writing Data to the Registry

With our topic ID in hand, we can now publish structured entries to the registry.

In an Indexed registry, updating the state of a specific item is as simple as publishing a new message with the same Index (key). The SDK automatically constructs the correct JSON payload and signs it.

    // ... previous code ...    // Let's define the data we want to register    // We'll register two physical IoT devices  entries := []struct { Index string Data map[string]any  }{ { Index: "device-001", Data: map[string]any{"type": "sensor", "status": "active"}, }, { Index: "device-002", Data: map[string]any{"type": "actuator", "status": "offline"}, },   }   for _, entry := range entries { fmt.Printf("Registering %s...\n", entry.Index) publishResult, err := client.PublishIndexedEntry(ctx, hcs2.PublishIndexedEntryOptions{ TopicID: topicID, Index: entry.Index, Data: entry.Data, }) if err != nil { log.Fatalf("Failed to publish entry: %v", err) } fmt.Printf("Published entry securely at Sequence #%d\n", publishResult.SequenceNumber)    }

Step 4: Reading the Decentralized StateDirect link to Step 4: Reading the Decentralized State

Writing is only half the battle. How do we retrieve the state of our registry?

Because HCS topics are public, anyone (not just you) can read the state of this registry using a Hedera Mirror Node. The SDK provides built-in methods to query the mirror node, parse the messages, and reconstruct the final "state" of the key-value store.

    // ... previous code ...    fmt.Println("Fetching current registry state from Hedera Mirror Node...")   // Fetch all valid entries for our topic    state, err := client.GetIndexedRegistryState(ctx, topicID)  if err != nil { log.Fatalf("Failed to fetch state: %v", err)    }   fmt.Println("\n--- Current Registry State ---") for key, value := range state { fmt.Printf("Key [%s]: %v\n", key, value)    }}

If you ever published a new message for device-001 saying "status": "maintenance", the GetIndexedRegistryState function would automatically resolve the history and return the most recent valid state for that key.

Under the HoodDirect link to Under the Hood

When you use the standards-sdk-go, you are interacting with the Hedera network through strongly typed, validated interfaces.

But what's actually happening?

Deterministic Memos : The CreateRegistry call automatically formats the memo of the Hedera topic to hcs-2;indexed, signaling to the rest of the ecosystem how to interpret the messages.
Schema Enforcement : The SDK ensures that messages submitted to the topic strictly adhere to the HCS-2 JSON schema.
Consensus Targeting : Messages are delivered instantly across the globe with fair-ordering consensus applied by the Hedera validators.

Next StepsDirect link to Next Steps

We've barely scratched the surface of what the Standards SDK can do. From this foundation, you can dive into more advanced protocols:

HCS-14 (Universal Agent IDs): Resolve AI identities.
Registry Broker : Use the pkg/registrybroker to interact directly with the global Hashgraph Online Registry Broker.

Ready to start building?

👉 Dive into the SDK Documentation or star the standards-sdk-go repository on GitHub to stay updated on the latest Go ecosystem releases!