Skip to content
TruthVouch Docs

Supply Chain Security

As an AI governance platform that helps organizations enforce SBOM compliance and software supply chain standards, TruthVouch practices what it preaches. Every artifact we publish — container images, SDK packages, and agent binaries — includes cryptographic signatures, a Software Bill of Materials, and verifiable build provenance.

Image Signing

All container images published to the GitHub Container Registry (ghcr.io/truthvouch/*) are signed using Sigstore cosign with keyless OIDC signing.

What Is Keyless Signing?

Traditional code signing requires managing a private key — storing it securely, rotating it periodically, and revoking it if compromised. Keyless signing eliminates this by tying the signature to the identity of the CI system that built the artifact.

When our CI pipeline builds a container image:

  1. The CI system issues an OIDC token proving the pipeline’s identity (project, workflow file, commit SHA)
  2. Sigstore’s Fulcio CA issues a short-lived signing certificate based on that OIDC token
  3. The image is signed with the ephemeral certificate
  4. The signature is recorded in Sigstore’s public transparency log (Rekor) for tamper-evident auditing

This means there is no private key to steal. The signature proves the image was built by a verified TruthVouch CI pipeline.

Verify an Image Signature

Terminal window
# Install cosign (https://docs.sigstore.dev/cosign/system_config/installation/)
# Then verify any TruthVouch container image:
cosign verify ghcr.io/truthvouch/governance-gateway:1.0.0 \
  --certificate-identity-regexp="https://gitlab.com/sentinal2/Sentinal//.*" \
  --certificate-oidc-issuer="https://gitlab.com"

This command checks:

  • The image digest has a valid Sigstore signature
  • The signing certificate was issued to the TruthVouch CI pipeline
  • The signature is recorded in the Rekor transparency log

Repeat for all 4 gateway images (governance-gateway, gateway-api, ai-engine, gateway-sync) to verify your entire deployment.

Software Bill of Materials (SBOM)

Every artifact TruthVouch publishes includes a CycloneDX SBOM that lists all direct and transitive dependencies, their versions, and SPDX license identifiers.

Container Images

Each container image has a CycloneDX SBOM attached as an OCI artifact. The SBOM is generated by Syft during the CI build and attached to the image digest via cosign attach sbom.

Retrieve the SBOM for a container image:

Terminal window
cosign download sbom ghcr.io/truthvouch/governance-gateway:1.0.0 > sbom.cdx.json

The SBOMs are also available as downloadable JSON files on each GitLab Release (e.g., sbom-governance-gateway.cdx.json).

SDK Packages

CycloneDX SBOMs are generated for every SDK package release and attached to the corresponding GitLab Release:

PackageSBOM GeneratorDistribution
@truthvouch/sdk (npm)@cyclonedx/cyclonedx-npmGitLab Release artifact
@truthvouch/cli (npm)@cyclonedx/cyclonedx-npmGitLab Release artifact
truthvouch (PyPI)cyclonedx-bomGitLab Release artifact
langchain-truthvouch (PyPI)cyclonedx-bomGitLab Release artifact
llama-index-truthvouch (PyPI)cyclonedx-bomGitLab Release artifact
TruthVouch.Sdk (NuGet)CycloneDX (.NET tool)GitLab Release artifact
TruthVouch.SemanticKernel (NuGet)CycloneDX (.NET tool)GitLab Release artifact

SBOM Format

All SBOMs use the CycloneDX format (JSON). CycloneDX is an OWASP project standardized as ECMA-424 and widely supported by vulnerability scanning tools including Grype, Trivy, Snyk, and Dependency-Track.

Each SBOM includes:

  • Component inventory — all direct and transitive dependencies
  • Version information — exact version of each dependency
  • License identifiers — SPDX license expressions for compliance review

Using SBOMs for Vulnerability Scanning

Feed the SBOM into your preferred vulnerability scanner:

Terminal window
# Grype
grype sbom:sbom-governance-gateway.cdx.json


# Trivy
trivy sbom sbom-governance-gateway.cdx.json


# Dependency-Track (via API upload)
curl -X POST "https://your-dtrack-instance/api/v1/bom" \
  -H "X-Api-Key: YOUR_KEY" \
  -F "project=GATEWAY_PROJECT_UUID" \
  -F "[email protected]"

Discovery Agent Binary Signing

The Discovery Agent (a Go binary for network discovery) is signed using Sigstore cosign keyless signing. Each release includes:

  • Cross-compiled binaries for Linux (amd64, arm64), macOS (Intel, Apple Silicon), and Windows (amd64)
  • SHA-256 checksums for integrity verification
  • Sigstore signature bundles (.sigbundle files) for each binary

Binaries are published via the GitLab Generic Package Registry and linked from the GitLab Release page.

Verify a binary:

Terminal window
# Verify the SHA-256 checksum
sha256sum --check checksums.sha256


# Verify the Sigstore signature
cosign verify-blob \
  --bundle vt-discovery-agent-linux-amd64.sigbundle \
  --certificate-identity-regexp="https://gitlab.com/sentinal2/Sentinal//.*" \
  --certificate-oidc-issuer="https://gitlab.com" \
  vt-discovery-agent-linux-amd64

Build Integrity

GitLab CI

All TruthVouch artifacts are built in GitLab CI with:

  • Tag-triggered release pipelines — release jobs only run when a semantic version tag is pushed (e.g., gateway-v1.2.3), ensuring only intentional releases are published
  • OIDC-based signing — Sigstore cosign uses GitLab’s OIDC identity token for keyless signing, with no stored private keys
  • Minimal secrets — registry credentials (GHCR, PyPI, npm, NuGet) are stored as masked, protected CI/CD variables
  • Shell executor isolation — builds run on a dedicated EC2 instance with Docker, providing a controlled build environment

Changelog Generation

Every release includes an auto-generated changelog produced by git-cliff from conventional commit messages. The changelog is included in the GitLab Release description for full transparency on what changed.

Compliance Standards

TruthVouch’s supply chain security practices align with the following standards and guidelines:

StandardRelevance
NIST AI RMF MS.2.8Software supply chain risk management for AI systems
CISA SBOM GuidelinesMinimum elements for an SBOM, transparency requirements
EU Cyber Resilience Act (CRA)SBOM requirements for software products sold in the EU
SLSA Level 2Build provenance via CI/CD (hosted build service, version-controlled build definition)
OWASP CycloneDXSBOM format standard (ECMA-424)
SigstoreKeyless signing and transparency logging for supply chain integrity

Summary

Artifact TypeSigned?SBOM?Provenance?
Container images (GHCR)Cosign keyless (Sigstore OIDC)CycloneDX (OCI attachment + GitLab Release)CI pipeline identity in signing certificate
npm packages—CycloneDX (GitLab Release)—
PyPI packages—CycloneDX (GitLab Release)—
NuGet packages—CycloneDX (GitLab Release)—
Discovery Agent binariesCosign keyless (Sigstore OIDC)—SHA-256 checksums + Sigstore signature bundles

Next Steps