Skip to content

Image signatures and build provenance

This page explains how to verify the integrity and build provenance of Logstrm container images. It does not claim that an image is vulnerability-free or production-certified.

Release artifacts

For version tags (v*), the release workflow builds multi-architecture Data Plane and Manager images for linux/amd64 and linux/arm64, and publishes them to the authorized GHCR packages. Each build also requests BuildKit provenance and an SPDX SBOM.

Each image digest is signed with Cosign and has a signed SLSA provenance v1 attestation attached in the registry. The predicate identifies the source repository, commit, release ref, workflow invocation, image digest and target platforms. The release workflow verifies both the image signature and provenance attestation before the publish job succeeds.

The images use a project-managed Cosign key. The matching public key is available as cosign.pub. Verify the public-key fingerprint through a trusted Logstrm distribution channel before relying on it.

These are Cosign image signatures and in-toto SLSA provenance attestations. They are not GitHub Artifact Attestations and do not claim a SLSA Build Level.

Verify an authorized image

The GHCR packages may require registry access. Authenticate with credentials authorized to read the image, then substitute the exact image digest supplied for your release:

IMAGE="ghcr.io/<owner>/logstrm@sha256:<digest>"

cosign verify \
  --insecure-ignore-tlog \
  --key cosign.pub \
  "$IMAGE"

cosign verify-attestation \
  --insecure-ignore-tlog \
  --key cosign.pub \
  --type "https://slsa.dev/provenance/v1" \
  "$IMAGE"

Repeat for logstrm-manager. Verify the digest, source commit, release ref and target platforms in the decoded attestation before deployment. Prefer digest references over mutable tags in production configuration.

--insecure-ignore-tlog is required because these signatures and attestations are not uploaded to a public Rekor transparency log. Verification checks the cryptographic signature against the project public key and validates image claims, but does not provide independent public transparency-log evidence. Keep a trusted copy of the public key and verify its fingerprint out of band.

Interpretation and limits

  • An SBOM lists build components; it does not prove that dependencies are vulnerability-free.
  • Provenance describes the build inputs and process; it does not certify application behavior, capacity or production readiness.
  • A valid signature confirms that the signed digest matches the project signing key; it is not a code review or vulnerability assessment.
  • Releases produced before Cosign signing was enabled may not have signatures or attestations. Do not infer them from a tag, BuildKit metadata or an SBOM.
  • The security workflow separately runs Gosec, Trivy filesystem/image scans and Gitleaks. Passing scans are time-bound and do not guarantee that an image has no vulnerabilities.

For reproducible deployment, preserve the release tag, image digest, verification result and source commit in your change record.