Plugin Development Overview

This article is for third-party developers: all you need is the official TestSecScan distribution package plus this documentation to write, from scratch, a plugin that the controller, a scan node, or the AI penetration agent can invoke.

1. Four Plugin Forms: Choose the Right Track First

A TestSecScan "plugin" is not a single thing but four independent extension points, each with its own SDK and signing system. The classic symptom of choosing the wrong track is: your code compiles, but the host will never call it.

There is also the Go hot-load POC (see Go Hot-Load POC Development): it is not a plugin but one form of vulnerability template. It is written in plain Go source and interpreted in-process by the scan node (the target machine needs no Go toolchain), which suits scenarios where "you need a Turing-complete script, but a full WASM build chain is not worth it".

2. The Boundary Between the Two WASM SDKs (the Easiest Trap to Fall Into)

A scan node injects two completely non-overlapping sets of host functions for the two kinds of WASM modules:

Key limitation: the scan_* host functions are injected only on the "POC template execution" call path. In other words, putting scan.HTTP(...) into an application plugin, or app.SpawnTool(...) into a WASM POC, will make instantiation fail, because the host does not export the corresponding functions. Telling the two apart is easy:

• Your artifact is scanned as a vulnerability from the POC template list → use scan.*;
• Your artifact runs as a resident plugin from the plugin store / application plugin directory → use app.*.

By the same token, controller plugins use ctl_* and AiAgent external tools use stdin/stdout JSON — the four sets are not interchangeable.

3. The Shortest Path to Getting Started

① Choose the form (table above)
② Copy the matching SDK into your project (every article shows how to wire up go.mod)
③ Compile locally into a .wasm file / executable
④ Sign locally (controller key, Ed25519)
⑤ Put it into the host's load directory, or submit it to the plugin store / POC store
⑥ See it in the GUI, trigger it, read the logs

Every chapter article covers: directory layout → build commands → every public function explained one by one (parameters / returns / scenarios / examples) → caveats → complete runnable examples → debugging methods.

How to Read Each Chapter Article (Uniform Structure)

All five chapter articles follow the same structure; reading them in the order below will keep you unstuck:

4. Downloads: Documentation and SDK Packages

Every documentation page has download buttons in the top-right corner, and you can also use the fixed addresses below (they follow releases and always point to the version currently in effect):

Every SDK package contains its own README.md explaining how to wire it into your project (how to write the replace directive in go.mod), the build commands, and the caveats; after unzipping, copy the whole directory into your plugin project.

5. Signing and Publishing (a Hard Security Gate)

All four kinds of TestSecScan extensions follow the same rule: no signature, no loading — and signature verification uses the public key held by the host, never a public key bundled inside the package:

• Controller / scan node WASM: Ed25519 signature; inside sig.json, signStatus must be verified or official;
• AiAgent external tool: the signature covers the whole-package digest (every file in the directory except sig.json, hashed with SHA-256 in ascending relative-path order), and verification runs once at load time and once before every invocation (TOCTOU protection);
• The signing private key is held only by the controller; third-party developers sign through one-click signing in the GUI or through the official build service.

6. Documentation Maintenance Conventions (for Future SDK Evolution)

This documentation set and the SDK source code evolve together:

1. After adding or modifying any public SDK function, you must update the corresponding chapter article and register it in the comparison tables on this page, such as "The Boundary Between the Two WASM SDKs";
2. The repository ships an SDK coverage guardrail test that parses the SDK source of each end and makes two assertions: ① every public symbol appears in the documentation body; ② every public symbol has a #### section named after it, and that section contains a code snippet (in other words, "every function needs an example of how to call it and how to read its return value"). Omitting it, or writing only a one-line description, fails the test, which forces the documentation to stay in sync;
3. The documentation body can be edited online in the backend under "Site Settings → Developer Docs"; edits are persisted as an override layer, while the built-in version is refreshed with each release and can be restored to the default with one click.