Infrastructure worth keeping — and kept patched.

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. [TO-VERIFY: pipeline: signed and checked at every stage of the v0.3 chain] This page says how.

DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live. [TO-VERIFY: source] marks a fact that must be checked against the v0.3 release; the source (cache, pipeline or payments) is named in the marker.

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. [TO-VERIFY: pipeline: the v0.3 chain, secured before the product ships]

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. [TO-VERIFY: pipeline: the signing identity is pinned to the release workflow and tag; no manual release path in v0.3]

The steps a release goes through

Signed at every stage, verified together at release. Each stage signs its own statement about the exact files, 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. [TO-VERIFY: pipeline: each v0.3 stage signs its own statement; the Release stage verifies all together]

  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. [TO-VERIFY: pipeline: v0.3 source admission unchanged from v0.2.2]
  2. Build. The binaries and the image's packages are built once. The image is assembled from those signed packages, with no base image. [TO-VERIFY: cache: melange packages, apko image, no base image]
  3. Sign. A separate stage, with its own identity, records the build and signs it. [TO-VERIFY: pipeline: the Sign boundary stage; a distinct certificate subject for each stage, visible in the cosign output]
  4. Rebuild. The image is assembled again, independently, on a separate machine. The digests must be identical, or the release fails. [TO-VERIFY: pipeline: the Rebuild stage runs on a separate runner and identity, sharing no cache or inputs with Build]
  5. Check. The scanners we list (the list is in the repository) run against the exact images, and each signs its verdict for those digests. 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. [TO-VERIFY: pipeline: scanner list and acceptance suites at v0.3]
  6. Release. One step verifies every earlier signature together. Anything missing stops the release. Then the same digests are published, promoted without a rebuild, and checked again the way a customer would check them. [TO-VERIFY: pipeline: the Release job runs the same commands as the verify page]

The full description, as the pipeline actually runs, is in RELEASING.md. [TO-VERIFY: pipeline: RELEASING.md matches the v0.3 chain]

What you get with each release

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. [TO-VERIFY: cache/ops: the daily rescan; "kept patched" only after the first automatic patch release has been cut; the brief also says "new or abandoned upstream": that needs a written scope before a page can say it]

What we do not claim

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