How FosterStack Cache is built and signed

Every release is built by an automated pipeline, checked, signed, and published with files you can verify yourself. This page says what that means today.

Releases are built only in CI

No release file is ever made on a person's laptop, ours included. A release starts when a signed tag is pushed, and there is no manual release path. That is what makes the signatures mean something: nobody can forge a release that GitHub's own build machines never built.

The steps a release goes through

1. Source check. The tag and the commit must be signed by an allowed signer, sit on the main branch, and have every required check green.
2. Build. The binaries are built, with checksums and a software bill of materials for each archive.
3. Container images. Each image is assembled once, from the unmodified distroless base plus one binary.
4. Reproducibility check. The image is assembled a second time on a separate machine. The results must be identical, or the release fails.
5. Scans and tests. Every scanner on our list runs against the exact images. A finding blocks the release unless a published VEX statement explains why it does not apply. The Gradle and Maven acceptance tests run against the same images.
6. Authorization. One step checks that every earlier step produced signed proof for these exact files. Anything missing stops the release.
7. Publish. The published images are the same digests that were scanned and tested, promoted without a rebuild, and checked again the way a customer would check them.

The full description, as the pipeline actually runs, is in RELEASING.md.

What you get with each release

• Container images on GitHub's registry, signed without a stored key (Sigstore), with build provenance.
• Plain binaries and a checksums.txt with its own signature file.
• A software bill of materials (SBOM) for each binary archive.
• A VEX file saying which known vulnerabilities do and do not affect the release.
• A release-manifest.json listing every file and its digest.

All of it is public. You do not need an account or a purchase to check any of it. The commands are under "Verifying a release" in RELEASING.md.

Kept patched

The current release's images are scanned again every day, so a vulnerability disclosed against something we already shipped raises an issue without anyone having to remember to look.

What we do not claim

• Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (the scope is in SECURITY.md).
• The paid tiers are not built. Everything here is the free MIT core.