mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
3668c71860
* 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.
114 lines
3.7 KiB
Plaintext
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>
|