Skip to main content

Supply Chain and Release Verification

What a release contains

Verify before installing

Pinned images

Builds use lock files (npm ci, NuGet with explicit versions). Vulnerable transitive .NET packages are pinned to patched versions in Quixa.Core.csproj; npm transitive fixes use overrides.

SBOM and scans

scripts/security-evidence.sh <tag> produces, for every image, a CycloneDX SBOM and a Trivy scan (HIGH and CRITICAL), plus dotnet list package --vulnerable and npm audit results. The release gate fails when a Quixa image or dependency has a HIGH or CRITICAL finding with a fix available. Findings in third-party images (SQL Server, Metabase) are listed in SUMMARY.md and followed up with the vendor; they are fixed by moving to the vendor’s next patched version. Current state (Oct 30, 2026): the Quixa images (API, web app, script sandbox, Metabase setup) have no HIGH or CRITICAL findings. Metabase v0.64.4 has none. The SQL Server 2022 image from Microsoft (all current CU/GDR tags) contains Ubuntu 22.04 packages with HIGH findings for which Ubuntu has published updates; Microsoft rebuilds the image with them. SQL Server is not reachable from outside the Docker network. Customers who run their own SQL Server can point Quixa at it instead.

Updates

  • Base images and dependencies are reviewed with every release and at least monthly.
  • Security fixes follow the patch timelines in Privacy, incidents and patching.
  • The script sandbox image runs its isolation tests (escape attempts, time and memory limits) during the build; an image that fails them is not produced.