VeloLog — Security Disclosure Policy

Version 1.0 · Drafted [Date]

If you believe you've found a security vulnerability in VeloLog, we want to hear about it. This page explains how to report responsibly and what you can expect from us in return.

How to report

Email security@velolog.io with as much detail as you can share:

• What the vulnerability is (description of the issue).
• Where it lives (URL, endpoint, screen).
• How to reproduce (step-by-step, payload, request body).
• Impact you observed or could plausibly demonstrate.
• Your name (or a handle if you prefer) for the acknowledgement.

If the vulnerability is sensitive (data exposure, account takeover, authentication bypass), encrypt the report with our PGP key:

`` [PGP key fingerprint and public key block to be inserted here once generated] ``

What you can expect from us

• Acknowledgement within 5 working days that we've received your report and started investigating.
• A specific contact person assigned to your report — usually the CTO, with the engineering team for resolution.
• Status updates at least every 7 days until the vulnerability is resolved or we've explained why we won't act on it.
• Public acknowledgement in our security advisories page once the fix is deployed — but only if you want to be named.
• No legal action against you if you acted in good faith and respected the rules in the next section.
• Honest gratitude. This is unpaid work that helps protect our users. We don't currently run a bug bounty programme, but if your report prevents real harm, we want to thank you in a way that matches the contribution — at minimum public recognition, more for significant finds.

Rules for safe testing

To stay within the safe-harbour described below, please:

• Don't access more user data than necessary to demonstrate the vulnerability. If you find you can read other users' email addresses, one or two examples is plenty. Don't dump the table.
• Don't modify or delete data belonging to other users.
• Don't pivot — if you find a vulnerability that gives you access to internal systems beyond what's needed to prove it, stop and report.
• Don't run automated scanners at high rate without telling us first. We have rate limits and DDoS protection; aggressive scans look identical to attacks and get null-routed.
• Don't use social engineering against our staff or other users.
• Don't disclose publicly before we've had a reasonable chance to fix (we suggest 90 days from initial report, or sooner by mutual agreement).

Safe harbour

We commit not to pursue legal action against anyone who:

• reports a vulnerability in good faith;
• respects the rules above;
• gives us a reasonable opportunity to fix before public disclosure;
• doesn't use the vulnerability for personal gain or to harm others.

This safe harbour applies to civil claims VeloLog could otherwise bring under the Computer Misuse Act 1990 (UK), equivalent national laws, contract law, or otherwise. It does not override criminal law in jurisdictions where unauthorised access is itself a crime regardless of intent — please check your local law.

If a third party (a User, a regulator, law enforcement) brings a claim against you in connection with your report, we will, where lawful, do what we reasonably can to support you, including providing documentation that you acted under this Policy.

What's in scope

Specific things we want to hear about

• Authentication or authorisation bypasses
• Account takeover (including via password reset, OAuth, session theft)
• IDOR (insecure direct object reference) on any endpoint
• SQL injection or other server-side code execution
• Server-side request forgery (SSRF)
• XSS or HTML injection that escapes our sanitisation
• CSRF on sensitive endpoints
• Privilege escalation (Basic Rider → Premium / Business / Admin)
• Bypasses of rate limits or content moderation
• PII exposure (email, name, address, hashed credentials, etc.)
• EXIF metadata leaks (we strip on upload — finding a path that doesn't is something we want to know)
• Stolen-flag bypass or false-flag-without-consequence
• Marketplace transfer-token replay or theft

What's less interesting

We'd rather not receive reports on:

• Missing security headers (we know; they're prioritised internally).
• Cookie attributes (SameSite, Secure, HttpOnly) — please check whether the cookie is actually used for authentication before reporting.
• Self-XSS (the user has to attack themselves).
• Clickjacking on pages without sensitive actions.
• DNS issues outside our control (CAA, DMARC missing on email — we know).
• Auto-discovered findings from generic scanners with no proof-of-concept.
• Theoretical issues without demonstrable impact.

These aren't unwelcome, just lower priority.

How fast we fix

We try to resolve based on impact:

We will tell you when a fix is deployed and invite you to verify.

Past advisories

Resolved vulnerabilities are published at velolog.io/legal/security-advisories with reporter attribution (consent permitting).

Contact

security@velolog.io for vulnerability reports.

For general security questions: support@velolog.io.

For privacy-related issues (data exposure, breach response): dpo@velolog.io.