Secure software dependency management everywhere with Nix

Secure software dependency management everywhere with Nix

Speakers: Tom Berek, Farid Zakaria, Morgan Jones (Nix packages committer, Viasat)

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=xecOnPOxc3w

Overview

In this groundbreaking DEF CON talk, "Secure software dependency management everywhere with Nix," Tom Berek, Farid Zakaria, and Morgan Jones introduce the Nix ecosystem as a revolutionary approach to software packaging, deployment, and security. Nix, encompassing a package manager, a declarative language, a vast package set (Nixpkgs), and an operating system (NixOS), aims to "rebuild the world" of software distribution from the ground up. The speakers argue that Nix provides fundamental primitives for atomic, reproducible, and auditable software environments, directly addressing long-standing challenges in supply chain security and system reliability.

The core premise of Nix is to manage software dependencies and system configurations in a purely functional and declarative manner. This approach stands in stark contrast to traditional imperative methods, which often lead to "dependency hell," environmental drift, and opaque software supply chains. By ensuring that every software build is fully reproducible and its entire dependency graph is explicitly defined, Nix empowers developers and security professionals with unprecedented control and visibility over their software estates. The talk emphasizes how this paradigm shift not only enhances development workflows but fundamentally transforms how organizations can approach vulnerability management, compliance, and the trustworthiness of their deployed systems.

Ultimately, the talk posits Nix not as a mere alternative but as an essential evolution in software management, particularly pertinent in an era dominated by complex distributed systems and heightened cyber threats. It highlights Nix's ability to coexist with and even enhance existing tools like Docker, offering a robust packaging solution where others fall short. The speakers articulate a vision where Nix's "superpowers"—reliability, reproducibility, and auditability—become standard capabilities, enabling secure and predictable software environments across diverse platforms, from embedded devices to large-scale cloud infrastructure.

Background

▶ Watch: Introduction to Nix and its 'Rebuild the World' goal (0:00)

The landscape of software deployment has long been plagued by issues stemming from mutable environments, implicit dependencies, and non-reproducible builds. Historically, managing software involved a series of imperative steps—installing packages, configuring settings, and resolving conflicts—often leading to "works on my machine" syndrome and unreliable updates. The rise of containerization, exemplified by Docker, offered a significant step forward by providing immutable artifacts and simplifying orchestration. However, as the speakers highlight, Docker intentionally sidestepped the fundamental problem of packaging. Docker excels at distributing final artifacts and orchestrating runtime environments, but its Dockerfile approach often relies on existing, often fragile, package ecosystems or simply copies in pre-built binaries, offering "zero opinion about packaging." This leaves the core problem of how software components are built, linked, and composed largely unaddressed, leading to issues when combining multiple, potentially conflicting, libraries or SDKs within a single container or across a larger system.

Nix emerged from a different philosophy, starting with the Nix package manager and its declarative language. The original idea was to create a universal software distribution mechanism that could reliably build and move software across any Unix-like system. This necessitated a robust way to manage build recipes and ensure reproducibility. This led to the creation of Nixpkgs, a vast collection of build recipes. Subsequently, the concept extended to managing entire operating systems, giving birth to NixOS. Unlike traditional distributions that manage files imperatively, NixOS manages the entire system configuration declaratively, treating the operating system itself as a reproducible artifact.

The fundamental problem Nix solves, as articulated by Farid Zakaria, is the inability to "deploy more than one file atomically prior to Nix." Nix introduces primitives that allow for atomic updates and rollbacks of entire software configurations, ensuring that a system is always in a consistent, known state. This contrasts sharply with traditional package managers where updates can leave systems in an inconsistent or broken state, requiring complex recovery procedures. The speakers emphasize that while Docker provides immutability of the final image, it doesn't guarantee reproducibility of the build process itself, often leading to broken builds when attempting to modify an existing image. Nix, conversely, prioritizes build reproducibility from the ground up, providing "rail guards" that prevent such issues.

