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.

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, SLSA 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.

More than kept patched.

• Signed releases you can verify in minutes.
• 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.
• 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, 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.