What this domain covers#
The third domain covers third-party services that are not integrated software components, but that constitute the production and distribution infrastructure without which the declarant’s activity stops. Concretely: forge where the source code lives (GitHub, GitLab, Codeberg, internal instance), package registries on which builds depend daily (npm, PyPI, Maven Central, RubyGems, crates.io), container registries (Docker Hub, GitHub Container Registry, Quay.io), critical CI/CD services, CDNs, third-party authentication services, certificate providers (Let’s Encrypt, DigiCert, Certigna, CertEurope), DNS, monitoring services.
For each service identified, the declarant indicates the operator, the jurisdiction it is subject to, the estimated impact in the event of cut-off, and the planned migration path. The level of precision expected is not exhaustive on every secondary service — it targets services whose interruption would have a direct operational effect.
Why this domain matters#
The supply chain is the most systematically forgotten blind spot of sovereignty analyses. Many organisations that examine their software and their hosting providers carefully are unaware that their builds depend daily on infrastructures under foreign jurisdiction. Thesis 7 of the manifesto sets it out without circumlocution: “distributing free software through registries and networks subject to a foreign jurisdiction is to grant that jurisdiction a right of oversight and cut-off over what we believe we own.”
Historical incidents have illustrated the actual fragility of this chain. The left-pad crisis in March 2016, when the withdrawal of a tiny npm package caused tens of thousands of builds to fail worldwide within hours. The limitation of anonymous downloads on Docker Hub in November 2020. The voluntary sabotage of colors.js and faker.js by their maintainer in January 2022. The service suspensions to Russia in March 2022 (Microsoft, Adobe, Visa, Mastercard), which demonstrated that the geopolitical cut-off of an operator can be ordered and executed within days. The OpenAI restrictions toward China of July 2024.
PyPI illustrates multi-layered concentration: the Python foundation (PSF, American) operates the service, the compute infrastructure is provided by AWS, the CDN is delivered by Fastly to the tune of about $1.8M per month as a donation, the file storage is on Google Cloud Storage. Three American players are simultaneously in the critical path of any European organisation that runs pip install.
What is asked, by category of declarant#
For a software publisher. Primary forge and any mirrors, package registries used by the build pipeline, container registry on which images are published, CI/CD platform, third-party code-signing services, TLS certificate providers, production DNS. Explicit mention of self-hosting where it exists (for example, self-hosted GitLab CE) and of the jurisdiction of the instance.
For a hosting or cloud provider. Registries and forges used for its own infrastructure images, dependencies in the provisioning chain for new clients, third-party monitoring services used globally by the platform.
For a distributor or integrator. Forges and registries on which the packaging and delivery chain of the solutions to clients depends. If the distributor relies on the original publisher’s artefacts without a local mirror, explicit mention of the fact that a cut-off of this chain by the publisher would also stop the distributor.
An example of an honest, well-done answer#
A European scale-up of 130 staff declares its domain 3 as follows. Forge: self-hosted GitLab CE in France on internal infrastructure, security mirror on private GitHub kept read-only. npm package registry: direct use of registry.npmjs.org (Microsoft, United States), without local mirror — declared as a blind spot in domain 7. PyPI registry: direct use with triple dependency on PSF, AWS and Fastly. Container registry: self-hosted Harbor that mirrors Docker Hub for base images, which allows continuity of a few days in the event of cut-off. CI/CD: GitLab CI on the internal instance. CDN: Bunny.net (Slovenia). Web certificates: Let’s Encrypt (United States), with a parallel Certigna (France) contract on standby for critical services. DNS: Gandi (France). Monitoring: self-hosted Grafana.
The company mentions in domain 3 a project under way to mirror critical npm dependencies via Verdaccio by 2027, which will reduce exposure.
An anti-pattern to avoid#
A domain 3 that boils down to “we use the standard services of the industry for our development chain” is precisely what thesis 7 seeks to overcome. A vague mention of registries without qualification of jurisdiction (“we use npm and PyPI”) does not allow the buyer to understand the exposure. A triumphant declaration (“we fully control our production chain”) without technical justification is a false reassurance, except in the exceptional case of organisations that have actually rebuilt their entire chain in-house.
Articulation with the other domains and commitments#
Domain 3 is articulated directly with the user commitment user-005-document-jurisdiction-supply-chain: a declarant that has taken on this commitment already has the content of domain 3. It complements domain 1 by widening the notion of dependency beyond integrated code alone. It feeds into domain 7 when the absence of a local mirror or alternative is assumed as a blind spot under treatment.
How to fill in the form#
The form proposes a library of the most common supply-chain services (GitHub, npm, Docker Hub, Cloudflare, etc.). For each dependency retained, here are the fields to fill in.
Identification of the service#
- Type: choose from Code forge, Package registry, Container registry, CDN, Authentication, CI/CD, DNS, Certificates, Monitoring / supervision, Other.
- Name: commercial name of the service (e.g.: GitHub, npm, Docker Hub, Cloudflare, Let’s Encrypt).
- Publisher or provider: entity that operates the service.
- Jurisdiction: country under which this entity operates (US, FR, DE…).
Impact assessment#
- Level of impact in the event of cut-off: 5 levels. Blocking (activity interrupted immediately), Severe (major degradation), Moderate (partial workaround possible), Minor (easily worked around), Not assessed (to be acknowledged if you have not done the exercise).
- Description of the impact: what concretely stops (“100% of revenue on hold”, “impossibility of deploying a critical fix”, “RTO degraded to 24 h”).
Migration plan#
Distinct from the workaround plan of domain 2: here we are talking about a rapid operational switchover (hours to days), not a structural substitution (months).
- Status of the migration plan: Documented and tested, Documented not tested, Identified not documented, No plan, Not assessed. Honesty preferable to promise.
- Description of the migration plan: where do you switch to (mirror, secondary provider, degraded mode) and how.
- Source (URL): link to internal or public documentation of the plan, if it exists.