How we protect you

Your email address, your app names and descriptions, their slugs, the labels you give API keys, and our Stripe customer and subscription ids are encrypted with AES-256-GCM, one row at a time, before the write happens. The key that can read them lives only in our runtime environment, never in the database and never in a backup on its own. Where the system still needs to look a row up by one of these fields, such as finding your account by email at sign-in, it uses a separate keyed index next to the encrypted value. Legacy records can retain plaintext copies until the separate cleanup step is completed. The label you give a passkey is encrypted the same way, because it usually names a person or a machine, while the credential itself is a public key and there is nothing secret in it to protect.

Encryption protects the encrypted fields when the database is exposed without the application key. It does not protect legacy plaintext copies. Your component list, the advisories that match it, and the alert history are not encrypted by the application. Group names, slugs and tags are also stored as ordinary text. These fields and combinations of package versions can identify a business or help an attacker target it. Authentication records include session tokens, IP addresses and browser information. Passwordless sign-in does not make a database breach harmless.

VibeBeacon does not store sign-in passwords. You sign in with a one-time magic link sent to your email, with GitHub, or with a passkey you have added in Settings. The GitHub scope we ask for covers your email address only. The admin area accepts an allow-listed account only after GitHub or passkey sign-in; magic-link sessions cannot open it. This provider check does not verify that GitHub required a second factor during sign-in.

An API key is shown to you once, at the moment you create it, and never again. We store a SHA-256 hash of the key plus its first fourteen characters, so the CLI tab in your dashboard can show you which key is which without showing the key itself. Revoking a key removes the hash immediately; from that moment a request bearing the old key is rejected.

• HSTS, so a browser that has ever visited us will not downgrade to plain HTTP.
• A Content-Security-Policy built fresh per request with a random nonce: scripts run only from our own origin and that one nonce, so an injected script tag has nothing to attach to.
• Frame denial, so the app cannot be embedded in another site's frame and used for clickjacking.
• Sign-in rate limits, per email and per IP address, with generic magic-link responses to reduce account discovery. Network and delivery timing can vary; this is not a constant-time guarantee.

The app runs on Vercel, and the database on Neon, both in the Sydney region, so a database round trip stays in the same city as the server making it. Data is encrypted at rest and in transit. No secret, API key or connection string is committed to the repository; every one of them is checked for on every push.

Stripe handles billing. We never see or store a card number: Stripe collects it directly and hands us back an id we can bill against. Every webhook Stripe sends us is checked against its signature before we act on it, so a request claiming to be from Stripe that is not actually from Stripe is rejected.

Customer data routes check account ownership or sharing permissions. Asking for another account's app, alert or export by id returns a not-found response, the same response you would get for an id that does not exist at all, so there is nothing to distinguish “not yours” from “does not exist”. This is checked by tests that log in as one account and try to reach another account's data through every route that accepts an id.

• Dependabot opens a pull request when a dependency has a known fix available.
• Every pull request runs a security check that fails the build on a high or critical advisory in our production dependencies, if it is not on a short, dated exception list that someone has to keep reviewing.
• A weekly automated scan crawls the live site the way a visitor's browser would, and its findings are filed for us to read, every week.

• Export everything we hold on your account as one JSON document, on request.
• Delete an app, or your whole account, at any time. Deletion is immediate.
• Unsubscribe from any email from the link in its footer.

The package that installs

See exactly what would install, with no install happening.

npm pack vibebeacon@latest --dry-run

Provenance is specific to each published version. Check that version's npm provenance panel and attestation. CLI 0.4.0 and MCP 0.4.1 were published without attestations; a newer version or workflow setting alone does not prove one exists.

npm audit signatures

The manifest before anything sends

Print the manifest before uploading. npx may contact npm to fetch the client:

npx vibebeacon scan --json

The source

The source repository is private. You can inspect the exact release you plan to run by downloading its npm tarball, but we do not offer a public source checkout or independently reproducible build. A file listing does not prove source correspondence or build provenance.

The site itself

Run vibebeacon.app through independent scanners that grade transport and header configuration. We do not print a number here, because a number on this page would go stale the moment the site changes; run the check and see the grade live.

• Mozilla HTTP Observatory
• SecurityHeaders.com (a link only: it has no public API to run automatically)
• SSL Labs

Our own CI runs the Observatory and SSL Labs checks weekly and fails the build if a fetched grade drops below A; the grade in that job's summary is the one to trust, since it is fetched live rather than typed into this page.

What we cannot show you yet

We have not commissioned an external security audit of VibeBeacon. Everything above is checkable against the running code, but nobody outside the company has independently tested it.

Email security@vibebeacon.app with what you found, the steps to reproduce it and, if you have one, a proof of concept. We read every report and reply to say we have received it. Give us a reasonable amount of time to fix the issue before telling anyone else, do not access or change data that is not yours while testing, and do not run automated scanners that could degrade the service for other users. We do not run a paid bug bounty at this stage. We will credit you by name, if you want that, once a fix ships, and we will not pursue legal action against anyone who reports in good faith and follows the guidelines above. A machine-readable version of this contact is at /.well-known/security.txt. Questions about anything else: email hello@vibebeacon.app.