Skip to content
English
Book a demo
English
Book a demo

Responsible disclosure policy

Introduction

Roseman Labs B.V. (hereafter: Roseman Labs) has documented its policy for accepting vulnerability reports in our products. We embrace an open dialogue with the security community. The work the community does is important to ensure safety for all our customers.

Scope

Roseman Labs's Vulnerability Disclosure Program covers the following products:

Legal position

It is possible that, during the course of your research, you may take actions that are punishable under criminal law. If you have complied with the conditions below, we will not take legal action against you. However, the Public Prosecutor’s Office always retains the final right to decide whether to prosecute you. The Public Prosecutor has published information about this.

What we ask from you

  • Do not abuse the weakness by, for example:
    – Downloading more data than is necessary to prove a vulnerability
    – Changing or deleting data
  • Do not test outside the scope of our vulnerability disclosure program.
  • Do not disrupt our customer services, i.e., do not (D)DoS or stress test our websites and APIs.
  • Do not test (on-premise) customer environments without our customer's consent.
  • Do not disclose vulnerability details to the public before a mutually agreed upon time frame expires.
  • Do not use attacks on physical security or third-party applications, social engineering, distributed denial-of-service, or spam.
  • Provide sufficient information to reproduce the vulnerability so that we can resolve it as soon as possible.

What you can expect from us

  • We will respond to your report within 5 working days with our assessment of the report and an expected date for resolution.
  • We will treat your report confidentially and will not share your personal data with third parties without your permission unless this is necessary to comply with a legal obligation.
  • We strive to resolve the vulnerability as soon as possible. We will keep you informed of the progress in case of high or critical risk vulnerabilities.
  • Anonymous or pseudonymous reporting is possible. Note that this means we will not be able to provide you feedback or updates on your reported vulnerability.
  • In our communication we will give you credits for finding the vulnerability (unless you want to remain anonymous).
  • In exceptional cases we may choose to give you a small reward for your research, at our sole discretion. Whether we offer a reward and the form of the reward is determined case-by-case and depends on the diligence of your investigation, the quality of the report and the level of risk found. Typically, low or medium risk vulnerabilities will not qualify.
  • If we are unable to resolve the vulnerability, we may bring in a neutral third party (such as a CERT, or the relevant regulator) to assist in determining how best to handle the vulnerability.

How to submit a vulnerability

To submit a vulnerability report to Roseman Labs’s Security Team, please email security <at sign> rosemanlabs <dot> com.

The use of a well-written report is appreciated. A sample report form can be found here.

Limitations

In general, Roseman Labs does not respond to reports about trivial vulnerabilities or bugs that cannot be exploited. We make a distinction between public, low-impact environments and our customer environments.

Public website and support center

The following is a non-exhaustive list of known vulnerabilities and accepted risks that fall outside the scope of this policy:

  • HTTP 404 codes/pages, or other HTTP non-200 codes/pages, and content spoofing or text injecting on these pages
  • Version banner disclosure and fingerprinting on common/public services
  • Output of automated scans without proof of exploitability. Examples: nmap scan results, etc.
  • Public files or directories with insensitive information (e.g., robots.txt)
  • Clickjacking and problems that can only be exploited via clickjacking
  • No secure/HTTP-only flags on insensitive cookies
  • OPTIONS HTTP method enabled
  • Anything related to HTTP security headers, for example:
    • Strict-Transport-Security
    • X-Frame-Options
    • X-XSS-Protection
    • X-Content-Type-Options
    • Content-Security-Policy
  • Subresource integrity (SRI)
  • Tabnabbing
  • TLS/SSL configuration issues
    • SSL Forward secrecy disabled
    • Weak/unsafe cipher suites
  • Issues with SPF, DKIM or DMARC
  • Host header injection
  • Reports of outdated versions of any software without a proof of concept of a working exploit
  • Information exposure in metadata
Our product, customer environments and any other items in scope

No limitations are currently in place for these scopes. All issues can be reported.

Versioning and credits

This document has version 2.1, dated 13 August 2024. The policy is based on examples such as responsibledisclosure.nl and the RD policies of SURFnet and the KNAW.