From 054f55f5ad62d9efbe6149beb080a4b4f57c0d96 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 21:03:31 -0400
Subject: [PATCH 1/2] Regulated page: security block, owner's Maven line, links
to the verify and FIPS pages
---
regulated/index.html | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/regulated/index.html b/regulated/index.html
index 6d21657..aba79d3 100644
--- a/regulated/index.html
+++ b/regulated/index.html
@@ -93,7 +93,7 @@
For teams entering regulated markets
What our piece does — and does not do
FosterStack Cache is one component in your pipeline: a self-hosted remote
- build cache. For that component, we do the evidence work a compliance
+ build cache. Maven too, through the Apache Maven Build Cache Extension. For that component, we do the evidence work a compliance
program needs: the -fips build links Go's FIPS 140-3
validated cryptographic module (CMVP certificate #5247), and every
release ships with an SBOM, SLSA provenance, keyless signatures, and
@@ -108,6 +108,33 @@
What our piece does — and does not do
signed, and checkable instead of a shrug.
+
Security is the difference
+
Security is what sets this product apart. The release items below ship in the current release. The supply-chain items describe how we work today, in our own build and CI. You can check each one yourself.
+
Signed and verifiable
+
+
Signed releases. Images and the checksums file are signed with Sigstore, with no signing key stored anywhere. How to verify.
+
Build provenance. Every image and binary archive carries a signed statement naming the CI run that built it.
+
A bill of materials. Every binary archive ships with an SBOM.
+
Published vulnerability statements. A VEX file with each release says which known vulnerabilities do and do not affect it.
+
Reproducible. Each image is assembled a second time on a separate machine, and the digests must match or the release fails.
+
+
Supply chain
+
+
Pinned build steps. Every GitHub Action our releases use is pinned to an exact commit, and a check in CI enforces it on every change. The container base image is pinned by digest.
+
Hash-checked installs. Python tooling in our CI is installed with hash checking, so a swapped package is refused.
+
A 7-day wait. Our CI holds new dependency versions for 7 days before adopting them, and Dependabot has the same cooling-off period.
+
A daily supply-chain check. Once a day, everything our build and CI pull in (actions, tools, packages) is checked against public advisory databases and malicious-package reports. Any hit opens an issue.
+
Scanned before release. Two independent scanners with different databases check every release candidate, and any finding blocks the release unless a published VEX statement explains it. RELEASING.md.
+
Rescanned every day. Every published image is scanned again daily, so a new vulnerability in something we shipped raises an issue.
+
+
Small, quiet and patched
+
+
Tiny and quiet. A distroless image with one static program and no shell. It sends no telemetry and makes no outbound connections.
+
A FIPS build. A FIPS variant uses Go's validated FIPS 140-3 cryptographic module.
+
Patched for everyone. We aim to ship dependency fixes within 48 hours of disclosure. That is a target, not a promise. Security patches are never withheld from the free tier.
The evidence underneath is public and free — SBOMs, SLSA provenance,
@@ -133,6 +160,12 @@
Verify everything for free first
evidence doesn't hold up under your audit, the paid tier wouldn't either.
That's the test we invite.
+
+ Step-by-step, with the output of each command from a real release:
+ Verify a release yourself. To run the
+ -fips image and confirm FIPS mode from its own startup log:
+ FIPS 140-3 build cache.
+