Skip to content
VibeBeacon

Verify us

Everything on the security page is checkable. This page gives the same steps in more detail, so you can run them yourself before you add a real app.

The package that installs

Before you run anything against a real project, see the exact files that would be included in the published package, with no install happening:

bash
npm pack vibebeacon@latest --dry-run

From version 0.4.0, the published package carries a signed build provenance attestation: a project that already has it installed can check the attestation with the command below, and the package page on npmjs.com shows the same check as a provenance panel.

bash
npm audit signatures

What provenance proves, and what it does not

A passing provenance check proves the package was built by a specific, public CI workflow, from a specific commit in a specific repository, rather than assembled and published by hand from an unknown machine. It does not prove the code is free of bugs or vulnerabilities, and it is not a substitute for reading the code or for an independent security audit. It answers one question only: did this package come from the build you can see, or from somewhere else.

The manifest before anything sends

Print the exact manifest the CLI would upload, before any network call happens. Nothing in this command talks to VibeBeacon:

bash
npx vibebeacon scan --json

Read the output. It should hold package names, versions and ecosystems, never file contents, source code or environment values. If it ever holds something it should not, that is a bug worth reporting.

The source

The CLI, the MCP server and the manifest library that parses your lockfiles are public. Nothing about how a manifest gets built runs on a server you cannot see:

github.com/rhys100/vibebeacon-packages

The site itself

Run vibebeacon.app through independent scanners that grade transport and header configuration. This page does not print a number, because a number written here would go stale the moment the site changes.

  • Mozilla HTTP Observatory grades response headers such as the Content-Security-Policy and HSTS.
  • SecurityHeaders.com covers similar ground. It has no public API, so it is a link only here and is not run by our own automated check below.
  • SSL Labs grades the TLS configuration: protocol versions, cipher suites and certificate setup.

A scheduled GitHub Actions workflow runs the Observatory and SSL Labs checks weekly against vibebeacon.app and fails the build if a fetched grade drops below A. Its job summary is the number to trust, since it is fetched live rather than typed into a page. Run the same check yourself from a clone of the repository; the Observatory half needs nothing extra, and the SSL Labs half needs an email address already registered with SSL Labs' own free registration endpoint, set as SSLLABS_EMAIL:

bash
npm run grades:check --workspace=@vibebeacon/web

security.txt and reporting a problem

/.well-known/security.txt carries the disclosure contact in a machine-readable form, per RFC 9116. The full reporting process is on the security 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 and the public package source, but nobody outside the company has independently tested it. That is the honest gap today.

See also

The full list of what VibeBeacon stores, encrypts and never sees is on the security page.

Verify us | VibeBeacon