mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
Anso
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.
1.9 KiB
1.9 KiB
Security Policy
Supported Versions
| Version | Supported |
|---|---|
| 0.2.x+ | Yes |
| < 0.2 | No |
Reporting a Vulnerability
Please do not open a public issue for security vulnerabilities.
You can report security issues in two ways:
- Email: Send details to security@sencho.io
- GitHub: Use private vulnerability reporting in the Security tab
In your report, include: steps to reproduce, impact assessment, and any suggested fixes.
You can expect an initial response within 72 hours. We will work with you to understand and address the issue before any public disclosure.
Security Considerations
Sencho manages Docker containers and has access to the Docker socket. When deploying:
- Always run behind a reverse proxy with TLS in production
- Use strong passwords and rotate JWT secrets
- Restrict network access to the Sencho port
- Review the security configuration docs for hardening guidance
Verifying Release Artifacts
Every published image is signed and carries verifiable supply-chain artifacts. See the full guide at docs.sencho.io/operations/verifying-images.
Quick summary:
# Verify image signature (cosign keyless, Rekor logged)
cosign verify saelix/sencho:<tag> \
--certificate-identity-regexp "https://github.com/AnsoCode/Sencho/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com
# Scan with VEX applied (zero unresolved HIGH/CRITICAL CVEs)
trivy image --vex sencho.openvex.json --severity HIGH,CRITICAL saelix/sencho:<tag>
CycloneDX SBOM (sbom.cdx.json), SPDX SBOM (sbom.spdx.json), and the VEX document (sencho.openvex.json) are attached to every GitHub Release as downloadable assets and as cosign attestations on the image digest.