Status & support

VectorStep is supported on a best-effort basis. There is no SLA and no bug bounty. Only the latest released version receives fixes — there are no long-term support branches. Pin production deployments to a released tag, not :latest or :edge — see Versions and releases below.

Bug reports, questions, and feature requests are wanted — see the Licence page for what’s in scope. Reports are read, but response times aren’t guaranteed. Reach out at [email protected].

Versions and releases

Tagging a release (vX.Y.Z) is what publishes a container image — see Docker for pulling published images and running them. An edge tag tracks the default branch; latest and the semver tag track the most recent release. An untagged local build reports dev.

VectorStep and the Gateway deploy as a matched pair. There’s no protocol version negotiation between them yet, so the only supported configuration is running matching release tags together — don’t mix, say, VectorStep v0.7.0 with Gateway v0.5.0 and treat it as supported even if it happens to work.

GET /health on both services reports the running version, which is the fastest way to confirm what’s actually deployed in a given environment.

Verifying a release

Every tagged release publishes three things you can verify independently of GHCR: a signed container image, a CycloneDX SBOM attached to the GitHub release, and — for the native Linux install — a signed tarball alongside its existing .sha256 checksum. Signing is cosign keyless, via GitHub’s own OIDC identity — no key to manage on either side, and no key to compromise.

Verify an image signature:

cosign verify ghcr.io/bantex01/vectorstep:0.1.0 \
  --certificate-identity-regexp '^https://github.com/bantex01/VectorStep/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Verify a native tarball:

Download the tarball’s matching .bundle file from the same release (alongside the .tar.gz and its .sha256) — it carries the signature, the signing certificate, and a transparency-log proof in one file, which is what a current cosign needs to verify a standalone file offline (a bare signature file alone is no longer independently verifiable):

cosign verify-blob --bundle vectorstep-0.1.0-linux-amd64.tar.gz.bundle \
  --certificate-identity-regexp '^https://github.com/bantex01/VectorStep/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  vectorstep-0.1.0-linux-amd64.tar.gz

Both commands succeed with no output beyond a confirmation once verification passes, and exit non-zero with a clear error if the image or the tarball doesn’t match what VectorStep’s own CI actually built and signed. The same pattern applies to ghcr.io/bantex01/vectorstep-gateway and the Gateway’s own native tarball, with VectorStep-Gateway in place of VectorStep in the identity regexp.

The SBOM (sbom.cyclonedx.json) is attached directly to each GitHub release — download it from the release page rather than generating one yourself; it reflects the exact build that shipped, not a re-scan of whatever’s on your machine.

Reporting a security issue

Do not open a public issue for a suspected vulnerability. Email [email protected] instead, with a description of the issue, steps to reproduce or a proof of concept, the version or commit you were running, and any relevant deployment details.

Reports will be acknowledged as promptly as realistically possible, you’ll be told whether the issue is accepted and what the fix timeline looks like, and you’ll be credited in the release notes when a fix ships, unless you’d prefer not to be. Please allow a reasonable period for a fix before disclosing publicly.

Scope. VectorStep executes AI pipelines that can call tools and take actions. Some behaviour that looks alarming is intentional and configurable rather than a vulnerability — for example, an agent taking an action its agent.yaml grants it, or a pipeline step running without a verifier because none was configured. Reports about the trust and gating machinery not behaving as documented are firmly in scope; reports that amount to “a permissive configuration is permissive” generally are not. If you’re unsure, report it anyway and say so.