Clear
WEKA
23andMe VFX gartner reference architecture cloud workflow
WEKA
WEKA
Close

Vulnerability Discovery Procedure

Introduction

Security is our top priority and in the core of our values. We value the input of the security researchers community to help us maintain a high standard for the security and privacy of our products, systems and users.

This procedure sets out our definition of finding and reporting process of security and privacy vulnerabilities, as well as what you can expect from weka.io in return for your effort, skill, and time.

Ground Rules

To encourage vulnerability research and to avoid any confusion between legitimate research and malicious attack, we ask that you attempt, in good faith, to:
  • Play by the rules. This includes following this procedure and the guideline below;
  • Report any vulnerability you’ve discovered as soon as you can
  • Avoid violating the privacy of our users, interrupting our systems, destroying data
  • Handle any discovered vulnerabilities with confidentiality
  • Perform testing only on in-scope systems, and respect systems, activities and processes which are out-of-scope
  • 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 (POC);
  • Cease testing and submit a report immediately if you encounter any sensitive user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or any other personal information or any commercial sensitive information
  • You should only use accounts you own or account with explicit permission from the account holder
  • Do not engage in extortion.

Guidelines

We require that all security researchers to:
  • Act in good faith to avoid privacy violations, degradation of our services, disruption to production systems, and destruction or manipulation of data during security testing (including denial of service)
  • Once you’ve established that a vulnerability exists, or encountered any of the sensitive data outlined above, you must stop your test and notify us immediately
  • Perform vulnerability research only within the scope set out below
  • Be clear and concise, a short proof-of-concept link is invaluable
  • Keep information about any vulnerabilities you’ve discovered confidential between us until we have had 60 days to resolve the issue or informed you on the vulnerability status.
If you follow these guidelines when reporting a vulnerability to us, we commit to:
  • Not pursue or support any legal action related to your research;
  • Work with you to understand and resolve the issue quickly (including an initial confirmation of your report within 48 hours of the vulnerability submission);
  • Recognize your contribution on our Leader board, if you are the first to report the vulnerability and we make a code or configuration change based on the issue.

Expectations

When working with weka.io you can expect us to:
  • Work with you to understand and validate your report, including a timely initial response for your submission;
  • Work to remediate discovered vulnerabilities in a timely manner;
  • Recognize your contribution and effort to improving our security and privacy. If you are the first to report a unique vulnerability, and your report triggers a code or configuration change.

How to report a security vulnerability?

If you believe you’ve found a security or privacy vulnerability in one of our products or platforms please send it by emailing securityvulnerability@weka.io mentioning “Vulnerability Disclosure” in the subject. Please include the following details with your report:
  • Description of the location and potential impact of the vulnerability; and
  • A detailed description of the steps required to reproduce the vulnerability (POC, scripts, screenshots, and compressed screen captures are all helpful); and
  • Your name or a link for recognition in our Hall of Fame.

Scope

In Scope
https://*.weka.io

In-Scope Vulnerabilities

The vulnerabilities listed here are explicitly qualified for our vulnerability security and privacy program. Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Authentication or Authorization Flaws
  • Server-Side Request Forgery (SSRF)
  • Server-Side Template Injection (SSTI)
  • SQL injection (SQLI)
  • XML External Entity (XXE)
  • Remote Code Execution (RCE)
  • Local or Remote File Inclusions

While this list represents our primary focus for security research, we are interested in reports for all of our software and dependencies especially if it impacts sensitive user data.
This can include any open source libraries, software, or third-party components.

Outside Scope

The following test types are excluded from the scope:
  • Network denial of service (DoS or DDoS) tests.
  • Physical testing (e.g. office access, open doors, tailgating), social engineering (e.g. phishing, vishing), or any other non-technical vulnerability testing.
  • Findings from applications or systems not listed in the ‘Scope’ section
  • Findings derived primarily from social engineering (e.g. phishing, vishing)
  • UI and UX bugs and spelling mistakes

Things we do not want to receive:

  • Personally identifiable information (PII)
  • Confidential information from third-parties
  • Credit card holder data

Compliance

If you comply with this procedure during your security research and do not compromise the security of our systems, or the safety or privacy of our users, we will work with you to understand and resolve the issue quickly, and will not initiate or recommend legal action related to your research.