AI
Nix’s Three-Layer Architecture
Nix has three separate components that people often conflate. The package manager came first, designed as a universal software distribution mechanism that works across distros and Unix flavors. Nixpkgs, the package set, grew out of the need to manage build recipes. NixOS came third. The key primitive Nix adds: before Nix, you could not deploy more than one file atomically. That single primitive is what unlocks everything else, regardless of which component you enter through.
How Nix Solves What Docker Left Unfinished
Docker took a hands-off approach to packaging. Copy in a binary or piggyback on another distro’s toolchain. That works well for runtime orchestration and final artifact delivery. The problem surfaces when you need to combine three SDKs or libraries from different sources. You cannot merge three Docker containers and expect them to work together. Nix can compose multiple distributions into one coherent build. Docker’s own debugger now uses Nix internally for exactly this: bringing in packages without conflicts.
SBOM by Construction, Not by Scan
Most SBOM tools scan a built artifact and try to reconstruct the bill of materials. Nix inverts that. The derivation, Nix’s name for a build recipe, is the SBOM. It existed 20 years before the term did. Provenance tracks to commit level, not just version string. The gap today: security vendors use CPE and package URLs, not commit hashes. The roadmap is to generate both, so vendors can ingest a Nix-produced SBOM directly instead of scanning container images with heuristics.
Binary Substitution and the Trust Chain
The Nix Foundation runs a build farm through Hydra. All packages build from source, get signed, and land in a binary cache. For most users, the default trust is the public key signing those cache entries. Companies with stricter policies rebuild everything from source, sign with their own key, and trust only that artifact. Turning off the substitutor rebuilds the entire world from scratch. Software bundles that disappeared from the internet still exist in the Nix binary cache from builds ten years ago.
XZ and the Honest Limits of Source-Based Defense
Nix was not vulnerable to the XZ backdoor. The build model gives visibility into what changed. That matters. But building from source does not eliminate a backdoor embedded in source. If source contains malicious code, Nix faithfully builds it. A rough audit suggests a double-digit percentage of Nixpkgs packages have single authors, the same risk vector the XZ attack used. The defense is active community members with high fidelity into what runs on their systems, not a technical guarantee.
The Nix Everywhere Roadmap
The steering committee’s working theme is “Nix everywhere.” The plan covers Windows support, easier use inside Docker, and a libnix library other package managers can call into for sandboxing and caching without users knowing. Static binaries for embedded and medical hardware are on the list. Flakes stabilization is blocked on fetch-tree, which had Git reproducibility issues with smudging. Once fetch-tree ships, few remaining hurdles block a stable flakes release. Flakes have driven recent adoption by giving newcomers a single pinned entry point.
Q&A
What caused the recent surge in Nix adoption? Software complexity and supply chain security concerns grew, Docker’s packaging limits became apparent, and polyglot stacks (Python, Go, Rust) created demand for a system that composes them. Flakes also drove newcomer onboarding by locking down and reproducing environments easily. ▶ 34:46
What are the security plans post-XZ? Nix was not vulnerable due to build visibility, but single-maintainer packages are a shared risk across all package sets. The Sovereign Tech Fund is funding a security team, and the fixed output derivation oracle tracks upstream source changes to detect tampering. ▶ 41:00
Why is NixOS built on systemd? It was pragmatic and it works. Efforts exist to make the init backend more agnostic, and building non-systemd operating systems with Nix is already possible. ▶ 45:22
Notable Quotes
we have zero opinion about packaging. Tom Breck · ▶ 5:00
correct by construction. Tom Breck · ▶ 13:03
essentially rebuild the world. Tom Breck · ▶ 18:07
think of another way or a better way. Fared · ▶ 24:37
Key Takeaways
- Nix generates SBOMs by construction through derivations, tracking provenance to commit level rather than scanning artifacts.
- Binary substitution is an optimization. Organizations can rebuild everything from source and sign artifacts with their own key.
- Building from source does not eliminate backdoored source. XZ shows single-maintainer risk exists across all package sets.
About the Speaker(s)
Joe FitzPatrick is a trainer and researcher at SecuringHardware.com. His career has focused on low-level silicon debug, security validation, and penetration testing of CPUs, SoCs, and microcontrollers. He has instructed hundreds of security researchers and hardware validators worldwide, teaches Applied Physical Attacks training, and contributes to the NSA Playset and related hardware projects.
Grace Parrish is completing a cybersecurity degree at Oregon State University. Her background spans industrial control systems, electrical engineering, FPGAs, microcontrollers, and a decade of board-level repair. She has captained a pentesting competition team, written custom Binary Ninja plugins, and helped deliver hardware security training at Black Hat.