Vulnerability disclosure policy

Vandorisk sells software that helps manufacturers run a coordinated vulnerability disclosure process. Not having one ourselves would be difficult to defend, so this is ours. It is also published in machine-readable form at /.well-known/security.txt.

How to report

Email hello@vandorisk.comwith “security” in the subject. Tell us what you found, where, and the steps to reproduce it. A short proof of concept helps more than a scanner export. If a report contains details you would rather not send in plain email, say so and we will arrange another channel before you send anything.

Please do not open a public issue or post the details before we have had a chance to fix them.

What to expect

• Acknowledgement within 72 hours, from a person, saying whether we have reproduced it yet.
• An assessment and a plan within 10 working days, including our view of the severity and whether we disagree with yours.
• Credit in the fix note if you want it, and no credit if you would rather not be named.
• We will tell you when it is fixed. We are a small team, so we will give you a real date rather than a target we cannot meet.

Safe harbour

If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you for your research, and we will say so in writing if a third party asks. Good faith means: you stay within the scope below, you stop as soon as you have demonstrated the problem, you do not access, modify or retain other people’s data, and you give us a reasonable chance to fix it before telling anyone else.

If you are unsure whether something is in scope, ask first. We would rather answer a question than receive an apology.

In scope

The Vandorisk application at www.vandorisk.com, including its API, and this website.

Out of scope

• Anything that requires denial of service, brute force at volume, spam, social engineering, or physical access. Please do not test availability against production.
• Findings against our infrastructure providers rather than us. Report those to the provider.
• Missing hardening headers, cookie flags or TLS configuration with no demonstrated impact. Tell us anyway if you like, but they will be triaged as improvements rather than vulnerabilities.
• Accounts, products or assessments belonging to anyone other than you. Create your own account to test against.

For the controls behind the product, see Security.