Verify a Release

obserae ships as closed-source pre-built binaries and Docker images. Because you can’t read the source, the project signs every release with Sigstore keyless signing and publishes an SBOM (software bill of materials) and a SLSA build-provenance attestation for each artifact. Together they let you prove, before you run anything:

• Integrity — the file you downloaded is bit-for-bit what was published.
• Authenticity — it was signed by obserae’s official release pipeline.
• Origin — it was built by that pipeline from a specific commit (provenance), and you can list exactly which dependencies went into it (SBOM).

There is no public key to fetch or trust: keyless signing mints an ephemeral key per build, takes the identity from the release workflow’s GitHub OIDC token, gets a short-lived certificate from Fulcio, and records the proof in the public Rekor transparency log. The signing identity is obserae’s build workflow inside the spartan-conseil GitHub organisation — that’s why the commands below match on https://github.com/spartan-conseil/.*.

Tools

1. Integrity — checksums

Every release includes checksums.txt (SHA256 of every archive). Download it next to the tarball(s) and check:

sha256sum -c checksums.txt

You should see obserae_linux_amd64.tar.gz: OK (and/or arm64). A mismatch means a corrupted or tampered download — stop here.

2. Authenticity — signature of the checksums

checksums.txt is signed (keyless cosign). Signing the checksum file transitively covers every tarball it lists. Download checksums.txt, checksums.txt.sig and checksums.txt.pem from the release, then:

cosign verify-blob checksums.txt \
  --signature checksums.txt.sig \
  --certificate checksums.txt.pem \
  --certificate-identity-regexp "https://github.com/spartan-conseil/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Verified OK confirms the checksums were signed by obserae’s release pipeline. Combined with step 1, your tarball is authentic.

3. Provenance — how the release was built

The release carries a keyless SLSA build-provenance attestation, provenance.intoto.jsonl, attached as a release asset. It records the source commit and the workflow that produced the release. The attestation is over checksums.txt — so it transitively covers every tarball that file lists (verify the tarball with steps 1–2 first, then the provenance of checksums.txt).

Download checksums.txt and provenance.intoto.jsonl from the release, then:

cosign verify-blob-attestation checksums.txt \
  --bundle provenance.intoto.jsonl \
  --type slsaprovenance1 \
  --certificate-identity-regexp "https://github.com/spartan-conseil/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

The --bundle form verifies entirely against the downloaded files (cert + signature + predicate are in the bundle), so it works even though obserae is built from a private repository — no GitHub or registry lookup needed.

4. SBOM — what’s inside

Each archive ships an SBOM alongside it: obserae_linux_amd64.tar.gz.sbom.json (generated by syft). It is a machine-readable inventory of every dependency in the build, ready for vulnerability scanning:

# scan the SBOM for known CVEs (https://github.com/anchore/grype)
grype sbom:obserae_linux_amd64.tar.gz.sbom.json

# …or just browse it
jq '.artifacts[].name' obserae_linux_amd64.tar.gz.sbom.json

Docker images

The multi-arch image manifests are signed and carry their own provenance, verifiable straight from the registry. Replace <version> with the tag you pulled (e.g. 0.1.0):

# Signature
cosign verify ghcr.io/spartan-conseil/obserae:<version> \
  --certificate-identity-regexp "https://github.com/spartan-conseil/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

# Provenance (attestation stored next to the image in ghcr)
cosign verify-attestation ghcr.io/spartan-conseil/obserae:<version> \
  --type slsaprovenance1 \
  --certificate-identity-regexp "https://github.com/spartan-conseil/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

What to do if verification fails

A failed checksum, signature or provenance check means the artifact is not trustworthy: a corrupted download, a man-in-the-middle, or a wrong file. Do not run it. Re-download from the official releases page and re-verify; if it still fails, report it via Security.