There is a particular kind of false confidence that comes from running a vulnerability scan and seeing nothing. For teams running Nix-based deployments, a clean result is not a sign of a secure environment. It is a sign that the scanner does not know how to look.
This matters more than it might seem. Organizations adopting Nix tend to be on the more security-conscious end of the spectrum. They chose it precisely because of its reproducible builds, hermetic environments, and precise dependency graphs. These are teams that take supply chain integrity seriously. The irony is that Nix's packaging model creates a blind spot in the vulnerability tooling they depend on, and most of them don't know it's there.
Why the Scanner Comes Back Empty
When you generate a software inventory for a Nix-based system, packages are correctly identified as coming from the Nix ecosystem and assigned Nix package URLs. That identification is accurate. The problem is that no major vulnerability database indexes against Nix package URLs. Grype does not natively map Nix package URLs to vulnerability databases, which can result in limited or incomplete vulnerability detection for Nix-based systems. The data is there. The bridge between the inventory and the vulnerability database does not exist.
The standard workaround is to fall back to CPE matching or raw package names. This trades one problem for a worse one. CPEs are not ecosystem-specific. The same name or vendor can refer to an npm library, a system package, a compiled binary, or something unrelated entirely. At scale, this produces false positives at a rate that makes the results unusable. The NixOS community has been wrestling with this publicly for years. At least one maintainer abandoned regular vulnerability roundups entirely because the false-positive rate made the process unsustainable. Teams that push through the noise and try to triage the results spend significant engineering time chasing findings that turn out to be wrong ecosystem matches.
The result is an ecosystem where the two available options are equally bad: near-zero results that create false confidence, or a flood of false positives that erode trust in the tooling. Neither is a security program.
Nix Packages Are Wrappers. The Signal Is Inside
The insight that unlocks a better approach is this: a Nix package is almost always an upstream artifact from another ecosystem wearing a Nix wrapper. A package that builds a Python library is still fundamentally a Python package. One that compiles a Go binary is still a Go module. A C library wrapped for Nix is still, at its core, a C library with a CVE history that maps to known identifiers.
The nixpkgs build recipes contain the information needed to identify that original ecosystem. Source URLs point to upstream repositories. Build phases reveal which toolchain is in use. Dependency declarations name the ecosystem they came from. Patch information ties back to upstream versions. This information is recoverable. It just requires looking at the right layer of the abstraction rather than taking the Nix package URL at face value and stopping there.
Reconstructing the Identity Underneath
The approach Manifest's engineering team developed works backwards from the Nix package to its upstream origin. Starting with a Nix package URL from a software inventory, the pipeline queries the Nix packages API to retrieve metadata and locate the corresponding build recipe in the nixpkgs repository. It then fetches and parses that recipe, looking for ecosystem signals: npm build commands, Go build patterns, Python setuptools usage, common C and C++ build systems.
When those signals are present and unambiguous, the pipeline reconstructs a valid ecosystem package URL, the kind that vulnerability databases actually understand and can match against. A Nix package wrapping a PyPI library becomes a PyPI package URL. A Go binary becomes a Go module URL. The reconstructed identifier carries the ecosystem specificity that CPE fallback lacks, which means vulnerability matches are meaningful rather than noisy.
Not every package yields a confident reconstruction. Build recipes vary in how much ecosystem information they expose, and some packages are genuinely novel to the Nix ecosystem with no upstream analog to map to. For these cases, the pipeline falls back to the generic package URL type used by OSS-Fuzz, which preserves coverage against source-level vulnerability data without pretending to know the ecosystem and introducing false positives.
Early results from production-scale software inventories show successful reconstruction for roughly 50 percent of packages. Ecosystems like npm, PyPI, and Go map most reliably, because their build recipes tend to include clear, consistent signals. Native C and C++ packages are harder, and purely Nix-native packages represent the remaining gap. The work to push that reconstruction rate higher is ongoing, but 50 percent of a previously invisible surface area is not a small number.
Visibility You Can Actually Use
The operational shift this creates is significant. Teams that previously received zero actionable vulnerability matches for hundreds of Nix components now get consistent, ecosystem-accurate coverage. The findings that come back are meaningful rather than noisy, because the identifiers are specific rather than ambiguous. Engineers spend time on real vulnerabilities rather than triaging false ecosystem matches.
The risk was always there. The software was always there. The upstream vulnerabilities affecting these packages existed regardless of whether the scanner could see them. The reconstruction pipeline does not create new risk. It makes existing risk visible to the teams responsible for managing it.
Organizations that adopted Nix because they care about supply chain integrity deserve security tooling that matches that standard. A clean scan built on a broken matching model is not a clean bill of health. It is a gap report that nobody asked for, and everyone is implicitly relying on.