TRUSTIVAN has two integration surfaces, and it is worth being plain about the size of that list: a security tool that is vague about its boundary is worse than one with a narrow boundary. Everything else — a pipeline gate, a chat notification, a ticket created from a finding — is built out of those two.

​
There is no CLI

The CI story is curl, or any HTTP client, against a scoped API key. There is no trustivan command to install, no binary to pin a version of, and nothing to keep up to date on a build image. Every example in these docs is a shell command you can paste. That is a deliberate trade rather than an omission. A single-endpoint HTTP call with a bearer token works in every CI system, every language and every container, and it does not become a supply-chain dependency of the pipeline whose supply chain you are trying to secure.

​
The machine API

Base path /api/v1, Authorization: Bearer twk_…. A machine principal has no role. Its authority is exactly the set of scopes its credential was granted. That is what makes least privilege expressible: a pipeline key holding scans:create, scans:read and verdicts:request can gate a build and cannot silence the findings that failed it, because findings:suppress is a separate scope and was not granted. Three scopes are not grantable to a key at all — policies:manage, webhooks:manage and apikeys:manage. Each closes a loop that would otherwise make the surrounding control meaningless: a build that can rewrite the policy it is judged by, a credential that can add a destination every future event is copied to, or one that can mint its own successor. The practical consequence is a division of labour. A human configures policies, webhook endpoints and credentials, from the dashboard or a browser session. A pipeline consumes them.
  • API overview — conventions, credentials and the contract.
  • Scopes — the full grantable set.
  • CI pipelines — the recipe, and it as GitHub Actions and GitLab CI.

​
Webhooks

Three events, and the set is closed: scan.completed, verdict.recorded, finding.state_changed. Signed with HMAC-SHA256, delivered at least once with exponential backoff, and published from a transactional outbox so an event is a committed row before it is a request.

​
What the GitHub connection is

TRUSTIVAN supports GitHub sign-in, and a GitHub App installation whose purpose is authentication and listing the repositories an installation can see. GitLab and Google sign-in exist on the same basis. That is the whole of it, and the distinction matters because the shape suggests otherwise:
  • There is no pull-request scanning. TRUSTIVAN does not comment on PRs, does not add a check run, and does not scan a branch.
  • There is no push-triggered scanning. POST /github/webhook verifies the signature and then acknowledges without processing. It is fail-closed and it does nothing else. The work it once dispatched belonged to a product TRUSTIVAN is not.
If you want a scan on every push, drive it from your pipeline: that is CI pipelines, and it is a few lines of curl.

​
What does not exist

Stated rather than left to be discovered:
  • No infrastructure-as-code scanning. No shipped engine parses a Terraform or Kubernetes manifest; a scan subject is a container image, a Git repository, or — where the operator has permitted a directory — a filesystem path or an SBOM document. Connecting a cloud account or a Kubernetes cluster to inventory it is a separate capability that ships — see Cloud and Kubernetes.
  • No credential can be read back. Registry authentication ships on Pro and Enterprise — store a credential against a registry host and scans of images from that host present it — but there is no endpoint that returns a stored secret at any role. A lost secret is rotated, not recovered.
  • No mail sender. Members are invited from the dashboard and an invitation token is issued, but TRUSTIVAN does not send it — the administrator who created it delivers it. Directory-sourced membership through SCIM or just-in-time SSO login remains the way to avoid handling tokens at all.
  • No reachability analysis. Findings carry an explainable 0–100 risk score built from severity, the CISA KEV catalogue, EPSS (opt-in), runtime evidence, fix availability and asset criticality, each factor shown with its source — but nothing determines whether vulnerable code is actually called.
  • No third-party attestation. Evidence is mapped to controls in SOC 2, ISO 27001, PCI DSS 4.0, NIST SSDF and EU CRA, and the audit trail exports as a hash-chained package — but TRUSTIVAN holds no report or certificate of its own, and no control is ever reported as “compliant” or “pass”. The conclusion belongs to your auditor.
  • No published price. A deployment with BILLING_PROVIDER=stripe offers a hosted checkout and the provider’s billing portal, and plans and their limits are enforced either way — but a price lives in the provider’s catalogue and none has been set up for this service, so a plan is arranged by conversation.

​
Where to go next