Security

The claim, and its current status

The design goal: an adversary who fully compromises a Pellets namespace maintainer cannot run code on a downstream installer's machine. Known sandbox gaps remain open (see known limitations). Until they are closed, we do not present this claim as proven.

Threat model

The specification (Pellets security overview, section 2) defends against:

• a compromised maintainer account;
• a compromised developer workstation or CI runner;
• a deliberately malicious package publisher;
• a network attacker who cannot break TLS;
• a semi-trusted registry operator who cannot forge signatures;
• typosquatting and dependency confusion.

Out of scope for now: hardware supply-chain attacks, compromise of a publisher's signing root, theft of code-signing certificates by nation states, and side-channel attacks on the sandbox kernel.

What the specification requires

These are normative requirements from the Pellets security specification. Requirement IDs are listed so every statement can be checked. A requirement listed here is a design commitment; it is not a statement that the requirement is met today. Where we know a requirement is not met, it is listed under known limitations.

Known limitations

Disclosure is part of the Early Access offer. We describe each limitation plainly and cite the requirement it affects.

Sandbox and install isolation

• PEL-SBX-001 — hooks reaching host-local services: fixed. Security review found that a hook could connect to unix sockets on the installing machine's filesystem, such as the desktop session bus and, if the installing user was in the docker group, the Docker socket. Fixed in the engine source on 2026-10-12: hooks now see only their own package and scratch folders, run with no host groups, and never receive socket environment variables. Builds of the engine from before 2026-10-12 are affected; use a current build.
• Hooks under a root engine — open. If nestr itself runs as root, a hook runs mapped to the host's root user rather than to an unprivileged user as PEL-SBX-001 requires. Otherwise it runs as the installing user, also not a dedicated unprivileged user. Do not run installs or hooks as root.
• PEL-ART-003 — install paths: fixed. Our adversary test showed a lockfile name could make install write outside the project folder. Fixed in the engine source on 2026-10-12: names are validated and every install path is checked to stay inside the workspace.
• PEL-SBX-012 — hook network isolation: fixed. Our adversary test showed a hook granted any network access shared the host network. Fixed in the engine source on 2026-10-12: every hook runs in its own network namespace, and network-granted hooks reach the network only through the allowlisting proxy (PEL-SBX-020).

Related: the hook syscall filter is currently a deny-list, not the default-deny filter that PEL-SBX-002 requires.

General-availability pricing is deferred until the adversary vectors pass.

Namespace authority is not production-grade

The full namespace identity model (PEL-NS-*) is not yet running at production strength. The registry checks a namespace's ownership record first but still falls back to a stub allowlist for unclaimed namespaces. Of the ownership-proof methods in PEL-NS-003, DNS TXT works. Email proof is not delivered, the passkey check is a stub that does not verify the attestation, and OIDC proof is not configured, so an operator countersigns every namespace claim by hand.

Transparency-log witnesses

registry.nestr.tools does not yet run a real transparency log: entries carry no witness co-signatures and PEL-LOG-003 is not met.

Dashboard

The quarantine, structural-diff and provenance screens show labelled sample data, and quarantine actions are not sent to the registry. Other screens fall back to sample data when the backend is empty or unreachable.

Not running yet

• No production signing or builder keys exist yet, so there is nothing for a customer to pin and no Nestr pellet can be installed.
• Customers cannot publish to registry.nestr.tools yet.
• Hooks run only on Linux x86-64. On macOS, Windows and arm64 the sandbox refuses to run them.
• The install-time witness co-signature check ships with placeholder keys, so an online install cannot pass it until real witness keys are configured.
• Install does not yet verify transparency-log inclusion proofs; it checks only that the registry returns a matching entry.
• Install-time policy runs only when a previous version is cached, so a first install skips it, and a deny verdict is not yet acted on (only quarantine is).

Paying never changes verification

A lapsed, refunded or cancelled subscription removes paid features only (team invites, extra seats, security-record history, support). It never makes verification weaker or stronger. A paying organisation gets no extra trust, and a non-paying one gets no less.

Other

• Payments currently run in a sandbox; no real money moves yet.
• Early Access does not include single sign-on (SSO). SSO is Enterprise only.
• The nestr CLI is private for now and has no install path yet, including for Early Access. Self-hosting is not documented or supported yet.
• We hold no security certifications (for example SOC 2 or ISO 27001) and offer no uptime SLA.

Reporting a vulnerability

Email security@nestr.tools with the subject “Security report”; we do not offer an encryption key yet. Please do not open a public issue. We will acknowledge your report within 3 business days.