How FosterStack Cache is built and signed

You are about to run our software inside your build pipeline. How do you know the files you run are the ones we built? Every release is signed and checked at every step, and you can verify it yourself. This page says how.

DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.

We do it to our own pipeline first

We started with a build cache, and we secure our own release pipeline the same way before we ask you to run it.

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 lets the signatures mean something: a release that our CI workflow did not build does not carry its signature.

The stages a release goes through

Signed at every stage, verified together at release. Each stage signs a statement about what it did, each stage checks the one before it, and the Release stage verifies them all together. A signature shows who signed these exact files; it does not show the software has no bugs.

Build. The stage first checks that the tag is signed, then builds the binaries and both images, for amd64 and arm64, once. It signs what it built.
Sign. A separate stage, with its own identity, receives only the build's digests, records the build and signs it.
Rebuild. The same commit is built again on a fresh machine and every digest is compared with the first build. Any difference stops the release. It signs its result.
Check. The scanners we list (the list is in the repository), the Gradle and Maven tests and the no-phone-home test run against the exact images, and the stage signs its verdict for those digests. A finding blocks the release unless a published VEX statement explains why it does not apply.
Release. The only stage that can publish. It verifies every earlier signature together, then publishes the same digests that were built and judged, with no rebuild.

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 on verify a release yourself.

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. We keep it patched. Our target for vulnerable dependencies is 48 hours from disclosure (the scope is in SECURITY.md); more on the security page.

What we do not claim

A signature shows who signed these exact files. It does not show the software has no bugs, and it is not a certification by anyone.
The paid tiers are not built. Everything here is the free MIT core.

Verify a release yourself How each stage maps to NIST and SLSA

Moving off the free Build Cache Node? See what the end of life means and the migration guide.