Security

fend is a security tool. This page documents what it does, what it doesn’t, and how to report problems.

Threat model

fend protects against arbitrary code execution by your dependencies at install and run time. The threat model assumes any package you install — directly or transitively — may be malicious.

In scope:

• A preinstall / postinstall script reading ~/.ssh/id_rsa, ~/.aws/credentials, or other host secrets
• A package scanning your home directory for .env files or browser cookies
• A package installing background processes, launchd agents, or cron jobs
• A package exfiltrating data to a remote endpoint via HTTP
• A package planting persistence on your host filesystem
• A package reading another project’s source on your machine

Not in scope:

• Bugs in code you write or import. fend isolates execution, not the semantics of your application. If you import a package and call into it from your own code in the sandbox, the package can do anything your code can do inside the VM. The host stays safe; the VM does not.
• Network-level supply-chain attacks before the package reaches OSV.dev or the registry. Use Socket.dev for behavioral analysis; the two tools are complementary.
• Compromise of the npm registry itself (replacing a published tarball with a backdoored one). fend audits against the published version; if the upstream record is wrong, the audit is wrong.
• Side channels between your project files and the rest of your home directory if you put secrets inside the project (e.g. a .env file in the project root). Anything visible to the project is visible to the VM.

Reporting a vulnerability

If you’ve found a sandbox escape, audit bypass, or any other security issue, please email [email protected] rather than opening a public issue.

We aim to:

• Acknowledge within 48 hours
• Provide an initial assessment within 5 business days
• Coordinate a fix and disclosure window with you (default: 90 days)

A GPG key for encrypted reports will be published here once the v0.1 release is signed and notarized.

What fend collects

Nothing leaves your machine except:

• Audit queries to OSV.dev — these contain name@version strings from your package-lock.json. No file contents, no project paths, no machine identifiers. Cached locally per advisory ID.
• Network traffic initiated by your dependencies during installs and dev scripts. fend does not proxy or inspect this traffic; it goes out via the VM’s NAT interface, same as if you’d run npm install natively.

There is no telemetry, no analytics, no usage reporting in fend.

Verifying installs

Once the v0.1 release is signed and notarized, the npm package will ship with a pinned SHA256 of the platform binary. Until then, the recommended path is to build from source — see the GitHub repo.

Known limitations

We’re upfront about what’s still rough:

• Apple Virtualization.framework only. macOS Apple Silicon. Intel and Linux/Windows are on the roadmap but not in this release.
• VirtioFS DELETE event gaps. File-watcher tools running inside the VM may miss DELETE events on host-side file removals. fend mitigates with a host-side FSEvents → vsock bridge but the gap exists at the VirtioFS layer.
• No --no-network mode yet. All network traffic is currently allowed (NAT to host). Per-project network policy and outbound-call logging are planned for the macOS app tier.
• Ad-hoc codesigning in alpha builds. Until Developer ID notarization ships, you may need to allow the binary in System Settings → Privacy & Security after first launch.

What fend does NOT claim

• Not “100% secure.” Sandbox escapes are possible; that’s why this page exists.
• Not a replacement for code review. fend buys you the freedom to try unfamiliar packages without inviting them into your home directory.
• Not a behavioral-analysis tool. It does not classify packages as good or bad — it makes the question less load-bearing.