← back to safety

[SECURITY.md]

Security

Yes, the company that builds security tools has a security page. We're aware of the recursion.

Our Approach

We build tools that help people audit their network security, so it would be genuinely humiliating if our own infrastructure was held together with duct tape and default passwords. It's not. Probably. We check regularly.

Our security posture is “paranoid but realistic” — we assume everything can be compromised and architect accordingly, while acknowledging that we are a small team and not the NSA. If the NSA wants to get in, they will get in. This page is not for them.

Infrastructure

TRANSPORT

All traffic is encrypted via TLS 1.2+ in transit. We enforce HTTPS everywhere. HSTS is enabled. Our SSL certificates are not self-signed. We are not animals.

STORAGE

Data at rest is encrypted. Database access requires authenticated service roles with row-level security policies. There are no public database policies. If you can read our database, something has gone very wrong and please email us.

APPLICATION SIGNING

NetGhost is signed with an Apple Developer ID certificate, notarized by Apple, and stapled for offline verification. Auto-updates are verified with EdDSA signatures via Sparkle. The signing keys are stored in GitHub Secrets and a hardware security module, not in a sticky note on a monitor. We checked.

AUTHENTICATION

Webhook endpoints verify cryptographic signatures. API endpoints require authenticated headers. Edge functions verify request origins. License activation uses device fingerprinting with one-way hashes. We do not use “admin/admin” as credentials on any system. We also do not use “admin/password123.” We are not going to tell you what we do use.

Local-First Architecture

The best way to protect user data is to never have it. Our products process sensitive data (network traffic, audio transcriptions) entirely on-device. This data never touches our servers. It is not uploaded. It is not synced. It does not exist in our infrastructure. This is not a policy decision — it is an architectural one. You cannot leak what you do not possess.

Responsible Disclosure

If you discover a security vulnerability in any h₀ product or service, we would genuinely like to know. Please report it to:

root@nullfoundation.org

We ask that you:

  • Give us reasonable time to fix the issue before public disclosure (90 days is standard)
  • Do not access or modify other users' data
  • Do not degrade the service for others
  • Act in good faith

We do not currently operate a formal bug bounty program because our bug bounty budget is approximately $0. But we will credit you publicly (if you want), fix the issue promptly, and be genuinely grateful. If our finances ever improve, we will revisit the bounty situation.

What We Don't Do

  • We do not run analytics or telemetry
  • We do not embed third-party trackers
  • We do not use your data to train models
  • We do not sell or broker data
  • We do not store passwords in plaintext (this should not need to be stated in 2026, and yet)
  • We do not have a “data monetization strategy”

Transparency

We have never received a government request for user data. If we do, we will comply with valid legal process and notify affected users to the extent permitted by law. We will not voluntarily cooperate beyond what is legally required. We will also not pretend this paragraph makes us special — it doesn't. It's the bare minimum. But bare minimums are apparently worth stating explicitly now.

This page is intentionally light on specific implementation details because publishing your exact security stack is a security vulnerability. If you're an auditor and need more detail, contact us directly. If you're an attacker, also contact us directly and we'll pay you in gratitude and maybe a sticker.