Per-Release Security Evidence Package

Audience: Enterprise security architects, supply-chain reviewers, procurement reviewers who would otherwise ask for an annual SOC 2 report.

Purpose: Explain what HailBytes ships with every release that provides per-release evidence relevant to a BYOC deployment. For software the customer runs in their own tenant, per-release supply-chain artifacts answer “what is in the code we are about to deploy?” more directly than an annual third-party attestation of HailBytes’ internal controls. Both have a place; this document is about the per-release artifacts.

1. What ships with each release

Every tagged release of HailBytes ASM and HailBytes SAT publishes the following artifacts. Sources are the actual CI workflows in the product repositories.

HailBytes ASM (.github/workflows/build.yml, .github/workflows/ci.yml)

Trivy SARIF is uploaded to the GitHub Security tab on every CI run, making it browseable to anyone with read access to the repository.

HailBytes SAT (.github/workflows/ci.yml)

SBOM and SARIF artifacts retain for 90 days on GitHub Actions. The Trust Pack is attached to GitHub Releases and has no retention limit.

2. The Trust Pack archive

The Trust Pack is a single downloadable ZIP that aggregates the per-release evidence for one tagged version of the product. Each Trust Pack ships with a MANIFEST.json (machine-readable inventory of contents and their SHA-256 hashes) and an index.html that browses the same contents for a human reviewer.

Contents:

• SBOMs for every container image in the release, in both SPDX and CycloneDX where applicable.
• Trivy scan results (SARIF + JSON) for every image.
• For SAT: govulncheck SARIF and the go-licenses CSV.
• For ASM: UAT artifacts — JUnit XML, screenshots, WCAG 2.1 AA accessibility audit output.
• Signing reference: the image digest, the Sigstore certificate, and the exact cosign verify command needed to re-verify the signature.

Trust Packs are attached to GitHub Releases on the product repositories. The filename pattern is hailbytes-<product>-trust-pack-v<version>.zip. A customer can pin to a specific release, archive the Trust Pack to their own evidence store, and have a reproducible record of what shipped on what date.

3. Reproducible builds and how to verify them

Versioning

Versions are derived from git commit count: 1.<git rev-list --count HEAD>. This is computed at build time and embedded in the binary (SAT, via Makefile ldflags) or container metadata (ASM). Given a tagged release, a reviewer can reproduce the version computation from the public source tree.

Image signature verification (ASM today, SAT planned)

ASM container images are signed keylessly via Sigstore. There is no HailBytes-held signing key; signatures are tied to the GitHub Actions OIDC identity that built the image. To verify a pulled image:

cosign verify \
  --certificate-identity-regexp 'https://github.com/HailBytes/.+/.github/workflows/.+' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  ghcr.io/hailbytes/hailbytes-asm-web@sha256:<digest>

The full verification command for each image is included in the Trust Pack’s index.html.

Infrastructure-as-code

The Marketplace images (AWS AMI, Azure VHD) are produced by Packer 1.11.2 with pinned plugin versions (amazon = 1.3.6, azure = 2.1.9). The Packer template (marketplace/packer/hailbytes-asm.pkr.hcl), provisioning scripts, and Ubuntu 24.04 hardening script (scripts/hailbytes-asm-harden-ubuntu-2404.sh) are in the open source repository. A customer who wishes to build their own image from source instead of pulling the Marketplace artifact can do so from the same inputs.

Docker-Compose deployments pin exact versions of every dependency: PostgreSQL 16.13-alpine, Redis 7.4.8-alpine, PgBouncer 1.24.1. The compose file (docker/docker-compose.yml) is also in the open source repository.

4. Why per-release evidence matters for a BYOC product

In a multi-tenant SaaS posture, the relevant compliance question is “what controls operate inside the vendor’s environment, evaluated by an independent auditor?” — and SOC 2 Type 2 answers it well.

In a BYOC posture, the relevant compliance question is “what code is actually running inside my environment, and how do I prove it?” — and SOC 2 of the vendor’s office does not answer it. Per-release SBOMs, SARIF scans, and image-signature attestations do answer it, and they answer it on the timescale a customer cares about (every release, not every twelve months).

Both kinds of evidence have a place. HailBytes is producing per-release evidence today and is on a stated path to SOC 2 Type 1 then Type 2 (see compliance-roadmap.md). The point of this document is that the per-release evidence is not a substitute for SOC 2 in tension with it — it’s complementary, and for a BYOC product the per-release evidence is the more operationally relevant of the two.

5. Known gaps and remediation

• SAT image signing. SAT does not yet sign container images with Cosign. ASM does. Target: parity with ASM by 2026-Q3. Tracked in GAPS.md (internal).
• SLSA provenance level. Neither product currently asserts a formal SLSA build level. The GitHub Actions OIDC-bound signing model on ASM is consistent with SLSA Level 2; formal declaration is on the compliance roadmap.
• Per-release third-party penetration test. Not feasible per release; the compliance roadmap commits to annual third-party pen tests with a named vendor (see compliance-roadmap.md).
• Customer-side image-signature verification. Today this is documented but not enforced at install time by the Marketplace images. A future install-time verification gate is in the roadmap.

Cross-references: byoc-architecture.md for the deployment model these artifacts apply to; compliance-roadmap.md for the dated commitments above; caiq-lite.md for the CSA-mapped controls.