Skip to main content
A connector packages one external security tool behind a uniform contract. It has exactly two parts:
  • A declarative manifest.yaml describing the tool: name, capabilities, and the JSON schemas for the inputs and config the operator supplies.
  • A Go Adapter that adapts the tool’s output into the platform’s canonical Finding stream.
The same skeleton serves every kind of tool — an in-process library, a CLI wrapper, or a remote API client — because nothing outside the adapter knows which one it is.
This guide covers only the integration surface you write: the manifest, the adapter, and the inputs/config plumbing. The SDK owns everything between your adapter and the platform — dialing, registration, the stream, container reuse, and cancellation — so you never touch it.

​
The two things you write

manifest.yaml

Declares the connector. Validated at build time — unknown fields and duplicate slugs fail the build.

Adapter

One Go type with two methods, Validate and Execute. This is the only code every connector must write.

​
SDK packages

Import the SDK from github.com/oasm-platform/oasm-connectors/sdk. You only need three packages.
Never import sdk/runtime, sdk/transport, or sdk/proto internals into your adapter. The adapter package must stay tool-specific and nothing else.

​
Repository layout

Connectors live in a multi-module Go monorepo. Each connector is an independent module that consumes the SDK through a local replace directive.
The category directory groups connectors in the catalog and matches the connector’s capabilities entry — vulnerabilities, ports_scanner, or url_discovery.
A dependency added for one connector lands only in that connector’s go.mod. Never promote a tool-specific dependency into the SDK.

​
Next steps

Quickstart

Build a minimal connector end to end.

Adapter reference

The Validate and Execute methods in detail.

manifest.yaml reference

Every field the manifest accepts.

Inputs & config

How per-run inputs and the config profile reach your adapter.