Responsible Disclosure Policy

How to report a security vulnerability in FleetRight, and what to expect after you do.

Scope

This policy covers the FleetRight web application and its API, as reachable at the base URL published in our security.txt file. It does not cover third-party services we integrate with (e.g. the SMTP provider used to send email) unless the issue is in how FleetRight itself uses them.

How to report

Email the address listed in /.well-known/security.txt - that file is the single source of truth for our current contact address, so it won't go stale here. Please include:

A clear description of the vulnerability and its potential impact
Steps to reproduce it, or a proof-of-concept
Any accounts, URLs, or requests involved

Please don't post the issue publicly (including on GitHub, social media, or forums) until we've had a reasonable opportunity to fix it.

What to expect

Acknowledgement within 5 business days of your report.
An initial assessment - severity and whether we can reproduce it - within 10 business days.
Remediation timeline communicated once severity is confirmed; critical issues are prioritised over lower-severity ones.
Credit, if you'd like it, once the fix ships.

This is a good-faith disclosure channel, not (currently) a paid bug bounty program - we don't yet offer monetary rewards for reports, though that may change as the product matures.

Safe harbor

We won't pursue legal action against, or report to law enforcement, anyone who reports a vulnerability in good faith and in accordance with this policy, provided they:

Avoid privacy violations, data destruction, or service disruption
Only interact with accounts and data they own or have explicit permission to test
Give us a reasonable opportunity to investigate and fix the issue before any public disclosure
Don't use automated scanners in a way that degrades service for other users
Don't attempt social engineering or physical attacks against our team, users, or infrastructure

Out of scope

Reports generated purely by automated scanning tools without a demonstrated, exploitable impact
Missing security headers or best-practice suggestions with no demonstrated exploit
Issues that require an already-compromised device or browser to exploit
Rate-limit or account-lockout tuning ("I could send N requests before being blocked")

This policy is a starting point and may be refined as FleetRight's security program matures.