Why Apache 2.0 hardened images

There are three honest answers to “where does this base image come from” today, and most teams have lived all three at some point:

1. The upstream community image. Patched on a best-effort cadence. No signature you can verify against an organisational identity. SBOM if you’re lucky, attestation almost never. Free, but the patch SLA is whatever the upstream maintainers feel like that week.

2. A closed hardened-image vendor. Strong signatures, strong SBOMs, strong attestations, fast patch latency. Locked behind a per-pull subscription, a non-commercial-use carve-out, or both. The signature chain lives on infrastructure you don’t control. The binary you ship to production has someone else’s commercial terms attached to it.

3. Build it yourself. Strong everything, controllable everything, expensive everything. Most teams cost-account this at one or two FTEs of supply-chain engineering ongoing — which is fine when the workload justifies it, and crushing when it doesn’t.

Apache-2.0-licensed hardened images are a fourth answer. This post is about what that fourth answer actually buys you, and why we picked Apache 2.0 specifically.

What “Apache 2.0 hardened” means in practice

Apache 2.0 is a permissive licence with two clauses that matter here:

• § 2 (the grant). You get a perpetual, worldwide, royalty-free, irrevocable copyright licence to reproduce, prepare derivative works, publicly display, distribute, and sublicense the work.
• § 4 (redistribution). When you redistribute, you preserve the NOTICE attribution. That is the whole obligation.

For container images that means: pull the binary, run it, vendor the digest, redistribute under your own brand, repackage it inside an offline bundle, sublicense it to your downstream customers. All of that is allowed. The licence on the binary does not change, ever. And no clause of the licence reaches up into your downstream usage or imposes a copyleft obligation on your code.

That’s the deal you sign when you docker pull images.rasid.cc/<image>. There is no other deal.

Why permissive matters for production

Procurement teams have one big question about any binary you ship in production: what do we owe the upstream. With GPL-family licences, the answer is non-trivial and depends on how you link, deploy, and distribute. With proprietary subscriptions, the answer is “renewal every year and audit rights into your environment.” With Apache 2.0 hardened images, the answer is “preserve the NOTICE.”

That clarity is the procurement value. It is the reason Apache 2.0 — not GPL, not BSD-3, not MIT — is the licence most enterprise procurement departments will sign off on without escalating to legal.

What you get from us on top of the licence

The licence is the floor. On top of it, here’s what we ship per image:

Artifact	Format	Where
Image binary	OCI	images.rasid.cc/<image>:<tag>
Cosign signature	OCI artifact	cosign verify against our published key
Transparency-log inclusion	Rekor entry	rekor.rasid.cc
SBOM (machine-readable)	CycloneDX 1.5	cosign download sbom or direct HTTPS
SBOM (procurement)	SPDX 2.3	direct HTTPS
Build provenance	in-toto v1.0 + SLSA L3	cosign verify-attestation
Patch latency promise	published	Image lifecycle docs

This is what “hardened” actually unpacks to. Not a marketing badge — a list of artifacts your supply-chain pipeline can consume and verify.

Self-hosted signing chain

A point that matters more than it sounds like it should: our Sigstore chain is at fulcio.rasid.cc and rekor.rasid.cc, with the verification key at rasid.cc/.well-known/rasid-cosign.pub. The whole verification path touches only Rasid-operated infrastructure.

The pragmatic consequence: when you bake cosign verify into your CI, you’re not building a dependency on a foreign signing root, a foreign transparency log, or a third-party identity provider. If our signing chain goes away, you can vendor the public key into your verification policy and the chain you’ve already verified continues to verify offline.

For air-gap workloads, this is the difference between “the air-gap bundle is self-verifying” and “the air-gap bundle assumes a live network call to a CDN-hosted Sigstore”. We picked the first one.

What’s not included, on purpose

Some things we deliberately do not ship in the public catalogue:

• The build pipeline source. That’s proprietary. It is the operational machinery that produces the binaries. You don’t need it to verify what we shipped, and we don’t publish it.
• A community PR channel. We do not accept external pull requests against the build pipeline. Customer feature requests come via support contracts.
• A non-commercial carve-out. There isn’t one. The licence is Apache 2.0 for everyone.
• Vendor-locked extensions to OCI. What we ship is standards-compliant OCI Distribution v2. You can swap us out for an upstream image and everything still works.

The enterprise tier, briefly

The enterprise tier is what funds the work. It is also the only way to get:

• FIPS 140-3 cryptographic variants of language runtimes and TLS stacks.
• Air-gap delivery bundles with signatures, SBOMs, attestations packed for disconnected operation.
• Compliance evidence packs mapped to your audit framework.
• Private custom builds of your internal services, on the same daily pipeline as the public catalogue.
• Patch-time, advisory-response, and escalation SLAs against a named on-call.

If those don’t apply to your workload, the public Apache 2.0 catalogue is the whole product. That is by design.

The smallest evaluation that proves it

docker pull images.rasid.cc/postgres:17
cosign verify images.rasid.cc/postgres:17 \
  --key https://rasid.cc/.well-known/rasid-cosign.pub
cosign download sbom images.rasid.cc/postgres:17 > postgres-17.sbom.json
cosign verify-attestation images.rasid.cc/postgres:17 \
  --type slsaprovenance \
  --key https://rasid.cc/.well-known/rasid-cosign.pub

Five commands. Zero accounts. The bytes you pulled, the signature, the SBOM, the SLSA provenance — all in your shell history. Run those against your existing scanner and the answer is the answer.

— Fahad