Files
sencho/docs/operations/verifying-images.mdx
T
Anso 3668c71860 feat(security): add SBOM attestations, VEX document, and retire .trivyignore (#790)
* feat(security): add SBOM attestations, VEX document, and retire .trivyignore

Add OpenVEX triage document (security/vex/sencho.openvex.json) for the 5
residual CVEs vendored inside docker/compose v5.1.2 that were carried over
from the previous PR. All 5 are marked not_affected with justifications.

Configure Trivy in both CI and release workflows to consume the VEX document
via trivy.yaml so the same source of truth gates PR scans and release scans.
Delete .trivyignore, which is fully superseded by the VEX file.

Add two new release pipeline steps after image publication:
- CycloneDX 1.6 SBOM via anchore/sbom-action (also installs syft)
- SPDX 2.3 SBOM via syft directly (reuses OCI layer cache from prior step)
Both are attached as cosign OCI referrer attestations (keyless, OIDC-signed)
and uploaded as GitHub Release assets alongside the OpenVEX file.

Bump docker-publish.yml permissions from contents:read to contents:write,
required for softprops/action-gh-release to create Release assets.

Add docs/operations/verifying-images.mdx with copy-paste verification
commands for all supply-chain artifacts: signature, SLSA provenance,
CycloneDX SBOM, SPDX SBOM, OpenVEX, and Rekor entry. Update docs.json
navigation and expand the Supply chain security section in docs/security.mdx.
Add a Verifying Release Artifacts section to SECURITY.md.

* fix(vex): cover otel SDK CVE-2026-39883 in rebuilt Docker CLI binary

The rebuilt Docker CLI v29.4.0 vendors otel/sdk v1.42.0, which still
contains CVE-2026-39883 (BSD kenv PATH hijacking; fixed in v1.43.0).
docker-compose v5.1.2 vendors otel/sdk v1.38.0 separately. The original
VEX statement only covered the compose binary's location and version,
so Trivy's scan of /usr/local/bin/docker was not suppressed.

Add a second subcomponent entry for the CLI binary path with the
correct vendored version. The not_affected justification (BSD-only
code path; we ship linux/amd64 and linux/arm64 only) holds for both
binaries.

* fix(ci): use list form for vulnerability.vex in trivy.yaml

Trivy's config schema requires vulnerability.vex to be a list (mapped
to the multi-value --vex flag). The previous bare-string value was
silently dropped, so the OpenVEX document was never loaded and HIGH
findings already covered by VEX statements still failed the scan.

* fix(ci): mirror VEX CVE in .trivyignore for local-image scan

Trivy does not emit an OCI purl for locally-built images without a
RepoDigests entry (aquasecurity/trivy#9399), so OpenVEX product
matching against the CI build target sencho:pr-test resolves to no
artifact and every statement is silently dropped. The VEX document
remains the canonical triage record and is still attached as a cosign
attestation on the published image; this file just mirrors the single
CVE that surfaces on the local scan so CI does not block on a finding
already triaged in VEX. Updates the Trivy step comment to document
the relationship between the two files.
2026-04-26 23:21:11 -04:00

114 lines
3.7 KiB
Plaintext

---
title: Verifying Published Images
description: How to verify signatures, provenance, SBOMs, and CVE triage for Sencho Docker images.
---
Every Sencho release image published to Docker Hub is signed and carries verifiable supply-chain artifacts. This page explains how to check each one.
## Prerequisites
Install the following tools once:
```bash
# cosign (Sigstore)
brew install cosign # macOS
# or: https://github.com/sigstore/cosign/releases
# syft (optional, for inspecting SBOM content)
brew install syft
# or: https://github.com/anchore/syft/releases
# Trivy (optional, for local vulnerability scan with VEX)
brew install trivy
# or: https://github.com/aquasecurity/trivy/releases
```
## Verify the image signature
Every published tag is signed with cosign keyless signing via GitHub Actions OIDC. No private key is stored anywhere; the signing identity is bound to the GitHub Actions workflow that published the image.
```bash
cosign verify saelix/sencho:<tag> \
--certificate-identity-regexp "https://github.com/AnsoCode/Sencho/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com
```
A successful verification prints the verified payload and exits 0. The Rekor transparency log entry is included in the output; you can also query it directly:
```bash
cosign tree saelix/sencho:<tag>
```
## Verify SLSA provenance
BuildKit produces an SLSA v1 provenance attestation during every multi-arch build. Retrieve and verify it:
```bash
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity-regexp "https://github.com/AnsoCode/Sencho/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
saelix/sencho:<tag> | jq -r '.payload' | base64 -d | jq
```
## Retrieve the CycloneDX SBOM
```bash
cosign verify-attestation \
--type cyclonedx \
--certificate-identity-regexp "https://github.com/AnsoCode/Sencho/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
saelix/sencho:<tag> | jq -r '.payload' | base64 -d | jq
```
Alternatively, download `sbom.cdx.json` directly from the GitHub Release assets for the matching version.
## Retrieve the SPDX SBOM
```bash
cosign verify-attestation \
--type spdxjson \
--certificate-identity-regexp "https://github.com/AnsoCode/Sencho/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
saelix/sencho:<tag> | jq -r '.payload' | base64 -d | jq
```
`sbom.spdx.json` is also available as a GitHub Release asset.
## Retrieve the VEX document
The OpenVEX document explains Sencho's triage decisions for any CVEs that appear in vendored dependencies but are not reachable via Sencho's usage of those dependencies:
```bash
cosign verify-attestation \
--type openvex \
--certificate-identity-regexp "https://github.com/AnsoCode/Sencho/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
saelix/sencho:<tag> | jq -r '.payload' | base64 -d | jq
```
`sencho.openvex.json` is also available as a GitHub Release asset and at `security/vex/sencho.openvex.json` in the source repository.
## Run a local vulnerability scan with VEX applied
To reproduce the same scan that gates every release:
```bash
# Download the VEX document
curl -Lo sencho.openvex.json \
https://github.com/AnsoCode/Sencho/releases/latest/download/sencho.openvex.json
# Scan with VEX applied (exit 1 if any unresolved HIGH/CRITICAL CVE)
trivy image \
--vex sencho.openvex.json \
--severity HIGH,CRITICAL \
--exit-code 1 \
saelix/sencho:<tag>
```
A clean result means no unresolved HIGH or CRITICAL CVEs. CVEs listed as `not_affected` in the VEX document are suppressed with their justification visible in the VEX file.
<Note>
Trivy 0.36.0 or later is required for `--vex` flag support.
</Note>