For teams entering regulated markets

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 sell their way through that pile with compliance teams and six-figure contracts. 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. 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 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 be is evidence and validated crypto for your program — one row of that questionnaire where the answer is written, 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.
• Report a problem privately. See the security policy.

What is free, and what is not available yet

The evidence underneath is public and free: SBOMs, build provenance, signatures, VEX statements, and the FIPS 140-3 validated module and its certificate number. Anyone can verify it, with no account and no purchase. Paid support tiers are not available yet.

Verify everything for free first

Before spending 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 free evidence doesn't hold up under your audit, nothing we add on top 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.