Forty-four plugins turn security methods into agent procedures
The marketplace manifest at commit 123037e lists 44 plugins. Most target work that benefits from a fixed sequence: map a codebase before hunting bugs, inspect state-changing contract entry points, verify a suspected false positive, compare code with a specification, or search for variants of a known flaw. Others wrap concrete tools such as Semgrep, CodeQL, YARA, Burp project parsing, SARIF, fuzzers, and compiler output. The catalog reads like a security team's internal playbook made installable.
That specificity is the appeal. A general coding assistant can ask sensible security questions, but these plugins tell it which artifacts to gather, which shortcuts to reject, and where to stop for review. The repository's authoring guide requires security skills to name dangerous rationalizations and match prescriptiveness to risk. None of that guarantees a correct finding. It gives the agent a repeatable route and gives a reviewer a better record of how it reached the result.
One marketplace serves Claude Code, Codex, and ChatGPT workspaces
Claude Code installs the repository as a plugin marketplace, then lets the user choose plugins from its menu. Codex reads the same Claude marketplace metadata, so the maintainers explicitly reject duplicate Codex sidecar files that could drift. ChatGPT workspace imports use .claude-plugin/marketplace.json; skills with agents/openai.yaml also need display-name and short-description fields. commit 123037e, pushed September 16, 2026, fixed that interface metadata and tightened the corresponding validation.
The support statement has edges. The root README documents those 3 destinations, while issue 8 asks about Cursor compatibility and issue 12 asks for Gemini CLI instructions. Many plugins invoke host tools, hooks, or namespaced subagents, so copying a SKILL.md into another client does not prove the complete plugin works there. If your client is absent from the installation section, test component discovery and every tool call before trusting an audit workflow.
What happened when we ran it
Our sandbox identified plugins/constant-time-analysis/ as the runnable Python project. Installing it took 19 seconds, added 36 packages, and used 37 MB on disk. The wheel build succeeded in 1 second. Pip-audit reported 0 known vulnerabilities in that installed environment. These figures describe one plugin at commit 123037e, not the dependencies or runtime cost of all 44 marketplace entries.
The scoped project exposed no test script or target, so our harness skipped tests. It would be wrong to convert that result into a pass or a failure. The full repository documents a separate make check route, but that was outside the supplied lab run. Our checkout contained 1,441 files, about 92,367 lines of source, and occupied 8.7 MB. The repository had 3 CI workflow files, no Dockerfile, and no repository-level tests directory in the harness signal.
Constant-time analysis covers 7 architectures and many runtimes
The measured plugin includes ct-analyzer, a Python 3.10+ command that inspects compiled assembly or runtime bytecode for operations whose timing may depend on secrets. Its README names 7 architecture targets and compiler paths for GCC, Clang, Go, Rust, and Swift. It also documents bytecode inspection for JVM languages, C#, PHP, JavaScript, TypeScript, Python, and Ruby. JSON and GitHub annotation output make the command usable in CI.
Results still need interpretation. Integer division and selected floating-point instructions are errors, while conditional branches are warnings because their risk depends on whether the condition carries secret data. The Claude plugin adds language references and triage guidance around the command. System requirements vary by target: TypeScript needs a compiler, PHP's preferred path uses VLD, and compiled languages need their compiler or cross-compiler. The 37 MB Python install does not include that whole external toolchain.
The full check needs 5 host tools and still omits CI-only work
The contribution guide says make check needs uv, shellcheck, shfmt, bats, and Node on the path. It runs metadata validators, formatting and shell checks, plugin Python suites, JavaScript tests, and validator self-tests. Two loadability checks stay in CI because they require Claude Code and Codex. Review-walkthrough browser checks need Chrome or Chromium, and a version-increment rule needs a pull-request base reference. A local green check is useful evidence with stated omissions.
Open reports show why plugin-level testing matters. Issue 298 says the static-analysis skill silently omits files larger than 1 MB under Semgrep's default, while issue 299 identifies a recommended ruleset URL that returns 404. Issue 289 reports that CRLF conversion breaks packaged workflows on Windows and that an fp-check stop hook can deadlock a session. These reports concern named plugins and conditions; they do not establish that every plugin shares the fault.
September activity matters more than the missing release page
GitHub showed 7,127 stars, 26 combined open issues and pull requests, and a last push on September 16, 2026. Pull request 311 was active on September 17. The latest-release endpoint returned no release, but current commits and issue activity show that work is continuing. Plugin versions live in the marketplace and individual manifests, and the contribution rules require a version bump when a plugin changes so clients can receive it.
The repository uses CC BY-SA 4.0, a meaningful difference from permissively licensed code collections. Review that obligation before adapting and distributing the skill text inside a private marketplace. For a security team already able to judge scanner output, the 44-plugin catalog is worth selective adoption. For a developer hoping an agent can approve a system without expert review, the constant-time plugin's split between errors and warnings explains why that expectation is unsafe.