Security
What we protect, what we don't, and how to report.
Nipcode is a trust layer; we hold ourselves to the standard we ask of the packages we evaluate.
Report a vulnerability
Email info@nipcode.xyz with subject SECURITY. Please do not open public issues for security reports. We acknowledge within 72 hours.
Include affected surface, reproduction steps, impact assessment, and optionally a proposed fix.
In scope
- Authentication and session management (
/api/auth*) - API key generation, scoping, and revocation
- Trust scoring and install-plan boundaries
- Supabase RLS and schema
- DNS, TLS, deployment surface
Out of scope
- Third-party source registries (npm, PyPI, etc.). Report to them directly
- Social engineering and physical security
- Denial of service that does not bypass existing rate limits
Hard rules in the codebase
- Hosted API is read-only. Any change that would let it install, clone, extract, or write to a caller workspace is rejected on review.
- Package metadata is treated as untrusted data. It is never passed as instructions to a language model without quoting/escaping context.
- Trust scores must trace back to source-owned evidence. No fabricated numbers.
- API keys are scoped per-account, RLS-protected. The server-side service-role path is the only writer.
What we store
See data retention in the repo. Short version: account emails, API keys, waitlist emails, usage counters. No raw queries, no raw IPs, no User-Agents.