Integrations
Two surfaces, no plugin directory
There is no marketplace of one-click connectors. There is an HTTP API that any pipeline can call with a scoped credential, and webhooks that push three events wherever you want them.
Integration surfaces
The platform API
Request a scan, poll it, ask for a verdict, and branch on the answer. Works from any CI system that can make an HTTP request, which is all of them. Authenticate with an API key scoped to exactly what the pipeline needs — typically the ability to create and read scans, and nothing more.
Webhooks
Three events — a scan completing, a verdict being recorded, a finding changing state. Signed with a rotatable secret, timestamped against replay, retried with backoff for about a day, and published from inside the transaction that caused them so a delivery never describes a state that was rolled back.
CI systems
Anything that can make an HTTP request
Worked examples exist for the common ones. There is nothing special about them — the underlying recipe is the same four calls.
- GitHub Actions
- GitLab CI
- Jenkins
- CircleCI
- Buildkite
- Anything with curl
There is no TRUSTIVAN command-line tool to install on your runners. The CI story is HTTP calls against a scoped key, which is one fewer binary to keep up to date and one fewer thing to trust on a build machine.
A clarification
What the GitHub connection is, and is not
TRUSTIVAN can sign you in with GitHub, and a GitHub App can be installed. Neither of those scans anything.
There is no pull-request scanning andno push-triggered scanning. The webhook receiver verifies signatures and acknowledges deliveries without acting on them. If you want a scan on a push, request one from your CI job — the pipeline already knows what it built.
This is spelled out because “GitHub integration” in this category usually implies repository scanning, and implying it here would be misleading.