Introducing FlakeAudit, a CLI for evaluating CycloneDX SBOMs against custom policiesSkip to main contentFlakeHub is now FedRAMP High authorized , bringing Nix to federal agencies and their partners →<br>Get Determinate (opens in a new tab)
$refs.mobileMenu.querySelector('a')?.focus())" @keydown.escape.window="mobileOpen = false; $refs.mobileToggle.focus()" role="dialog" aria-label="Navigation menu" aria-modal="false" class="absolute inset-x-0 top-full border-t border-gray-200 bg-white dark:border-ds-border dark:bg-ds-bg lg:hidden">
Introducing FlakeAudit, a CLI for evaluating CycloneDX SBOMs against custom policies
Dominique Hummel<br>August 3, 2026·14 min read
announcementnixdeterminate-nixflakesschemassbomsecure-packagessupply-chainsecurityvexcompliancelicenses
Earlier this year, we introduced Determinate Secure Packages (DSP), our first major effort to revolutionize the software supply chain.<br>This offering takes an ever-expanding curated package set based on Nixpkgs and adds a wide variety of industry-leading features, including SLA-backed CVE remediation, optional Federal Information Processing Standards (FIPS) support, and full binary cache coverage in FlakeHub Cache.
A few weeks ago, we took things another step forward with FlakeBOM, a CLI for generating SBOMs from Nix flakes.<br>FlakeBOM turns the “what is actually in this software?” question into a concrete CycloneDX v1.5 document that you can hand to a vulnerability scanner, an auditor, or your own internal tools.
Today, we’re announcing FlakeAudit , a CLI for evaluating CycloneDX SBOMs against custom policies that pairs perfectly with FlakeBOM.<br>But first, a bit of explanation about why an additional tool is necessary (and powerful).
The limits of SBOMs
An SBOM on its own is only half the story.<br>You can produce the most exhaustive document in the world and it still wouldn’t tell you whether the components it lists are actually acceptable within your organization: whether the licenses line up with your org’s policy, whether any open vulnerabilities have already been triaged by your security team, and so on.<br>Without a scanning layer, an SBOM is a report on what exists on a system rather than something you can act on—and any true supply chain solution needs to empower you to act.
Open source SBOM auditing tools do exist.<br>Dependency-Track and Trivy, for example, are both excellent in what they are aiming to accomplish, but both leave certain things to be desired in a Nix-first pipeline.<br>Dependency-Track is a full OWASP project: a Java backend, a frontend, and an API server, all of which you have to stand up, harden, and keep on a supported version yourself before you can audit a single SBOM.<br>For a team that just wants a CI gate, that’s a lot of operational weight to take on.<br>Trivy is much lighter, but when it scans an SBOM it looks up vulnerabilities by Package URL (PURL), so it can only be as accurate as the PURL coverage in the SBOM you feed it.<br>Some packages don’t carry a PURL at all.
On the proprietary side, most major vendors tend to bundle SBOM production, signing, and scanning into a single platform, and they assume your SBOMs live inside their system.<br>But for an organization that already generates SBOMs locally, that’s a non-starter: you don’t get to bring your own SBOM, and you don’t get to apply your own policy without re-implementing it in their DSL.
Once you have an SBOM in hand, the natural next question is: “What do I do with it?”<br>This is where the existing landscape of tools gets a bit dicey.<br>Most vulnerability scanners are either proprietary, sluggish, written in bulky runtimes (like Dependency-Track in Java), or tied to a vendor platform that wants you to upload your build artifacts to their cloud.<br>Each of those has its place, but none of them are a great fit for a Nix-powered team that’s already producing SBOMs locally and wants to gate release on the result of SBOM audits.
The other side of the problem is policy.<br>Even after vulnerabilities are surfaced, you still need to express things like:
“Any component released under license X is not allowed in this product.”
“We need to ban this whole set of components, though with a per-component allowlist for exceptions.”
“We can only consume packages from these PURL types.”
“An exploitable vulnerability at high severity or above must block this release.”
You can write all of that down in a Markdown policy document, but it can only have teeth if a tool actually evaluates the SBOM against it and either passes or fails your CI run.
Enter FlakeAudit
Like FlakeBOM, FlakeAudit is a single Rust binary called flakeaudit, and it ships in the same statically linked form for Apple Silicon (aarch64-darwin), Linux on 64-bit Arm processors (aarch64-linux), and Linux on 64-bit x86 processors (x86_64-linux).<br>It consumes any CycloneDX 1.5 JSON SBOM and currently exposes three subcommands:
check: evaluate the SBOM against a flakeaudit.toml policy and fail CI on violations.
compare: diff two...