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
+-
+
- 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. +
- Build. The binaries are built, with checksums and a software bill of materials for each archive. +
- Container images. Each image is assembled once, from the unmodified distroless base plus one binary. +
- Reproducibility check. The image is assembled a second time on a separate machine. The results must be identical, or the release fails. +
- 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. +
- Authorization. One step checks that every earlier step produced signed proof for these exact files. Anything missing stops the release. +
- 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.txtwith 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.jsonlisting 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
+Every published image is 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
+-
+
- We aim to ship fixes for dependency vulnerabilities within 48 hours of public disclosure. That is an intention, not a promise you can hold us to. +
- The paid tiers are not built. Everything here is the free MIT core. +