Pigment Vulnerability Disclosure Policy

Introduction

This policy describes the scope and conditions under which Pigment deems security research on its properties as acceptable, how to submit us vulnerability reports or findings, and the terms of our responsible disclosure process.

Authorization

If you make a good faith effort to comply with this policy during your security research, we will consider your research to be authorized, we will work with you to understand and resolve the issue quickly, and Pigment commits not to engage in litigation pertaining to  your research or findings. Should legal action be initiated by a third party against you for activities that were conducted in accordance with this policy, we will make this authorization known.

Guidelines

Under this policy, "research" means activities in which you:

• Notify us as soon as possible after you discover a real or potential security issue.
• Make every effort to avoid privacy violations, degradation of userexperience, disruption to production systems, and destruction ormanipulation of data.
• Refrain from accessing or retrieving data or acquire privilege any more than necessary to demonstrate the validity of the issue. Whenever possible, demonstrate the issue on non-production or non-sensitive data (ie: using a test account or a fake data) to avoid unnecessary exposure of production data.
• Do not disclose the issue to any other party unless explicitly authorized by Pigment in writing.
• Refrain from submitting reports pertaining to non qualifying vulnerabilities (see below), issues resulting from unapproved test methods (see below), issues not resulting from original research such as automated scanners or issue with negligible or inexistent business impact to Pigment. Pigment reserves the right to silently ignore any such report.
• Perform testing in a way that limits the pollution of our systems with testing records that may be visible to other users or used by Pigment. If the creation of such testing records are absolutely required for the performance of the test, delete them as soon as possible and include clear markers that identify them as testing records an helps selectively delete them.

Once you've established that a vulnerability exists or encounter any sensitive data (including Personally Identifiable Information, financial information,  proprietary information or trade secrets of any party), you must stop your test, notify us immediately, and not disclose this data to anyone else.

Note that some relevant findings may be fortuitous and not be the result of a research effort, in this case, our responsible disclosure conditions still apply.

Test methods

The following test methods are not authorized:

• Network denial of service (DoS or DDoS) tests or other tests that impair access to or damage a system or data
• Physical testing (e.g. office access, open doors, tailgating), social engineering (e.g. phishing, vishing), or any other non-technical vulnerability testing
• Spamming

Non Qualifying Vulnerabilities

Following vulnerabilities are out of scope:

• Reports from automated tools or scans
• HTML injection, Self-XSS without impact
• Clickjacking on pages with no sensitive actions
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability.
• Missing best practices in SSL/TLS configuration.
• Any activity that could lead to the disruption of our service (DoS).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Lack of rate limiting
• Missing best practices in Content Security Policy.
• Missing HttpOnly or Secure flags on cookies or use of LocalStorage for session tokens
• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
• Tabnabbing
• Open redirect - unless an additional security impact can be demonstrated
• Issues that require unlikely user interaction
• Information exposed in pigment.app/env.js are only public keys for trackers embedded on our frontend and do not contain any sensitive information.
• Unset Certificate Authority Authorization

Reporting a vulnerability

Please report any relevant finding using our VDP submission form.

What we would expect to be reported

In order to help us triage and prioritize submissions, we recommend that your reports:

• Describe the location the vulnerability was discovered and the potential impact of exploitation.
• Offer a detailed description of the steps needed to reproduce the vulnerability (proof of concept scripts or screenshots are helpful).
• Be in English

What you can expect from us

• Within 7 business days, we attempt to acknowledge that your report has been received.
• To the best of our ability, we will confirm the existence of the vulnerability to you and be as transparent as possible about what steps we are taking during the remediation process, including on issues or challenges that may delay resolution.
• We will maintain an open dialogue to discuss issues.
• If we are running a Bug Bounty program at the time of the submission, we will consider rewarding any qualifying issue as per the terms of the program.

Document change history