Security, login gate and reliability
What Flox says about SBOMs, provenance and hermetic builds, and which of those claims have a documented mechanism behind them; the Oct 20 2026 catalog login requirement and what stays public; how packages are cached and served; the live status page, incident history, GitHub advisories and release cadence as fetched on 2026-11-04; and how to talk to a customer about the gaps. Mechanisms the sources do not document are flagged
[verify]. Nothing here is an uptime guarantee.
This page is drawn from https://flox.dev/secure-software-by-construction/, https://flox.dev/cve-remediation/, https://flox.dev/compliance/, https://flox.dev/blog/achieving-rapid-cve-remediation-in-an-era-of-escalating-vulnerabilities/, https://flox.dev/blog/mitigating-shai-hulud-attacks-with-hermetic-builds/, https://flox.dev/docs/concepts/authentication, https://flox.dev/docs/concepts/base-catalog, https://flox.dev/docs/customer/signing-keys, https://status.flox.dev/, https://github.com/flox/flox/releases and https://github.com/flox/flox/security/advisories.
Claimed versus documented
| Claim | Where Flox says it | What the sources document | Gap |
|---|---|---|---|
| Deterministic SBOMs | “Every Flox environment is hash-pinned with a deterministic SBOM.” (https://flox.dev/cve-remediation/) | The changelog lists “Package SBOMs” (2025-11-15) and, on 2026-03-15, “Environment SBOMs” with the line “Export SPDX and CycloneDX compliance documents for your environments” (https://flox.dev/docs/changelog/2025, https://flox.dev/docs/changelog). The CVE post says “FloxHub generates SBOMs for individual packages and complete environments” (https://flox.dev/blog/achieving-rapid-cve-remediation-in-an-era-of-escalating-vulnerabilities/). | The CLI command or UI step that exports an SBOM is not in the docs I read [verify]. |
| Provenance in the artifact | “build provenance is encoded in the artifact itself” (https://flox.dev/secure-software-by-construction/) | The mechanism offered is the hash-addressed store path and lockfile: each package “resolves to an immutable, hash-addressed store path” (same page). | No attestation format is named; the CVE page’s summary block lists provenance as attestable without saying how [verify]. |
| Signed bill of materials | “Every environment carries a signed bill of materials and a full lineage” (https://flox.dev/) | Package signing is documented: “In order to upload a package it must be signed”, and FloxHub-hosted catalogs sign with the floxhub-1 key (https://flox.dev/docs/customer/signing-keys). | Who signs an SBOM, and how a customer verifies it, is not documented [verify]. |
| SLSA | The Series B post lists the goal to “Provide real-time vulnerability detection with comprehensive SBOMs and SLSA compliance” (https://flox.dev/blog/about-our-series-b/) | Stated as future work. | Do not say Flox is SLSA compliant; no level is stated [verify]. |
| Software policy engine | Listed under Enterprise (https://flox.dev/pricing/) | The Kubernetes post says admission control “can gate on the Flox environment annotation in the Pod template and its SBOM”, which is the customer’s own policy tooling (https://flox.dev/blog/with-kubernetes-uncontained-flox-unlocks-faster-more-reproducible-workloads-on-k8s/). | What Flox’s own policy engine enforces, and its rule language, are not documented [verify]. |
| SOC 2 Type II and ISO/IEC 27001:2022 | https://flox.dev/compliance/ | The page says “Customers and prospects can request access to our SOC 2 Type II report and ISO/IEC 27001:2022 certificate.” | Audit period and scope are in the report, not the page [verify]. |
Say: the SBOM comes from the resolved dependency graph, not from a scanner guessing afterwards. Do not say that Flox signs your SBOM, or that it is at any SLSA level.
Remediation, and what the blog admits
Flox’s CVE workflow is: find the lockfiles or closures containing the affected package, edit the manifest, re-lock, rebuild, promote (https://flox.dev/blog/achieving-rapid-cve-remediation-in-an-era-of-escalating-vulnerabilities/). The post is candid about limits: “No, this isn’t O(1) remediation” and “Teams still need to test the runtime environment’s behavior, coordinate rollout, and promote the replacement FloxHub generation” (same post). It also marks the blind spot: “This reuse applies to dependencies captured by the Flox/Nix environment; packages or artifacts fetched imperatively at activation or runtime must be pinned and tracked separately.” (same post). Ask the customer what their hooks download at activation.
Hermetic builds
Flox’s Shai-Hulud post is the best statement of the claim and its limit. It says “Hermetic build environments won’t prevent attacks like Shai-Hulud, but they will tightly limit the damage” and the mechanism is “no network access (when sandboxing is enabled)” (https://flox.dev/blog/mitigating-shai-hulud-attacks-with-hermetic-builds/). It also warns: “It’s important to flag that this approach only works if you use a hermetic builder for everything.” (same post), and “we should caveat that Flox was not designed to be a security product” (same post).
Documented specifics for flox build: with sandbox = "pure" the build runs in a clean environment, and “Sandboxed builds on Linux are also restricted from accessing the network”, but “pure builds on macOS will still have network access” (https://flox.dev/docs/concepts/manifest-builds). That macOS exception is the first thing to tell a security reviewer.
The Oct 20 2026 login requirement
From 2026-10-20, commands that resolve packages against the catalog need a free FloxHub account (https://flox.dev/docs/concepts/authentication).
| Needs sign-in | Stays public |
|---|---|
flox install of a catalog package, flox upgrade, flox run, any command that must lock because manifest.lock is missing or a catalog package or system changed, flox push, flox publish | flox search, flox show, flox activate with a current lockfile, flox build with a current lockfile, flox pull of a public environment, editing [vars], [hook], [profile] or [services] |
All rows are from https://flox.dev/docs/concepts/authentication. Key points for reliability conversations:
- It applies to old CLIs: “The Flox catalog enforces the requirement” and so it reaches every version; versions before 1.3.5 must be upgraded (https://flox.dev/docs/concepts/authentication).
- CI: commit the lockfile, or set
FLOX_FLOXHUB_TOKEN; tokens need Flox 1.14.0 or newer (https://flox.dev/docs/concepts/authentication). - Air-gapped agents: “A lockfile eliminates the need to resolve dependencies, but it doesn’t eliminate the need to obtain packages” and “Authentication tokens cannot substitute for network connectivity” (https://flox.dev/blog/flox-catalog-login-requirement-what-you-need-to-know/).
- Failure mode: commands that resolve packages do not prompt; they fail with an error telling you to run
flox auth login(https://flox.dev/docs/concepts/authentication). - Stated motive: abuse prevention and understanding usage, and “this is not a paywall” (same page).
How packages are cached and served
- The Base Catalog comes from Flox’s nixpkgs fork, ingesting the equivalent of nixos-unstable daily (https://flox.dev/docs/concepts/base-catalog). A separate process records build information from cache.nixos.org, which “allows flox to make attempts to serve up known good builds” (same page).
- Flox runs its own public binary cache at https://cache.flox.dev for CUDA packages (https://flox.dev/docs/concepts/cuda-catalog-and-cache).
- Each organization gets a Catalog Store for its published packages: “By default, Flox provides a pre-configured Catalog Store to each organization as part of the organization’s private Catalog”, and customers can use their own S3-compatible bucket (https://flox.dev/docs/customer/catalog-store).
- “Last good build”: the sources support attempts to serve up known good builds for the base catalog, not a guarantee
[verify]. The one documented case of Flox pulling bad content is the 2025-11-20 status incident below, where it “removed 2 previous updates” (https://status.flox.dev/api/v2/incidents.json). - Environment rollback is separate and documented:
flox generations rollbackundoes a change (https://flox.dev/docs/concepts/generations).
Status page
Flox has a public status page at https://status.flox.dev/. As fetched on 2026-11-04 its API reports “All Systems Operational” with five components: flox.dev, hub.flox.dev, api.flox.dev, downloads.flox.dev and shipit.flox.dev (https://status.flox.dev/api/v2/summary.json). The incidents API returned 10 entries, the oldest on 2025-03-20 (https://status.flox.dev/api/v2/incidents.json). Six fall in the 12 months to 2026-11-04 (derived from that list):
| Date | Entry | Flox’s wording |
|---|---|---|
| 2025-11-18 | flox.dev is down | “flox.dev is currently down because of a major global Cloudflare outage.” Resolved the same day. |
| 2025-11-20 | Flox package updates are paused | Upstream updates were paused after Go packages broke; Flox “removed 2 previous updates”; regular updates resumed 2025-11-25. |
| 2026-04-17 | Install package signing key expired | “Our Debian (deb) package signing key has expired”; fixed in v1.11.4 the next day. |
| 2026-05-22 | Flox documentation unavailable | Restored in about 45 minutes. |
| 2026-06-10 | Intermittent Catalog Service Errors | “503 Service Unavailable” errors in the CLI; fixed in about 70 minutes. |
| 2026-10-29 | Degraded catalog response time and increased error rate | “We have identified an increased rate of 502 errors in response to catalog requests”; “A retry should proceed normally.”; resolved 2026-10-30. |
All rows: https://status.flox.dev/api/v2/incidents.json. The last one is the most relevant: it came nine days after the login gate, and catalog errors are the thing that breaks flox install for everyone. I did not find a published root-cause write-up for it [verify]. No SLA appears on the pricing page; the homepage lists “Support with an SLA” under enterprise but gives no numbers (https://flox.dev/) [verify].
GitHub advisories and release cadence
The Security tab of flox/flox shows There aren’t any published security advisories and the API returned an empty list for https://api.github.com/repos/flox/flox/security-advisories (fetched 2026-11-04). That does not mean no security fixes: Flox ships them in release notes. Examples:
- v1.18.2 updates bundled Nix to address the October 2026 Nix and Lix advisory; “All Flox releases prior to 1.18.2 are affected” (https://github.com/flox/flox/releases/tag/v1.18.2).
- v1.19.2 patches CVE-2026-111497, a vulnerability in the Brotli decompression library used by Flox’s bundled Nix, and says “We are not currently aware of a direct exploit against Flox.” (https://github.com/flox/flox/releases/tag/v1.19.2).
- v1.19.1 makes Linux CA certificates distrust four compromised roots (https://github.com/flox/flox/releases/tag/v1.19.1).
The README’s reporting route is “We encourage responsible disclosure of potential security issues” by emailing security@flox.dev (https://github.com/flox/flox). Cadence: the releases API lists 30 releases from v1.8.0 on 2025-12-17 to v1.19.3 on 2026-10-28, roughly one every 11 days (derived, https://api.github.com/repos/flox/flox/releases). Within eight days of the login change there were four releases, v1.19.0 to v1.19.3 (https://github.com/flox/flox/releases). Fast patches are a strength; the flip side is that “upgrade” is a frequent instruction.
How to talk about gaps
Say:
- Here is the claim, here is the page, here is what the docs show for the mechanism. Use the table above.
- Flox itself says it is not a security product, and that hermetic builds limit blast radius (https://flox.dev/blog/mitigating-shai-hulud-attacks-with-hermetic-builds/)
- Catalog resolution needs a free account since Oct 20; activation of a locked environment does not (https://flox.dev/docs/concepts/authentication)
- There was a catalog degradation on Oct 29, and the status page has the timeline (https://status.flox.dev/api/v2/incidents.json)
Never say:
- That Flox is SLSA compliant, that SBOMs are signed, or what the policy engine enforces, without a source.
- That no advisories means no vulnerabilities. Fixes are in release notes.
- Any uptime number.
- Root cause for an incident Flox has not written up.
When you do not know, say so and offer to ask the security team at security@flox.dev (https://github.com/flox/flox).