How our release pipeline maps to NIST SP 800-204C, 800-204D and SLSA
-This page takes the release pipeline that built FosterStack Cache v0.2.2 and puts each stage next to the NIST practice it maps to. It says where a stage only partly implements a practice, and it says which SLSA Build level we assess v0.2.2 at: Level 2, not Level 3.
-This is guidance we followed when designing the pipeline. It is not a certification.
-Words used here:
--
-
- SBOM: a parts list of what is inside a build. -
- VEX: a note on whether a known flaw affects us. -
- Provenance: a signed record of how and where something was built. -
- Digest: the fingerprint of a file or image. -
- SLSA: a public scale for how far you can trust the way software was built. Its Build track runs from Level 0 to Level 3. -
The two NIST documents
--
-
- NIST SP 800-204C, Implementation of DevSecOps for a Microservices-based Application with Service Mesh. We use its pipeline sections, mainly sections 4.6 and 4.8. -
- NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines. We use sections 4 and 5, mainly sections 5.1.1 and 5.2. -
Parts of both documents cover running services in your own cluster, such as service mesh and GitOps. That is your environment, not our release pipeline, so this page does not map it.
- -Stage by stage: what runs, and which practice it maps to
-This describes the workflow files as they were at the v0.2.2 tag. What changed since v0.2.1 is listed after the table. "Signs" means the stage records what it did and signs it, with a short-lived key and no stored signing key. The signature is tied to that stage's own workflow and logged in a public transparency log.
-| Stage | What it does in v0.2.2 | NIST practice | How much |
|---|
| Stage | What it does | NIST practice | How much |
|---|---|---|---|
| Source admission | -The tag must be annotated, signed and strictly named: signed by the owner's key or, for an automatic patch tag only, by the release workflow's own keyless identity. The commit must be signed (by the owner's key, or GitHub's own key for merges made on github.com) and be on main. Every required check must pass on that exact commit or, for the checks that run only on pull requests, on the pull request that produced it. An owner-approved requirements list must exist for the version. The lists of allowed signers and required checks are read from main, not from the tagged commit. Signs. |
- 800-204D 5.1.4 "Secure Code Commits" (commit-signing enforcement, COMMIT-REQ-2); 5.1.2 "Secure Pull-Push Operations on Repositories" (automated checks before code is trusted) | -Partly. There is one maintainer, so no second person reviews or approves a change. | -
| Build | -Builds the binaries once on a fresh GitHub-hosted machine with the toolchain pinned, and checks that the dependency files did not change. Writes checksums and an SBOM per archive. Signs a build statement and SLSA provenance. | -800-204D 5.1.1 "Secure Build"; 800-204C 3.3.3 (SBOM generation and code signing as pipeline tasks) | -Partly. The signing runs in the same job as the build steps, not in a separate, more trusted process as 5.1.1 asks. | -
| Image assembly | -Checks every archive against the signed build statement before opening it. Adds one binary to a base image pinned by digest, with no commands run inside the image, using a BuildKit image that is also pinned by digest. Pushes by digest only, with no version tags, to a separate candidates package. Signs, recording the base digest and binary hashes, plus SLSA provenance. | -800-204D 4.2: "The inputs and outputs of each build step should be verified" | -Matches the practice as we read it. | -
| Reproducibility check | -Assembles the images again on a separate machine. The digests must match, or the release fails. Signs. | -No direct match in either document. | -Not mapped. It repeats the image assembly; it does not rebuild the binaries from source. | -
| Scans | -Two scanners with different vulnerability databases run, each on its own machine. They first check the image-assembly and reproducibility statements, then scan every platform image of every variant. One also scans the archives, the other the Go module files. Any finding blocks the release, even the lowest-rated one. For one of the two scanners, a published VEX statement can clear a finding. Each scanner signs its verdict for the exact digests. | -800-204C 4.8 and 4.8.1 (container image scans, software composition analysis); 800-204D 5.2, DEPLOY_REQ-4 (evidence the image was scanned) | -Partly. The release pipeline runs no static or dynamic application security testing itself. The signed verdict records a pass, not the full scan report. | -
| Acceptance tests | -Run against the exact candidate images: the Linux archives and binaries (macOS archives are checked, not run), the images on both CPU architectures, the image variants, the Gradle and Maven test suites, the Kubernetes setup from our docs, and a test that the server makes no outbound connections. A final job checks that every release-blocking acceptance test in the approved list passed, then signs one statement. | -800-204C 3.3.1 (tests run in the pipeline; an organisation may choose to stop the pipeline when a test fails); 4.6 (stop further pipeline tasks if a test fails) | -Matches the practice as we read it. The individual test jobs do not sign their own results. | -
| Release authorization | -Verifies every earlier statement: signed by the expected stage, naming this commit and these digests, scan verdicts pass, acceptance results complete. Anything missing stops the release. It also stops the release if a VEX statement says a flaw affects us and no owner acceptance of that risk is recorded. Records each statement's transparency-log entry. Signs the approval. | -800-204C 4.6: "verify that all required signatures … are present to ensure that no one bypasses the pipeline"; 800-204D 5.1.1 (policy checks that the required attestations are found) | -Partly. The policy is code in the workflow file, not a separate signed policy document as 5.1.1 describes. | -
| Promotion and publish | -Will not start without the signed approval. Copies the approved digests to GitHub's registry and the Docker Hub mirror with no rebuild, and checks the digests did not change. Signs the public images and the checksums file. Publishes the VEX statements in three forms: OpenVEX, scanner suppression rules and CSAF 2.0. Uploads the release files, re-checks the image signatures, the signed checksums and every tag the way a customer would, without credentials, then makes the release page public. | -800-204D 5.2, DEPLOY-REQ-3 (only an artifact made by the approved build process is cleared) | -Partly. Promotion only copies the digests named in the signed approval. Enforcing that at deploy time is up to your own environment. | -
| Signing, across all stages | -Keyless signing: a short-lived signing identity per stage, no stored signing key, every signature logged publicly. | -800-204C 4.6: "signing the release artifact during each required CI/CD stage (preferably multi-party signing)"; 800-204D 5.1.1 (attestations signed, stored tamper-proof) | -Partly. Not multi-party: every signature is made by automation in one repository, run by one maintainer. | -
| Evidence bundle | -release-manifest.json lists every digest, the hash of the approved requirements list, per-test results, and the transparency-log entry of every statement the authorization verified. It is attached to each image in GitHub's registry as a signed statement and published with the SBOMs, VEX file and signed checksums. |
- 800-204D 4 (record provenance, with a way to verify and authenticate it) | -Matches the practice as we read it. Neither document has a section on VEX. | -
| Source admission | [TO-VERIFY] whether unchanged from v0.2.2: signed tag, signed commit on main, required checks passed. | [TO-VERIFY] 800-204D 5.1.4 and 5.1.2 | [TO-VERIFY] |
| Build | [TO-VERIFY] Builds the binaries and the signed packages once. The image is assembled from those packages, with no base image. | [TO-VERIFY] 800-204D 5.1.1 | [TO-VERIFY] |
| Sign | [TO-VERIFY] A separate stage records the build and signs it under its own identity, from the build's digest list only. | [TO-VERIFY] the part of 5.1.1 that asks for signing outside the build steps | [TO-VERIFY] |
| Rebuild | [TO-VERIFY] Builds the release again, independently. The digests must match or the release fails. | [TO-VERIFY] none found in either document | [TO-VERIFY] |
| Check | [TO-VERIFY] Scans and acceptance tests run against the exact candidate images, and the stage signs a verdict for those digests. | [TO-VERIFY] 800-204C 4.8 and 800-204D 5.2 | [TO-VERIFY] |
| Release | [TO-VERIFY] Verifies every stage's signature together, then publishes the same digests. | [TO-VERIFY] | [TO-VERIFY] |
What changed from v0.2.1 to v0.2.2
-The v0.2.2 tag changed 31 workflow files. The build stage and the scan stage did not change. These did:
--
-
- Admission. A tag can be signed two ways: with the owner's key, as before, or, for an automatic patch tag only, with the release workflow's own keyless signature, whose certificate must name
release.ymlonmainof this repository for the tagged commit. For such a patch tag the approved requirements list must be byte for byte the one from the line's latest owner-signed tag.
- - Image assembly and reproducibility. The BuildKit image is pinned by digest. -
- Authorization. It reads the requirements list that admission chose, and it has the new VEX risk-acceptance check described in the table. -
- Promotion. It publishes the VEX statements in three forms, takes the release notes of an automatic patch release from the tag message, and records the requirements list it used in the manifest. -
- Acceptance tests. The two test workflows were merged into one file. The suites are the same, and the four acceptance stage files had small edits. -
- The release workflow. It also runs on pushes to
mainand once a day, but on those runs only the newdecideandpatch-notesjobs can run. A newpatch-failedjob opens an issue when a release run fails. The release run for v0.2.2 has 19 jobs where the v0.2.1 run had 16, and the three new jobs are not on the build, sign and promote path.
-
Which SLSA Build level do we assess v0.2.2 at?
-We assess v0.2.2 at SLSA Build Level 2, against the SLSA v1.0 requirements and levels. We do not claim Build Level 3.
--
-
- Consistent build process (L1). Met, by our reading. One workflow builds every v0.2 release. Only a tag push starts the build job, and the first stage stops any tag not signed by the owner's key or, for an automatic patch tag, the release workflow's own identity. -
- Provenance exists (L1). Met, by our reading. SLSA v1 provenance covers the binary archives, their SBOMs,
checksums.txt, and the three container images, naming each digest, the source commit and the workflow run.
- - Distribute provenance (L1). Met, by our reading. It is in GitHub's attestation store, and
gh attestation verifyreturns it.
- - Hosted build platform (L2). Met, by our reading. The build and image jobs ran on GitHub-hosted
ubuntu-latestmachines, never on a workstation. The build job's log shows image ubuntu-24.04, version 20261004.327.1.
- - Provenance is authentic (L2). Met, by our reading. The provenance is signed with a short-lived certificate issued to the building workflow, and the signature is logged in a public transparency log. The image, reproducibility and scan stages check who signed the statement before them. The acceptance tests do not. The build, the release authorization and the publishing step also check the source commit and the tag. You can check them yourself. -
Level 3 is not claimed. It asks the build platform to "prevent runs from influencing one another, even within the same project" and to "prevent secret material used to sign the provenance from being accessible to the user-defined build steps". We have not shown either. In v0.2.2 the build job can ask for a signing identity for the whole job, and it also runs this repository's build configuration and compiles its code: the goreleaser hooks and the Go build. The image job can ask for a signing identity too, and it builds this repository's Dockerfiles. So the build steps could reach the signing, and Level 3 needs that kept apart. The build job also restored a GitHub Actions cache written by earlier runs, and we have not shown that other workflows or branches cannot write to it. The spec calls that "cache poisoning" under its "Isolated" requirement. Build Level 3 is not claimed for v0.2.2.
- -What we do not meet
+Our wording: signed at every stage, verified together at release.
+SLSA
+[TO-VERIFY] The SLSA Build level we assess v0.3.0 at. We claim Level 3 for the Build stage only after a test shows that a malicious build step cannot produce provenance the release step accepts. Until that test has passed, this page says nothing about Level 3.
What this page does not say
-
-
- SLSA Build Level 3. -
- We rely on GitHub-hosted machines being a fresh, isolated machine for each job. We have not checked that ourselves. -
- The promotion job holds the Docker Hub token and also runs helper scripts from this repository, in the same job that signs the public images. We do not describe promotion as isolated. -
- Evidence made by a separate, more trusted process than the build itself (800-204D 5.1.1). -
- A second person: one maintainer writes, approves and releases every change. No review by another person, and no multi-party signing (800-204D 5.1.2, 800-204C 4.6). -
- All signing is automated. 800-204D 5.1.3, written for software update systems, points the same way: multiple keys with threshold trust, and automated keys kept out of roles customers rely on. -
- The acceptance test jobs pass their results to the job that signs them; they do not sign or verify statements themselves. -
- No dynamic application security testing, and no static testing inside the release pipeline. -
- The release policy is workflow code, not a separate signed policy document. -
- The reproducibility check covers image assembly, not a second build of the binaries from source. -
- Promoted images are in the public registries a few steps before the final customer-style checks finish. Only the release page waits for those checks. -
- Scan verdicts are signed, but the full scan reports are not published as release files. -
- Checking provenance with
gh attestation verifyneeds a GitHub token. Thecosignchecks need no account.
-
Check it yourself
-This checks the SLSA provenance of the v0.2.2 image and the workflow that signed it:
-$ gh attestation verify oci://ghcr.io/fosterstack/cache:0.2.2 \
- --repo fosterstack/cache \
- --signer-workflow fosterstack/cache/.github/workflows/stage-image.yml-
-
- Verify a release: every check we ran against v0.2.2, with its real output. -
- The v0.2.2 release run: 19 jobs, in three attempts. The images were built and authorized in attempt 2, and attempt 3 published them (see Verify a release). -
- The v0.2.1 release run: all 16 jobs. -
- What changed from v0.2.1 to v0.2.2, including the workflow files. -
- The v0.2.2 release: SBOMs, VEX files, signed checksums and
release-manifest.json.
- - RELEASING.md at v0.2.2: the pipeline in the maintainer's words. -
- The workflow files at v0.2.2, starting with release.yml and stage-authorize.yml. +
- No stage here is certified by anyone. +
- Parts of both NIST documents cover running services in your own cluster. That is your environment, so this page does not map it.
Section numbers refer to the final published versions of NIST SP 800-204C and NIST SP 800-204D. This is guidance we followed when designing the pipeline. It is not a certification.
- -Related: verify a release yourself and how releases are built and signed.
More than kept patched.
@@ -144,7 +145,6 @@More than kept patched.
[TO-VERIFY: pipeline: the Rebuild stage][TO-VERIFY: cache: image assembled from signed packages; production and fips images only]How we build · Security policy · Verify a release
@@ -153,7 +153,7 @@Built to be verified, not trusted
The answer is to make everything checkable:- MIT-licensed core. Read the code before you run it. -
- One public container image. Free and paid users pull the identical bytes — scan exactly what you deploy. +
- One public container image per variant. Free and paid users pull the identical bytes — scan exactly what you deploy.
- When the paid tiers ship, a license key will unlock them in the same public image — no private registry, no gated downloads. (They are not built; the pricing below is direction, not a shelf.)
- Security patches are never withheld from the free tier. Not delayed, not embargoed — never.
- Signed commits, signed releases, public release notes. The repository's SECURITY.md states exactly what the release evidence does and does not prove today. @@ -164,7 +164,7 @@
- No telemetry, and no required FosterStack connection. The server
reports nothing to us — no usage data, no license check, no update ping — and today's
free core makes no outbound connections at all: it works identically on a machine with
- no route to the internet. When the paid features ship, the only outbound traffic will
+ no route to the internet.
[TO-VERIFY: cache: also true of the v0.3 server]When the paid features ship, the only outbound traffic will be what you configure (your identity provider for SSO, your peer replicas for HA) — endpoints you choose, never FosterStack. - This website collects no email addresses. There is no signup
@@ -180,7 +180,7 @@
What we do not collect
Pricing
Per product. Free is the full product.
-Paid tiers are described here, not sold: checkout is not open, and SSO, multi-user access control, usage analytics, HA/replication and named-version LTS are not built.
+[TO-VERIFY: payments: what is and is not built when v0.3 ships]Paid tiers are described here, not sold: checkout is not open, and SSO, multi-user access control, usage analytics, HA/replication and named-version LTS are not built.
-Free Team Business Compliance From 9e8bb998053746a42f8fe7df15b65e36591b7f45 Mon Sep 17 00:00:00 2001 From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com> Date: Sat, 10 Oct 2026 22:18:01 -0400 Subject: [PATCH 08/40] v0.3 trust pages: markers on the unmarked v0.3 facts, the abandoned-upstream sentence --- how-our-pipeline-maps-to-nist-and-slsa/index.html | 2 +- how-we-build/index.html | 8 ++++---- verify-a-release/index.html | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/how-our-pipeline-maps-to-nist-and-slsa/index.html b/how-our-pipeline-maps-to-nist-and-slsa/index.html index a52f7e3..eb423d2 100644 --- a/how-our-pipeline-maps-to-nist-and-slsa/index.html +++ b/how-our-pipeline-maps-to-nist-and-slsa/index.html @@ -105,7 +105,7 @@ Stage by stage
Release [TO-VERIFY]Verifies every stage's signature together, then publishes the same digests.[TO-VERIFY][TO-VERIFY]Our wording: signed at every stage, verified together at release.
+Our wording: signed at every stage, verified together at release.
[TO-VERIFY: pipeline]SLSA
[TO-VERIFY]The SLSA Build level we assess v0.3.0 at. We claim Level 3 for the Build stage only after a test shows that a malicious build step cannot produce provenance the release step accepts. Until that test has passed, this page says nothing about Level 3.What this page does not say
diff --git a/how-we-build/index.html b/how-we-build/index.html index 5877219..2d10790 100644 --- a/how-we-build/index.html +++ b/how-we-build/index.html @@ -91,7 +91,7 @@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.
+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.
[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
@@ -116,14 +116,14 @@What you get with each release
- Container images on GitHub's registry, signed without a stored key (Sigstore), with build provenance.
[TO-VERIFY: pipeline/cache: v0.3 image signing and provenance] - Plain binaries and a
checksums.txtwith its own signature file.[TO-VERIFY: cache fix A #276: which files the signed checksums list covers]
- - 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 software bill of materials (SBOM) for each binary archive.
[TO-VERIFY: cache: v0.3 release assets]
+ - A VEX file saying which known vulnerabilities do and do not affect the release.
[TO-VERIFY: cache: v0.3 release assets] - A
release-manifest.jsonlisting every file and its digest.[TO-VERIFY: cache: manifest layout at v0.3]
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.
+[TO-VERIFY: cache/ops: the daily rescan, and automatic patch releases not yet cut]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, including software its own maintainers have abandoned.
[TO-VERIFY: cache/ops: the daily rescan; "kept patched" only after the first automatic patch release has been cut; what is covered when upstream has abandoned a component]What we do not claim
-
diff --git a/verify-a-release/index.html b/verify-a-release/index.html
index 09edf3a..f2df7a5 100644
--- a/verify-a-release/index.html
+++ b/verify-a-release/index.html
@@ -88,7 +88,7 @@
- Signed releases you can verify in minutes. +
- Signed releases you can verify in minutes. We secure our own pipeline the same way, first: how we build.
[TO-VERIFY: pipeline: the v0.3 chain and the verify guide] - Build record, parts list (SBOM) and vulnerability statements published with every release.
- Scanned before every release. The current release is rescanned every day. -
- Images assembled twice on separate machines; the results must match. -
- Minimal image, no telemetry. FIPS variant available. +
- Every release is rebuilt independently; the results must match.
[TO-VERIFY: pipeline: the Rebuild stage]
+ - Minimal image with no base image, no telemetry. FIPS variant available, built from the same source as the standard image.
[TO-VERIFY: cache: image assembled from signed packages; the FIPS and standard images come from two builds of one source] - Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (the scope is in SECURITY.md).
- To get a fix, move to the latest release. Older releases are not on the supported list. +
- To get a fix, move to a supported release.
[TO-VERIFY: cache: which releases are supported once v0.3.0 is out] - Pin the image to an exact version or digest, not
latest, so a deploy never changes without you choosing it. - Upgrade on a routine. A build cache is disposable, so an upgrade that goes wrong costs you slower builds while it refills, not lost work.
- Watch the repository's releases on GitHub. It is the one notice channel, and you can stop at any time. We do not collect email.
- Container images, signed without a stored key (Sigstore), with build provenance.
checksums.txtwith its own signature file.
@@ -129,7 +132,7 @@ - The server has a read-write login and an optional read-only login. There is no per-person identity.
- The paid tiers are not built. -
- We are not announcing an LTS line, a support period, or a date. +
- We do not promise a date for any release or any support period.
[TO-VERIFY: cache/owner: the support terms for the v0.3.0 long-term-support line] - 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] - 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]
- - Sign. A separate stage, with its own identity, records the build and signs it.
[TO-VERIFY: pipeline: the Sign boundary stage and its own identity]
- - Rebuild. The release is built again, independently. The results must be identical, or the release fails.
[TO-VERIFY: pipeline: the Rebuild stage]
- - Check. 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.
[TO-VERIFY: pipeline: scanner list and acceptance suites at v0.3]
- - 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 stage]
+ - 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]
+ - 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]
+ - 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]
+ - 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] - Vulnerable dependencies fixed fast: our target is 48 hours from disclosure (the scope is in SECURITY.md). -
- A signature shows who signed these exact files. It does not show the software has no bugs. +
- 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.
- A valid signature proves who signed these exact bytes. +
- A valid signature proves who signed these exact files.
- Provenance proves which workflow and run produced them.
- It does not prove the software has no bugs.
- Linux only.
[TO-VERIFY]v0.3.0 ships Linux archives (amd64 and arm64) and no macOS archive. If you run the server on a Mac, run the container image or a Linux machine instead.
- - No
-debugimage.[TO-VERIFY]The images areproductionandfips. To look inside a running container, usekubectl debugordocker debug.
- - Oversized requests.
[TO-VERIFY]A request with more than 500 header values is rejected with431before it reaches the cache. Gradle and Maven send far fewer.
+ - Linux only.
[TO-VERIFY: cache: the owner's Oct 9 answer; the platform requirement text is not ratified]v0.3.0 ships Linux archives (amd64 and arm64) and no macOS archive. If you run the server on a Mac, run the container image or a Linux machine instead.
+ - No
-debugimage.[TO-VERIFY: cache: the owner's Oct 9 answer; README section on debugging a running container]The images areproductionandfips. To look inside a running container, usekubectl debugordocker debug.
+ - Oversized requests.
[TO-VERIFY: cache: next-release notes (Go 1.27 behaviour); whether it ships in v0.3.0]A request with more than 500 header values is rejected with431before it reaches the cache. Gradle and Maven send far fewer.
Verify a FosterStack Cache release yourself
-You should not have to take our word for what you run. Each stage of a release is signed on its own, and the signatures are verified together at release. These commands check that yourself, using only
+cosign,ghandjq.You should not have to take our word for what you run. Each stage of a release is signed on its own, and the signatures are verified together at release.
[TO-VERIFY: pipeline]These commands check that yourself, using onlycosign,ghandjq.DRAFT for v0.3.0, not published and never merged before v0.3.0 is live.
[TO-VERIFY]marks anything not yet run against a real release.Use the image by digest for
<IMAGE_REF>. There are two images; run every step for each.[TO-VERIFY]which two variants.1. The signature and who signed it
@@ -100,7 +100,7 @@2. The digest is the one in the release
-# [TO-VERIFY] file name and layout gh release download <TAG> --repo fosterstack/cache -p release-manifest.json jq -r '.images[] | "\(.variant) \(.digest)"' release-manifest.jsonEvery statement names the image by digest, never by tag. The digest you verified should match this list.
+Every statement names the image by digest, never by tag.
[TO-VERIFY: pipeline]The digest you verified should match this list.3. How it was built
# [TO-VERIFY] signer workflow gh attestation verify oci://<IMAGE_REF> --repo fosterstack/cache \ From cda38c53e643ad3e498b989d3bbee951ba48d3f8 Mon Sep 17 00:00:00 2001 From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com> Date: Sat, 10 Oct 2026 22:18:01 -0400 Subject: [PATCH 09/40] v0.3 policy pages draft: security and regulated (WIP) --- regulated/index.html | 9 ++++++--- security/index.html | 15 +++++++++------ 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/regulated/index.html b/regulated/index.html index 5518bfd..389d0f1 100644 --- a/regulated/index.html +++ b/regulated/index.html @@ -1,6 +1,7 @@ +FosterStack for teams entering regulated markets @@ -89,6 +90,8 @@For teams entering regulated markets
FosterStack Cache gives the build-cache part of your pipeline public, checkable evidence: a FIPS 140-3 build, an SBOM, SLSA provenance, signatures and VEX statements. It does not make you compliant.
+DRAFT for v0.3, private preview, not published.
+[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.It usually starts with one customer. A contract lands on the table with federal or compliance requirements attached — FIPS-validated cryptography, @@ -119,11 +122,11 @@
What our piece does — and does not do
More than kept patched.
-
-
How we build · Security policy · Verify a release
diff --git a/security/index.html b/security/index.html index 85d42b0..fe4c06d 100644 --- a/security/index.html +++ b/security/index.html @@ -1,6 +1,7 @@ +Security policy: how to report a vulnerability @@ -88,6 +89,8 @@Security policy: how to report a vulnerability
Found a security problem in FosterStack Cache or on this website? Tell us privately. Here is how, what happens next, which version gets fixes, and what we sign and publish so you can check our work.
+DRAFT for v0.3, private preview, not published.
+[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.Report a vulnerability
-
@@ -97,20 +100,20 @@
Report a vulnerability
Send the report, not a patch. Please do not post details publicly before a fix ships.
-What we aim for
-Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (the scope is in SECURITY.md). Security patches are never withheld from the free tier: the same fix ships to everyone on the same day.
+Kept patched
+We keep FosterStack Cache patched, whether the problem is in our code or in a dependency that its own maintainers have abandoned.
[TO-VERIFY: cache/ops: "kept patched" holds only after the first automatic patch release has been cut; what is covered when upstream has abandoned a component]Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (the scope is in SECURITY.md). Security patches are never withheld from the free tier: the same fix ships to everyone on the same day.Long-term support: what is supported
-"LTS" means a version that keeps getting fixes for a stated period, so you can stay on it. The supported version is the latest minor release. That is the whole policy. There is no separate long-term-support line, no list of older versions that get fixes, and no support period to quote.
+"LTS" means a version that keeps getting fixes for a stated period, so you can stay on it.
[TO-VERIFY: cache/owner: v0.3.0 is the only long-term-support line, and what that promises is not written yet]Today the supported version is the latest minor release: there is no list of older versions that get fixes.-
-
What we sign and publish
-Releases are built only in CI. Each one comes with files you can check without an account:
+Releases are built only in CI. Every release is signed and checked at every step, and each one comes with files you can check without an account.
[TO-VERIFY: pipeline/cache: the v0.3 chain; the four metadata files signed via the signed checksums list (cache fix A)]What we do not claim
Machine-readable contact: security.txt.
From 1bab23fa3ec64f6c7331e57a461f0974a0d3c061 Mon Sep 17 00:00:00 2001 From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com> Date: Sat, 10 Oct 2026 22:18:33 -0400 Subject: [PATCH 10/40] v0.3 trust pages: overstated sentences narrowed or marked, one stage description, draft notices --- .../index.html | 6 ++--- how-we-build/index.html | 22 +++++++++---------- verify-a-release/index.html | 4 ++-- 3 files changed, 16 insertions(+), 16 deletions(-) diff --git a/how-our-pipeline-maps-to-nist-and-slsa/index.html b/how-our-pipeline-maps-to-nist-and-slsa/index.html index eb423d2..8e48cd7 100644 --- a/how-our-pipeline-maps-to-nist-and-slsa/index.html +++ b/how-our-pipeline-maps-to-nist-and-slsa/index.html @@ -4,9 +4,9 @@ -NIST SP 800-204C, 800-204D and SLSA: Our Release Pipeline +How our release pipeline maps to NIST and SLSA (draft) - + @@ -93,7 +93,7 @@How the v0.3.0 release pipeline maps to NIST and SLSA
DRAFT for v0.3.0, not published and never merged before v0.3.0 is live.
[TO-VERIFY]marks anything not yet run against a real release.This is guidance we followed when designing the pipeline. It is not a certification.
Stage by stage
-"Signs" means the stage records what it did and signs it with a short-lived key, under its own workflow identity, logged in a public transparency log.
+[TO-VERIFY]against the workflow files at the v0.3.0 tag.The six stages are described step by step on how we build. "Signs" means the stage records what it did and signs it with a short-lived key, under its own workflow identity, logged in a public transparency log.
[TO-VERIFY]against the workflow files at the v0.3.0 tag.Stage What it does NIST practice How much How FosterStack Cache is built and signed - + - + @@ -92,23 +92,23 @@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.
+[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.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
-FosterStack's business is helping organisations secure their build and release pipeline. We started with a build cache your team can know is secure, and we secure our own release pipeline the same way before we ask you to trust it.
+[TO-VERIFY: pipeline: the v0.3 chain, secured before the product ships]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 makes the signatures mean something: nobody can forge a release that GitHub's own build machines never built.
+[TO-VERIFY: pipeline: no manual release path in v0.3]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 no stage takes the one before it on trust.
+[TO-VERIFY: pipeline: each v0.3 stage signs its own statement; the Release stage verifies all together]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]The full description, as the pipeline actually runs, is in RELEASING.md.
@@ -128,7 +128,7 @@[TO-VERIFY: pipeline: RELEASING.md matches the v0.3 chain]Kept patched
What we do not claim
Verify a FosterStack Cache release yourself
-You should not have to take our word for what you run. Each stage of a release is signed on its own, and the signatures are verified together at release.
+[TO-VERIFY: pipeline]These commands check that yourself, using onlycosign,ghandjq.You should not have to take our word for what you run. Each stage of a release is signed on its own, and the signatures are verified together at release.
[TO-VERIFY: pipeline]These commands check the final signature, how the image was built, its parts list and what it was assembled from, using onlycosign,ghandjq.DRAFT for v0.3.0, not published and never merged before v0.3.0 is live.
[TO-VERIFY]marks anything not yet run against a real release.Use the image by digest for
<IMAGE_REF>. There are two images; run every step for each.[TO-VERIFY]which two variants.1. The signature and who signed it
@@ -117,7 +117,7 @@5. What the image was assembled from
cosign verify-attestation <IMAGE_REF> --type '<INPUTS_TYPE>' ... | jq '<FILTER>'What this proves
-
-
FosterStack Cache changelog: v0.1.0 to v0.2.2 @@ -90,6 +91,11 @@FosterStack Cache changelog: v0.1.0 to v0.2.2
The release notes from GitHub, quoted as published. Newest first. For anything else, the releases page is the source.
+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.v0.3.0
+The v0.3.0 release notes will be quoted here as published, like the others.
+[TO-VERIFY: cache: the v0.3.0 release notes; nothing here is written before the release exists]v0.2.2
Release name: fscache v0.2.2. Published 2026-10-09.
@@ -106,7 +112,7 @@
v0.2.1
v0.2.0
-No release was published for v0.2.0: the tag exists, but its release run failed. Use v0.2.2, the latest release.
+No release was published for v0.2.0: the tag exists, but its release run failed.
v0.1.0
Published 2026-08-22.
diff --git a/fips-140-3-build-cache/index.html b/fips-140-3-build-cache/index.html index 5f19091..38b8293 100644 --- a/fips-140-3-build-cache/index.html +++ b/fips-140-3-build-cache/index.html @@ -1,6 +1,7 @@ +FIPS 140-3 build cache: run the FIPS image and confirm it @@ -87,10 +88,11 @@FIPS 140-3 build cache: run the FIPS image and confirm it
-FosterStack Cache has a FIPS build that uses Go's validated FIPS 140-3 cryptographic module. This page shows how to run it and how to see for yourself that it is in FIPS mode. The outputs below are from the real 0.2.2 images.
+Your contract asks for FIPS-validated cryptography, and you have to show what your build cache actually runs. FosterStack Cache has a FIPS build that uses Go's validated FIPS 140-3 cryptographic module. This page shows how to run it and how to see for yourself that it is in FIPS mode. The outputs below are from the real 0.2.2 images.
+[TO-VERIFY: cache: re-run on the v0.3 FIPS image; the module version and status output]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.What the FIPS build is
-It is the same source as the standard build, compiled so that it uses Go's validated FIPS 140-3 module (CMVP certificate #5247). It is available as a container image tag ending in
+-fips, and as Linux binaries for amd64 and arm64. There is no macOS FIPS build.It is the same source as the standard build, compiled so that it uses Go's validated FIPS 140-3 module (CMVP certificate #5247).
[TO-VERIFY: cache: at v0.3 the FIPS and standard images come from two builds of one source]It is available as a container image tag ending in-fips, and as Linux binaries for amd64 and arm64. There is no macOS FIPS build.[TO-VERIFY: cache: v0.3 ships Linux archives only (amd64 and arm64), and the images are production and fips]Run it
docker run -d -p 127.0.0.1:8080:8080 -v fscache-data:/home/nonroot \ diff --git a/regulated/index.html b/regulated/index.html index 389d0f1..6fd99f0 100644 --- a/regulated/index.html +++ b/regulated/index.html @@ -90,7 +90,7 @@For teams entering regulated markets
FosterStack Cache gives the build-cache part of your pipeline public, checkable evidence: a FIPS 140-3 build, an SBOM, SLSA provenance, signatures and VEX statements. It does not make you compliant.
-DRAFT for v0.3, private preview, not published.
+[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.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.It usually starts with one customer. A contract lands on the table with diff --git a/security/index.html b/security/index.html index fe4c06d..09e30ee 100644 --- a/security/index.html +++ b/security/index.html @@ -89,7 +89,7 @@
Security policy: how to report a vulnerability
Found a security problem in FosterStack Cache or on this website? Tell us privately. Here is how, what happens next, which version gets fixes, and what we sign and publish so you can check our work.
-DRAFT for v0.3, private preview, not published.
+[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.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.Report a vulnerability
From 1bd995b770948d6a4d7409801bf0a0eeaa1b2df7 Mon Sep 17 00:00:00 2001 From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com> Date: Sat, 10 Oct 2026 22:19:05 -0400 Subject: [PATCH 12/40] v0.3 changelog draft: a neutral title --- changelog/index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/changelog/index.html b/changelog/index.html index e1b3f40..7c6ce8c 100644 --- a/changelog/index.html +++ b/changelog/index.html @@ -4,9 +4,9 @@ -FosterStack Cache changelog: v0.1.0 to v0.2.2 +FosterStack Cache changelog - + @@ -88,7 +88,7 @@Infrastructure worth keeping — and kept patched.- FosterStack Cache changelog: v0.1.0 to v0.2.2
+FosterStack Cache changelog
The release notes from GitHub, quoted as published. Newest first. For anything else, the releases page is the source.
DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.
From 2f3a9cb855d339923b44ccda04feeb78910a80ec Mon Sep 17 00:00:00 2001 From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com> Date: Sat, 10 Oct 2026 22:19:34 -0400 Subject: [PATCH 13/40] v0.3 product pages draft: the laptop page and what's new, markers with sources --- laptop-builds-reuse-ci-build-cache/index.html | 7 +++++++ whats-new-fosterstack-cache-v0-3-0/index.html | 18 ++++++++++-------- 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/laptop-builds-reuse-ci-build-cache/index.html b/laptop-builds-reuse-ci-build-cache/index.html index a70b19f..4bd80b3 100644 --- a/laptop-builds-reuse-ci-build-cache/index.html +++ b/laptop-builds-reuse-ci-build-cache/index.html @@ -1,6 +1,7 @@ +[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.Your Laptop Builds Reuse What CI Already Built @@ -89,6 +90,8 @@Your laptop builds reuse what CI already built
CI builds your code, and then your laptop builds the same code again from scratch. FosterStack Cache is a build cache server you run yourself: CI stores its results there, and your laptop takes them instead of redoing the work.
+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.How it works
-
@@ -109,6 +112,10 @@
What has to match
Keep those the same on laptops and CI. For what to expect after an upgrade, see we upgraded Gradle or Maven and builds got slow. If your laptop still rebuilds, see why the Gradle hit rate is low or why the Maven cache is not restoring. To set it up, see Maven remote build cache setup and the Gradle setup in the CI-writes page.
+A cache every laptop trusts is a cache you can check
+CI and every laptop trust the same server, so you should be able to see what it is. 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]We keep it patched, and we secure our own release pipeline the same way before we ask you to run it: how we build.[TO-VERIFY: cache/ops: "kept patched" only after the first automatic patch release has been cut]The server runs on Linux; a Mac laptop is a client.
+[TO-VERIFY: cache: v0.3 ships Linux archives and images only; the Mac-and-Linux result above was measured on 0.2.x]How we checked
Stored on Restored on Gradle Maven What changes for you in FosterStack Cache v0.3.0
-If you run FosterStack Cache for Gradle or Maven builds, these are the things to check before you upgrade from 0.2.2.
-DRAFT for v0.3.0, not published and never merged before v0.3.0 is live.
+[TO-VERIFY]marks anything not yet checked against the release itself.You run FosterStack Cache for Gradle or Maven builds and you want to know what an upgrade to v0.3.0 changes before you do it. These are the things to check, from your point of view.
+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.Check these before you upgrade
-
-
What stays the same
-
+[TO-VERIFY]The Gradle and Maven protocols, theFSCACHE_*settings and the data folder. No change is intended; confirm each against the release notes before this page says so.
+[TO-VERIFY: cache: unchanged at v0.3]The Gradle and Maven protocols, theFSCACHE_*settings and the data folder. No change is intended; confirm each against the release notes before this page says so.Kept patched
+[TO-VERIFY: cache/ops: "kept patched" only after the first automatic patch release has been cut; the abandoned-upstream scope]We keep FosterStack Cache patched, whether the problem is in our code or in a dependency its maintainers have abandoned.How the release is built
-
+[TO-VERIFY]Each stage of the release is signed on its own, and the signatures are verified together at release. The image is built from signed packages, with no base image. You can check all of it yourself: see verify a release yourself.[TO-VERIFY: pipeline: the v0.3 chain]Each stage of the release is signed on its own, and the signatures are verified together at release. The image is built from signed packages, with no base image. You can check all of it yourself: see verify a release yourself.Upgrading
-
+[TO-VERIFY]Whether the back-up and upgrade steps on the upgrade page change for this release. Support terms for v0.3.0:[TO-VERIFY].[TO-VERIFY: cache: the 0.2.2 to 0.3.0 upgrade steps]Whether the back-up and upgrade steps on the upgrade page change for this release. Support terms for v0.3.0:[TO-VERIFY: cache/owner: what the long-term-support line promises].Related: changelog and security policy.
- Container images on GitHub's registry, signed without a stored key (Sigstore), with build provenance.