TRUSTIVAN ships five container images from one commit, each built by a single CI workflow that runs only on a pushed v* tag — never on a merge to main. This page states exactly what happens to those images between the build and your pull, in the same terms an auditor would ask for, including the parts that are not built yet.

​
What is signed

Every published image is signed keylessly with cosign, using GitHub Actions’ own OIDC token. There is no long-lived private key anywhere in this process: the workflow proves its identity to Sigstore’s public Fulcio certificate authority for the few seconds the signing step runs, and the certificate that comes back names this repository, this exact workflow file, and the tag being released — nothing else can produce a valid signature under that identity, including a fork, a branch build, or a maintainer signing by hand. Verify an image before you pull it into anything that matters:
To accept any TRUSTIVAN release rather than one specific tag (for example, in an admission-controller policy), anchor the identity as a regular expression instead of naming one tag:
Both commands run against the exact bytes GitHub’s registry serves — cosign resolves the signature as a referrer of the image digest you name, so a signature that verifies is a signature over the manifest you are about to run, not over a tag that could since have moved.

​
What is attested

Alongside the signature, each image’s software bill of materials — generated from the published image, not from the build context, using syft — is attached as a signed CycloneDX attestation. Extracting it needs no separate download:
The signature and the attestation are separate objects stored beside the image as OCI referrers of its digest — never baked into the manifest itself. That is deliberate: Docker Buildx can attach its own provenance and SBOM by turning an image reference into an index, which changes the digest every consumer pins. Signing after the push, against the digest that was actually published, means the digest an operator writes into a Kubernetes manifest never moves.

​
What CI checks before any of this runs

Nothing above executes unless the tagged commit already passed, in order:
  • the full test suite and every architecture guard (make ci-guards);
  • govulncheck in binary mode over every shipped Go binary, gated by an exceptions file that expires — an exception needs the primary advisory in hand and a review date, and an expired one fails the build rather than being forgotten;
  • npm audit at high and critical severity, and the equivalent gate for NHI Security’s own dependency tree;
  • a secret scan of every commit in the repository’s history, not just the tip;
  • the real end-to-end scan, against a real registry and a real advisory database — the one gate that catches a scanner reporting a clean image wrongly, which nothing else here can.
A tag on a commit that fails any one of these publishes nothing.

​
Bills of materials for what you scan

The signed attestation above describes TRUSTIVAN’s own images. Separately, every asset TRUSTIVAN scans has its own inventory, exportable on demand as CycloneDX 1.5 or SPDX 2.3:
See the API reference for the full contract. These documents describe what is installed inside the software you asked TRUSTIVAN to look at; they are unrelated to the attestation above, which describes TRUSTIVAN’s own shipped images.

​
What none of this claims

Stated plainly, because a security page that only lists what a product does is a marketing page:
  • No SLSA provenance. Signing proves who published an image and at what tag; it does not attest to the build steps, the builder’s own supply chain, or reproducibility. Nothing here is a SLSA attestation and nothing should be read as one.
  • No signature verification anywhere else in the product. Images TRUSTIVAN itself scans — your images — are not checked for a signature. sigstore and in-toto appear in this repository only as indirect dependencies of the tooling described above; TRUSTIVAN does not verify third-party signatures as a feature.
  • No reproducible builds claim. Two builds of the same commit are not asserted to produce byte-identical images.
  • Multi-architecture is not built. Every image is linux/amd64 only.
  • The registry is private. ghcr.io/trustivan/* requires a pull secret in your cluster; nothing here makes an image publicly pullable.
  • A signature is not a vulnerability clean bill. It proves provenance — this exact organisation published this exact digest — not the absence of findings. Read the attached SBOM, or better, scan the image, for that.

​
If verification fails

Do not deploy the image. A signature that fails to verify, an attestation whose predicate does not decode, or a digest that no longer matches the tag you resolved means one of: the image was not built by this release workflow, the tag was moved after publication (tags here are treated as immutable, but Sigstore’s transparency log is what lets you prove that independently), or your verification command named the wrong identity. See Reporting a vulnerability if you believe an image was tampered with rather than misconfigured locally.