This policy covers every repository in the Nixidae organisation unless that repository ships its own SECURITY.md.

Do not open a public issue.

Report privately through GitHub's private vulnerability reporting on the affected repository (Security → Report a vulnerability), or by email to nixidae@lillecarl.com.

Useful things to include:

• Which repository and which version, commit or flake revision
• What an attacker can do with it, and what access they need first
• A reproduction — a script, a flake, or a sequence of commands
• Anything you already know about a fix

These are small projects maintained in spare time, so there is no around-the-clock response. In practice:

• Acknowledgement within a few days.
• An assessment — whether it reproduces, and how serious it looks — once the report has been read properly.
• A fix, on a timeline that follows the severity. Anything that lets an attacker execute code or reach a store or cluster they should not reach gets priority over everything else.
• Credit in the advisory and release notes, unless you would rather not be named.

Please give a reasonable window to ship a fix before disclosing publicly. If you have a deadline in mind, say so in the report and it will be worked with rather than around.

Everything here is pre-1.0. Only the current main of each repository is supported; fixes land there and go out in the next release. There are no backports to older tags.

In scope: the code in these repositories, their build definitions, and their published packages.

Out of scope, because they are not ours to fix:

• Vulnerabilities in Nix, nixpkgs, Kubernetes, or third-party Python dependencies — report those upstream, though a heads-up is welcome if one affects how a Nixidae project should be configured
• Findings that require an attacker to already have root on the machine, or write access to the Nix store
• Reports generated by a scanner with no accompanying analysis of impact

A note on the threat model these projects assume: Nix expressions and derivations are treated as trusted input. Evaluating an untrusted flake can run arbitrary code, and that is true of Nix itself, not something these projects introduce. Reports along the lines of "evaluating this malicious expression runs code" are expected behaviour rather than vulnerabilities — unless the project claims a sandbox boundary that turns out not to hold, in which case that is very much worth reporting.