Key Findings

▶ Watch: Nix's core primitive: atomic updates for files (3:30)

The central contributions and findings presented in the talk revolve around Nix's unique approach to software management and its profound implications for security:

1. Atomic and Reproducible Deployment as a Core Primitive: Nix introduces the fundamental capability to deploy software and system configurations atomically. This means that a change either fully succeeds, leaving the system in a new, consistent state, or it completely fails, reverting to the previous known-good state. This is achieved through the Nix store, a content-addressed directory (/nix/store) where every package and its dependencies reside in unique, cryptographically hashed paths, preventing conflicts and enabling instant rollbacks. This primitive fundamentally changes how updates, deployments, and system recovery are performed, offering unparalleled reliability.

1. SBOMs by Construction, Not by Scanning: Unlike traditional methods that attempt to generate a Software Bill of Materials (SBOM) by scanning pre-built binaries or container images, Nix constructs its SBOMs "by construction." Every derivation (Nix's term for a build recipe) explicitly lists all its inputs—source code, patches, build tools, and dependencies—down to their exact cryptographic hashes. This means the complete provenance of every piece of software is known and verified before it is built. This approach provides hyper-accurate SBOMs, offering a definitive answer to "what goes into your software" from the very beginning of the supply chain.

1. Enhanced Supply Chain Trust and Auditability: Nix's trust model is based on cryptographic signatures and the ability to rebuild everything from source. While Nix provides pre-built binaries from the Nix foundation's build farm (Hydra), signed with a public key, users always have the option to rebuild "the world" from source themselves. This capability ensures complete auditability and allows organizations to enforce policies requiring internal builds and signing with their own keys. Furthermore, Nix and initiatives like the Software Heritage Foundation actively cache source code, ensuring that even ancient or disappeared software bundles can be reliably rebuilt years later, mitigating risks associated with upstream source disappearance.

1. Complementary, Not Conflicting, with Containerization: The speakers clarify that Nix is not a replacement for Docker but a powerful complement. While Docker handles orchestration and artifact delivery, Nix addresses the packaging problem that Docker leaves open. Nix can be used to build highly optimized OCI containers (Docker images) from the ground up, ensuring their contents are reproducible and fully auditable. This "Nix and Docker" synergy offers a stronger, more secure foundation for containerized applications, as demonstrated by the use of Nix within Docker's own debugger.

1. "Superpowers" for Development and Operations: Nix provides developers and operations teams with "superpowers" that drastically improve productivity and reliability. These include:

• Reproducible development environments: Eliminating "dependency hell" and "works on my machine" issues.
• Seamless software distribution: Moving complex software stacks between different machines and architectures with ease.
• Declarative infrastructure management: Managing entire systems, from personal laptops to large server farms, through code, enabling easy sharing and recovery.
• Effortless rollbacks: Instantly reverting to previous system states in case of issues.

1. Mitigation of Supply Chain Attacks (with caveats): While Nix's transparency and source-based builds offer significant mitigation against certain types of supply chain attacks, the speakers are pragmatic. They acknowledge that highly sophisticated attacks, like the XZ vulnerability, where malicious code is deeply obfuscated within legitimate source, still pose a challenge. Nix's strength here lies in providing unprecedented visibility and auditability of the source, making such attacks detectable by vigilant community members and enabling more precise analysis of vulnerabilities, even if the version number remains unchanged.

Technical Deep Dive

▶ Watch: Addressing the question: 'Why not just use Docker?' (4:15)

The Nix ecosystem fundamentally redefines how software is built, managed, and deployed through its unique architectural principles. At its core, Nix operates on three main components:

1. Nix the Package Manager and Language: This is the foundation. The Nix language is a purely functional, lazy-evaluated language designed specifically for describing software packages and system configurations. It's not a general-purpose programming language but optimized for this domain. The Nix package manager uses these descriptions (called derivations) to build software in isolated, hermetic environments. Each derivation explicitly defines all inputs: source code, build tools, environment variables, and dependencies. This ensures that a build is hermetic (isolated from the host system) and reproducible (given the same inputs, it will always produce the same output).

1. Nixpkgs the Package Set: This is a vast, community-maintained collection of derivations for thousands of software packages, libraries, and applications. Nixpkgs is essentially the "recipe book" for building nearly any open-source software. Because these recipes are written in the Nix language and adhere to its functional principles, all packages within Nixpkgs are built reproducibly and can coexist without conflict. This collection is constantly updated and forms the backbone of the Nix ecosystem.

1. NixOS the Operating System: Built atop the Nix package manager and Nixpkgs, NixOS is a Linux distribution that manages its entire system configuration declaratively using the Nix language. Instead of imperatively installing packages and modifying configuration files, users define their desired system state in a configuration.nix file. NixOS then builds and deploys this entire configuration, treating the OS itself as a reproducible artifact. This enables atomic upgrades and rollbacks of the entire system, as well as easy sharing of configurations across different machines.

A key technical innovation is the Nix store, typically located at /nix/store. When a package is built, its output (binaries, libraries, configuration files) is placed into a unique path within the Nix store, e.g., /nix/store/hash-package-name-version/. The hash part of the path is a cryptographic hash of all inputs that went into building that package, including its source code, build script, and all its dependencies. This content-addressed storage mechanism has several profound implications:

• Conflict-free coexistence: Different versions of the same library or even conflicting dependencies can reside side-by-side in the Nix store without interference.
• Atomic upgrades and rollbacks: Because each system generation (a specific configuration of software) points to a set of paths in the Nix store, switching between generations is simply a matter of changing symbolic links. If an upgrade fails, rolling back is instantaneous and guaranteed to restore the previous working state.
• Reproducibility verification: The hash in the store path acts as a fingerprint for the entire build process. If any input changes, the hash changes, indicating a non-identical build.

Software Bill of Materials (SBOMs): Nix inherently generates SBOMs "by construction." A derivation is effectively a pre-SBOM, detailing every input down to the commit level. This provides an incredibly granular level of provenance. The speakers note that while this hyper-specificity is powerful for auditing, it presents a challenge for integration with traditional security tools and databases (like NVD/MITRE) which operate on fuzzier identifiers like CPE (Common Platform Enumeration) or PackageURL. The proposed solution is to "weaken" these precise Nix-generated SBOMs to include these fuzzy identifiers, making them consumable by existing security vendors without losing the underlying precision for internal analysis.

Trust Model: The default trust model for Nix users relies on a central build farm (Hydra) run by the Nix foundation. Hydra builds all packages from source, signs them with a public key, and places them into a binary cache. Users can download these pre-built binaries (known as substitutions) instead of rebuilding from source, which is an optimization. The trust is placed in the integrity of the build farm and its signing key. However, users and organizations can opt to disable substitutions and rebuild everything from source themselves, sign it with their own keys, and run their own internal binary caches. This provides a robust mechanism for verifiable builds and adherence to internal security policies. The Fixed Output Derivation (FOD) oracle is an ongoing effort to ensure that upstream source dependencies don't change unexpectedly, further strengthening supply chain integrity.

Flakes: A more recent addition to the Nix ecosystem, Flakes aim to improve the reproducibility and usability of Nix by providing a standardized project structure and a more opinionated way to define inputs and outputs. Flakes address issues like pinning exact versions of Nixpkgs and other dependencies, making it easier to share and reproduce development environments. While still undergoing stabilization (with fetchTree being a major hurdle for full reproducibility of Git repositories), Flakes are seen as a significant driver of recent Nix adoption due to their ability to "lock things down nicely and pin things," simplifying the creation of personalized, reproducible configurations.

Demo / Proof of Concept

▶ Watch: How Nix and Docker can work together effectively (6:00)

While the talk did not feature a live, explicit technical demonstration or a step-by-step proof of concept during the presentation, the speakers effectively illustrated Nix's capabilities through various real-world scenarios and tangible examples, both personal and enterprise-level.

One powerful "proof of concept" was the physical presence of a binary cache server at the DEF CON venue. This server, running on two (actually three) Ampere Altra nodes configured identically with Nginx failover, served as a live example of Nix's ability to manage and reproduce complex infrastructure. This demonstrated that Nix's declarative configuration applies equally well to small-scale personal setups and robust, high-availability production systems. The ability to configure multiple machines "the exact same way and just reproduce that config on another machine" underscores a core Nix superpower.

The speakers also extensively shared personal anecdotes that served as compelling demonstrations of Nix's practical benefits:

• Home Labs: Tom Berek described using Nix to spin up old projects on new hardware, highlighting the ease of recovery and continuity ("I never left it"). Farid Zakaria spoke about managing his two Raspberry Pis and laptop declaratively, leveraging GitHub code search to discover and instantly apply configuration snippets from others' Nix setups, effectively "shopping" for desired software configurations.
• Seamless OS Upgrades: Morgan Jones recounted updating three NixOS systems from version 2411 to 255 the night before DEF CON without issues, a testament to NixOS's atomic updates and robust rollback capabilities.
• Collaborative Computing: Farid Zakaria shared an engaging story about him and a friend running identical NixOS configurations on their Framework laptops, including each other's user profiles and applications. This setup allowed them to SSH into each other's machines, share fixes instantly, and experiment without fear, as any breakage could be easily rolled back. This showcases Nix's potential for highly collaborative and resilient development environments.

These examples, ranging from personal home lab setups to enterprise-grade server infrastructure and collaborative development, collectively served as a powerful "proof of concept" for Nix's core tenets: reproducibility, atomic updates, declarative configuration, and the resulting reliability and flexibility it offers across diverse use cases. The absence of a traditional demo was compensated by these vivid illustrations of Nix's transformative impact on real-world software management.

Defensive Implications

▶ Watch: Docker's limitations and complexity for development environments (7:00)

Nix's unique approach to software management carries profound implications for cybersecurity defenses, particularly in the realms of supply chain security, vulnerability management, and system hardening.

1. Enhanced Supply Chain Security: Nix provides an unparalleled level of transparency and control over the software supply chain. By building packages from source in hermetic environments and explicitly tracking every dependency down to its cryptographic hash, Nix inherently mitigates many common supply chain attack vectors.

• Provenance and Auditability: Defenders gain an exact understanding of the origin and composition of every piece of software. This granular provenance allows for deep auditing of the source code, patches, and build processes used for any deployed component.
• Mitigation of Binary Tampering: Since all builds are from source (or verifiable binary caches), the risk of malicious code injection into pre-built binaries is significantly reduced. The Fixed Output Derivation (FOD) oracle further aims to detect unexpected changes in upstream sources, preventing malicious modifications from slipping into builds.
• XZ Vulnerability Context: While the speakers acknowledge that Nix doesn't solve all sophisticated attacks like the XZ backdoor (which involved obfuscated malicious code within legitimate source), the Nix ecosystem's transparency and active community oversight made it less susceptible in that specific instance. The discussion highlights that Nix provides the visibility and fidelity required for introspection, allowing for more effective detection and analysis when such attacks occur, even if version numbers remain unchanged.

1. Superior Vulnerability Management with SBOMs: Nix's "SBOMs by construction" represent a paradigm shift for vulnerability management.

• Accurate and Comprehensive SBOMs: Instead of relying on post-build scanning (which can be incomplete or heuristic-based), Nix inherently generates highly accurate and complete SBOMs. This means defenders know precisely which software components, and what exact versions/commits, are present in their systems.
• Streamlined Vulnerability Scanning: The challenge, as noted by Tom Berek, is translating Nix's hyper-precise identifiers to the "fuzzy identifiers" (like CPE or PackageURL) used by NVD and commercial security vendors. However, efforts are underway to bridge this gap, allowing Nix-generated SBOMs to be easily ingested by existing security tools, removing the burden of scanning and heuristics from vendors. This promises faster, more accurate vulnerability alerts and patch management.
• Targeted Patching and Remediation: With precise knowledge of vulnerable components, defenders can apply targeted patches or updates more effectively, reducing the attack surface and minimizing disruption. The atomic update and rollback capabilities of NixOS further facilitate rapid, low-risk remediation.

1. System Hardening and Isolation: NixOS offers robust capabilities for system hardening.

• Declarative Security Configuration: Security policies, service hardening (e.g., systemd hardening), and access controls can be defined declaratively within the NixOS configuration. This ensures consistency and makes auditing security posture straightforward. There are projects that automate the testing of systemd hardening options until services function correctly, maximizing isolation.
• Independent Tooling for Red Teams/CTF: For offensive security practitioners (Red Teams, CTF players), Nix offers a powerful way to deploy tools independently of the host system. This means tools can be run without interfering with the "living off the land" approach or leaving unwanted traces. The mention of Athena OS (a Nixpkgs overlay for security tools) demonstrates how Nix can create portable, self-contained environments for offensive operations, ensuring tools function reliably and can be quickly spun up or torn down without impacting the underlying host.

1. Resilience and Rapid Recovery: Nix's atomic updates and rollbacks are critical for defensive operations. In the event of a compromise, misconfiguration, or failed patch, systems can be instantly reverted to a last-known-good state, significantly reducing downtime and recovery efforts. This resilience is invaluable for maintaining operational continuity during incident response.

In summary, Nix provides defenders with a powerful set of tools and architectural principles that fundamentally enhance visibility, control, and resilience across the software lifecycle, from development to deployment and ongoing maintenance.

Key Takeaways

• Atomic Software Management: Nix fundamentally redefines software deployment by enabling atomic updates and rollbacks for entire systems and applications, ensuring consistency and reliability in every operation.
• Reproducibility by Design: Every software build in Nix is hermetic and reproducible, guaranteeing that given the same inputs, the same output is always produced. This eliminates "works on my machine" issues and provides a verifiable software supply chain.
• SBOMs from First Principles: Nix generates highly accurate Software Bills of Materials (SBOMs) "by construction," explicitly detailing all dependencies and their provenance from the build recipe itself, rather than relying on post-build scanning.
• Enhanced Supply Chain Security: Nix's source-based builds, cryptographic signing, and auditability significantly strengthen supply chain security, offering deep visibility into software components and mitigating various attack vectors.
• Complementary to Containerization: Nix is not a Docker replacement but a powerful complement, solving the packaging problem that Docker intentionally leaves open. Nix can build robust, reproducible OCI containers and integrate with existing orchestration tools.
• Declarative Infrastructure as Code: NixOS extends these principles to entire operating systems, allowing users to manage system configurations declaratively. This enables easy sharing, auditing, and recovery of system states, from personal laptops to large-scale cloud deployments.

About the Speaker(s)

Tom Berek (Tom B) has been deeply involved with the Nix ecosystem for over a decade. His primary efforts are focused on promoting and promulgating the use of Nix across various industries, companies, organizations, and individuals worldwide, aiming to spread the benefits of this unique software management approach.

Farid Zakaria has been an active user and contributor to Nix for over half a decade, though he does not professionally work on the project. He is known as a vocal and analytical voice within the Nix community, offering both critical insights and positive reinforcement based on his extensive experience.

Morgan Jones is a Nix packages committer and works at Viasat, focusing on reproducible builds of various software components using Nix. He has been using Nix for approximately eight years, having initially discovered it through a Raspberry Pi project in college. He credits Nix with completely transforming his approach to deploying Linux systems.