Attestation

info

The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.

Each image comes with verifiable evidence about the build artifact. This evidence is called an attestation. Attestations are signed statements linked directly to image digests as OCI referrers. Because they are linked by digest, they stay connected to the image even if the image is mirrored elsewhere.

The image signature is part of the same mechanism. The release pipeline uses a short-lived certificate issued through GitHub Actions OIDC and signs each image against the public Sigstore instance with keyless signing. Fulcio issues the certificate, and the signing event is recorded in the public Rekor transparency log, so there is no long-lived signing key to distribute or manage. The same keyless identity signs SLSA Provenance, SBOM, and VEX attestations. Signatures are attached to both the multi-arch index digest and architecture-specific child digests.

Verify an image signature

Verifying the signature lets you confirm which build pipeline execution produced the image. Because the signature is attached to the multi-arch index, you can verify a tag directly and let cosign resolve the index. The following example verifies the busybox image and prints the signed digest.

$ cosign verify \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github.com/flatt-security/takumi-images/.github/workflows/release.yml@.*' \
  images.flatt.tech/takumi/busybox:latest \
  2>/dev/null | jq -r '.[0].critical.image["docker-manifest-digest"]'
sha256:3a8d31becc2516f6fdf236964622d0d70c4b83843a91d370b6ea737a4735bd4b

The identity condition fixes the workflow path (.../release.yml). This accepts only signatures produced by that release workflow. The @.* suffix matches the ref on which the workflow ran, whether it was a branch or tag. If you do not fix the workflow path, you may accept signatures made by another workflow or another repository.

Verify attestations

SLSA Provenance, SBOM, and VEX are verified with the same identity. Use cosign verify-attestation and specify the predicate type for each attestation: slsaprovenance1, cyclonedx, or openvex. The digest to verify depends on where the attestation is attached. SLSA Provenance and SBOM are attached to architecture-specific child digests, so first extract the child digest from the index.

# Extract the child digest for an architecture from the index.
$ crane manifest images.flatt.tech/takumi/busybox:latest \
    | jq -r '.manifests[] | select(.platform.architecture=="amd64").digest'
sha256:7481eedfc1b6c70596d335f24665422438c17162e5cf97ee4584ae84b2629bf7

VEX is attached to the multi-arch index, so you can verify it directly against the tag or index digest.

cosign verify-attestation \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github.com/flatt-security/takumi-images/.github/workflows/release.yml@.*' \
  --type openvex \
  images.flatt.tech/takumi/busybox:latest \
  | jq -r '.payload' | base64 -d | jq '.predicate'

See SLSA Provenance, SBOM, and VEX for the contents of each attestation and the exact retrieval flow for child digests.

The three attestations

The three attestation types record different information and attach to different subjects.

Attestation	Format / predicate type	Records	Attached to	Main use
SLSA Provenance	in-toto / SLSA v1 (slsaprovenance1)	Source revisions and workflow used for the build	Architecture-specific child digest	Verifying build origin and comparing with reproducible builds
SBOM	CycloneDX (cyclonedx)	Components in the runtime closure	Architecture-specific child digest	Understanding contents and feeding vulnerability scanners
VEX	OpenVEX (openvex)	not_affected, fixed, and affected decisions with rationale	Multi-arch index	Triage of scan results and false-positive suppression

SLSA Provenance and SBOM are attached to child digests because their contents differ by architecture. VEX is linked to the index digest because it records a decision for the image as a whole.