False Positives in Nix CVE Scanning and Version String Normalization

Nix vulnerability scanning produces false positives for more than one reason. It comes from a structural mismatch between how NVD identifies software and how Nix builds it, and that mismatch produces at least three separate, compounding failure modes before any scanner-specific bug even enters the picture. Understanding each one separately is the only way to know which fix addresses which problem.

CPE-based matching and Nix

Common Platform Enumeration is the identifier scheme NVD uses to tie a vulnerability record to the software it affects, and it was built to be ecosystem-agnostic. A CPE entry names a vendor, a product, and a version, under the assumption that any given piece of software has one canonical name that the NVD CPE Dictionary has already catalogued. That assumption holds reasonably well for commercial software with a single publisher and a stable product line. It breaks down fast at scale, because the same vendor or product string can refer to an npm library, a compiled system binary, or something else entirely, and a scheme with no ecosystem awareness has no way to tell these apart.

Nix derivations fall outside this scheme. There is no registration process that gives a Nix package a canonical vendor and product name in the NVD dictionary, no PURL type for Nix that any major advisory database has ratified, and no vendor field in a derivation that maps cleanly onto NVD's taxonomy. A Nix package is defined by its build inputs and its derivation path, not by a vendor-product pair somebody submitted to a central registry.

The resulting identity gap cuts in both directions. A name that fails to match returns zero results, and there is no way to tell from that empty result whether the package genuinely has no recorded vulnerabilities or whether the scanner simply could not find it under any name it tried. The NixOS community's own retrospective on its vulnerability roundups named this exact pattern, excessive false positives paired with an unknown rate of false negatives, as a central reason the roundups became unsustainable to maintain.

Vulnix's name-matching heuristic and package-level noise

Vulnix, the most widely used Nix-native vulnerability scanner, closes the identity gap with a heuristic its own maintainers describe as too simplistic to trust fully. The tool first attempts a direct name match against the product strings in NVD. If that fails, it retries with the name lowercased and hyphens swapped for underscores. That is the entire matching strategy: two passes of string transformation against a database that was never built with Nix's naming conventions in mind.

The consequences of that heuristic show up directly in scan output. A scan of a recent stable NixOS system turned up 47 derivations carrying active advisories, among them ShellCheck, a shell-script linting tool, flagged at a CVSS score of 9.8. A linting utility landing at the top of the severity scale is the kind of result that should make any triage engineer pause, because the explanation is far more likely to be a name collision between ShellCheck and some unrelated NVD product entry than an actual critical vulnerability in a static analysis tool. The same two-pass heuristic that produces this kind of over-match also under-matches in the other direction: a clean scan carries no guarantee of a clean system, since a silent failure to find the right product string looks identical to the absence of a known vulnerability.

Version string normalization as a second, independent failure mode

Name matching is only half of what a CPE-based scanner has to get right. Once a product string resolves, the scanner still has to compare the installed version against the version ranges NVD records in a CVE's "known affected software configurations." That specification is inconsistently defined across entries, which creates a second point of failure entirely independent of the naming failures described above. A scanner can match the correct product and still misjudge whether a given build falls inside or outside the affected range, because the range format and its edge-case conventions are not uniformly applied across the NVD corpus.

This matters because Nix version strings often diverge from the conventions NVD's data entry assumes, carrying suffixes, patch identifiers, or packaging-specific qualifiers that a strict range parser was never designed to handle. When that parsing fails, it tends to fail quietly in one particular direction: an unusual version suffix is more likely to cause a scanner to miss a real match than to manufacture a false one. That asymmetry matters for how teams should read their results, because it means version-string failures compound the risk that a clean report hides a real exposure, rather than the alert fatigue that name collisions create.

Backported patches and scanner output

The explanation most often repeated in Nix security discussions is that nixpkgs backports security fixes without bumping the version string, so a scanner matching purely on version number flags a vulnerability that the actual build no longer contains. This is a real mechanism. Vulnix even ships a mitigation for it: a CVE patch auto-detection feature that recognizes patches named with a CVE identifier in the filename or in a fetchpatch call, such as CVE-2018-6951.patch or a fetchpatch entry with name = "CVE-2018-9055.patch". That detection only works when the patch author happens to follow this naming convention, and nothing in nixpkgs enforces it.

The scope of the backport problem is less settled than the folk explanation suggests. Nobody has published a measurement showing that nixpkgs routinely backports CVE fixes without a version bump as a general practice. The available evidence points the other way: security fixes in nixpkgs appear to arrive predominantly as ordinary version bumps, which version-matching scanners already handle without issue, and the patches that do exist in the tree skew toward build changes, packaging adjustments, and policy fixes rather than silent CVE backports. The honest position is that the real false-positive rate attributable to backported patches is unknown, and no team should invest in a suppression architecture built on exploitability claims to solve a problem whose size has not been measured. The right next step is a direct count: scan a Nix-built project, run its SBOM through a matcher, tally how many reported findings trace back to an actual backported patch, and let that number, not the folk explanation, decide how much engineering effort the problem deserves.

A real triage event where these failure modes compound

A NixOS Discourse thread documenting a scan of a stable system shows all three failure modes landing in a single result set, which is what turns this from a theoretical concern into an operational one. zlib was flagged for CVE-2023-6992 and unzip carried several CVE flags in that scan, both NVD CPE false positives: unzip's relevant CVEs were already patched in-tree in nixpkgs, and samba, pulled in only through libsmbclient as a client dependency of gvfs-smb, was never running as an exposed service on the system.

