Supply-chain verification

Verify signed Helm charts, signed container images, and the SBOM published with each Scrydon release.

Scrydon publishes signed Helm charts and signed container images with each release, plus an SBOM. This page covers how to verify them.

What's signed

Artefact	Signing tool	Where it's published
OCI images	Cosign	OCI registry (configurable per release channel)
Helm chart	Cosign + OCI artifact	Same registry as images
SBOM	Cosign attestation	Attached to each image as a Cosign attestation
Provenance	SLSA-compatible build attestation	Attached to each image

Verifying an image

# Discover the published key for the release channel
cosign verify \
  --certificate-identity-regexp 'https://github.com/scrydon/.*' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  <registry>/scrydon/<image>:<version>

cosign verify returns the verified signature payload or an error if the signature doesn't match.

Verifying a Helm chart

Helm charts are signed as OCI artifacts. Same command as above with the chart's OCI reference:

cosign verify \
  --certificate-identity-regexp 'https://github.com/scrydon/.*' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  <registry>/scrydon/helm/scrydon:<version>

Fetching the SBOM

The SBOM is attached to each image as a CycloneDX attestation. Retrieve it with:

cosign download attestation \
  --predicate-type 'https://cyclonedx.org/bom' \
  <registry>/scrydon/<image>:<version> | jq -r '.payload | @base64d' | jq .

The SBOM lists every dependency, version, license, and known vulnerability identifier.

Verifying provenance

The build provenance is also a Cosign attestation, in SLSA format:

cosign download attestation \
  --predicate-type 'https://slsa.dev/provenance/v1' \
  <registry>/scrydon/<image>:<version> | jq -r '.payload | @base64d' | jq .

The provenance includes:

The source commit.
The build entry point.
The build environment.
The build trigger.

This is what's typically required by EU CRA Annex I.1.2(h) and by SLSA Level 3 evidence.

In air-gapped deployments, the same artefacts are bundled into the Zarf package. Verification happens locally against the keys bundled with the package — same cosign commands, with the registry replaced by the local Zarf store.

What to do if verification fails

A failed verification means do not deploy. Either the artefact has been tampered with, or it wasn't published by Scrydon's release pipeline. Contact Scrydon support before proceeding.

Air-gapped deployment — how supply-chain verification works in air-gapped mode.
Compliance → EU CRA — what regulators expect to see.
Compliance → ISO 27001 — A.8.25 supply-chain integrity.