Security posture
This page is the honest scorecard: what ships today in v0.2, what is on the roadmap, and the line between them drawn clearly — because a security page that blurs that line is itself a security finding. Deep-dive documents behind each row are available under approved access.
Cryptography
The data plane runs the Noise IK handshake pattern with X25519 key agreement, ChaCha20-Poly1305 AEAD and BLAKE2s hashing — a modern, formally analyzed construction (Dowling & Rösler 2018; Noise Explorer, IEEE EuroS&P 2019) in the same family as widely deployed commercial VPN protocols. Node identities are static Curve25519 keys; private keys live in zeroizing memory and rekeying is make-before-break. Release signing is Sigstore keyless — short-lived certificates tied to the CI workflow's identity — so there is no long-term release-signing private key to protect or leak.
At a glance — v0.2
| Axis | Status |
|---|---|
| Memory-safe core language (Rust) throughout the daemon | shipped |
| SBOM (CycloneDX) published with every release | shipped |
| Signed releases — Sigstore/cosign keyless + SLSA L3 provenance | shipped |
| Dependency gate in CI: advisories, yanked versions, license allowlist — re-scanned weekly | shipped |
| Hardened systemd unit (unprivileged user, one capability, syscall allowlist) | shipped |
| SELinux policy module and AppArmor profile | shipped |
| Ansible role deployable onto a STIG-baseline host | shipped |
| Peer-reviewed data-plane cryptography (Noise IK / X25519 / ChaCha20-Poly1305) | shipped |
| FIPS 140-3 validated cipher backend | roadmap |
| Hybrid post-quantum handshake (X25519 + ML-KEM) | roadmap |
| CSfC components-list submission | roadmap |
| Reproducible builds · VEX statements | roadmap |
The compliance framing to take from this table: the shipped artifacts are designed to satisfy the software-supply-chain expectations of EO 14028-era procurement (SBOMs, signed provenance, dependency auditing) — that is a design statement, not a certification claim.
Security properties of the architecture itself
- No phone-home by default. The daemon works fully offline; console enrolment is an explicit operator action; crash reports stay local until an operator sends one, redacted, with an anonymous mode that strips identity.
- Fail closed, everywhere it matters. Unknown peers are rejected by default; every auth-provider failure mode denies; a misconfigured trust setup refuses to start rather than starting open.
- Least privilege as packaging, not advice. The shipped unit runs an unprivileged user with a single capability inside a syscall-filtered sandbox — verifiable on your own host in one command.
- Honest observability boundaries. Support bundles and uploaded diagnostics are redacted by allowlist; private keys and mesh secrets cannot leave the node through any built-in path.
- Know your crypto boundary. Multi-hop mesh forwarding is hop-by-hop encrypted — a relay node you operate can read what it forwards, and the documentation says so in bold instead of hoping you don't ask. Traversal relay servers, by contrast, forward opaque envelopes they cannot read.
Verify, don't trust
Every release ships checksums, keyless signatures, SLSA L3 provenance and per-crate SBOMs — and the verification recipe is public, runnable by any auditor with a Linux box in about a minute. We publish the recipe precisely so that "how do we know this binary is yours?" is a command, not a meeting.
The deep-dive set approved access
- CNSA 2.0 transition plan — the migration path to a post-quantum-ready data plane, mapped against published deadlines.
- CSfC inner-layer positioning — how Atlas composes as the inner layer of a two-layer architecture.
- OS hardening profile — the confinement stack directive by directive, with live-system verification.
Vulnerability disclosure
Security research is welcome. The canonical disclosure policy for the whole site family lives at nexusatlas.io/security, and every Nexus Atlas host — this one included — serves /.well-known/security.txt pointing at it.