The triage guidance that came out of working through that scan amounts to a working taxonomy of the problem. Genuine exposures get fixed with version-guarded overrides. Whitelisting is reserved for confirmed vulnix name collisions or for CVEs verified not to apply to the actual runtime closure. Any build-tooling derivation that shows up in a runtime scan gets investigated rather than whitelisted, because its presence there is itself evidence that the closure was constructed incorrectly, independent of whether it reflects an actual vulnerability finding.

What makes this compounding effect operationally dangerous is the choice it forces on a team that cannot quickly sort a name collision from a genuine CVSS 9.8 exposure. One path is to chase every finding, which burns engineering time on ShellCheck-style phantoms. The other is to tune the scanner toward silence, which buries the real exposures the scan was supposed to catch. Both paths are failures, and the scan above shows why: name collisions, version-matching failures, and backport confusion were all present in the same 47-finding report, indistinguishable from one another without manual review of each line.

SBOM toolchains and their own layer of identity confusion

The identity gap does not stay contained inside the scanner. It propagates upstream into the SBOM generator that produces the inventory the scanner reads, and different generators resolve Nix's identity gap in incompatible ways. A documented comparison ran the same package closure through three generators, bombon, Syft, and sbomnix, and fed each output into the same Grype scanner. The three pipelines returned three different result sets for identical underlying packages, which demonstrates that the point of divergence sits between the generator and the scanner rather than in either tool alone.

Bombon illustrates the problem cleanly. It captures Nix packages accurately in the SBOM it produces, but it emits them with a pkg:nix/ PURL, an identity format Grype does not recognize against any vulnerability database it consults. The result is zero findings, and that zero means nothing about the security of the packages involved. It means the identity format itself was unreadable to the scanner.

The Package URL specification, often treated as the modern alternative to CPE, does not resolve this cleanly either. The qualifier fields that follow the version in a PURL are entirely unstandardized, and SBOM generators, scanners, and vulnerability databases each interpret those qualifiers on their own terms. That inconsistency is a distinct source of mismatch, layered on top of the CPE problems already described rather than replacing them.

First-party signals nixpkgs already provides

Set against all of this, nixpkgs already carries two fields that resolve cleanly at evaluation time, without invoking any external scanner or database at all: meta.knownVulnerabilities and meta.insecure. Nixpkgs maintainers populate these fields directly for packages they know to be end-of-life, for versions kept around only for compatibility despite known issues, and for anything the distribution itself judges insecure. The mechanism has real teeth: nix build refuses to proceed on a flagged package unless permittedInsecurePackages explicitly allows it.

These fields are correct by construction for the cases they cover. They are not inferred through a name-matching heuristic against an external database that was never designed with Nix in mind. They reflect direct maintainer knowledge of the package's actual state, and a team can read them without standing up scanning infrastructure.

They also have a real limit. These fields are maintained by hand, they lag behind newly published upstream advisories, and they carry no weight in a compliance workflow that requires third-party attestation. A clean meta.knownVulnerabilities list tells an internal engineering team something true and useful, but it does not constitute an auditable SBOM that will satisfy a security questionnaire from an external auditor. That gap between internally trustworthy and externally attestable is precisely the territory the NixOS Software Provenance Team has taken on, with a charter that includes encouraging the infrastructure needed to generate high-quality SBOM documents and improving package metadata so it matches vulnerabilities more reliably.

A trustworthy Nix CVE pipeline today

Given all of these failure modes, the single highest-leverage change available to most teams, without adopting any new tool, is making sure the SBOM generator and the vulnerability scanner in use come from the same toolchain and agree on identity format. Mismatching them, as the bombon-and-Grype pairing shows, loses findings or manufactures false ones without any warning that the mismatch has occurred.

A concrete pattern already documented in practice builds on that foundation. Pin nixpkgs to an exact revision. Build release artifacts through a Nix derivation rather than an ad hoc build step. Generate reproducible per-binary CycloneDX 1.5 SBOMs twice and diff them byte-for-byte to confirm the build is deterministic. Produce certification bundles for both x86_64 and aarch64 separately. This is the pattern the seradotcom/semwright supply chain pull request from September 2026 demonstrates, built around fail-closed release admission rather than best-effort scanning.

Beyond individual pipelines, the community's own identified path forward is explicit CPE mapping recorded directly in package metadata, rather than inferred after the fact by a heuristic. The NixOS Discourse thread on the future of the vulnerability roundups points to FreeBSD ports as the reference model for this approach, where the package itself carries its CPE identity instead of leaving a scanner to guess it. Until that kind of mapping exists at scale, whitelist maintenance remains unavoidable, and it stays defensible only when scoped narrowly: confirmed vulnix name collisions, CVEs verified not applicable to the runtime closure, and build-tooling derivations treated as closure construction errors to fix rather than findings to suppress.

The most consequential capability this foundation unlocks is architectural rather than procedural. An environment with fully pinned inputs and a reproducible build carries an input-derived hash that can travel with it into deployment. That hash turns an SBOM from a static document generated once at build time into a live signal: when a new CVE is published, the hash lets a team identify exactly which deployed environments contain the affected input, directly and immediately, without re-scanning a single image or grepping through a single log.