For teams entering regulated markets

A contract lands with FIPS, SBOM and provenance requirements attached, and your build cache needs paperwork it has never had. FosterStack Cache gives that part of your pipeline public, checkable evidence: a FIPS 140-3 build, an SBOM, build provenance, signatures and VEX statements. It does not make you compliant.

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

It usually starts with one customer. A contract lands on the table with federal or compliance requirements attached — FIPS-validated cryptography, SBOMs, provenance, a security questionnaire with two hundred rows — and suddenly every tool in your build pipeline needs paperwork it has never had. Big vendors have compliance teams to get through that pile. Small teams mostly just lose the deal.

The cost of compliance shouldn't determine who gets to compete.

What our piece does — and does not do

FosterStack Cache is one component in your pipeline: a self-hosted remote build cache. It also serves Maven, 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, build provenance, keyless signatures, and published VEX statements. Our requirements and their evidence are public in the repository, criterion by criterion.

What it does not do: make you compliant. FedRAMP and CMMC attach to your service and your organization, never to a component you deploy. What a component can offer is evidence and validated crypto for your program: one row of that questionnaire, answered with something written, signed and checkable instead of a shrug.

What stands behind it

• Signed releases you can verify in minutes. How we sign and check our own releases: how we build.
• Build record, parts list (SBOM) and vulnerability statements published with every release.
• Scanned before every release. The current release is rescanned every day.
• The image of every release is assembled a second time, independently; the digests must match.
• Minimal image with no base image, no telemetry. FIPS variant available, built from the same source as the standard image.
• Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (the scope is in SECURITY.md).

How we build · Security policy · Verify a release

The evidence underneath is public: SBOMs, build provenance, signatures, VEX statements, and the FIPS 140-3 validated module and its certificate number. Anyone can verify it, with no account.

Verify everything yourself first

Before you decide anything: pull the -fips image (public, no login), run the signature and provenance verification commands in RELEASING.md, read the scan posture in SECURITY.md — including what it says is not yet proven — and check the requirements matrix that maps every product promise to its evidence. If the evidence doesn't hold up under your audit, nothing else would either. That's the test we invite.

Step by step: Verify a release yourself. To run the -fips image and confirm FIPS mode from its own startup log: FIPS 140-3 build cache.

The Compliance tier, plainly: the security evidence underneath — SBOMs, SLSA provenance, signatures, VEX statements, and the FIPS 140-3 validated module (CMVP certificate #5247) — is public and free, verifiable by anyone. What the tier describes is the authored analysis — a FIPS applicability statement mapping the validated module boundary onto this product — plus per-release attestation letters signed by FosterStack LLC, and time on your security questionnaires. FosterStack Cache is not "FedRAMP compliant" or "CMMC compliant"; those attach to your service and your organization, never to a component you deploy. It is validated crypto and publishable evidence for your compliance program.