From 5078abe2cd1b2f8acafc07bb9944457d1d0b28f3 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:20:04 -0400
Subject: [PATCH 1/7] Page: how FosterStack Cache is built and signed
---
how-we-build/index.html | 140 ++++++++++++++++++++++++++++++++++++++++
sitemap.xml | 4 ++
2 files changed, 144 insertions(+)
create mode 100644 how-we-build/index.html
diff --git a/how-we-build/index.html b/how-we-build/index.html
new file mode 100644
index 0000000..cba6653
--- /dev/null
+++ b/how-we-build/index.html
@@ -0,0 +1,140 @@
+
+
+
+
+
+How FosterStack Cache is built and signed
+
+
+
+
+
+
+
+
+
+
fosterstack
+
Infrastructure worth keeping — and kept patched.
+
+
+
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 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 approved images are copied to the public registry 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
+
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
+
+
Nobody runs it in a real build pipeline yet except us.
+
Scan results are visible in our public CI logs. They are not yet attached to each release as permanent evidence.
+
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.
+
+
+
+
diff --git a/sitemap.xml b/sitemap.xml
index 8c1e470..de6df3f 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -16,4 +16,8 @@
weekly1.0
+
+ https://fosterstack.com/how-we-build/
+ 2026-10-08
+
From b983dc2d74db6c0ae633a2466e43f7ea8ad08e70 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:20:16 -0400
Subject: [PATCH 2/7] How we build: drop the no-rebuild phrase pending the
README conflict
---
how-we-build/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/how-we-build/index.html b/how-we-build/index.html
index cba6653..885d74e 100644
--- a/how-we-build/index.html
+++ b/how-we-build/index.html
@@ -95,7 +95,7 @@
The steps a release goes through
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 approved images are copied to the public registry without a rebuild, and checked again the way a customer would check them.
+
Publish. The approved images are published to the public registry and checked again the way a customer would check them.
The full description, as the pipeline actually runs, is in RELEASING.md.
From 4e8bdd9788906769df7bc0f55212c29a75f7c6d0 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:21:37 -0400
Subject: [PATCH 3/7] How we build: published images are the tested digests,
promoted without a rebuild
---
how-we-build/index.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/how-we-build/index.html b/how-we-build/index.html
index 885d74e..04e120e 100644
--- a/how-we-build/index.html
+++ b/how-we-build/index.html
@@ -91,11 +91,11 @@
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 the unmodified distroless base plus one binary.
+
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 approved images are published to the public registry and checked again the way a customer would check them.
+
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.
From f2a0e13428d427f2dae3026c1c5e5ca342483e39 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:23:33 -0400
Subject: [PATCH 4/7] How we build: Maven acceptance wording; drop
scan-evidence bullet
---
how-we-build/index.html | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/how-we-build/index.html b/how-we-build/index.html
index 04e120e..f9d1c93 100644
--- a/how-we-build/index.html
+++ b/how-we-build/index.html
@@ -93,7 +93,7 @@
The steps a release goes through
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.
+
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 acceptance tests run against the same images. Maven acceptance coverage is in progress.
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.
@@ -115,7 +115,6 @@
Kept patched
What we do not claim
Nobody runs it in a real build pipeline yet except us.
-
Scan results are visible in our public CI logs. They are not yet attached to each release as permanent evidence.
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.
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 acceptance tests run against the same images. Maven acceptance coverage is in progress.
+
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 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.
From 2f533b4381bdbf10b0889902bc834280fa413966 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:36:36 -0400
Subject: [PATCH 6/7] How we build: Gradle and Maven acceptance tests (proved
on the v0.2.1 release run)
---
how-we-build/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/how-we-build/index.html b/how-we-build/index.html
index 648f153..f2bee00 100644
--- a/how-we-build/index.html
+++ b/how-we-build/index.html
@@ -93,7 +93,7 @@
The steps a release goes through
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 acceptance tests run against the same images.
+
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.