Vulnerability Disclosure Policy

The Vulnerability Disclosure Program (VDP) is an experimental program aiming to improve Netreo’s security through responsible testing and submission of previously unknown vulnerabilities. The VDP creates clear guidelines for eligible participants to conduct cyber security research on Netreo systems and applications.


Please adhere to the following guidelines in order to be eligible for recognition under this disclosure program:

  • Do not permanently modify or delete Netreo – hosted data.
  • Do not intentionally access non-public Netreo data anymore than is necessary to demonstrate the vulnerability.
  • Do not DDoS or otherwise disrupt, interrupt or degrade our internal or external services.
  • Do not share confidential information obtained from Netreo, including but not limited to member or donor payment information, with any third party.
  • Do not engage in social engineering, as it is out of scope. Do not send phishing emails to, or use other social engineering techniques against, anyone, including Netreo staff, members, vendors, or partners.

In addition, please allow Netreo at least 90 days to fix the vulnerability before publicly discussing or blogging about it. Netreo believes that security researchers have the right to report their research and that disclosure is highly beneficial, and understands that it is a highly subjective question of when and how to hold back details to mitigate the risk that vulnerability information will be misused. If you believe that earlier disclosure is necessary, please let us know so that we can begin a conversation.


Just as important as discovering security flaws is reporting the findings so that users can protect themselves and vendors can repair their products. Public disclosure of security information enables informed consumer choice and inspires vendors to be truthful about flaws, repair vulnerabilities, and build more secure products. Disclosure and peer review advances the state of the art in security. Researchers can figure out where new technologies need to be developed, and the information can help policymakers understand where problems tend to occur. On the other hand, vulnerability information can give attackers who were not otherwise sophisticated enough to find the problem on their own the very information they need to exploit a security hole in a computer or system and cause harm. Therefore we ask that you privately report the vulnerability to Netreo before public disclosure. If you do not want to be publicly thanked on our Netreo Security Hall of Fame page (or elsewhere), please let us know that you want your submission to be confidential in your report email.  We are also happy to accept anonymous vulnerability reports, but of course, we can’t send you our thanks if you report a vulnerability anonymously. We will make every effort to respond to valid reports within seven business days. The validity of a vulnerability will be judged at the sole discretion of Netreo. To ensure that your observations are properly reported you shall use only approved channels, namely, you should report discovered vulnerability via email to [email protected]. The validity and severity of a vulnerability will be judged at the sole discretion of Netreo.


  • *.netreo.com
  • *.stackify.com


We accept only manual or semi-manual tests. All findings coming from automated tools or scripts will be considered out of scope. Furthermore, all issues without clearly identified security impact, missing security headers, or descriptive error messages will be considered out of scope.

These items also are considered to be out of scope:

  • Attacks designed or likely to degrade, deny, or adversely impact services or user experience (e.g., Denial of Service, Distributed Denial of Service, Brute Force, Password Spraying, Spam…).
  • Attacks designed or likely to destroy, corrupt, make unreadable (or attempts therein) data or information that does not belong to you.
  • Intentionally accessing data or information that does not belong to you beyond the minimum viable access necessary to demonstrate the vulnerability.
  • Performing physical, social engineering, or electronic attacks against our personnel, offices, wireless networks, or property.
  • Security issues in third-party applications, services, or dependencies that integrate within the products or infrastructure that do not have demonstrable proof of concept for the vulnerability (e.g., libraries, SAAS services).
  • Security issues or vulnerabilities created or introduced by the reporter (e.g., modifying a library we rely on to include a vulnerability for the sole purpose of receiving a recognition).
  • Attacks performed on any systems not explicitly mentioned as authorized and in-scope.
  • Reports of missing “best practices” or other guidelines which do not indicate a security issue.
  • Attacks related to email servers, email protocols, email security (e.g., SPF, DMARC, DKIM), or email spam.
  • Missing cookie flags on non-sensitive cookies.
  • Reports of insecure SSL/TLS ciphers (unless accompanied by working proof of concept).
  • Reports of how you can learn whether a given client can authenticate to a product or service.
  • Reports of mappings between code names and client names.
  • Reports of simple IP or port scanning.
  • Missing HTTP headers (e.g. lack of HSTS).
  • Email security best practices or controls (e.g. SPF, DKIM, DMARC).
  • Software or infrastructure bannering, fingerprinting, or reconnaissance with no proven vulnerability.
  • Clickjacking or self-XSS reports.
  • Reports of publicly resolvable or accessible DNS records for internal hosts or infrastructure.
  • Domain-based phishing, typosquatting, punycodes, bitflips, or other techniques.
  • Violating any laws or breaching any agreements (or any reports of the same).


The following classes of vulnerabilities are of particular interest to us, and are eligible for attribution upon review:

  • Remote Code Execution (RCE)
  • SQL injection
  • XML External Entity Injection (XXE)
  • Authorization bypass/escalation
  • Sensitive information leaks
  • Cross-site scripting (XSS)
  • Cross-site request forgery (CSRF)
  • Business logic Vulnerabilities (with Impact)

Hall of fame

We thank you and appreciate your efforts in making Netreo more secure. We would like to thank the following individuals who have helped improve the security of our products.

Ready to get started? Get in touch or schedule a demo.