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 (see below)l before going any further.

‍

To encourage vulnerability research and to avoid any confusion between good-faith hacking and malicious attacks, we ask that you:

• Play by the rules. This includes following this policy, as well as any other relevant terms or 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 personal data and sensitive personal data, 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 offer two options for reporting:

1. Visma Responsible Disclosure Program is available on the Intigriti platform
2. If you do not want to send the report through Intigriti, you can use our official communication channel: security@visma.com. 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.

‍

We do not offer monetary rewards for Responsible Disclosure reports, but if you report via our Visma Responsible Disclosure program on Intigriti, for all valid Medium+ reports we do offer swag as a sign of appreciation.

The only monetary reward exceptions are the specific assets listed in our Public Bug Bounty Program on Intigriti. Please note that for the Public Bug Bounty Program, we will only accept reports for those assets that are listed into the program scope and no other variations.

For all other assets and regardless of the option used for reporting, we will offer a place in our Security Hall of Fame (HoF) for all researchers that submit a previously unknown vulnerability that triggers a code or configuration change.

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.
• Self-XSS.
• 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.
• Expired SSL certificates, weak SSL Ciphers, or issues regarding old TLS/SSL versions.
• 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.
• Google Maps API key disclosure.

‍

When duplicates occur, we will only accept the first report. A duplicate is a vulnerability that we are already aware of, regardless of how we first became aware of it (it could have also been discovered by us internally).

‍