Security & data handling
How the audit works, and where its boundaries are
Everything on this page describes the product as it actually works today. No certifications are displayed because none have been obtained yet — when that changes, you'll see it here first.
Audit methodology
The free external audit evaluates publicly accessible production behavior: served pages, response headers, redirects, client-delivered assets, and the third-party services an application loads. It observes the same information any visitor's browser receives.
Findings are labeled with a severity (Critical to Informational) and a confidence level (Confirmed, Strong signal, or Requires verification). We do not present probabilistic detection as confirmed fact, and a clean scan is never represented as proof that an application is secure.
External scanning boundaries
External scans do not brute-force accounts, bypass authentication, attempt privilege escalation, modify application data, run denial-of-service tests, or attempt to exploit detected vulnerabilities. If an application restricts automated requests, we respect that and report only the checks that could be safely completed — we do not attempt to evade protection mechanisms.
Only submit applications you own or are authorized to assess.
Data handling
URL scans process publicly accessible application data required to generate the report. Lead information you provide (application URL, email address if submitted, and attribution parameters) is stored to deliver the report and follow up when you request it.
Analytics events carry identifiers, domains, score bands, and counts — never secrets, raw audit evidence, or report contents.
Potential secrets & redaction
If the scanner identifies a value resembling a secret (for example, a payment-provider key pattern in client-delivered code), reports display a redacted fingerprint rather than the full value. The report format is designed so full sensitive values are not stored or displayed unnecessarily.
GitHub permissions
The deep code audit is optional and separate from the free external scan. When it is requested, repository access happens only after your explicit authorization through GitHub, is read-only, and is limited to the repository you select. We never push code during an audit, and you can revoke access at any time from your GitHub settings.
Report access & retention
Report links include an access token, so a report cannot be opened by guessing its scan identifier. Reports are designed for time-limited retention (the retention date is displayed on each report). As retention automation and repository-data policies are finalized, this page will document them precisely — we would rather publish nothing than an unimplemented promise.
Vulnerability disclosure
If you believe you've found a security issue in VibeCheck itself, please email tech@vibereadystack.com with details. We appreciate responsible disclosure and will respond as quickly as we can.
Responsible use
The scanner must only be pointed at applications you own or are authorized to assess. We may block scans that appear abusive or unauthorized.
Ready to see what an audit looks like?
View Example Report →