Responsible Disclosure Policy
The information on this page is intended for security researchers interested in reporting security vulnerabilities to the Visma security team. If you are a customer and have a question about security or a password or account issue, please contact us through the support channels available for your product.
This policy sets out our definition of good faith in the context of finding and reporting vulnerabilities, as well as what you can expect from us in return.
When working with us according to this policy, you can expect us to:
- Extend Safe Harbor for your vulnerability research that is related to this policy
- Work with you to understand and validate your report, including a initial response to the submission within 12 business hours
- Work to remediate discovered vulnerabilities in a timely manner
When conducting vulnerability research according to this policy, we consider this research to be authorized, lawful, helpful to the overall security of the Internet, and conducted in good faith.
You are expected, as always, to comply with all applicable laws.
If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through our Official Channel before going any further.
To encourage vulnerability research and to avoid any confusion between good-faith hacking and malicious attack, we ask that you:
- Play by the rules. This includes following this policy, as well as any other relevant agreements. If there is any inconsistency between this policy and any other relevant terms, the terms of this policy will prevail.
- Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope.
- Only interact with accounts or devices you own or with explicit permission from the owner.
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
- If a vulnerability provides unintended access to data, limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept.
- Cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information.
- Do not attempt to execute Denial of Service attacks.
- Social engineering (e.g. phishing, vishing, smishing) is prohibited.
- Report any vulnerability you’ve discovered promptly.
- Do not engage in extortion by demanding a reward before disclosing vulnerability details.
- Use only the Official Channels to discuss vulnerability information with us.
You are not allowed to publicly discuss or publish any vulnerability before it has been fixed and you have received explicit permission from us to do so.
We do not currently offer money or swag as rewards for reports.
The only exceptions are the specific assets listed in our Bug Bounty Program on HackerOne, see https://hackerone.com/visma. In HackerOne, we will only accept reports for the explicitly listed assets.
For all other assets, we will as a small token of appreciation, offer a place in our Security Hall of Fame (HoF) for all researchers that submits a previously unknown vulnerability that triggers a code or configuration change.
How to Contact Us
Our official communication channel is via email to firstname.lastname@example.org. The issues are triaged by a Security Analyst before being escalated to the appropriate team. If you feel that the email should be encrypted, our PGP key is available below.
This policy covers all Visma services, products or web properties.
Please note! Most reports we receive have little or no security impact or are already known. To avoid a disappointing experience when contacting us, please take a moment and consider if the issue you want to report actually has a realistic attack scenario.
More specifically, we ask you to not submit issues regarding:
- Theoretical vulnerabilities without any proof or demonstration of the real presence of the vulnerability.
- Findings from automated tools without providing a Proof of Concept.
- Vulnerabilities requiring MITM, or physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones.
- Missing or weak security-related HTTP headers.
- Non-Sensitive Data Disclosure, for example server version banners.
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS.
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions.
- Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.).
- Host header injection, unless you have confirmed that it can be exploited in a practical attack.
- Previously known vulnerable software or libraries without a working Proof of Concept.
- Rate limiting or bruteforce issues on non-authentication endpoints.
- Denial of Service.
- CSV/formula injection.
- Flash based exploits.
- Clickjacking on pages with no sensitive actions.
Our PGP key
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: Mailvelope v2.0.0
-----END PGP PUBLIC KEY BLOCK-----