At Arrival, the safety and security of our customers and users has always been a top priority. We are dedicated to improving our products continuously, focusing on changing market needs, technologic breakthrough, as well as evolving threat surface and new attack vectors. This Responsible Disclosure Policy is in place to identify new vulnerabilities and security issues in the relevant hardware, software or services provided and maintained by Arrival and to address them in a timely manner.
The main scope: *.arrival.com. Service domain zone: *.arrival.co.
Also report a vulnerability or security issue in any Arrival product or service, excluding end-of-life Arrival products and services.
Reporting a vulnerability in good faith and by academical or private research is possible through our Responsible Disclosure Policy and will not be penalised. Targeted, malicious or persistent attacks, however, are strictly forbidden and will be reported to the relevant authorities in accordance with the relevant laws.
If issues reported to us affect a third-party library, external project, or another vendor, Arrival reserves the right to forward details of the issue to that party without further discussion with the researcher. We will do our best to coordinate and communicate with researchers through this process.
How to report
If you have any questions about scope, please ask us at [email protected] before performing any testing.
What we are looking for
Please send us the following information over a secure channel to be able to address the issue:
- Arrival product or service affected, including version numbers if applicable;
- Steps to reproduce the vulnerability/security issue including technical details as well as supporting evidence, e.g. logs, screenshots, pictures, exploit code;
- Vulnerability/security issue type, e.g. spoofing, tampering, remote code execution, server-side request forgery, information disclosure, denial of service, elevation of privilege;
- If you are reporting cross-site scripting (XSS), your exploit should at least pop up an alert in the browser.
- For a cross-site request forgery (CSRF), use a proper CSRF case when a third party causes the logged in victim to perform an action.
- For a SQL injection, we want to see DBMS name and version, not just producing an error message or stack trace log.
- HTTP request / response captures or simply packet captures are also very useful to us.
- Make sure the bug is exploitable by someone other than the user (e.g. “self-XSS”). The impact is always important!
- If you are reporting exposed credentials/source-code from the public repositories, don't forget to share links of that source with the screenshot of the place of leakage.
What we are not looking for
- Descriptive error messages (e.g. application or server errors).
- HTTP 404 codes/pages or other HTTP non-200 codes/pages.
- Banner disclosure on common/public services.
- Disclosure of known public files or directories, (e.g. robots.txt).
- Clickjacking and issues only exploitable through clickjacking.
- CSRF on forms that are available to anonymous users (e.g. the contact form).
- Logout Cross-Site Request Forgery (logout CSRF).
- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
- Lack of Secure and HTTPOnly cookie flags.
- Lack of Security Speedbump when leaving the site.
- Weak Captcha / Captcha Bypass.
- Username enumeration via Login Page error message.
- Username enumeration via Forgot Password error message.
- Login or Forgot Password page brute force and account lockout not enforced.
- OPTIONS / TRACE HTTP method enabled.
- SSL Attacks such as BEAST, BREACH, Renegotiation attack.
- SSL Forward secrecy not enabled.
- SSL Insecure cipher suites.
- The Anti-MIME-Sniffing header X-Content-Type-Options.
- Missing HTTP security headers, specifically.
Vulnerability Reporting Agreement
Please review these terms before you test and/or report a vulnerability. Arrival pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.
Arrival does not permit the following types of security research
Whilst we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited:
- Performing actions that may negatively affect Arrival, its personnel or its customers.
- Do not compromise the safety of the vehicle or expose others to an unsafe condition.
- Accessing, or attempting to access, data or information that does not belong to you.
- Destroying or corrupting, or attempting to destroy or corrupt, data or information that does not belong to you.
- Conducting any kind of physical or electronic attack on Arrival personnel, property or data centers.
- Social engineering any Arrival service desk, employee or contractor.
- Conduct vulnerability testing of participating services using anything other than test accounts.
- Violating any laws or breaching any agreements in order to discover vulnerabilities.
Arrival security team commitment
We ask that you do not share or publicise an unresolved vulnerability with/to third parties. If you responsibly submit a vulnerability report, the Arrival security team and associated development organizations will use reasonable efforts to:
- Respond in a timely manner, acknowledging receipt of your vulnerability report.
- Provide an estimated time frame for addressing the vulnerability report.
- Notify you when the vulnerability has been fixed.
- We are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Arrival.
Please note that by submitting a vulnerability report to us, you grant us a perpetual, worldwide, royalty-free, irrevocable and non-exclusive license and right, to use, modify, and incorporate your submission or any parts thereof into our products, services, or test systems without any further obligations or notices to you.
We would be thankful for any further relevant technical information that you may have, especially if reproduction is tricky. If we cannot reproduce it, we cannot reward you. However, there is no need to describe the security impact of your finding - we understand security risks and we can figure that out. We only need technical details.
We maintain flexibility with our reward system; rewards are based on severity, impact, and report quality. We do have specific things we are (and are not) looking for - so check What we are looking for.
If you report several issues that are duplicates in different parts of the service (e.g. the same code running on different nodes or platforms), or part of a larger issue, these may be combined into one and only one reward may be possible. If someone else has already reported the finding earlier, we will let you know after the issue has been fixed. If several researchers report the same issue, we only reward the sender of the first report that provides us with enough technical details to reproduce the finding. We know that this would give us a loophole to claim that everything’s been already previously found, but trust us, we want to be fair. A reward will not be provided if the finding becomes known by anyone else other than you or us, in any way, before it is fixed.
Payment of any reward is made at ARRIVAL’s sole discretion.
Please note that zero-day vulnerabilities (vulnerabilities that were not previously known to the security community) are not eligible for awards unless you identify a zero-day vulnerability on an in-scope system more than 30 days after the zero-day vulnerability was disclosed to the security community. Additionally, we have an internal team dedicated to addressing zero-day vulnerabilities and vulnerabilities that are already known and being tracked by our internal team at the time of your report will not be eligible for an award.
You can always keep tracking of how your issue is progressing. Contact Arrival Security team for this: [email protected]