Security and privacy
Supply chain
A release of Archipelago runs inside customer networks and, for station modules, inside the station itself. This is how we keep that trustworthy, and which parts exist today.
Implemented today
- This website is built from a locked dependency set and ships no external resource; a build-time check fails on any.
- Nothing else: there is no release of the platform.
Planned
- Lockfiles with clean installs only; vulnerability scanning and grouped dependency updates in CI; secret scanning on every push; static analysis for TypeScript and Java; actions pinned by hash; least-privilege workflow tokens. Phase 0.
- A software bill of materials (CycloneDX) attached to every release. Phase 1 for the site, Phase 3 for the edge.
- Build provenance attestations for TypeScript artifacts. Phase 3.
- Release signing through a public transparency log, so a signature can be checked without trusting this site; a CI job that verifies every artifact's hash and signature against the tagged source before publication. Phase 3.
- If an optional vendor-side module is ever published, it is signed separately on a hardware key that never enters CI, and CI verifies the signature and hash before publication. Phase 4, after legal review.
- A protected release environment that requires a maintainer's approval before anything is published; signed release tags. Phase 1.
- A dependency egress audit: every package capable of opening a socket, compared against an approved list. Phase 3.
What we will not do
- Put a signing key in a CI secret.
- Ship a dependency we have not pinned.
- Include any vendor's proprietary jars, documentation or SDK in a public repository.
- Copy code, fixtures or data from any other project, including the founding organization's own tools, into Archipelago. Clean implementations on synthetic fixtures only.