Why a platform alone isn’t enough
Most “defense platform” conversations stop at the cluster: which Kubernetes, which distro, which support contract. That answers where software runs. It does not answer the question defense organizations actually struggle with:
How do we get trustworthy software into operators’ hands, repeatedly, in weeks rather than years — including into disconnected environments — and prove it is trustworthy every time?
That is a factory problem, not a platform problem. The platform is one layer of it.
What the US demonstrated, in public
Platform One is the US Department of Defense’s DevSecOps effort, and its baseline platform,
Big Bang, is developed in the open. Anyone can read the architecture: the repository is
public at repo1.dso.mil/big-bang/bigbang and the documentation at
docs-bigbang.dso.mil.
From those public documents, the shape is clear. Big Bang is a Helm- and GitOps-based (Flux) hardened Kubernetes baseline that composes well-known open-source components: Istio for a hardened service mesh, Kyverno and OPA Gatekeeper for policy, Keycloak for identity, Vault with the External Secrets Operator for secrets, Harbor as a registry, and a Prometheus/Grafana/Loki/Tempo observability stack. Container images come from Iron Bank, the hardened image source. Notably, the documentation treats air-gapped installation as a first-class, documented path — not an afterthought — and includes work on OSCAL, the machine-readable format behind compliance-as-code.
Two things follow from that, and they matter more than any product comparison.
First: the pattern is proven and it is not secret. A national defense establishment built a software factory on open source, in the open, and published how. The argument that this can only be done with proprietary, accredited-by-a-vendor tooling is empirically false.
Second: the components are ordinary. Kyverno, Istio, Keycloak, External Secrets Operator — these are CNCF-ecosystem projects any organization can run. Our own platform and the DoD baseline independently converge on several of the same building blocks, simply because they are the sensible open-source choices for these problems.
To be explicit: that convergence is a statement about open source, not about us. We have no affiliation with, endorsement from, or accreditation by Platform One, the US DoD, or any of their programmes. Everything above is drawn from their public documentation.
What Europe cannot borrow
Here is where copying breaks down. The transferable part of Platform One is the architecture. The non-transferable part is the jurisdiction:
- The hardened image source is US-operated. Depending on Iron Bank means your software supply chain begins under a foreign government’s control — the exact dependency a European sovereignty programme exists to remove.
- The accrediting authority is US. An authorisation granted under a US framework does not discharge a German or EU obligation. BSI IT-Grundschutz, NIS2 and national defense accreditation are their own regimes.
- The operator is US. A platform someone else runs is a platform someone else can be compelled about.
An EU defense organization that adopts the US stack wholesale gets a very good architecture and a brand-new foreign dependency at the most sensitive layer it has. That is the sovereignty-washing test failing at the supply chain instead of the datacenter.
What a sovereign version looks like
Same five layers. European jurisdiction. Open source you can audit end to end:
- Supply chain — a hardened image and package source operated in Europe, under European law, with SBOMs and provenance you can verify yourself.
- Policy — the same policy-as-code engines, with baselines mapped to BSI IT-Grundschutz and NIS2 rather than US controls.
- Identity — self-hosted, working fully disconnected.
- Delivery — GitOps and air-gap packaging, so a release can cross an air gap as a reviewable artefact. See how air-gapped Kubernetes actually works.
- Evidence — continuous, machine-readable compliance evidence rather than a pre-audit scramble.
The platform layer of this is what we build: secure operations for the fleet, sovereign VMs for the estate you can’t containerise yet, and secrets and zero-trust for the credentials underneath it all.
What we are not claiming. We do not operate an accredited hardened-image registry, and we do not hold or grant any authorisation to operate. Those are real gaps in the European landscape — see the article below. We would rather name them than paper over them.
Where to start
Most organizations do not build all five layers at once. In practice the order that works is: get delivery and policy right on a platform you control, add identity, then work outward to supply chain and evidence — because the first two are what make everything after them provable.