Security teams produce an enormous amount of work that engineers never see. Threat models, hardening guides, code-review checklists, runbooks, the right way to use the auth library, the wrong way to write a SQL query. Most of it lives in Confluence pages nobody opens, or Slack threads that scroll out of memory by Tuesday.

Engineers don’t read security docs. They never have. What they do read, increasingly, is whatever shows up inside their AI coding assistant.

That makes Claude Code plugin marketplaces an interesting opportunity for security teams: a way to put our work where engineers already are, instead of where we wish they’d come look for it.

The visibility problem

Security work is structurally invisible. A well-designed IAM model, a clean threat model, a thoughtful SDLC: none of these have a UI. Engineers experience them only through friction (a permission denied, a code review comment, a Jira ticket) or not at all.

The result: security teams that do excellent work get perceived as either bottlenecks or invisible. Both are bad for budget and influence. The teams that get budget and influence are the ones whose work shows up in the engineer’s daily flow as something useful, not something blocking.

A Claude Code marketplace is a distribution channel for that kind of work.

What you can actually distribute

The plugin format lets you bundle, into a single installable unit:

  • MCP servers the team should query (your SIEM, your secret scanner, your vuln scanner, your access-review tool)
  • Slash commands that codify the right way to do a thing (/threat-model, /iam-review, /check-deps)
  • Skills that the LLM consults when the engineer is writing certain types of code
  • Hooks that fire on relevant actions (about to commit a secret, about to merge a PR touching auth code)
  • Settings that wire up the right defaults

Each of these is something a security team already produces in some form. The marketplace just makes it installable in 10 seconds and live inside the engineer’s editor.

Segment by engineer type

The mistake to avoid: shipping one giant security plugin that has everything for everyone. Engineers won’t install something that adds 40 slash commands they don’t care about. They will install something that adds the 6 they need.

The pattern that works: one plugin per engineer type, plus one common plugin.

  • Frontend engineers get a plugin with XSS-aware code review prompts, CSP guidance, the right way to handle auth tokens in the browser, an MCP integration with your bug-bounty tool.
  • Backend engineers get a plugin with SQL-injection-aware code review, secret management guidance, the SDLC pre-commit hook, an MCP integration with your vuln scanner.
  • Data engineers get a plugin with PII-aware schema review, data classification rules, the data-export approval flow as a slash command.
  • Platform/infra engineers get a plugin with IaC scanning, IAM policy review, the cloud security baseline as a runbook.
  • Common plugin for everyone: incident-reporting slash command, “is this a security issue” assistant, the security team’s contact info, links to the right Confluence page when asked.

This segmentation respects that different engineers care about different threats, and reduces the install friction to “the one plugin that’s actually for me.”

Why this is worth trying

Three reasons.

One: the install is free. A plugin marketplace is a five-second add. Engineers will try things that cost five seconds and have a useful name. They will not read a 30-page security playbook.

Two: the value is immediate. A slash command that runs a threat model on the current diff returns a useful answer in seconds. Same with a hook that catches a secret before commit. The feedback loop is tight enough that engineers form positive associations with the security team.

Three: it’s measurable. You can instrument plugin usage. You’ll know which slash commands engineers actually run, which MCP queries they make, which hooks fire most. Real signal about where security tooling helps vs. where it just exists.

What to start with

If you’ve never shipped a security plugin marketplace and want to start, the minimum viable version is:

  • One common plugin with: an incident-reporting slash command, an MCP server for your secret scanner, and a hook that catches obvious leaked secrets pre-commit.
  • One engineer-type plugin (pick the largest cohort) with: a code-review slash command tuned to their domain, and an MCP server for the one tool they should be querying.

Ship that. Watch the install rate. Iterate.

It’s not a silver bullet, and it won’t replace the parts of security work that have to happen elsewhere. But for teams trying to escape the “invisible function” trap, it’s one of the more direct things to try.